[AFS3-std] PROTO writeup for draft-allbery-afs-srv-records-04.txt

[Jeffrey Hutzelman]

[ Normally, I'd also copy iesg-secretary on this, but in this case, I'm 
omitting that, since the document has already gone fairly far through the 
process, and a "publication requested" would just confuse things ].


(1.a)  Who is the Document Shepherd for this document?  Has the
       Document Shepherd personally reviewed this version of the document
       and, in particular, does he or she believe this version is ready
       for forwarding to the IESG for publication?

       >> The Document Shepherd for this document is Jeffrey Hutzelman,
       >> <jhutz@cmu.edu>.  I have reviewed this document, and I believe
       >> it is ready for IETF-wide review and publication as a Proposed
       >> Standard.

(1.b)  Has the document had adequate review both from key members of
       the interested community and others?  Does the Document Shepherd
       have any concerns about the depth or breadth of the reviews that
       have been performed?

       >> This document has been reviewed and discussed extensively
       >> among the AFS development community, as well as receiving
       >> review within the IETF.

(1.c)  Does the Document Shepherd have concerns that the document
       needs more review from a particular or broader perspective, e.g.,
       security, operational complexity, someone familiar with AAA,
       internationalization or XML?

       >> No, I have no such concerns.

(1.d)  Does the Document Shepherd have any specific concerns or
       issues with this document that the Responsible Area Director
       and/or the IESG should be aware of?  For example, perhaps he or
       she is uncomfortable with certain parts of the document, or has
       concerns whether there really is a need for it.  In any event, if
       the interested community has discussed those issues and has
       indicated that it still wishes to advance the document, detail
       those concerns here.

       >> No, I have no such concerns.

(1.e)  How solid is the consensus of the interested community behind
       this document?  Does it represent the strong concurrence of a few
       individuals, with others being silent, or does the interested
       community as a whole understand and agree with it?

       >> I believe this document to represent the consensus of the
       >> AFS community, both in its overall intent to introduce use
       >> of SRV records to locate AFS database services and deprecate
       >> use of AFSDB records for this purpose, and in the details of
       >> its specification for how SRV RR's should be applied to AFS.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
       discontent?  If so, please summarise the areas of conflict in
       separate email messages to the Responsible Area Director.  (It
       should be in a separate email because this questionnaire is
       entered into the ID Tracker.)

       >> There have been no expressions of discontent.

(1.g)  Has the Document Shepherd personally verified that the
       document satisfies all ID nits?  (See
       http://www.ietf.org/ID-Checklist.html and
       http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
       enough; this check needs to be thorough.  Has the document met all
       formal review criteria it needs to, such as the MIB Doctor, media
       type and URI type reviews?

       >> The id-nits tool finds no problems with this document.
       >> Additionally, I have verified that the document satisfies
       >> those requirements not checked by the automatic tool.
       >> Note that this document makes references to "AFS", which
       >> is the name of a distributed filesystem product and protocol.
       >> Historically, "AFS" was abbreviation for "Andrew File System",
       >> but that designation has long since been dropped, and today
       >> "AFS" is a proper name with no expansion.

(1.h)  Has the document split its references into normative and
       informative?  Are there normative references to documents that are
       not ready for advancement or are otherwise in an unclear state?
       If such normative references exist, what is the strategy for their
       completion?  Are there normative references that are downward
       references, as described in [RFC3967]?  If so, list these downward
       references to support the Area Director in the Last Call procedure
       for them [RFC3967].

       >> References are properly split.  This document, intended for the
       >> standards track, contains a normative downreference to RFC1183,
       >> an Experimental RFC which defines the AFSDB RR.  The present
       >> document deprecates the use of AFSDB records as describe in
       >> RFC1183 for location of AFS database services, but in the name
       >> of interoperability, recommends that cells advertising AFS
       >> database services via SRV RR's also do so via AFSDB RR's when
       >> possible.

(1.i)  Has the Document Shepherd verified that the document IANA
       consideration section exists and is consistent with the body of
       the document?  If the document specifies protocol extensions, are
       reservations requested in appropriate IANA registries?  Are the
       IANA registries clearly identified?  If the document creates a new
       registry, does it define the proposed initial contents of the
       registry and an allocation procedure for future registrations?
       Does it suggested a reasonable name for the new registry?  See
       [I-D.narten-iana-considerations-rfc2434bis].  If the document
       describes an Expert Review process has Shepherd conferred with the
       Responsible Area Director so that the IESG can appoint the needed
       Expert during the IESG Evaluation?

       >> This document contains a logically empty IANA considerations
       >> section.  Because the names it uses for SRV record service
       >> and proto fields have appeared in the port and protocol
       >> registries for some time, no new IANA actions are needed.

(1.j)  Has the Document Shepherd verified that sections of the
       document that are written in a formal language, such as XML code,
       BNF rules, MIB definitions, etc., validate correctly in an
       automated checker?

       >> This document contains an example zone file illustrating
       >> the use of AFSDB records.  This example zone was successfully
       >> validated using BIND 9.5.0.

(1.k)  The IESG approval announcement includes a Document
       Announcement Write-Up.  Please provide such a Document
       Announcement Writeup?  Recent examples can be found in the
       "Action" announcements for approved documents.  The approval
       announcement contains the following sections:


Technical Summary

   This document specifies how to use DNS (Domain Name Service) SRV RRs
   (Resource Records) to locate services for the AFS distributed file
   system and how the priority and weight values of the SRV RR should be
   interpreted in the server ranking system used by AFS.  It deprecates
   use of the AFSDB RR to locate AFS cell database servers and provides
   guidance for backward compatibility.

Working Group Summary

   This document represents the consensus of the AFS community to
   deprecate the use of DNS AFSDB resource records to locate AFS
   database services, as described in RFC1183, in favor of using SRV
   records.  While the AFS protocols themselves are not the subject
   of any IETF work, this document is being advanced via the IETF
   because it updates previous IETF extensions to the DNS.

Document Quality

   Major AFS client implementors have indicated plans to implement
   support for use of SRV records as described by this document.
   In addition, a variety of developers and operators have indicated
   a desire to publish and use SRV records as described here.  There
   was substantial discussion surrounding the mapping of weight and
   priority information advertised via these records onto the server
   ranking system used by current AFS implementations, which resulted
   in the advice given in section 4.1.