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.