(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 as stated in the title page header. This document
normatively specifies various IS-IS codes points used by TRILL, is
normatively referenced by a number of TRILL documents, and
obsoletes RFC 6326 which was a 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:
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol provides optimal pair-wise data frame forwarding without
configuration in multi-hop networks with arbitrary topology and link
technology, and support for multipathing of both unicast and
multicast traffic.
This document, in conjunction with RFC 6165, specifies the data
formats and code points for the IS-IS [ISO-10589] extensions to
support TRILL. It obsoletes RFC 6326, which corresponded to the
base TRILL protocol as the TRILL Working Group passed it up to the
IESG in 2009. There has been substantial development of TRILL since
them. The changes from RFC 6326 are briefly summarized in the
Introduction and a full list is given in Section 7.
Working Group Summary:
The need for an IPR disclosure was found after the first Working
Group Last Call resulting in a second Working Group Last Call. As a
non-controversial update extending a previous RFC, there was
relatively little discussion.
Document Quality:
The document is of good quality. The vast majority of the code
points and code points specified in this document are in use in
shipping TRILL or similar control plane code from multiple
equipment manufacturers. The predecessor document RFC 6326 was
thoroughly review by Mike Shand and this revision is based on
RFC 6326 incorporating the results of that review.
Personnel:
Document Shepherd: Adrian Farrel
Responsible Area Director: Adrian Farrel
(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 document shepherd has reviewed the current version of the
document including running the usual tools and discussing the idnits
issues with the authors. The small number of comments raised will be
fixed during IETF last call.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. The document is originated by the Trill community and reviewed
there, but is a product of the ISIS working group and has had
adequate review in that context. There has been, perhaps, too little
comment and discussion from the ISIS WG, but this is in part because
it is a bis and in part because the ISIS WG is primarily concerned
with the stability of ISIS and less concerned with the new use made
for layer 2 by TRILL.
(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.
No.
(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.
More comments from the WG on this document might have been nice but
it is just a non-controversial updating and expansion of RFC 6325
and RFC 6325 that was thoroughly reviewed with extensive comments
from Mike Shand.
(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. See ISIS WG mailing list messages for December 2nd and 4th:
http://www.ietf.org/mail-archive/web/isis-wg/current/maillist.html
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Yes. See https://datatracker.ietf.org/ipr/2159/ This IPR disclosure
was announced on the WG mailing list when it was filed and when the
subsequent WGLC was started. There were no WG comments on the
disclosure.
http://www.ietf.org/mail-archive/web/isis-wg/current/msg03234.htmlhttp://www.ietf.org/mail-archive/web/isis-wg/current/msg03248.html
(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?
This is a non-controversial update of the previous approved RFC
6326. There was consensus for the document with supporting comments
and no opposing comments. The ISIS WG is normally very vocal if it
has issues.
(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.
(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.
The reference to RFC 5342 should be updated to refer to RFC 7042.
(There are a number of other false warnings from the nits checker.)
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such formal review required.
(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?
All normative references are to approved standards or standards
track documents, either RFCs or drafts in the RFC Editor's queue.
(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.
There are no downward normative references. There is a reference to
the ISO/IEC IS-IS standard which the nits checks flags as suspicious.
(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?
This document obsoletes RFC 6326 as stated in the abstract,
introduction, and at the top left of the title page.
(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).
Because this document is concerned with the assignment of code
points, the IANA Considerations are fairly extensive. All of the
assignments that were made in RFC 6326 and the new assignments
added in this document are listed. The several referenced IANA
IS-IS and TRILL Parameters registries are clearly identified. The
three newly created TRILL Parameters sub-registries have reasonable
names and their initial contents and allocation procedures are
defined.
The document adds 3 sub-registries under the TRILL Parameters
Registry.
(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 of the registries created by this document require Expert
Review.
(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.
There is no such formal language in this document.