Subject: Re: Last Call: <draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Mon, 20 May 2013 11:56:18 -0400

--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
<[email-masked]> wrote:

>...
>> This is not my primary (or even secondary) area of expertise
>> but, given that the RR space is not unlimited even though it
>> is large, wouldn't it be better to have a single RRtype for
>> IEEE-based EUIs with a flag or other indicator in the DATA
>> field as to whether a 48 bit or 64 bit identifier was present?

> the basis for assignment of rr-types is expert review. Whether
> the draft advances or not the rr-types have been assigned.
> 
> http://tools.ietf.org/html/rfc6895#section-3.1.1
> 
> http://www.iana.org/assignments/dns-parameters/dns-parameters.
> xml#dns-parameters-3

Joel,

I don't know who the current expert is and, for the moment, am
glad I don't and don't intend to check.  I believe there is
broad consensus in the community that having something as
significant as an RRTYPE documented in the RFC Series is a good
idea.  Certainly leaving the reference pointing, long-term, to
an I-D would not be a good idea (and would violate several other
principles).

However, if 

(i) the expert review consists largely of making sure
	that the template contains the right information and the
	ducks are not obviously out of line rather than a
	design/architectural review with at least meaningful
	potential for community review of the request, and 
	
(ii) the response to a design/architectural concern
	raised during IETF LC is essentially "too late, code
	points already allocated", and
	
(iii) "Proposed Standard" still does not imply
	"recommended" and the alternative to approving the I-D
	for that category is non-publication,
	
then I would like to understand, as a procedural matter, what
the IETF Last Call is about.  Certainly it is not for editorial
review; that is the RFC Editor's job and there are, IMO, no
glaring editorial problems.  If the RRTYPEs have been allocated
and can't be un-allocated and this is in use, then there is
nothing to propose as an individual submission for
standardization: an informational document to inform the
community about what this is about would be both appropriate and
sufficient.  

Beyond that, your shepherd's report implies that the issue I
raised may have been discussed and successfully resolved in
DNSEXT.   If that is the case, an explanation in the document
about the tradeoffs and decision would still be appropriate.

Alternatively and especially if there wasn't clear consensus in
DNSEXT, if this really is to be processed as a Proposed
Standard, then a suggestion during IETF Last Call that the IETF
Standard way to represent EUIs in the DNS should be a single
RRTYPE with length/type information in the DATA is still in
order: the community could reasonably conclude that the single
RRTYPE is a better solution, that the single type should be
allocated, and that these two types should be deprecated.   We
have certainly done similar things before with other protocols
and parameters that were already in use before standardization
was proposed from an individual submission.

    john

p.s. I've tried reading your shepherd writeup now in three
different browsers.  It appears to be formatted for extremely
long (paragraph-length) lines, with no provision for automatic
wrapping to fit the page frame.  That means that trying to read
and understand it requires extensive horizontal scrolling, which
is a fairly large impediment and, although I assume
unintentionally, a way to discourage anyone but the most
determined of readers from actually reading it.  May I suggest
that the IESG, on a priority basis, either get the format of
those writeup pages changed so that they wrap appropriately or
that it insist that writeups conform to RFC/I-D norms for line
lengths.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 May 2013 09:24:12 -0700

On May 20, 2013, at 8:56 AM, John C Klensin <[email-masked]> wrote:

> the IETF Last Call is about.

Whether or not the document clear enough for an implementor to create interoperable software from. That's what the IETF is supposed to be doing, yes?

>  Certainly it is not for editorial
> glaring editorial problems.

Correct.

>  If the RRTYPEs have been allocated

...only if the authors don't care about interoperability between implementations.

An author asking for IETF-wide review seems like something that should be encouraged, not pecked to death.

--Paul Hoffman

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 May 2013 12:26:30 -0400

Hi John,

> an I-D would not be a good idea (and would violate several other

There has been a long term fight to make RRTYPEs easy to get, a fight
in which substantial victory has only recently been achieved
(RFC6895). The result of tight control over RRTYPEs is that most new
uses just take the path of least resistance and overload the TXT
RRTYPE, something which requires no one's permission but, as per RFC
5507, has significant long term disadvantages. One lesson of the
Internet has been the benefits of FREEDOM TO INNOVATE. In my opinion,
most IETF WGs impose tighter control over code points that necessary
most of the time (note most, not all).

>         potential for community review of the request, and

The guidelines are in RFC 6895 which I recommend you consult. There is
no requirement for community review. A primary concern is that the
RRTYPE can be safely handled an unknown RRTYPE (or is an ignorable
meta RRTYPE). The community has people that will complain about and
delay andy new RRTYPE.

How is an RRTYPE any more earth-shaking than, say, an AFN number, a
range of which are available on a first-come, first-served basis? What
are these "principles" you refer to above that require RFC
documentation of RRTPYEs when no documentation whatsoever is required
for some AFN numbers?

> community about what this is about would be both appropriate and

Perhaps it should be informational. I believe the author was
originally going to submit as an Informational Independent submission.
Others, including myself, suggested different paths. Perhaps we were
mistaken.

The perfect is always the enemy of the good.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 May 2013 12:31:04 -0400

> that it insist that writeups conform to RFC/I-D norms for line

This happens in a number of places in the datatracker, and there's an
open ticket for the tools team to make a general fix.  In the
meantime, we have to try to remember to put in line-breaks manually.
When I encounter something that doesn't have them, I just copy/paste
into my favourite local editor, and read it there.

Barry

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 May 2013 09:55:13 -0700

On 5/20/13 8:56 AM, John C Klensin wrote:
> idea.
IETF consensus tends to indicate that is is better to assign new 
RR-types then it is to keep having developers jam these usages into text 
RRs.
>   Certainly leaving the reference pointing, long-term, to
an ISE submission for documentary purposes would minimal impediment and 
documentary value would be preserved an rr-type assignement might well 
point at an external resource.
> 	points already allocated", and
IETF LC should be, "can we live with this?" The document has been 
discussed in dnsext and reviews were requested, I was prevailed on to 
take it on as that WG is supposed to be shutting down.
> was proposed from an individual submission.
So, I don't have a  problem philosophically or otherwise with the fact 
that there my be a better solution out there. It takes somebody to do 
that work. The can obviously get an rr-type for that application.

In the use cases associated with provisioning systems I would expect 
that knowledge of media type would drive usage of one rr type or another 
e.g. if you're provisioning 6lowpan/zigbee/802.15.4 devices you probably 
don't have to query for eui48.

     john

p.s. I've tried reading your shepherd writeup now in three
different browsers.  It appears to be formatted for extremely
long (paragraph-length) lines, with no provision for automatic
wrapping to fit the page frame.

I can fix that by editing the text. a tool fix for that is forthcoming iirc.
>    That means that trying to read

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 May 2013 15:17:52 -0400

--On Monday, May 20, 2013 09:55 -0700 joel jaeggli
<[email-masked]> wrote:

>> significant as an RRTYPE documented in the RFC Series is a
>> good idea.

> IETF consensus tends to indicate that is is better to assign
> new RR-types then it is to keep having developers jam these
> usages into text RRs.

I certainly agree with that.  If I had my druthers, the IETF
would have loosened up on registrations and issued a strong
statement discouraging the use of text RRs for anything other
than what I believe was their original purpose -- unstructured
textual comments to be read by humans.  So no disagreement
there.    But even in the pre-1999 IANA days and with registries
that were almost purely FCFS, the then-universal expert reviewer
felt it was reasonable to deal with an application for two code
points by saying something equivalent to "hey, can't you use one
and a different data structure?".  It is, IMO, an obvious
question and, other issues aside, I think the answer should be
explained in the document.  How strong "should" is depends on
another consideration; see below.

>> an I-D would not be a good idea (and would violate several
>> other principles).

> an ISE submission for documentary purposes would minimal
> impediment and documentary value would be preserved an rr-type
> assignement might well point at an external resource.

Yes.  And?    I didn't say "no external reference", I said "no
permanent reference to an I-D".   Remember that "not an archival
series", "reference only as work in progress", etc., stuff?
Again, see below.

> IETF LC should be, "can we live with this?" The document has
> been discussed in dnsext and reviews were requested, I was
> prevailed on to take it on as that WG is supposed to be
> shutting down.

See below.
 
> So, I don't have a  problem philosophically or otherwise with
> the fact that there my be a better solution out there. It
> takes somebody to do that work. The can obviously get an
> rr-type for that application.
>...
  
Somewhat informed by your note and the other responses to my
original one, let me clarify what I'm suggesting...

(1) As indicated above, I think that an easy application and
registration process is A Good Thing for RRTYPEs (and lots of
other things).  Unless there is some substantial reason to not
do so, I think that such registrations should be bound to
sufficient information to make interoperability easy or at least
feasible.  In the general case, I don't think it makes any
difference where that information is recorded as long as the
document location or maintenance arrangements are sufficiently
stable to create a plausible expectation of long-term
accessibility of the description.  I note that the latter has
been an IANA requirement since before there was an IETF and that
occasional exceptions have been made for almost that long.

(2)  I think publication of descriptions of RRTYPE values (and
other parameters) in the RFC Series is generally A Good Thing
and that it should be encouraged.  If that results in better
quality documentation or documentation that is easier to
interpret in ways that increase interoperability, that is great.

(3) However, if someone wants both a code point (in this case,
RRTYPE) or two and an IETF Standards Track document, they should
expect to conform to IETF norms about standards track
specifications.  I think those norms include the expectation of
a meaningful IETF Last Call that could, e.g., question design
decisions, expect substantive responses, and expect changes if
the consensus leads that way.  The situation with a WG document
being processed inside a WG and with an individual submission
for Standards Track ought to be the same: design decisions
belong to the WG or IETF, not the authors.  A registration
procedure should not be able to be used to create a back door
and preempt that principle, so the would-be registrants can use
the expert process to register whatever they would like but, in
doing so, they should accept that, if they want to publish in
the RFC Series, the result will be Informational.  Or, if they
want whatever value that IETF Standardization adds, they need to
make a proposal to the IETF and let it be reviewed, and possibly
changed, by the process.  If they pick the latter course, it
will usually be preferable to defer registering until the IETF
reaches consensus but, if that is not feasible, they need to be
prepared for the IETF to agree on something else, expect to be
asked to reflect that in their document, register the
agreed-upon solution, and then deprecate the earlier
registrations (possibly leaving their documentation in an
appendix to the Standards Track RFC).  

It seems to me that, if someone can register something, ask for
Standards Track status, and then reject requests to discuss
changes on the basis that the registration has already occurred
and expect the document to be standardized anyway, the standards
process is headed toward fairly difficult territory.

     john

p.s. Thanks to you and Barry for the explanation of the
shepherd/ tracker problem.