Subject: DNSEXT WGLC: RFC2929bis

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 19 Jul 2006 14:02:24 -0400

This message starts at 3 week last call for this document ending
on midnight August 10'th 2006 (Reykjavik time).

The URL for the document is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt

This document updates RFC2929 which defines how IANA handles registrations
affecting the DNS. This document attempts to liberalize and speed up the
process for getting new DNS RR types, as well as clarifying few things
from older RFC's.

RFC2929 is BCP 42 so this document will replace it as a BCP.

The document process rules in this group, require that at least
5 members of the working to state that they have read the document
and consensus support that it be published.
	
	Olafur

--
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: Peter Koch <[email-masked]>
Date: Wed, 19 Jul 2006 20:26:09 +0200

> and consensus support that it be published.

as agreed upon in Montreal I'd like to re-insert my comments expressed in
<http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.html>
into the WGLC. Modulo those I support this document.

-Peter

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 19 Jul 2006 14:33:31 -0400

> and consensus support that it be published.

 I have read the document and I support it going forward

Scott

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 25 Jul 2006 17:38:15 -0400

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt

Minor editorial: On section 3.1, sentence starting with "Thus far ...", 
missing reference to DLV and TA assignments.

My main concern with this document is the limited coverage of namespace 
management implied by sub-typing. The AFSDB sub-typing is covered in 
section 3.1.5. The same should apply to CERT sub-typing (see section 2.1 
in RFC4398), and perhaps others. In the case of SRV records (RFC2782), 
the alphanumeric sub-typing manespace is populated by reference to 
[STD2] "or locally".

For new RR type allocations, there is a potential pitfall with the 
following sub-typing dilemma:

if the RR type applicant requests an allocation for his very specific 
solution in an application area, he/she will face rejection from expert 
guideline 5 ("The requested RRTYPE would conflict with one under 
development within the IETF and the existence of more than one such type 
would harm interoperability.") or even 7 ("An excessive number of RRTYPE 
values is being requested when the purpose could be met with a smaller 
number.");

if the RR applicant acknowledges the need for multiple co-existing 
solutions (identified by sub-type) within a given application issue 
(indicated by the requested RR allocation), he/she faces the onus of 
defining namespace management for the sub-type, without guidelines.

I understand that this is perhaps an extension of the scope of the draft 
(but then why is section 3.1.5 present in the first place?). 
Nonetheless, I think the RR sub-typing guidelines would be useful for 
making the RR type application process more predictable and attractive.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 25 Jul 2006 23:15:11 -0400

Peter,

Thanks for these detailed and extensive comments.

See below at @@@

Donald Eastlake wrote:

> The last feedback I got from the working group on this draft was that it
> was in good shape except for the need for some specific guidelines for
> the designated RR type allocation expert. So this updated version has
> such guidelines in section 3.1.3. Hopefully this version, or perhaps -04

as one of those asking for such guidance (and apologies for failing to
send text), I am pretty much happy with what Donald came up in 3.1.3, just
modulo some nits.

3.1.3 first:

(nit) s/designed/Designated/
(nit) use consistent spelling of "RR TYPE" vs. "RRTYPE"

@@@ Right. There are also cases of "RR type". I would prefer to replace them all with RRTYPE.

>   and to consult with other experts as necessary. The Expert should
>   reject any RRTYPE allocation request which meets the following
>   criterion:

"which meets at least one of the following criteria" to emphasize these
items are ORed.

@@@ How about "which meets any of the following criteria" ?

>  4. The intended use of the proposed RRTYPE would cause problems with
>     existing DNS deployments.

add "or the DNS infrastructure" to cover cases like tree climbing.

@@@ I think that is already included but wouldn't mind adding it.

>  5. The requested RRTYPE would conflict with one under development
>     within the IETF and the existence of more than one such type would
>     harm interoperability.

rephrase /harm interoperability/ to /put interoperability at risk/ to
shift the burden of the proof on the requester.

@@@ The idea is to make it easier to get an RRTYPE. Given all the other criteria provided here to reject a request, I don't think this change is warranted.

The template in 3.1.2 I'd like to be amended

>       Does the proposed RR TYPE require special handling within the
>       DNS different from an Unknown RR TYPE or ignorable meta-TYPE?

so that a "no" would require some explanation or discussion.

@@@ The applicant has to provide detailed documentation anyway and I would imagine that in most cases the Designated Expert would look at it. This question is here more to remind the applicant of the requirement. I think it would be very hard to write a more detailed requirement here that the applicant couldn't answer by just cutting and pasting a wad of text from their documentation. What's the point?

The document doesn't say what an "ignorable" meta type (nit: consistent
spelling) is, other than

>  2. The RR for which a TYPE code is being requested is either (a) a
>     data TYPE which can be handled as an Unknown RR as described in
>     [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e.,
>     which it is safe to simply discard.

Would that encourage silence in response to a Meta Query?

@@@ Hummm, well, I guess I meant that the Meta TYPE could would be safe to simply discard if it appeared as Additional Information. It would probably be best to specify that it be prohibited to use it as an RRTYPE being queried for.

Also, if this is what makes 2929bis update 3597, could that be mentioned
explicitly?

@@@ RFC 3597 specifically refers to RFC 2929 for ranges of RRTYPES which can be Meta- or Q-TYPES. This is changed by 2929bis and I would be happy to mention that in the RRTYPEs section of the draft.

Other comments, some of which may apply to text that already appeared in
RFC 2929, but since this is an update attempt anyway:

o The introduction and 3.2 call the DNS a database, which it isn't. Slightly
  change that to data store, data repository or something close.

@@@ I think it is a database. It has limitations, but so do many databases.

o The Opcode list in 2.2 (and one could argue that such list doesn't
  really belong into the policy setting document in the first place)
  uses mixed case for codes of QUERY, IQUERY and STATUS with a reference
  to RFC 1035, where that uses all caps. Same for NOTIFY and UPDATE.
  Could be these names are either non-normative or case insensitive
  (as everything else in the DNS) but some authoritative words would be fine.

@@@ I'd like to keep the list but converting to all upper case for consistency is a good idea.

o Same applies to the error code list in 2.3, even more so since RFC 1035
  didn't even define a mnemonic for every code.

@@@ OK. Many of these are all upper case but I have no problem converting those in mixed case to upper case.

o ``Allocation'' and ``assignment'' are used synonymously throughout the draft.
  Suggest to use one term (assignment) only.

@@@ I'm not sure how important this is. Looks like "alloc*" occurs about 25 times and "assign*" about 36 time so "assignment" would be easier to change to. It could be that some parts would not read as well with that change.

o bottom of page 6: ``TTL is a four octet (32 bit) [bit] unsigned integer''

@@@ Yes, the extra bit should be deleted...

o page 11: QCLASS None, the case issue again

@@@ Do you maintain that all the CLASS names, including Hesiod and Chaos, should be all upper case?

o still page 11: strictly speaking 255 is for QCLASS=*, not "any" (in any
  case :-)

@@@ How about if it were to say "* (ANY)" ?

o 3.3 RR NAME Considerations
  this touches both label type and label content issues, so I'd suggest to
  rename the section to "Label Considerations" and make the split between
  label types (currently the 2nd paragraph) and label content.

@@@ OK, renaming the section is certainly reasonable and I could look at restructuring it.

o still 3.3

>   A somewhat out-of-date description of name allocation in the IN Class
>   is given in [RFC 1591].  Some information on reserved top level
>   domain names is in BCP 32 [RFC 2606].

  This is kinda level 9ish, but I don't think the WG or the IETF should
  make a statement, however fuzzy, on how outdated RFC 1591 is (2929 said
  "dated"). The main point here is that there is no IETF label registry,
  be that TLD labels or those further down the tree (although there are
  proposals to change the latter).

@@@ The statements are intended to be of some informational use. I think they are correct and don't see any problem leaving them.

o There are normative references to experimental RFCs (1183, 2673) that
  are probably really informative references.

@@@ Well, I've generally listed things which define RRTYPEs, opcodes, etc., that are listed in 2929bis, as Normative. I don't really care much but if these two are moved to Informative, seems like a lot of other normative references should be moved there. 

-Peter

@@@ Thanks,
@@@ Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Koch
Sent: Wednesday, July 19, 2006 2:26 PM
To: IETF DNSEXT WG
Subject: Re: DNSEXT WGLC: RFC2929bis

> 5 members of the working to state that they have read the document and 
> consensus support that it be published.

as agreed upon in Montreal I'd like to re-insert my comments expressed in <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.html>
into the WGLC. Modulo those I support this document.

-Peter

--
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: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 25 Jul 2006 23:33:07 -0400

Hi,

I find some of your comments just a bit cryptic but I'll try responding to them. See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thierry Moreau
Sent: Tuesday, July 25, 2006 5:38 PM
To: [email-masked]
Subject: Re: DNSEXT WGLC: RFC2929bis

Ólafur Guðmundsson /DNSEXT co-chair wrote:

> 
> This message starts at 3 week last call for this document ending on 
> midnight August 10'th 2006 (Reykjavik time).
> 

Minor editorial: On section 3.1, sentence starting with "Thus far ...", missing reference to DLV and TA assignments.

@@@ OK, I can add those. 

My main concern with this document is the limited coverage of namespace management implied by sub-typing. The AFSDB sub-typing is covered in section 3.1.5. The same should apply to CERT sub-typing (see section 2.1 in RFC4398), and perhaps others. In the case of SRV records (RFC2782), the alphanumeric sub-typing manespace is populated by reference to [STD2] "or locally".

@@@ "sub-typing" isn't covered at all as a topic in this draft. AFSDB sub-typing is covered because, and only because, IANA Considerations are not given for it anywhere else. CERT RR IANA Considerations are given in RFC 4398 and, as both RFC 2929 and draft 2929bis say, you should generally go to the RFC for the RR you are interested to find IANA Considerations within that RRTYPE.

For new RR type allocations, there is a potential pitfall with the following sub-typing dilemma:

if the RR type applicant requests an allocation for his very specific solution in an application area, he/she will face rejection from expert guideline 5 ("The requested RRTYPE would conflict with one under development within the IETF and the existence of more than one such type would harm interoperability.") or even 7 ("An excessive number of RRTYPE values is being requested when the purpose could be met with a smaller number.");

@@@ Just because an RRTYPE is in some application area, I don't see that it would necessarily conflict with one under development in the IETF and it is even less obvious that it would necessarily harm interoperability. As for rejection reason 7, that only is intended to apply if the particular applicant is applying for multiple RRTYPEs. I could clarify the wording of reason 7.

if the RR applicant acknowledges the need for multiple co-existing solutions (identified by sub-type) within a given application issue (indicated by the requested RR allocation), he/she faces the onus of defining namespace management for the sub-type, without guidelines.

@@@ ? If an existing RRTYPE provides for sub-typing, the RFC defining that RR should give the IANA Considerations for getting a sub-type allocated. The exception generally being any RR defined before IANA Considerations were required.

I understand that this is perhaps an extension of the scope of the draft (but then why is section 3.1.5 present in the first place?). 

@@@ As explained about, 3.1.5 is there only because AFSDB IANA Considerations are not given anywhere else.

Nonetheless, I think the RR sub-typing guidelines would be useful for making the RR type application process more predictable and attractive.

@@@ This document (2929bis) is not a document on sub-typing.

Regards,

@@@ Thanks,
@@@ Donald

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 26 Jul 2006 09:23:59 -0400

Eastlake III Donald-LDE008 wrote (in @@@ paragraphs):

> [...]

I accept your explanations, and as I reveiewed the draft and it is in 
good shape (despite my personal opinion that the RR applicant needs 
would be better server with an expanded scope), I am in favor of 
progressing the draft.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900