Review of draft-jabley-reverse-servers-01

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]