Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LASTCALL?)

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 15 Jun 2000 16:01:53 -0400

Dear Al,

From:  "Al Costanzo" <[email-masked]>
Message-ID:  <[email-masked]>
Reply-To:  "Al Costanzo" <[email-masked]>
To:  "Bill Manning" <[email-masked]>, <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>, <[email-masked]>
References:  <[email-masked]>
Date:  Wed, 14 Jun 2000 15:14:05 -0400

>Dear ALL,
>
>Concerning the document: draft-ietf-dnsext-iana-dns-00.txt (LAST CALL)
>
>I am opposed to this document being moved forward because of certain
>language contained within it.
>
>The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from
>issuing DNS Resource Record assignments for anything other than a standards
>track RFCs.  There are a number of RR that are currently defined in
>Experimental RFCs and I would NOT think that any document should restrict
>IANA from issuing assignments in this fashion for Experimetal RFCs.

(1) There is no such thing as an "Experimental RFC".  There are Experimental
Protocols.  An RFC may document a protocol which can be, at some particular
time, an Experimental Protocol.

(2) The Phrase "IETF Consensus", like all of the other terms of art for
IANA Considerations in this draft, is defined in RFC 2434 as follows:
      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG.
Note that this does NOT restrict to Standards Track.  In any case,
under this draft this applies ONLY to a certain range of RR number, in
particular 1-32767.  However, other values are assigned by IANA based
on other criterion.  In particular, RR numbers in the range of 32768 -
65279 are assigned based on "Specification Required" as specified in
RFC 2434:
      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.
Thus, of course, IANA is quite free to assign RR numbers in connection
with an Experimental Protocol documented in an RFC without any
requirement to get the approval of or go through a WG or the IESG.

>If this is what the implication is, in my opinion is downright wrong and the
>verbage needs to be changed to allow this...

I don't see that we are talking about any vague "implication" in the
draft.  It is quite clear that certain RR values can be allocated by
IANA if IANA is satisfied that the Specification Required criterion is
met.  If it will give people a warm fuzzy feeling for a sentence like
"Thus IANA can allocate RR numbers in this range for documented
Experimental Protocols."  I'm willing to do that, although I don't see
the need to add such verbiage.

>-Al Costanzo

Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 140 Forest Avenue                          [email-masked]
 Hudson, MA 01749 USA     +1 978-562-2827(h)    +1 508-261-5434(w)

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bill Manning <[email-masked]>
Date: Thu, 15 Jun 2000 21:06:28 -0700 (PDT)

% >The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from
% >issuing DNS Resource Record assignments for anything other than a standards
% >track RFCs.  There are a number of RR that are currently defined in
% >Experimental RFCs and I would NOT think that any document should restrict
% >IANA from issuing assignments in this fashion for Experimetal RFCs.
% 
% (1) There is no such thing as an "Experimental RFC".  There are Experimental
% Protocols.  An RFC may document a protocol which can be, at some particular
% time, an Experimental Protocol.
% 

Donald,

	I beleive that while you may technically be correct that there are
no "Experimental RFCs" there are RFCs that are in experimental status.
(e.g. RFC 2844)  To acheive this status, it is not nessasary to reach "IETF
consensus" as elswhere documented. This does place an interesting burden on
those using the process of experimentation and implementation to advance the
state of the art in that they may not get an IANA approved codepoint until
some time after the code is in use.  Given the existing process and its
associated latencies in getting an RFC through the IETF and the IESG, I 
am becoming convinced that we are encouraging anarchy by delaying the
registration and documentation of new features and code points.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 16 Jun 2000 08:13:45 +0859 ()

Bill;

> registration and documentation of new features and code points.

Yes, I wrote in last September.

:             IANA Registration and the End to End Principle

:   To promote better interoperability, IANA is the place, recognized by
:   those who developed the protocols, to register interpretations of
:   various values of the protocol fields.
:
:   IANA assigns unique values and make lists of the assigned values and
:   their meaning with references to more detailed information.
:
:   However, IANA registration does not mean that IANA provides collision
:   management nor automatic identification of the registered values. The
:   registration, either, does not assure the interoperability of the
:   protocols.

:   IANA assignment of values, neither, overrides any intellectual
:   property rights such as trademark or copyright.
:
:   The Internet works based on the end to end principle [ARCH] that,
:   parties, that is, end systems or hosts, of a communication are
:   required to have an interpretation of values common only to them.
:   The interpretation may be different from that registered to IANA.
:
:   As such, when many or most hosts in the Internet share an
:   interpretation of protocol values, some protocol fields have defact
:   interpretations different from IANA registered ones.
:
:   Because of the end to end principle, there, principally, can be no
:   mechanism to enforce IANA registrations.

That is, Almost all the registration restrictions are silly, only to
make IANA ignored by the Internet.

However, please don't apply the argument to domain names, as I also wrote:

:   It should be noted that the argument above is not applicable to
:   values to identify end systems, namely, IP addresses and domain
:   names. IP addresses are essential to routers while domain names offer
:   a lot more human friendly identification.

It was draft-ohta-iana-registration-00.txt.

> associated latencies in getting an RFC through the IETF and the IESG, I 

No, I did not bother to try to make it an RFC. :-)

							Masataka Ohta

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 15 Jun 2000 19:35:39 -0400

Bill,

From:  Bill Manning <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked] (Donald E. Eastlake 3rd)
Date:  Thu, 15 Jun 2000 21:06:28 -0700 (PDT)
Cc:  [email-masked]
In-Reply-To:  <[email-masked]> from "Donald E. Eastlake 3rd
" at Jun 15, 2000 04:01:53 PM

>% time, an Experimental Protocol.

You seem to have edited down the previous message so as to produce a
misleading impression.

>no "Experimental RFCs" there are RFCs that are in experimental status.

I would point out that one AD criticism which lead to my editing of
the tkey and sig(0) drafts was that the phrase "Experimental RFC" be
reworded.

>consensus" as elswhere documented. This does place an interesting burden on

Of course not.  It requires only approval by the RFC Editor for an
Experimental Protocol, although the IESG can approve them also.  But
so what?  "IETF Consensus" is NOT NECESSARY to get an RR value
assigned according to this draft.

>some time after the code is in use.  Given the existing process and its

If you are saying that anyone needs either IESG or WG or RFC editor
approval to get a codepoint allocated, you are wrong.  Read the text I
quoted from RFC 2434 which you unfortunately edited out of my message.
The do NOT have to have ANY code written, they do NOT have to have any
code deployed, they do NOT have to have any code in use.  The need
only provide a specification as described in RFC 2434.  They CAN do so
by an RFC by the are NOT REQURIED to do so by an RFC.

>registration and documentation of new features and code points.

Since this draft does not require an RFC, I'm sure you will be
relieved to know that your fears are groundless.

Donald