Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wed, 22 Jun 2005 14:25:01 -0400

Well, I'm open to suggestions as to what forumulation we want for these allocation decisions.

I could replace all occurances of "IETF Standards Action modified by [RFC 4020]" in the new draft with "the DNS Special Allocation policy" and then add a section defining that policy as

"1. IETF Standards Action or
 2. Approval as an an Experimental Protocol or
 3. As provided in RFC 4020, or its successor, for Early Allocation except that the crieria in Section 2 of RFC 4020 are replaced by the following:
    3.a: The format, semantics, processing, and other rules related to
         handling the protocol entities defined by the code points
         (henceforth called "specifications") must be adequately described
         in an Internet draft that is intended to become Standards Track or
         Expeirmental.
    3.b: There is sufficient interest in early (pre-RFC) implementation and
         deployment in the community as determined by working group
         consensus."

The above is just off the top of my head and could be made tighter or looser. Particularly the stability criterion in RFC 4020 could be added.

It seems to me there will always be tension between the idea that unstable usage/experimentation should use values from the private usage range so avoid using up regular numbers for things that may never be deployed and the idea that such things may stabilize and become popular resulting in deployment with a private usage value that might conflict with other private usage, etc. Given how many type codes are available, I think wasting a few on experiments that end up going nowhere isn't that much of a problem. So I don't see the need for added a stability criterion to item 3 above.

Thanks,
Donald

-----Original Message-----
From: william(at)elan.net [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 11:56 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt

On Tue, 21 Jun 2005, Eastlake III Donald-LDE008 wrote:

> Hi,
>
> I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now 
> in the ID directories.
>
> It continues to have about half the RR Type Code and CALSS space 
> allocated by "Specification Required" but most of the instances of "IETF 
> Consensus" and "IETF Standards Action" have been changed to "IETF 
> Standards Action modified by [RFC 4020]".

http://www.faqs.org/rfcs/rfc4020.html

| 2.  Conditions for Early Allocation
|
|   The following conditions must hold before a request may be made for
|   early allocation of code points:
|
|   a) The code points must be from a space designated as "Standards
|      Action", amended by IESG approval to permit Early Allocation.
|
|   b) The format, semantics, processing, and other rules related to
|      handling the protocol entities defined by the code points
|      (henceforth called "specifications") must be adequately described
|      in an Internet draft that is proposed as Standards Track.
|
|   c) The specifications of these code points must be stable; i.e., if
|      there is a change, implementations based on the earlier and later
|      specifications must be seamlessly interoperable.
|
|   d) There is sufficient interest in early (pre-RFC) implementation and
|      deployment in the community.
|
|   If conditions (a) or (b) are not met, then the processes in this memo
|   do not apply.

Unless I'm mistaken this would not allow allocation of RR codes for
experimental track drafts (it specifically says "Standard Track").

"c" and "d" may also be problematic for those who want to experiment
with new RR types.

So I do not believe just referencing RFC4020 will adequately address
need for easy procedure of getting new RR types assigned. That is not
to say that I think referencing RFC4020 for Standard Track documents
is bad, just that we still need separate procedure for provisional 
allocation of RR types for experimental purposes.

-- 
William Leibzon
Elan Networks
[email-masked]

--
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: Edward Lewis <[email-masked]>
Date: Wed, 22 Jun 2005 14:32:19 -0400

Thanks for starting this...I'm just busy at the moment.  If I had 
time at the moment, I'd certainly be contributing.

At 14:25 -0400 6/22/05, Eastlake III Donald-LDE008 wrote:
>I could replace all occurances of "IETF Standards Action modified by 
>[RFC 4020]" in the new draft with "the DNS Special Allocation 
>policy" and then add a section defining that policy as
>
>  3. As provided in RFC 4020, or its successor, for Early Allocation 
>except that the crieria in Section 2 of RFC 4020 are replaced by the 
>following:
>The above is just off the top of my head and could be made tighter 
>or looser. Particularly the stability criterion in RFC 4020 could be 
>added.
>
>It seems to me there will always be tension between the idea that 
>unstable usage/experimentation should use values from the private 
>usage range so avoid using up regular numbers for things that may 
>never be deployed and the idea that such things may stabilize and 
>become popular resulting in deployment with a private usage value 
>that might conflict with other private usage, etc. Given how many 
>type codes are available, I think wasting a few on experiments that 
>end up going nowhere isn't that much of a problem. So I don't see 
>the need for added a stability criterion to item 3 above.
>
>Thanks,
>Donald
>
>
>
>
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 27 Jun 2005 09:59:44 +0200

On Wed, 22 Jun 2005 14:25:01 -0400

> Well, I'm open to suggestions as to what forumulation we want for these allocation decisions.

Thanks, Donald!

>          deployment in the community as determined by working group

I like this line of thought. 

One detail in 3.b above; which working group? What if
the I-D is a personnal submission that falls between working group
cracks. 

I also think that you should add that the RR does not required special
processing for DNS servers and clients, name compression, is
case-insensitive, &c, &c. 

In another message you wrote:

> I'll revise the 2929bis draft to liberalize most assignments along
> the lines of my message below and to add a policy for the AFSDB RR
> subtype field.

Donald, will you be in Paris? I'd like to have this on the DNSEXT's
meeting's agenda.

--Olaf