I reviewed the document draft-jabley-reverse-servers-01 in general and for its operational impact.
Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track This document specifies a naming scheme for the nameservers which serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. Is the document readable? Yes. Does it contain nits? Output of IDNITS: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- ** There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3152 (Obsoleted by RFC 3596) Summary: 1 error (**), 1 warning (==), 1 comment (--). Is the document class appropriate? Not sure. The naming scheme for servers that host the IN-ADDR.ARPA and IP6.ARPA seems like an operational issue, that might be more appropriate for a BCP than a Proposed Standard. Is the problem well stated? Yes. Section 1 states: The naming scheme specified in this document allows IN-ADDR.ARPA and IP6.ARPA be delegated to two different sets of nameservers, to facilitate operational separation of the infrastructure used to serve each zone. This separation might help ensure that an operational failure of IN-ADDR.ARPA servers does not impact IPv6 reverse lookups as collateral damage, for example. Is the problem really a problem? Yes. As noted in Section 1: The secure and stable hosting of the IN-ADDR.ARPA and IP6.ARPA zones is critical to the operation of the Internet, since many applications rely upon timely responses to reverse lookups to be able to operate normally. Does the document consider existing solutions? Yes. As noted in Section 1: At the time of writing, the IN-ADDR.ARPA zone is served by a subset of the DNS root servers, and IP6.ARPA by servers operated by APNIC, ARIN, ICANN, LACNIC and the RIPE NCC (see Appendix A). Does the solution break existing technology? No. Does the solution preclude future activity? No. Is the solution sufficiently configurable? Yes. Can performance be measured? How? Yes. Presumably existing DNS performance measurement techniques can be used to determine how well the scheme is working. Does the solution scale well? Yes. As noted in Section 2, the authors have thought through issues such as fate sharing, compression and points of failiure: The IN-ADDR-SERVERS.ARPA zone will be delegated to the same set of servers as IN-ADDR.ARPA. IPv4 and IPv6 glue records for each of those servers will be added to the ARPA zone. The IN-ADDR-SERVERS.ARPA and IN-ADDR.ARPA zones are delegated to the same servers since they are both dedicated for a single purpose and hence can reasonably share fate. All servers in the set are named under the same domain to facilitate label compression. Since glue for all servers will exist in the ARPA zone, the use of a single domain does not present a practical single point of failure. Is Security Management discussed? No. As noted in Section 6: This document introduces no additional security risks for the Internet. ------------------------------------------------ From: Romascanu, Dan (Dan) [mailto:[email protected]] Sent: Friday, January 15, 2010 4:03 AM To: Tina TSOU; [email protected] Cc: Ron Bonica Subject: RE: Operations Directorate Review Hi Bernard, This document is on the agenda of the IESG telechat on 1/21. I did not see yet your OPS-DIR review, if I have missed it, or if you complete it until 1/20 please resend or send it to the OPS-DIR list and to the document authors. Thanks and Regards, Dan
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
