On 5/20/13 6:42 PM, Brian E Carpenter wrote:
On 21/05/2013 13:06, John C Klensin wrote:
--On Monday, May 20, 2013 19:49 -0400 Rob Austein
<sra@xxxxxxxxxx> 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.
Especially since there is an IEEE-defined method for representing
a 48-bit address in the 64-bit format. Now you mention it, why can't
that be used in all cases?
two observations
If you have an iab range the eui label would get inserted in the middle
of the IAB base value iirc. that sounds sort of appauling to read/decode.
Second it's not just a representation it's an encapsulation (you could
if you so choose use a mac-48 on an eui-64 supporting link layer
legitimately using the encapsulation). I'm sure some ugly bridge device
that I want nothing to do with will do that some time in the future, it
does therefore seem slightly desirable to render them as they are rather
than in some canonical form that is both.
Brian