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

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Tue, 21 Jun 2005 23:17:35 -0400

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

What do people think about making this a WG draft and possibly putting it through to enable the early allocation provisions of RFC 4020, particularly for Type Codes?

Thanks,
Donald
 =========================================================
 Donald E. Eastlake III       [email-masked]
 Motorola Laboratories              +1-508-786-7554 (work)
 111 Locke Drive                    +1-508-634-2066 (home)
 Marlboro, MA 01752 USA

--
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: "william(at)elan.net" <[email-masked]>
Date: Tue, 21 Jun 2005 20:56:15 -0700 (PDT)

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

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