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

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 16:50:39 +0100 (CET)

> > 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.)
> 
> Did you mean "after RFC2931 but before this RFC"?

Yes.

Upleveling. 
Since you seem to understand my concern but disagree with every textual
proposal I suggest to try to make things more clear, why
don't you suggest some clarifications to the text that make things
more clear?

  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, 25 Feb 2003 17:37:00 -0800 (PST)

> don't you suggest some clarifications to the text that make things

Since this perceived lack of clarity seems to be related to the use of
the time of publication of RFC2931 as a flag day, would you find it
clearer if the time of publication of unknown-RRs itself as an RFC
were used instead?

Here is an updated and expanded section 7 with this change as well as
some added rationale and other clarifications.  Using this text will
of course require that no new RR types with embedded domain names are
defined before this is published as an RFC.  Also, the RFC editor
needs to replace "TBD" with the actual RFC number of the unknown-rrs
RFC itself.

   7. DNSSEC Canonical Form and Ordering

   DNSSEC defines a canonical form and ordering for RRs [RFC2535, section
   8.1].  In that canonical form, domain names embedded in the RDATA are
   converted to lower case.

   The downcasing is necessary to ensure the correctness of DNSSEC
   signatures when case distinctions in domain names are lost due to
   compression, but since it requires knowledge of the presence and
   position of embedded domain names, it cannot be applied to unknown
   types.

   To ensure continued consistency of the canonical form of RR types
   where compression is allowed, and for continued interoperability
   with existing implementations that already implement the RFC2535
   canonical form and apply it to their known RR types, the canonical
   form remains unchanged for all RR types whose whose initial
   publication as an RFC was prior to the initial publication of this
   specification as an RFC (RFC TBD).

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types 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.

   This document specifies that for all other RR types (whether
   treated as unknown types or treated as known types according to an
   RR type definition RFC more recent than than RFC TBD), the
   canonical form is such that no downcasing of embedded domain names
   takes place, and otherwise identical to the canonical form
   specified in RFC2535 section 8.1.

   Note that the owner name is always set to lower case according to the
   DNS rules for character comparisons, regardless of the RR type.

   The DNSSEC canonical RR ordering is as specified in RFC2535 section
   8.3, where the octet sequence is the canonical form as revised by this
   specification.

Would this text be acceptable?
-- 
Andreas Gustafsson, [email-masked]