At Mon, 20 May 2013 21:06:53 -0400, John C. Klensin wrote: > > I've reread 5507 and did so again before writing my second note > today. I don't see that it helps. I was mostly referring to the discussion in section 3.1. > 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. The usual criteria are: - Does the entire set of records need to be retrieved as an atomic unit (eg, to avoid internal consistency problems)? If so, it should be a single RRset, thus a single new type. - If there's no internal consistency requirement, might an application reasonably want to retrieve only one flavor of data (eg, 48-bit EUIs in this case)? If so, multiple RRsets make more sense, thus multiple new types. - Is the total size of an RRset likely to be large if all cases are lumped into a single type? If so, multiple new types might be better, because large RRsets are a problem (amplification attacks, message truncation, DNSSEC verification failure due to truncation, etcetera ad nausium). If none of the above apply, it's mostly a matter of taste. My own bias is against sub-typing, both because we've been burned before by misguided (albeit well-intentioned) use of sub-typing and also because, other things being equal, I prefer the simplest RDATA structure that will get the job done (parsing code for this stuff is often written in low-level languages which make stupid coding mistakes all too easy, so, other things being equal, I prefer to reduce the number of gratuitous opportunities for code exploits). But if there really is no reason to expect that an application retrieving EUIs have any sane need to say it only wants the 48-bit ones or whatever, then a single RR type may be appropriate. I don't understand the intended uses well enough to have an informed opinion. > 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. Fair enough.