On 5/20/13 8:56 AM, John C Klensin wrote:
--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
<joelja(_at_)bogus(_dot_)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.
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 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.
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
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.
(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.
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
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.