Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 10:24:55 +0100 (CET)

> If I understand you correctly, the reason you are asking for this text
> is is to help assess the impact of the unknown-RRs specification on
> implementations that currently exist, or that may exist at the time of
> publication of unknown-rrs as an RFC.  That is a reasonable concern,
> but it is a meta-concern; it should be part of the current discussion
> about the specification, not part of the specification itself.

You at least understand my concern.

I don't understand why you don't agree with it.
The IETF produces documentation that try to be clear enough so that folks
can (with reasonable probability) produce interoperable implementations
from the specification. 
If a specification changes some other specification it makes a lot of
sense to make the change clear enough so that an implementor can
understand the change.

But when I asked you about the change you reviewed the specifications
and said that there is no change to existing RRs.
I then suggested that the reason you said "change" was because you wanted
to change the practise used for defining future RRs.
You balked at that proposal - but perhaps it was just a wording detail ...

> Of course I don't allow future RR types to specify different DNSSEC
> canonicalization rules.  All I said was that I do not expect future
> definitions of RR types to *explicitly state* that they use the
> unknown-rrs canonicalization algorithm, just like existing definitions
> of RR types do not explicitly state that they are using the RFC2535
> algorithm.  In the absence of an explicit statement, the unknown-RRs
> specification will apply, just like RFC2535 applies today.

So the 3rd paragraph in section 7 changes the practise for future definitions
of RRs? They can not have downcasing of embedded domain names.

Then it makes sense to say that and not say "For all other RR types ...".
And it is useful to implementors to point out that no RRs that have
been defined after RFC 2931 and this RFC contain embedded domain names".
(There aren't any RR definitions in the IETF last call, IESG, RFC-editor
pipeline right now and if any appear I'll make sure they get this right.)

  Erik

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 21 Feb 2003 14:35:33 -0800 (PST)

> sense to make the change clear enough so that an implementor can

Of course, but I think the changes you suggested would make the
specification less clear, not clearer.

> You balked at that proposal - but perhaps it was just a wording detail ...

The intent of the draft is that the new canonicalization algorithm
will apply to all future RR types.  I don't think there is any
disagreement about that.  The disagreement seems to be about two other
issues:

1. The use of temporal terms such as "current", "future", or
"existing" in the text of the specification.  That would only cause
confusion since an RR type which we today consider a "future" type is
likely to be an "existing" type when an implementor reads the RFC some
time in the future.  An explicit listing of the RRs that use the old
algorithm and a statement that all others use the new algorithm is
unambiguous, whereas a reference to "future types" is not.

2. When you say the draft wants to "change the practice used for
defining future RRs", you seem to be assuming that the DNSSEC
canonicalization algorithm to be used for any given RR type is part of
the RR type definition itself.  That has not traditionally been the
case - no existing RR type definition contains any mention of
downcasing or other aspects DNSSEC canonicalization, and there is no
reason for future ones to contain such specific mention, either. The
erefore, section 7 does not change the "practice of defining new RRs";
it only changes a part of the DNSSEC specification.

Furthermore, saying that the draft "changes the practice used for
defining future RRs" could be incorrectly interpreted as meaning the
new canonicalization algorithm only begins to apply to a new RR type
once it gets defined, when in fact it will apply even *before* it is
defined, when it is still only an unallocated RR type number being
treated transparently by implementations.  Keep in mind that the
reason why this change is being made in the first place is to ensure
that new RR types are canonicalized identically by all implementations
even if they are treated as known types by some implementations and as
unknown types by others.

> pipeline right now and if any appear I'll make sure they get this right.)

Did you mean "after RFC2931 but before this RFC"?

If you can guarantee that no new RR types with embedded domain names
are published as RFCs before the publication of unknown-RRs as an RFC,
then I have no problem with including a statement to that effect.

Regarding the possibility of publishing new RR types with embedded
domain names before unknown-RRs and making sure they "get it right",
that's much more problematic.  It would mean that these new RR type
definitions would not only have to explicitly mention DNSSEC
canonicalization (unlike previous RR type definitions), but they would
also have to contain a copy of the text from section 7 defining the
new canonicalization algorithm, and they would have to update RFC2535.
Also, I'm not sure what the text you want added to the unknown-RRs RFC
would say in that case - clearly it could not say "no RR types defined
at the time of the publication of this RFC use the new
canonicalization rules" nor "no RR types defined between RFC2931 and
this RFC have embedded domain names", since neither statement would be
true.
-- 
Andreas Gustafsson, [email-masked]