(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?
Proposed Standard is requested and indicated in the title page header. It is
proper because all required elements of this profile are Proposed Standard with
multiple interoperable implementations, there are no competing proposals, and
no WG member objected at end of 2017 when asked if this should be changed to
Proposed Standard.
(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary:
This document defines the subset of the Babel routing protocol [RFC6126bis] and
its extensions that a Homenet router must implement, as well as the
interactions between HNCP [RFC7788] and Babel.
Working Group Summary:
When this draft was adopted by the WG in 2015, there was extremely contentious
debate regarding what protocol to select as the recommended homenet routing
protocol. It was agreed at that time that this draft would be adopted as
Experimental. Over the past 2 years, no other homenet routing protocol profiles
have been proposed. The Babel protocol has completed WG Last Call as a Proposed
Standard in babel WG.
There has also been considerable debate related to recommendations for securing
the Babel protocol and HNCP [RFC7788]. There appears to be general agreement
that it is acceptable to allow these protocols to operate without encryption or
signatures in the homenet environment. This is not meant to preclude further
work on cryptographically securing both protocols; the homenet and babel WGs
are continuing work on this.
Document Quality:
Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g.,
one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert
review, what was its course (briefly)? In the case of a Media Type review, on
what date was the request posted?
This document specifies a profile of the Babel protocol and Babel-specific HNCP
protocol elements, and not a protocol itself. There are multiple, interoperable
implementations of the Babel protocol (including the Babel source-specific
routing extension) and HNCP protocol and of the profile defined in this draft.
The number of requirements needed to specify the profile are minimal, and there
have been no major changes to the profile defined in this draft. Several people
have reviewed and provided comments, including one early security review (Leif
Johansson). The review of the base protocol definition is being done in the
babel WG.
Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd is Barbara Stark. Responsible AD is Terry Manderson.
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.
The entire draft was reviewed.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
No concerns.
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.
Security has been of particular concern. An early security review was done by
Leif Johansson.
(6) Describe any specific concerns or issues that the Document Shepherd has
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 WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.
No specific concerns or issues.
(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?
Yes.
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR has been filed.
(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?
There has been strong WG consensus that a routing protocol is needed for
homenet, and that a profile definition is needed to achieve zero-configuration.
Initially, the WG was very split as to which routing protocol to select. Those
who had wanted another protocol (IS-IS) have been largely silent on this Babel
profile. However, they also have not proposed a homenet profile for IS-IS (note
that it was initially agreed to have this babel profile draft be Experimental,
to allow for competing proposals). The WG as a whole does understand this
document and agrees that a profile is needed to ensure zero-configuration
interoperability. There is also agreement that this document describes a
reasonable zero-configuration profile for Babel.
(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.)
There have been no appeal threats. No extreme discontent has been expressed
since the adoption of this draft.
(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.
No issues or nits were found by the idnits tool or by the document shepherd.
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.
Not applicable.
(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. The normative specifications are advancing normally. Of the works in
progress, draft-ietf-babel-rfc6126bis is in WG Last Call and
draft-ietf-babel-source-specific is an active WG draft.
(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.
No.
(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).
There are no IANA considerations.
(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.
None.
(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.
Not applicable.