[DNSOP] draft-gersch-dnsop-revdns-cidr-01: Alternative Encoding for Names at Octet Boundaries

[Shane Amante <[e-mail]>]

I think this is a good draft.

I do have one comment, based on experimenting with both encoding a /16 in DNS zone files and the resulting lookups on those IP prefixes contained under it.  As this document progresses I would very much like to advocate that the WG considers picking a single method for encoding the prefixes in zone files and, just as importantly, that the only method be the one outlined in Section 5.3:
http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01#section-5.3

Ultimately, I found it somewhat confusing to obey the encoding rules defined in Section 5.1 wrt octet/nibble-aligned vs. non-octet/nibble-aligned IP prefixes.  As one real-world example, consider the case of a IPv4 /8, with a variety of octet vs. non-octet aligned prefixes allocated (for routing) and delegated (for DNS) to downstream customers.  In that case, tools use to encode in the DNS zone files, as well as look them up (e.g.: dig), must not use "m" notation for prefixes at /8, /16 and /24 boundaries.  However, for prefixes at non-octet aligned boundaries, (e.g.: /9, /18, /20, etc.), they do need to use "m" notation.  I believe the problem will only get substantially worse when considering nibble vs. non-nibble boundaries for IPv6 prefixes being encoded.

While the current draft has tried to do a good job prescribing the rules for encoding & looking up prefixes on octet/nibble vs. non-octet/non-nibble boundaries in Section 5.1, I've found that it is substantially more simple using a single naming scheme in Section 5.3 for all prefix lengths.  Thus, I would propose that the WG consider all IP prefixes be encoded as per what has been defined in Section 5.3.  Ultimately, I think this should result in simpler tools used to encode the zones and, just as importantly, tools that will be developed to look-up RRsets in these zones.

Lastly, FWIW, I agree with the practical operational considerations provided in paragraphs 2 - 4 of Section 5.3 as to why having the "m" sub-domain for holding the IP prefixes is a good thing, hence why I recommend that be the single approach.

I would welcome others thoughts on the matter.

-shane