Subject: Re: DNSEXT WGLC: Unknown types support

From: Erik Nordmark <[email-masked]>
Date: Mon, 9 Sep 2002 22:43:56 +0200 (CEST)

> The language of the unknown-rrs draft is no more inexact than that of
> STD0013, or of other RFCs that reference the case insensitivity, e.g.,
> RFC2535.  You have a valid criticism of STD0013, but turning that into
> a criticism of the unknown-rrs draft is inappropriate and unfair.

Don't worry - from now on I'll be perfectly fair on this point.
(And I've noted but not yet told folks that the same issue
appears in at least one of draft-ietf-dnsext-dnssec-*).

Since this is the first document with this language that is likely to
come to IESG since we started the IDN discussions I think it makes sense
to do it right. Of course, others are welcome to help draft the appropriate
text to use for "case insensitive" and "lower case" - it would be good
to use the same wording in the future specifications.

> There are several other aspects of DNS classes that are poorly
> specified or insufficiently explained in STD0013 and that would be of
> interest to those contemplating the introduction new classes, but
> those are unrelated to the questions of known versus unknown RDATA
> formats that this draft is trying to address, and they apply equally
> to known and unknown classes.  Those would best be addressed in a
> separate draft (named "classes", not "unknown-classes").

So the document at hand is about "uknown RDATA formats" independently
of where they appear? Perhaps this should be made explicit somewhere 
(title/abstract/intro somewhere?)

  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: Mon, 9 Sep 2002 14:17:34 -0700 (PDT)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> appears in at least one of draft-ietf-dnsext-dnssec-*).

As Rob Austein said, this belongs in a separate draft of
clarifications to STD0013.  We shouldn't have to duplicate the
clarifictions in every draft that happens to mention case
insensitivity.

> of where they appear?

I'm not sure I understand your question - would you care to elaborate?
-- 
Andreas Gustafsson, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Sep 2002 15:00:15 +0700

Date:        Mon, 9 Sep 2002 14:17:34 -0700 (PDT)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | As Rob Austein said, this belongs in a separate draft of
  | clarifications to STD0013.  We shouldn't have to duplicate the
  | clarifictions in every draft that happens to mention case
  | insensitivity.

No, we shouldn't.   But nor should we be writing language that is
known now to be incomplete, or ambiguous.

New drafts don't need to "fix" 1034/5 (except one written just for the
purpose), but it should be possible to read them, and make sense of them,
without the clarifications doc needing to also update this new one.

If a new draft wants to just say "according to the DNS rules for
character comparisons", that's fine I think - the doc isn't attempting
to specify the rules.

But if it says "lower case compare equal to upper case" or "ignore case"
then a clarifications doc would have to fix this one, as well as the older
ones, and since we know now that it needs fixing, that's plain dumb.   Make
this doc be correct as it stands (as best we know what correct is anyway).

Or, if you like, pretend that there is a clarifications doc already existing
which has already fixed this problem for the older docs - and write this
one so that it makes sense in that environment (which would be one where
just saying "ignore case when comparing labels" is simply inadequate).

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 10:17:34 +0200 (CEST)

> clarifictions in every draft that happens to mention case

If folks agree then I guess the co-chairs need to make sure that draft gets 
written so that it is available when unknown-rrs or the new DNSSEC documents
(whichever comes first) are ready to be approved by the IESG.

> I'm not sure I understand your question - would you care to elaborate?

You seem to say that unknown-rrs is about the cases where the RDATA format
is unknown. Thus the fact that the RR type code is unknown is not
the central part of the draft; both unknown RRs and unknown classes can result
in an unknown RDATA format.

If that's true, then perhaps this should be more clear in introductory
material in the document and not just be mentioned in passing down in the
document.

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 10 Sep 2002 10:58:59 -0700 (PDT)

> (whichever comes first) are ready to be approved by the IESG.

I would like to avoid delaying the unknown-rrs draft and the new
DNSSEC documents by introducing a dependency on a new draft.  Adding
the text "according to the DNS rules for character comparisons" as
Robert Elz suggested and publishing the case insensitivity
clarifications separately should be sufficient.

> in an unknown RDATA format.

There may be some confusion regarding the definition of an "RR type"
(as opposed to a "type code").  For example, consider "IN A" and
"CH A": are they two distinct RR types, or one RR type with two class
specific RDATA formats?

The draft uses the former definition, which is consistent with
existing RFCs that define class specific RR types - for example,
RFC2874 claims to define the A6 RR type which specific to the IN
class, not to define the class IN RDATA format for the A6 type.
-- 
Andreas Gustafsson, [email-masked]