On 30 Mar 2012, at 12:09, Ondřej Surý wrote: > Hi Joseph, > > since I am not sure if you understood my point (I am not sure if I was able > to understand it myself :), I am summarizing it to the mailing list. > > I like the direction of your work, but I miss a way how to put more stuff > under > the named prefix. > > I would like you to update RFC2317 together with your document, so the end > customers don't have two distinct trees in their DNS infrastructure.
+1 > F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate > it to the customer, how do I put my PTRs in? The block owner would still have > to delegate another "dummy" prefix with CNAMEs and you have to handle it in > separate zone. > > BTW one more observation. Since you don't have to do any zone cuts in the > binary > part, why not merge them into just one label? E.g. something like > 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
