Draft Shepherd: Susan Hares
Draft Author: Donald Eastlake, Mingui Zhang, Radia Perlman, Ayan Banerjee, Anoop Ghanwani,
WG chairs: Susan Hares and Jon Hudson
AD: Alia Atlas
Early routing Area Review: Russ White - Nicely written, No Major points, No Minor points, 1 word Nit (-05 fixed).
Early secdir review: not done
Early IANA review: requested, not seen - but Michelle Cotton said "It's a Donald Eastlake draft - it is normally fine.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
This draft is targeted at Proposed Standard as indicated on the
title page. It changes mandatory provisions in previous Proposed
(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:
Since publication of the TRILL (Transparent Interconnection of Lots
of Links) base protocol in 2011, active development and deployment
of TRILL has revealed errata in RFC 6325 and areas that could use
clarifications or updates. This document provides known
clarifications, corrections, and updates to RFC 6325 and other
TRILL RFCs. It obsoletes RFC 7180, updates RFC 7177, updates RFC
7179, and updates RFC 6325.
Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?
No. Everyone one was pleased to get a 7180bis draft on the base specification.
Are there existing implementations of the protocol?
No specific implementations of these fixes, but this draft written Huawei
who is the largest producer of standard TRILL. Other standard TRILL suppliers
plan to implement.
The other non-Standard TRILL implementations (Brocade, cisco) have had
an input on these drafts, and are considering importing some of these changes to
No MIB Doctor, Yang Doctor required for this drft.
Document Shepherd: Susan Hares
Responsible Area Director: Alia Atlas
WG Chair: Susan Hares, Jon Hudson
(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 document shepherd did a line by line review, and discussed it with
the authors. It was run through Nits. Editorial pass was made prior to the
Routing Directorate review found one tiny nit.
IANA causual review (just after IETF 92) found no initial problems.
SEC-DIR and OPS-DIR Reviews not done.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Reviewing a major specification's "bis" to make sure enough people have reviewed it
ias always challenge. The co-authors represent many
of the major vendors who are deploying. Routing-Area directorate has reviewed this draft.
OPS-DIR should review this during the IESG final-review process.
(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
No. This draft is focused on TRILL mechanisms.
Any routing-area reviewer needs to be familiar with the
appropriate IESG specifications.
(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 special concerns.
(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?
(8) Has an IPR disclosure been filed that references this document?
No IPR disclosures.
(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?
Solid and Joyful! WG response as been "Thank you" since a base
specification "bis" draft makes other drafts clearer.
(10) Has anyone threatened an appeal or otherwise indicated extreme
(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.
All the possible nits found by the nits checker are not really
nits. They focus on the replacement of draft-ietf-trill-oam-fm
(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?
(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?
(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 down references but there is a reference to the
ISO/IEC IS-IS standard that the nits checker identifies as a
possible down reference.
(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?
As mentioned in the Abstract and Introduction, this draft obsoletes
RFC 7180 and updates RFCs 6325, 7177, and 7179. Appendix D
specifies how this draft differs from RFC 7180 and how it updates
the other three 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
1) IANA registries are clearly defined
2) Newly created IANA are clearly defined
3) A pre-submission IANA review has been requested.
(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.
No Expert Review Registries created.
(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.
No such checks required.
See earlier comment on nits.