On 10.11.2015 15:22, Tony Finch wrote: > I have published a new version of my Classless IN-ADDR.ARPA draft. This > incorporates some miscellaneous suggestions from before the IETF meeting, > and Petr's suggestions from last week. > > All comments and suggestions welcome! > > Petr, I've cut down your security considerations fairly viciously; please > shout if you think I have cut too much! I dropped the paragraph about > UPDATE security since that is covered in RFC 2136. I also dropped the last > paragraph since the earlier part seems to just repeat what the previous > paragraph said, and the later part seems to suggest some special server > side processing; if server-side processing is a real suggestion it needs a > real spec.
Good. The mention about server-side checks was just an example showing that unauthenticated updates might be good enough in certain situations but this example is pointless because you have removed references to plain RFC 2136 updates. I'm fine with that. To answer some of questions from the draft: > Appendix B. Questions for reviewers > > Is the $GENERATE section a good idea? Should it be ditched? Or > maybe promoted to its own document? I would prefer a separate document because this is really a separate issue. > RFC 2317 is BCP 20. Should this document be moved to the standards > track, since it updates RFC 2136? Or should the UPDATE amendment be > a separate document? Yes, I believe that standards track is appropriate. It can stay in one document so readers have the context and understand why we are making the change. > Is the indirection problem specific to classless reverse DNS (which > is the approach I took) or does it apply to the forward DNS as well? > Suggestions for wording welcome. Personally I would mention that this problem is generic to make application developers aware of it. In the previous exchange I was proposing text similar to this: Please note that this problem is generic. For names outside of IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation to decide if it is necessary to update alias itself or if it is necessary to update endpoint records and thus the method described in the section 9.2 needs to be applied. Is there something wrong with it? It should be just informational. > Is the detailed UPDATE behaviour sensible? Definitely yes :-) -- Petr Spacek _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
