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

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:15 +0100 (CET)

> >    Note that after RFC 2931 there has been no RR types defined which have
> >    an embedded domain name.
> 
> This is exactly the kind of statement regarding "defined RRs" I have
> already repeatedly objected to adding.  It is true today, but will
> become false as soon as additional RR types with embedded domain names
> are defined, and would cause nothing but confusion to an implementor
> reading it ten years from no.  Such a statement does not belong in an
> archival document.

Please suggest alternate text that captures the fact that this section
doesn't change any RR that is currently issued in an RFC and that the intent
is that no future RRs with embedded domain names have this behavior.

> >    It is expected that future definitions of
> >    RR types will explicitly state that there is no downcasing of embedded
> >    domain names as part of DNSSEC canonicalization.
> 
> That is not my expectation.  There is a precedent for explicit
> statements regarding the applicability of *compression*, but that is
> only because RFC1035 was so ambiguous about where compression was
> allowed that it had to be specified in the individual RR type
> definitions (and even then some RR definitions interpreted RFC1035
> differently from others).  In the case of DNSSEC canonicalization, I
> hope the specification will be complete and unambiguous so that we
> don't have to resort to that kind of workaround.

I don't understand.
I thought you wanted to specify rules to make unmodified servers/caches
be able to handle new RR types. How can you do that if you allow
future RR types to specify different DNSSEC canonicalization rules?

  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: Thu, 20 Feb 2003 19:41:51 -0800 (PST)

Erik Nordmark writes:
> doesn't change any RR that is currently issued in an RFC

I still think adding text to that effect is a bad idea, regardless of
wording.

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.

> future RR types to specify different DNSSEC canonicalization rules?

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