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

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

> Yes.  RFC2065 explicitly allowed compression of names in SIG and NXT
> records, and this is no longer allowed per the unknown-RRs draft.

But this isn't consistent with draft-ietf-dnsext-dnssec-records-02.txt
which allows compression of SIG and NXT.

Seems like the WG needs to figure out whether they want to allow or prohibit
compression in SIG and NXT. 
And the WG might also want to figure out how
to avoid having the AD be the only one that reads the documents for
consistency :-)/2

> As for "perhaps others", I could find one other case where an RR
> specification explicitly allows compression: RFC2163 allows
> compression in the PX records, which appears to be in direct conflict
> with the RFC1035 statement that "Pointers can only be used for
> occurances of a domain name where the format is not class specific"
> since RFC2163 restricts the PX record to the IN class.
> 
> > If so the document should explicitly state this
> > and also add an "updates RFC 2535" up front.
> 
> I will add this and "updates RFC2163".

It should also have a paragraph which says exactly what it is updating
e.g. "RFC 2163 allows compression of the xyz field in PX records which
is no longer permitted according to this document ..."

> >    For all other RR types, the canonical form is hereby changed such
> >    that no downcasing of embedded domain names takes place.  The owner
> >    name is always set to lower case according to the DNS rules for
> >    character comparisons, regardless of the RR type.
> > 
> > It would be useful to explicitly list the RR types to which this change
> > applies.
> 
> That's not really practical since there is more than 65000 of them.
> While you could attempt to list the currently allocated post-RFC2915
> types, such a list would soon become inaccurate as additional types
> are allocated.

I wasn't asking about listing all current and potential future RRs.
I'm asking about a specification of what "hereby changed" actually
means for an implementor. Being able to list the RRs which are subject
to this change seems like a requirement. If you don't have the list
how can we guage the impact of this change?

> > Nits (by themselves not necessitating an updated I-D at this point in time):
> > The references should be split into normative and non-normative.
> 
> Will do.  It appears there have been quite a number of changes to the
> I-D requirements since the initial publication of the draft...

Yep. This particular one about separating references is from
the rfc-editor.

> > A boilerplate IPR section should be added.
> 
> Can you please point me to a document describing this requirement and
> the form of the required boilerplate?

http://www.ietf.org/ID-nits.html 1.2 says:
# IPR notices
From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D)

  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: Rob Austein <[email-masked]>
Date: Mon, 10 Feb 2003 13:18:56 -0500

Presumably we could turn the question around and specify the list of
RR types for which compression of DNS names in the RDATA -is- allowed.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 10 Feb 2003 11:21:18 -0800 (PST)

> RR types for which compression of DNS names in the RDATA -is- allowed.

Erik Nordmark is not asking about compression (section 4), he is
asking about DNSSEC canonicalization (section 7).  The lists of RRs
pertaining by these two issues (and their complements) are different.
See the discussion on namedroppers on October 25, 2002.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 11 Feb 2003 13:14:21 -0800 (PST)

> which allows compression of SIG and NXT.

Right.  draft-ietf-dnsext-dnssec-records needs to be fixed.

> how can we guage the impact of this change?

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.

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.
-- 
Andreas Gustafsson, [email-masked]