Subject: Re: DNSEXT WGLC: RFC2929bis

From: Peter Koch <[email-masked]>
Date: Wed, 19 Jul 2006 20:26:09 +0200

On Wed, Jul 19, 2006 at 02:02:24PM -0400, Ólafur Guðmundsson /DNSEXT co-chair wrote:

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

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

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: "Scott Rose" <[email-masked]>
Date: Wed, 19 Jul 2006 14:33:31 -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:
> 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.
>

 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]