Hi, On Mon, May 20, 2013 at 9:06 PM, John C Klensin <john-ietf@xxxxxxx> 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@xxxxxxxxx > 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 >