On 5/20/13 7:18 AM, John C Klensin wrote:
--On Monday, May 20, 2013 06:44 -0700 The IESG
<iesg-secretary(_at_)ietf(_dot_)org> wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
<draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt> as Proposed
Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
substantive comments to the ietf(_at_)ietf(_dot_)org mailing lists by
2013-06-17. Exceptionally, comments may be sent to
iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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
In addition to saving an RRTYPE slot, my recollection of the
uses of EUI-64 is that an application trying to look up an EUI
may not, in the general case, know whether the device and its
EUI are of the 48 or 64 bit persuasions. If that is correct, a
single RRTYPE and a length/type indicator in the DATA would
avoid a two-stage lookup and/or unnecessary use of QTYPE=ANY.
The same one RRTYPE model would, with even a modicum of good
design, make transition easier when the IEEE goes interplanetary
or interstellar and discovers a need for EUI-128 (or some other
length > 64).
If there really are significant advantages to having two
separate RRTYPEs that override the considerations above, it
seems to me that the reasoning for doing so should at least be
briefly explained in the document.
john