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

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Feb 2003 22:50:12 +0100 (CET)

> An implementor can construct this list for any given implementation by
> finding all RR types the implementation knows about and determining
> which ones were defined in an RFC later than RFC2931 (the "2915" in
> the quoted text above is a typo and should be "2931" as in the draft).
> This will always yield a complete and up-to-date list, unlike any
> fixed list that could be embedded in the draft.

Future RRs will presumably not have this issue - they will be done right
from the start.

I'm specifically concerned about the statement that unknown-rrs
changes something without being specific about what defined RRs it
is changing.

> Assuming the list of RR type assignments at
> <http://www.iana.org/assignments/dns-parameters> is complete, there is
> currently exactly one post-RFC2931 RR type, the APL record defined in
> RFC3123, but the APL RR does not contain any embedded domain names and
> is therefore unaffected by the canonicalization change.  In other
> words, the impact of this change on existing implementations is zero.

Then it makes sense stating this in unknown-rrs as it *creating a new
rule* that downcasing canocalization of embedded domain names is not performed
for newly created RR types (and perhaps add the list of the defined
RR types that have embedded domain names where downcasing canonicalization 
is performed), instead of as current stating as a *change* to any existing
RRs. That would be much clearer.
(And the stuff in parenthesis could be something which could be deferred to
the new dnssec drafts - being explicit about which RRs have their embedded 
domain names downcased).

  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: Tue, 11 Feb 2003 18:48:15 -0800 (PST)

> changes something without being specific about what defined RRs it

And I'm concerned about the use of terms like "defined RRs" and
"existing RRs" since their meaning changes over time.  The draft
already precisely specifies which RRs use which canonicalization rule;
talking about "defined RRs" would be irrelevant and only confuse the
matter, especially for someone reading the RFC ten years from now.

> for newly created RR types

How is this different from what the draft says now?  Could you suggest
a wording which better captures "creating a new rule"?

> (and perhaps add the list of the defined
> is performed),

There is already such a list:

  "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB,
  MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT,
  NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according
  to the DNS rules for character comparisons"

> instead of as current stating as a *change* to any existing RRs.

I'm still not sure how you get that impression.  The draft does not
talk about a "changing RRs", it talks about "changing the canonical
form".  Also, it does not talk about "existing RRs", but of "RR types
defined in RFC2931 or earlier" and "other RR types".  Would changing
the text "all other RR types" into "post-RFC2931 RR types" make it
clearer which RRs the new canonical form applies to?
-- 
Andreas Gustafsson, [email-masked]