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:dromasca(_at_)avaya(_dot_)com]
Sent: Friday, January 15, 2010 4:03 AM
To: Tina TSOU; Bernard_Aboba(_at_)hotmail(_dot_)com
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf