Subject: Re: [dnsext] WGLC: RFC6195bis IANA guidance

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Jul 2012 07:55:50 -0700

On Jun 11, 2012, at 10:43 AM, Olafur Gudmundsson wrote:

> This message starts a 2 week WGLC for RFC6195bis ending at midnight UTZ June 28'th 2012.
> http://tools.ietf.org/html/draft-ietf-dnsext-rfc6195bis-02
> 
> This document addresses known flaws in the RFC6195 (see appendix A).
> 
> Please review the document and post a note that you have reviewed the document we need a minimum of 5 reviewers.

I apologize for getting to this so late, but I also note that I might be just the fifth reviewer... The document is mostly fine.

However, I have one major issue with it: it's not clear what IANA is supposed to do with it. There is a *lot* of text in this document that is repetition of the RFCs, as well as some important historical notes that are not currently in RFCs or in the IANA registry. When this document is finished, is IANA supposed to change each sub-registry to include the text from the relevant section of this RFC? If not, why is that text in this "IANA Considerations" document? I can see a few ways forward here:

a) Explicitly tell IANA what additional material from this document should go in each sub-registry

b) Tell IANA to put at the top of the registry something like "In order to understand this registry, you need to understand the underlying RFCs and the history of the registries. In order to do that, you should read BCP XXX" with a link to this document

My preference is the latter, but people might want the former to make it harder for readers of the registry to miss the relevant stuff. There might be other ideas as well.

Two other issues that should be clarified:

- Can anyone subscribe to the [email-masked] mailing list to see the applications come in? It is *not* listed on the page at <http://www.ietf.org/list/nonwg.html>.

- At the end of 2.2, what does "as modified by [RFC4020]" mean? Is is supposed to be "as described in [RFC4020]"?

--Paul Hoffman
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Dick Franks <[email-masked]>
Date: Thu, 5 Jul 2012 23:06:05 +0100

Donald,

My apologies for late response.

On 22 June 2012 19:10, Donald Eastlake <[email-masked]> wrote:
...
>> [3.1 paragraph 4]
>> and [3.2 paragraph 4]
>>
>> Regexes:
>>
>>                         [A-Z][A-Z0-9\-]*[A-Z0-9]
>>
>>                        (TYPE|CLASS)(0|[1-9][0-9]*)
>>
>> could be simplified to:
>>
>>                         [A-Z][A-Z0-9]*
>>
>>                        (TYPE|CLASS)[0-9]*
>
> That's not simplification, that's change.
A simplification of the underlying production rule for RRTYPE mnemonics,
which inevitably flows through to the regex.

> I believe that internal hyphens should be allowed within RRTYPE and
> CLASS mnemonics. We do not know what future mnemonics or sets of
> mnemonics will be required. Better to remain more flexible here.

There appears to be no real-world requirement to do so. The justification for
flexibility would best be debated if/when some genuine need arises.

The collective decision of a multitude of worthy authors, over a span of more
than 25 years, has been to treat RRTYPE mnemonics as simple Algol/Fortran
style identifiers, even when some clearly had the opportunity to do otherwise.

The regex should be tightened to make explicit a de facto standard observed
by prominent members of the IETF engineering community.

The unmodified regex has the unintended and undesirable consequence that
it allows the IANA tail to wag the IETF dog.

> I have no problem with making the Regex 2 exclusion slightly stronger
> so going with your changed Regex 2 is fine with me.
+

--Dick

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 5 Jul 2012 18:36:44 -0400

Hi Paul,

> My preference is the latter, but people might want the former to make it harder for readers of the registry to miss the relevant stuff. There might be other ideas as well.

I also favor the latter.

> - Can anyone subscribe to the [email-masked] mailing list to see the applications come in? It is *not* listed on the page at <http://www.ietf.org/list/nonwg.html>.

I don't think anyone else can subscribe. IANA is required to monitor
that list and presumably whoever IANA wants are the subscribers.

> - At the end of 2.2, what does "as modified by [RFC4020]" mean? Is is supposed to be "as described in [RFC4020]"?

The way I always thought of it, "Standards Action" is defined in
[RFC5226]. [RFC4020] ("Early IANA Allocation of Standards Track Code
Points") then modifies that definition to permit early allocation
under specific circumstances. The "as modified by [RFC4020]" is how
I've always written this. For example, it is how this is expressed in
RFC 6195 and its predecessor RFC 5395.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 5 Jul 2012 18:54:13 -0400

Hi Dick,

> which inevitably flows through to the regex.

OK, it is a simplification of the RegEx, but one I don't agree with.

> by prominent members of the IETF engineering community.

We appear to disagree and no one else has spoken on this. If this were
a brand new draft/standard, I'm not sure how this would be settled.
However, it is not. IANA Considerations for DNS has explicitly
permitted hyphens in these mnemonics since 2008 (and were silent on
this point before that) and a mnemonic with a hyphen was allocated
earlier and remains in the registry today. Under these circumstances,
I believe the RegEx should not be changed to prohibit hyphens.

> it allows the IANA tail to wag the IETF dog.

I don't understand that at all. The applicant normally selects the
mnemonic and, if the applicant doesn't, then the Expert does. IANA
does not.

Thanks,
Donald

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Jul 2012 19:45:47 -0400

I'm not speaking in any sort of chair "here's-the-rules" role, but I
am speaking with the background of what I've learned as a chair of
this WG over time.

> I believe the RegEx should not be changed to prohibit hyphens.

I completely agree with Donald's point here.  If we are going to make
a substantive change to the rules along these lines (and one
incompatible with existing registrations), the bar for adoption will
be _much_ higher than if we do not do that.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Chris Thompson <[email-masked]>
Date: 06 Jul 2012 19:56:16 +0100

>OK, it is a simplification of the RegEx, but one I don't agree with.

Regardless of the hyphen question in the first regexp, I think the
change to the second is probably desirable. I don't think RFC 3597
makes it totally unambiguous that unnecessary leading zeros are not
allowed after TYPE or CLASS, and it is sensible to protect parsers
that are sloppy in this respect.

Otherwise, one could argue that TYPE65536 ought to be allowed for
a new RR type mnemonic, because it clearly isn't meaningful as a
generic one.

This is all a bit reminiscent of the deprecation of all-digit TLDs.
Ought ".000" or ".256" to be allowed because they are would not
be part of the natural representation of IPv4 addresses? 

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 6 Jul 2012 15:33:11 -0400

Hi Chris,

> a new RR type mnemonic, because it clearly isn't meaningful as a

I agree and that change is actually already in the -03 version of the draft.

> be part of the natural representation of IPv4 addresses?

Not that relevant to our current discussion but it is my personal
opinion that all-numeric TLDs should be prohibited regardless of
length.

Thanks,
Donald