Shepherd writeup
rfc7286-10

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet 
Standard, Informational, Experimental, or Historic)? Why is this the 
proper type of RFC? Is this type of RFC indicated in the title page header? 

draft-ietf-alto-server-discovery is on the standards track (Proposed
Standard).

A standards track designation is being sought because the ALTO protocol
requires that an ALTO server be found so it can convey the network
information from the perspective of a network region.  Consequently a
discovery protocol is needed to help find an appropriate ALTO server.
The mechanics to discover an ALTO server will be best interpreted if
they are normatively specified in a standards-track RFC.

The proper type of track designation is included in the title page of
draft-ietf-alto-server-discovery.

(2) Document announcement

(i) Technical summary: This document specifies a sequence of steps that a
 resource consumer (i.e., an ALTO client) undertakes to find an appropriate
 ALTO server.

(ii) Working Group Summary: The draft was discussed extensively in the
 WG meetings as well as on the mailing list.  This particular document
 was the result of a merge of a draft discussing first-party discovery
 and another draft discussing third party discovery.  However, as the
 merged draft proceeded through the WG, it became clear that unifying
 first- and third-party discovery in a single draft is problemmatic.
 Therefore, the first- and third-party server discovery are now 
 separate drafts, with the third-party server discovery appearing in its
 own draft.  This implies that the draft under consideration 
 (draft-ietf-alto-server-discovery) is focused on first-party ALTO server
 discovery.

 During the Atlanta IETF meeting (IETF 85, November 2012) it was pointed
 out that there is some work on using HTTPS GET mechanism to discover the
 location of a given type of service (draft-jones-simple-web-discovery),
 and perhaps draft-ietf-alto-server-discovery could use the mechanism 
 mentioned in draft-jones-... instead of requiring a U-NAPTR lookup as
 is currently done.

 Discussion on the mailing list on this seem to weigh in favour of not
 using draft-jones-... since it is in its formative stages and there
 is nothing technically wrong with the specifications currently contained
 in draft-ietf-alto-server-discovery.

 At things stand right now, the WG is proceeding with 
 draft-ietf-alto-server-discovery in its current state; proponents of the
 mechanism mentioned in draft-jones-... will describe in a draft on how they
 forsee using it in the general problem of ALTO server discovery.  Subsequent
 to this, the WG can decide on next steps, i.e., whether to update the RFC
 that results from draft-ietf-alto-server-discovery or whether to publish
 a new and alternate first-party ALTO server discovery mechanism.

(iii) Document quality: There are no known implementations of the 
 mechanism specified in draft-ietf-alto-server-discovery, however, since
 this is a crucial aspect before ALTO services can be consumed, the WG
 believes that implementations will be forthcoming once the mechanism 
 is stable (as it appears now to be).  

 The document itself is well-written and reasonably precise.  There is 
 no need for a MIB doctor, or a media type expert.  

 The document has been shared with a DNS expert who weighed in 
 appropriately on Section 3 of the document.  More specifically,
 Olafur Gudmundsson provided an expert review on November 16, 2011
 addressing shortcomings in the -00 version of this draft.  The
 authors addressed the comments from Olaf in -03 of the draft, 
 and those changes have since been maintained as the draft 
 progressed.

(iv) Personnel: Vijay K. Gurbani is the document shepherd and Spencer
 Dawkins is the responsible AD.

(7) Has each author confirmed that any and all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 79 
have already been filed. If not, explain why?

 The authors were asked for IPR disclosures related to the IPR and the
 following are the results:
  Michael Scharf:     Not aware of any IPR.
  Haibin Song:        Indicated IPR has been filed.
  Nico Schwan:        Not aware of any IPR.
  Martin Stiemerling: Not aware of any IPR.
  Sebastian Kiesel:   Not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document? If 
so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

 An IPR disclosure was filed on 2013-01-25 and disclosed to the WG list
 (http://www.ietf.org/mail-archive/web/alto/current/msg01664.html).
 Subsequent to the disclosure, a second WGLC was issued 
 (http://www.ietf.org/mail-archive/web/alto/current/msg01667.html)
 to solicit additional input regarding the IPR.  The second WGLC
 was closed (http://www.ietf.org/mail-archive/web/alto/current/msg01706.html)
 after concluding that while there were some questions on the list regarding
 the IPR (it was written in Chinese and therefore not readable by the
 English-speaking population), there was nothing material that would 
 prevent the WG from moving the draft ahead towards standardization.

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

 The WG consensus behind the document is very strong.  The document has
 a long history in the WG and has been tracking the requirements listed
 in rfc6708 (ALTO Requirements) for server discovery.  The draft, in its
 various incarnations, has been presented at many ALTO WG face-to-face
 meetings.  The WG participants are comfortable with the contents of
 this draft and I am not aware of any WG member who has a disagreement
 with the draft.

(10) 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 publicly available.) 

 No participant of the WG or anyone else outside the WG has threatened 
 an appeal or otherwise indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this 
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts 
Checklist). Boilerplate checks are not enough; this check needs to 
be thorough. 
 
 There are not any additional ID nits to report.  

(12) Describe how the document meets any required formal review criteria, 
such as the MIB Doctor, media type, and URI type reviews. 

 The draft does not define any MIB metrics or new URIs.  As such, no
 formal MIB or URI review is required.  This document does define a 
 new U-NAPTR application service tag; to that extent and in view of
 the general DNS-ish nature of this draft, the draft has been 
 expert-reviewed by the DNS directorate in November 2011 (see response to
 (2)-iii).  Even though that review is dated, the mechanisms in the draft 
 on using DHCP and U-NAPTR were in the version of the draft that was reviewed
 in November 2011.

(13) Have all references within this document been identified as either 
normative or informative? 

 Yes.

(14) 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 plan for their completion? 

 No; all normative references are to published RFCs.

(15) Are there downward normative references references (see RFC 3967)? If 
so, list these downward references to support the Area Director in the 
Last Call procedure. 

 No.

(16) Will publication of this document change the status of any existing 
RFCs? Are those RFCs listed on the title page header, listed in the 
abstract, and discussed in the introduction? If the RFCs are not listed 
in the Abstract and Introduction, explain why, and point to the part of 
the document where the relationship of this document to the other RFCs is 
discussed. If this information is not in the document, explain why the 
WG considers it unnecessary. 

 The publication of this draft does not change the status of any
 existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations 
section, especially with regard to its consistency with the body of 
the document. Confirm that all protocol extensions that the document 
makes are associated with the appropriate reservations in IANA registries. 
Confirm that any referenced IANA registries have been clearly identified. 
Confirm that newly created IANA registries include a detailed specification 
of the initial contents for the registry, that allocations procedures for 
future registrations are defined, and a reasonable name for the new 
registry has been suggested (see RFC 5226). 

 The IANA section in the document asks IANA to register a U-NAPTR
 application service tag.  RFC4848 provides a template to register
 a U-NAPTR service tag.  The information in the draft matches what 
 is required in the template.

(18) List any new IANA registries that require Expert Review for 
future allocations. Provide any public guidance that the IESG would 
find useful in selecting the IANA Experts for these new registries.

 There aren't any new IANA registries that are required by the draft.

(19) Describe reviews and automated checks performed by the Document 
Shepherd to validate sections of the document written in a formal 
language, such as XML code, BNF rules, MIB definitions, etc.

 I have reviewed the draft and did not find any aspect that warrants
 additional scrutiny.  There isn't any ABNF grammar or MIB definitions
 in the draft.  There is an IANA consideration section and this 
 section corresponds to the required IANA template.

 As far as automated tools go, I depended upon the tools idnits checker, 
 which did not report anything untoward.
Back