Subject: WG Last Call: DNS-IANA

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 03 Dec 1999 16:56:22 -0500

As agreed to in the DNSIND meeting in Washington, the  "IANA DNS" draft 
is ready for WG last call. The document was recently updated to reflect 
comments made to the authors since last version and at the meeting. .
This is WG last call ending December 16'th. 

The draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-iana-dns-03.txt

There are no known defects in this version of the document. Please send
comments to the list.

This document is to be published as an Informational RFC, if you disagree
with that please state your reasons against that in a message to 
namedroppers.

        Olafur

--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
[email-masked]  [email-masked]  Private: [email-masked]

---

From: Brian Wellington <[email-masked]>
Date: Tue, 7 Dec 1999 18:05:49 -0500 (EST)

> There are no known defects in this version of the document. Please send

2.3 RCODE Assignment

  - The TKEY draft also adds rcodes.
  - EDNS extended rcodes don't match TSIG/TKEY extended rcodes.
    EDNS0 rcode 16 is BADVERS, while TSIG/TKEY rcode 16 is BADSIG

3.1 RR TYPE IANA Considerations

  - TKEY is another Meta-TYPE

3.2 RR CLASS IANA Considerations

  - Should Class 0 be reserved?  It would be consistent with Type 0, and
    at least one draft (TKEY) recommends using 0 in the class field.

Everything else looks good...

Brian

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Dec 1999 10:11:42 -0500

>              Domain Name System (DNS) IANA Considerations
>              ------ ---- ------ ----- ---- --------------

I am particularly interested in this document because of an experience I
had in writing code to handle the ATMA RR type.  The ATMA RR (number 37 +/-
5; the web page is inaccessible as I write) is not defined in an IETF
document, it is defined in an ATM Forum document only.

I would like to see a requirement placed on the DNS parameters page to
include the mnemonic, numeric value, and a document reference, as the page
does now.  I'd like to see this stated 1) to make sure we don't lose this
information and 2) put some importance on the information so that it is
maintained up to date.  Although the information is there, it is not always
up to date.

(I am not leveling a criticism at IANA "for failing to do this [right]." I
think the problem is that this "requirement" has never been formalized.)

>     32768 - 65279
>   0x8000 - 0xFEFF - assigned based on non-Standards Track RFC
>          documentation.

Again with the ATMA situation, I would like to 1) see a better definition
of what "non-Standards Track RFC documentation" is, e.g., an article in
People magazine?

I'd suggest that the "assignment be based on IETF consensus and documented
in a non-Standards Track RFC."  Throwing in "based on IETF consensus."

**Is Historic considered to be Standards Track?  The reason I ask is that
the quad-A record (RFC 1886) will probably go historic, which shouldn't
require that  the AAAA value be "moved."**

This brings up another issue, are old mnemoic values ever
garbage-collected?  (E.g., type MG.)  The values are not worth much, but
the bits in the NXT record bit map could be reclaimed.

Yet another issue - I would also like to see words [1] describing at what
point a value is assigned.  E.g., there have neen internet drafts with
establised values.  By mentioning "RFC" in the words above, is the
implication that a value can only be assigned when the IESG has finished
reviewing a proto-RFC?  Or is a "Standards Track" document anything deemed
to be standards track in a working group?

[1] I know that this implies that I should supply words to this effect.
First I'd like to know if this is should be in the document.

Time for a nit:

>References
>
>   [Moon 81] - D. moon, "Chaosnet", A.I. Memo 628, Massachusetts

Capitalizaiton of "moon"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Dec 1999 16:03:49 -0500

At 12:06 PM -0500 12/10/99, Bill Manning wrote:
>	Its as uptodate as the data provided to IANA.

The question is - should IANA demand more information from a requestor
before granting a number?

>	I'd rather not.  As long as the spec can be found in a competent
>	(there is a better word for this) technical journal of record, then
>	assignments can be made. (see the e164 RR et.al.)

"Refereed" journal?  But this excludes the assignment for the purposes of
an internet draft headed to standards track.  Hmmmm.

>	See poised on historic wrt standards track.

Shux, I was afraid someone would expose my failure to read all relevant
documents before responding...

>	Catch22 here.  If the IANA has to wait to assign the value
>	based on IESG feedback, then implementations will have to be
>	trashed once the spec "passes muster" and then, since the numbers
>	have changed, may have to be redone.

I'm well aware of this, I guess I was hoping this document would be
defining the de jure process in words.

I don't want to change the way things are now, however I do want to see the
document reflect the way things are now.  (Well, except that the reference
information should be more up to date.)

>	The IANA has always reserved the right to assign/document numbers
>	as needed.

I am aware of this - this is why I never waged a personal mini-war over the
ATM Forum document being the only definition of the ATMA.

But if the IETF has "no control" over IANA's assignment of numbers, why is
this document being written, I ask non-facetiously.  I thought the intent
here was to give instructions to IANA.  Is the intent to provide guidance,
or preferences?  Or is this a guide to future internet draft and RFC
producers (on what goes into the IANA considerations)?

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 18 Dec 1999 23:30:00 -0500

Hi Ed and Thomas,

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130305b476c254bfe8@[10.33.10.14]>
In-Reply-To:  <4.1.19991203162520.00bdf520@localhost>
Date:  Fri, 10 Dec 1999 10:11:42 -0500

>think the problem is that this "requirement" has never been formalized.)

This draft requires RFC documentation for all new RR # assignments.

It is not at all clear to me that a working group or the IESG can
impose that sort of operational requirement on IANA, which operates
under the supervision of the IAB.  The IANA Considerations type
requirements that this draft is an example of are being done at least
partly at IANA's request, to ease the burdens of judgement and
possible legal liability on IANA.  In any case IANA is not currently
under any requirement to even have an on-line DNS parameters web page.
However, I believe that when an RR is defined in an RFC, as all future
RR's will be under this policies suggested in this draft, IANA will
list those RFC numbers with the RR types on the web page.

>of what "non-Standards Track RFC documentation" is, e.g., an article in

In the IETF contest, an RFC is a publication in the traditional
numbered RFC series by the RFC Editor (see www.rfc-editor.org).
Standards track is, at least initially, a Proposed, Draft, or full
Standard under the IETF standards procedure.  See RFC 2026.  A
"non-Standards Track RFC" is an initially Informational, Experimental,
or BCP RFC.  A paragraph to spell this out is probably a good idea.

>in a non-Standards Track RFC."  Throwing in "based on IETF consensus."

I strongly oppose such a tight restriction.  Part of the genius and
success of the development of the Internet has been its openness and
the fact that not just addresses and names but protocol IDs, sockets,
etc., etc., and even RR type numbers have been easily available for
IETF communicty experimental and even non-IETF defined protocols and
uses.  When you make allocation too tight, people just grab a value
and use it and the IETF has never had any menas of legal
enforcement. The steady growth of bureaucratic restrictiveness is
something I think should be resisted even though it may be needed for
small fields with limited numbers of values, such as OpCode.

In the past, it was almost always up to IANA's discretion to assign
parameter values.  This allowed the stringency of the criterion to be
easily adjusted depending on the scarcity and rate of use of values.
It is quite unfortunate the we now have to set these criterion down in
writing.  Sure, they can always be changed, but not nearly as easily
and fluidly as they could in the past.

With 2**16 values and a very slow consumption rate, what is the reason
for requiring an IESG vote (which is required to determine IETF
consensus) to allocate a value?

>require that  the AAAA value be "moved."**

Well, Historic is incompaible with being Proposed, Draft, or full
Standard but former Standards Track RFCs can be moved to Historic, as
can non-Standards Track.

I agree that the draft should not require RR numbers to change except
perhpas that RRs initially numbered in the 0xFF00 - 0xFFFF range
before they have an RFC and are renumbered to a lower number as
assigned by IANA in accordance with the IANA Considerations when the
draft is forwarded to the RFC editor.

The following table from RFC 2400 is the most recent one I can find
that shows the possible combinations for an RFC (the multiple xxx's
indicate where most RFCs should fall).  An RFC is shown as having a
state of one of Standard, Draft, Proposed, Informational, Experimental
or Historic and a status of one of Required, Recommended, Elective,
Limited, or Not Recommended.  This table pre-dates BCP but probably
all BPC state RFCs should be Recommended or Elective...

                             S T A T U S
                     Req   Rec   Ele   Lim   Not
                   +-----+-----+-----+-----+-----+
           Std     |  X  | XXX | XXX |     |     |
       S           +-----+-----+-----+-----+-----+
           Draft   |  X  |  X  | XXX |     |     |
       T           +-----+-----+-----+-----+-----+
           Prop    |     |  X  | XXX |     |     |
       A           +-----+-----+-----+-----+-----+
           Info    |     |     |     |     |     |
       T           +-----+-----+-----+-----+-----+
           Expr    |     |     |     | XXX |     |
       E           +-----+-----+-----+-----+-----+
           Hist    |     |     |     |     | XXX |
                   +-----+-----+-----+-----+-----+

>the bits in the NXT record bit map could be reclaimed.

There isn't any mechanism and this would be the right place to
document one, but I don't see any need yet.

The problems with NXT are another matter.  I've been wanting to
suggest some backward compatible changes using the escape bit in NXT
but whenever I suggest any changes in DNSSEC, a number of people jump
on me with hob nailed boots claiming that any changes will slow down
deployment.  So DNSSEC remains unchanged, but unfortunately undeployed
as well...

>to be standards track in a working group?

The draft should be clarified on this point but I believe the intent
of the current is that for new RR's, those doing the internet-draft
and/or experimenting with the RR should pick a number in the 0xFF00 -
0xFFFF range and after WG and IETF Last Calls and approval by the
IESG, i.e. the point at which it goes to the RFC-Editor, IANA gets to
pick an appropriate lower number based on these IANA Considerations.

Is that the right thing?  Is there a danger of implementations using a
0xFF00 - 0xFFFF RR number spreading and becoming sufficienlty
entrenched that it is hard to get them to renumber or, even worse,
conflicting with each other?

Making it depend on a WG action has problems as well.  Standards Track
RFCs do not have to come from a WG.  While right now it seems like the
DNSEXT WG may be "permanent" and one would expect most DNS matters to
be refered to it, the WG will probably go away some year and there are
even now cases of RR's coming from other WGs and areas, like IPv6...

As you indicate in later mail you agree, I'm in favor of giving IANA
maximum discretion so I'd prefer to drop all that and let it be, as it
always has been in the past, up to IANA to decide whether to allocate
a number right then when its get a request from a draft author, WG
chair, AD, etc.

>>   [Moon 81] - D. moon, "Chaosnet", A.I. Memo 628, Massachusetts

Thanks for spotting that...

From:  Thomas Narten <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
In-Reply-To:  Message from Olafur Gudmundsson <[email-masked]> 
	        of "Fri, 03 Dec 1999 16:56:22 EST." <4.1.19991203162520.00bdf520@loca
lhost> 
Date:  Fri, 10 Dec 1999 11:39:49 -0500

>BCP would be my recommendation here.  A recent similar document would
>be 'IANA Allocation Policies For Values In the Internet Protocol and
>Related Headers' <draft-bradner-iana-allocation-03.txt>, which was
>recently last-called as a BCP.

OK, I'll make that change.

>Specific comments on the draft:
>
>In several places the term "non-standardstrack rfc documentation" is
>used, i.e.:
>
>>      32768 - 65280
>>    0x8000 - 0xFEFF - assigned by non-Standards Track RFC
>>    documentation.
>
>However, there is also a range of values:
>
>>      128 - 255
>>    0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
>>           Meta TYPEs only by IETF consensus.
>
>i.e., a different range of values is reserved for "IETF consensus".
>
>"IETF Consensus" (as defined in 2434) includes non-standards track
>documents. This would appear to be ambiguious. What space should
>IANA be using for non-standards track documents?

128-255 should probably have said IETF Standards Action.

>Second, assuming the desire is to reserve one set of numbers for
>standards track values, another range for non-standards track values,
>what is the technical reason for this? Does this have implementation
>significance? What happens if an informational document defining value
>gets put on standards track?

I don't think RR numbers should change, at least once they are
documented in an RFC of any type, and the draft should be claified to
say so.

Having different ranges with different stringencies of allocation is
encouraged by RFC 2434 and is the only practical way to approximate
the open and desireable situation of easy allocation which gets tigher
as the supply dwindles.  In fact, if there isn't a SINK RR of some
form, perhaps there should be a first come first served area so that
those who wish to put opaque propriety data into the DNS in a general
non-interfering way (i.e., so that it does not interfere with other
opaque proprietary used so NULL and TXT are ruled out) have some place
to go.  If you make allocation too stringent, it encourages people to
just grab a number and use it and the IETF has no legal enforcement
authority to stop it.

>(The previous question applies in several places.)
>
>>      1 - 127
>>    0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
>>           TYPEs only by IETF consensus.
>> 
>>      128 - 255
>>    0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
>>           Meta TYPEs only by IETF consensus.
>
>Is there a technical reason for this? The document itself states that
>there is already an exception to the above (i.e., OPT).

I believe some versions of BIND make caching decisions based on the
top bit of the lower RR type octet.  This arrangement was originally
set up, I believe, by Jon Postel and it is usually a good idea to
group similar values.

I think OPT was a goof and a majority of the few posting about this
advocated issuing a new RFC fixing the goof and obsoleting the
existing RFC.  This may illustrate a problem with RFC time RR number
issuance.  I've always asked for a real RR number when I had a more or
less coherent Internet-draft.  But more than once I've had to
immediatley return the number and ask for a different one in the right
range.

>>      65280 - 65534
>>    0xFF00 - 0xFFFE - assigned for experimental and pre-standards use.
>>           Because their use is not coordinated, these values/uses may
>>           conflict between different experiments.  These values should
>>           be used in Internet Drafts for protocols that do not yet have
>>           an RFC on the Standards Track [RFC 2026].  When such an RFC
>>           issues, a non-experimental value will be assigned.
>
>Clarification: does IANA give these out (and then reclaim them later)?
>If so, how is their use "not coordinated"? Would "Private Use" as
>defined in 2434 accomplish the same goal without requiring IANA be
>involved with individual requests?

"Not coordinate" is used to mean that no one gives them out, you just
grab one.  Although this is the same "allocaition mechanism" as
Private Use in RFC 2434, it is not intended to have the "local use"
implications.  It is for all those involved in the experiment or
pre-standards use, regardless of their locality.

>(this comment applies in several places.)
>
>Thomas

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [email-masked]
 Carmel, NY 10512 USA

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Dec 1999 08:06:29 +0100

At 23:30 18.12.99 -0500, Donald E. Eastlake 3rd wrote:

>under the supervision of the IAB.

Process point:

It is completely clear to me that wrt assignment of parameters for IETF 
standards, directions to the IANA are created under IETF consensus rules - 
that is to say: By the normal process of IETF document production.

The IAB is the steward of the IETF-IANA relationship, not its master.

                             Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Dec 1999 09:51:56 -0500

>consensus) to allocate a value?

I hadn't equated "IETF consensus" with an IESG vote.  (I haven't gone
through the  POISED documents for terminology.)  I thought such consensus
could be declared in WG (by passing a document through last call) and
getting the document an RFC.  I guess part of my comment's reason is my
confusion over the phrase "non-Standards Track RFC."  This, of course,
assumes WG action happens.

>Well, Historic is incompaible with being Proposed, Draft, or full

Does incompaible == imcompatible?

---

This document may not be intended nor be able to direct the actions of IANA
in anyway.  However, this document can influence the contents of the IANA
considerations of current and future documents.  I'd like to see
recommendations geared toward document writers and implementers covering
the contents of the section and what and when to ask for a value from IANA.

I'd like to avoid the OPT value problem, the ATMA situation, and
proliferation of dead-end types.  I'm not concerned about number-space
exhaustion, but rather the implementation of the parsing/writing/packet
processing code in name servers.

Perhaps the document ought to say "if you are writing a draft or are
writing software to prototype a draft, then this is how and when you
request a value - and what value should be requested."   The document ought
not to say "IANA, this is how we want numbers assigned," which is what I
originally thought this was, and commented the way I did.

This would allow DNS-IANA to state recommended number pools without
imposing a restriction on IANA.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Dec 1999 11:38:06 -0500

At 9:51 AM -0500 12/20/99, Edward Lewis wrote:
>in anyway.

in any way.

Darn spacebar...

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 21 Dec 1999 02:54:09 -0500

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130300b483ed1e4f3b@[10.33.10.14]>
In-Reply-To:  <[email-masked]>
References:  Your message of "Fri, 10 Dec 1999 10:11:42 EST."            
	     <v03130305b476c254bfe8@[10.33.10.14]>
Date:  Mon, 20 Dec 1999 09:51:56 -0500
To:  [email-masked]
Cc:  [email-masked]

>assumes WG action happens.

Yes, "IETF Consensus" means a consensus of the entire IETF, not just a
WG, and is currently determined by the IESG.

Non-Standards Track RFCs can get issued with no WG by the IESG or, at
least for Informational and Experimental, by the RFC edtior directly.

>Does incompaible == imcompatible?

Yup.

>imposing a restriction on IANA.

I think its pretty optimistic to think that draft writers, etc., will
always follow guidelines in an RFC resulting from this DNS-IANA draft.

The document could also have provisions like you suggest above for
those seeking parameter values but IANA Considerations sections/RFCs
are most definitely intended to "direct' IANA in certain ways.  They
are phrased in terms of the criterion for allocated various numbers
but IANA is almost always who does the assigning.  It is my
understanding that IANA has specifically requested guidance so as to
provide, in so far as posssible, mechanical criterion for parameter
value assignment, minimizing the IANA judgement involved (and thus
presuably minimizing the legal and other hassles IANA is likely to
get).

I don't think WGs or the IESG can direct IANA in general ways, like
requiring a web page be maintained or that it be up-to-date by a
certain criterion or that requests for parameters be processed within
some particular short time.  I suppose it's possible that some
consider the IANA Considerations for various parameter assignments to
just be suggestions to IANA but I would expect IANA has always
followed them.

Thanks,
Donald

PS:  I will have limited connectivity until Dec. 26th
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     [email-masked]
 Carmel, NY 10512 USA

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Dec 1999 08:28:49 -0500

>value assignment, minimizing the IANA judgement involved (and thus

This should be in the introduction.

---

From: Bill Manning <[email-masked]>
Date: Tue, 21 Dec 1999 07:54:02 -0800 (PST)

% 
% At 2:54 AM -0500 12/21/99, Donald E. Eastlake 3rd wrote:
% >but IANA is almost always who does the assigning.  It is my
% >understanding that IANA has specifically requested guidance so as to
% >provide, in so far as posssible, mechanical criterion for parameter
% >value assignment, minimizing the IANA judgement involved (and thus
% 

	Donald, we have discussed this previously and while I'd really like
	to understand where you gained this perception, I think it would
	be useful to get such a statement directly from the IANA before
	we codify your understanding.

	Josh, would you care to comment here?

--bill

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 25 Dec 1999 16:04:37 +0100

>         we codify your understanding.

What about RFC 2434, "Guidelines for writing an IANA consideratins section"?

I quote from the introduction:

>    In order for the IANA to manage a given name space prudently, it
>    needs guidelines describing the conditions under which new values can
>    be assigned. If the IANA is expected to play a role in the management
>    of a name space, the IANA must be given clear and concise
>    instructions describing that role.

This document was written because IANA asked us to ensure that IANA didn't 
have to "play expert" when allocating values.
 From the same document (section 2):

>    While discussion on a mailing list can provide valuable technical
>    expertise, opinions may vary and discussions may continue for some
>    time without resolution.  In addition, the IANA cannot participate in
>    all of these mailing lists and cannot determine if or when such
>    discussions reach consensus.  Therefore, the IANA cannot allow
>    general mailing lists to fill the role of providing definitive
>    recommendations regarding a registration question.  Instead, the IANA
>    will use a designated subject matter expert.  The IANA will rely on a
>    "designated expert" to advise it in assignment matters.

.............

>    Designated experts are appointed by the relevant Area Director of the
>    IESG. They are typically named at the time a document that creates a
>    new numbering space is published as an RFC, but as experts originally
>    appointed may later become unavailable, the relevant Area Director
>    will appoint replacements if necessary.

Bill, I'd like to understand why you seem to have a perception that IANA 
wishes to exercise independent judgment about when values should be 
allocated or not.

                          Harald A

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 31 Dec 1999 14:46:49 -0500

I don't see why we should have to say anything about this in the
introduction.  Essentially every RFC that defines any field or
parameter has to have an IANA Consierations section in it these days
or the IESG won't let it through.  I don't see the point of sticking
in such justification text in most RFCs.  After all, it's not like
this is some sort of new idea.  RFC 2434, the BCP on the subject, is
dated Octobver 1998 and this IANA Considerations stuff was going on,
as I recall, for at least a year before that.  I suspect that by about
a year from now, every parameter in every IETF protocol will have some
sort of assignment IANA Considerations governing it (or have been
allocated to another organization like the parts of ICANN).

Donald

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130300b48530d8b950@[10.33.10.14]>
In-Reply-To:  <[email-masked]>
References:  Your message of "Mon, 20 Dec 1999 09:51:56 EST."            
	     <v03130300b483ed1e4f3b@[10.33.10.14]>
Date:  Tue, 21 Dec 1999 08:28:49 -0500
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  Edward Lewis <[email-masked]>, [email-masked]