--On Monday, May 20, 2013 19:49 -0400 Rob Austein
<sra(_at_)hactrn(_dot_)net> wrote:
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin 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?
Short answer: Probably not, but it depends on the application.
Longer answer: See RFC 5507.
Rob,
I've reread 5507 and did so again before writing my second note
today. I don't see that it helps.
I haven't heard anyone proposing use of TXT (or any existing
RRTYPE) instead, so that is presumably a non-issue.
The discussion in 3.1 clearly applies to relatively complex
schemes like NAPTR, but it is not clear that it has anything to
do with this case. In particular, if I correctly understand the
IEEE's allocation scheme for longer identifiers (and I may not)
than a given device gets only one -- this is not analogous to a
dual-stack IPv4/IPv6 arrangement -- and an application gets back
whatever it gets back (whether the query is addressed to the
DNS, read off a label on the device and entered manually, or
something else). If so, then one RRTYPE with the appropriate
identifier in the data is the right answer.
If not... if, for example, different types of applications will
look for only one type-length of identifier and will either find
it or give up (not try falling back to the other because that
would make no sense), then the use of two RRTYPEs is entirely
reasonable. But, if that is the case and this is going to be
standards track, I expect to see an explanation in the document.
That explanation could be as simple as a statement to that
effect and an example or two of the types of applications that
would use each identifier and/or a reference to IEEE materials
that describe the circumstances under which one example or the
other is used.
I'm not opposed to having two separate RRTYPEs -- I just want to
see the rationale. And what passes for use cases in the draft
appears to me to be completely silent on that issue.
john