Hi,
On Mon, May 20, 2013 at 9:06 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
...
...
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 you are getting an address to connect with a device on an Ethernet
link, you just have to know what the right address size is. After
whatever start of frame mark there is, it is just DA-SA and using the
wrong size MAC addresses isn't going to work.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
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