RE: DNSEXT WGLC: RFC2929bis

["Eastlake III Donald-LDE008" <[e-mail]>]

Hi,

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Thierry Moreau
Sent: Tuesday, July 25, 2006 5:38 PM
To: [e-mail]
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).
> 
> The URL for the document is:
> 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.

@@@ 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

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

Tel.: [phone]
Fax:  [phone]

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


--
to unsubscribe send a message to [e-mail] with the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>