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?
Brian