(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.