Hi John, On Mon, May 20, 2013 at 11:56 AM, John C Klensin <john-i...@jck.com> wrote: > --On Monday, May 20, 2013 07:53 -0700 joel jaeggli > <joe...@bogus.com> 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).
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). > 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 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? > (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. 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 d3e...@gmail.com > 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.
