Hi Ed,
On 2013-04-15, at 13:14, Edward Lewis <[email protected]> wrote:
> I have no problem with this in spirit. But I always wonder why the
> presentation formats, as in section 3.2 and 4.2, have MUST concerning how the
> record is "written." I've never considered the presentation format to be
> subject to a standard...I realize that's just my opinion, but the on-the-wire
> format is what is subject to interoperability concerns.
I think that's valid.
My thinking when I wrote the draft is that there are two areas where interop is
important: (a) on the wire, where incompatibility would simply break
everything, and (b) in the canonical zone file format, where incompatibility
would annoy operators (who might have to generate two different zones to be
served by two different nameservers, for example).
The first draft specified MUSTs with aa:bb:cc:dd:ee style notation, since
that's what I see most often on network gear and in Unix. I was subsequently
shown an IEEE document that included aa-bb-cc-dd-ee as a canonical
representation, so I changed it.
> The document can have the MUSTs but I'd prefer SHOULDs. It's right that
> there's only one way these addresses ever get written, so the MUST seems
> logical, OTOH, it just seems over the top to demand it be written one way or
> another. I certainly understand it is INTENDED to be written as documented,
> but is it a sin if I implement something else? (How would an alternate form
> hinder interoperability.)
I think a SHOULD is too weak though. I spend a lot of time parsing the output
from tools that decode DNS messages, and if different tools used different
presentation formats for the same wire data it would make my life hard.
I could specify that both formats were permitted on input (parse zone file) or
output (generate zone file). I certainly agree that the canonical IEEE format
is not the most common, at least with the systems I most frequently use.
> Apparently I am a little cranky today.
One too many Beijing hamburgers.
Joe
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
