|
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@xxxxxxxxx] Sent:
Friday, January 15, 2010 4:03 AM To:
Tina TSOU; Bernard_Aboba@xxxxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf