Skip to main content

Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
draft-ietf-isis-rfc6326bis-03

Revision differences

Document history

Date Rev. By Action
2014-05-07
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-04-14
03 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-04-07
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-02-04
03 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-02-04
03 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2014-02-04
03 (System) IANA Action state changed to In Progress from Waiting on Authors
2014-02-03
03 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-02-03
03 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-02-03
03 (System) RFC Editor state changed to EDIT
2014-02-03
03 (System) Announcement was received by RFC Editor
2014-02-03
03 (System) IANA Action state changed to In Progress
2014-02-03
03 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-02-03
03 Amy Vezza IESG has approved the document
2014-02-03
03 Amy Vezza Closed "Approve" ballot
2014-02-01
03 Adrian Farrel IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-02-01
03 Adrian Farrel Ballot approval text was generated
2014-02-01
03 Adrian Farrel Ballot writeup was changed
2014-01-24
03 Donald Eastlake IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-01-24
03 Donald Eastlake New version available: draft-ietf-isis-rfc6326bis-03.txt
2014-01-24
02 Adrian Farrel Holding "point raised" for an IANA expert review.
2014-01-23
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Shawn Emery.
2014-01-23
02 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2014-01-23
02 Spencer Dawkins
[Ballot comment]
This draft is nicely written. Thank you for that.

I did have one comment. Please consider it along with any other comments you …
[Ballot comment]
This draft is nicely written. Thank you for that.

I did have one comment. Please consider it along with any other comments you receive.

In 2.2.3 Appointed Forwarders Sub-TLV

  o  Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
      appointment range, inclusive. To specify a single VLAN, the VLAN's
      ID appears as both the start and end VLAN. As specified in
      [RFC6439], appointing an IS forwarder on a port for a VLAN not
      enabled on that port has no effect. If the range specified is or
      includes the value 0x000 or 0xFFF, such values are ignored as they
      are not valid VLAN numbers and a port cannot be enabled for them.

and in 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV

      -  VLAN.start and VLAN.end: This VLAN ID range is inclusive.
        Setting both VLAN.start and VLAN.end to the same value
        indicates a range of one VLAN ID. If VLAN.start is not equal to
        VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as
        if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end
        and VLAN.end is 0xFFF, the sub-TVL is interpreted as if
        VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the
        sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000
        or both are 0xFFF, the sub-TLV is ignored.

I THINK these descriptions are saying the same thing, but the description in 2.3.6 was more precise and more clear to me. If they are saying the same thing, I'd suggest using the 2.3.6 description in both places.

For extra credit, the point from 2.2.3 that "0x000 and 0xFFF are not valid VLAN numbers and a port cannot be enabled for them" could usefully appear in both places.
2014-01-23
02 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-01-23
02 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2014-01-23
02 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-01-23
02 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-01-23
02 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Carlos Pignataro.
2014-01-22
02 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2014-01-22
02 Ted Lemon [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon
2014-01-22
02 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-01-22
02 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2014-01-22
02 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-01-22
02 Donald Eastlake IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-01-22
02 Donald Eastlake New version available: draft-ietf-isis-rfc6326bis-02.txt
2014-01-22
01 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-01-22
01 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2014-01-22)
2014-01-21
01 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-01-21
01 Jari Arkko
[Ballot comment]
Alexey Melnikov raised two valid points in his Gen-ART review. I'm hoping the draft is revised according to the discussion that took place …
[Ballot comment]
Alexey Melnikov raised two valid points in his Gen-ART review. I'm hoping the draft is revised according to the discussion that took place after the review.
2014-01-21
01 Jari Arkko Ballot comment text updated for Jari Arkko
2014-01-21
01 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-01-21
01 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-01-21
01 Benoît Claise
[Ballot comment]
From Carlos' OPS-DIR review:

This is a really well written document. It addresses operational considerations of backwards compatibility of the new protocol constructs …
[Ballot comment]
From Carlos' OPS-DIR review:

This is a really well written document. It addresses operational considerations of backwards compatibility of the new protocol constructs defined. Other considerations for operational impact are covered in the base protocol.

Nits: RFC 5342 was obsoleted by RFC 7042 and the pointer should probably be updated.
2014-01-21
01 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-01-21
01 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-01-20
01 Alexey Melnikov Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Alexey Melnikov.
2014-01-20
01 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2014-01-20
01 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-isis-rfc6326bis-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-isis-rfc6326bis-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about some of the IANA actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions IANA must complete.

First, IANA has registered the the Group Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type 145) in the TLV Codepoints Registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints/

IANA believes that the registration request contained in section 5.1 of the current document has been completed.

Second, section 5.2 of the current document appears to request the registration of a number of new sub-TLVs in the registry located at:

http://www.iana.org/assignments/isis-tlv-codepoints/

IANA Question --> Is a new registry being created in section 5.2 of the document?  If a new registry is being created, could the editors provide more specification regarding the appearance of the registry, its maintenance rules and structure?  If the information in section 5.2 is intended to update existing registries, could the editors provide more specification about which registries and subregistries are being updated?

Third, in the IS-IS PDU registry also located at:

http://www.iana.org/assignments/isis-tlv-codepoints/

the references that currently point to [RFC6326] will be changed to [ RFC-to-be ].

Fourth, a new registry is to be created in the TRILL Parameters Registry - located at: http://www.iana.org/assignments/trill-parameters/ - called the TRILL-VER Sub-TLV Capability Flags subregistry.  This new registry will be maintained via IETF Review as defined in RFC 6226.  The initial structure of the registry is as follows:

Bit  Description                      Reference
=== =======                    ===== 0    Affinity sub-TLV support.        [Affinity]
1-13  Available
4-31  Extended header flag support.    [ExtendHeader]

[Affinity] and [ExtendHeader] are currently Internet-Drafts and would be early registrations in the new registry.

QUESTION: Are values 1-13 "available" for assignments?  If so,
should the authors use the term "Unassigned" as defined in RFC5226?


Fifth, a new registry is to be created in the TRILL Parameters Registry - located at: http://www.iana.org/assignments/trill-parameters/ - called the PORT-TRILL-VER Sub-TLV Capability Flags subregistry.  This new registry will be maintained via IETF Review as defined in RFC 6226.  The initial structure of the registry is as follows:

Bit  Description                      Reference
=== =======                    ===== 0    Hello reduction support.          [ClearCorrect]
1-2  Available
3-13  Hop-by-hop extended flag support. [ExtendHeader]
4-31  Available

[ClearCorrect] and [ExtendHeader] are currently Internet-Drafts and would be early registrations in the new registry.

QUESTION: Are values 1-2 and 4-31 "available" for new assignments?  If
so, should the authors use the term "Unassigned" as defined in RFC5226?

Sixth, a new registry is also to be created in the TRILL Parameters Registry - located at: http://www.iana.org/assignments/trill-parameters/ - called the TRILL Neighbor TLV NEIGHBOR RECORD Flags subregistry.  This new registry will be maintained via Standards Action as defined in RFC 6226.  The initial structure of the registry is as follows:

Bit Short Name  Description            Reference
=======  =======          =====0  Fail      Failed MTU test.        [RFC6325]
1  OOMF      Offering OOMF service.  [ClearCorrect]
2-7  -          Available.

[ClearCorrect] is currently Internet-Drafts and would be early registrations in the new registry.

QUESTION: Are values 2-7 "available" for new assignments?  If so,
should the authors use the term "Unassigned" as defined in RFC5226?

IANA understands that these six actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2014-01-20
01 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-01-16
01 Adrian Farrel Ballot has been issued
2014-01-16
01 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-01-16
01 Adrian Farrel Created "Approve" ballot
2014-01-16
01 Adrian Farrel Ballot writeup was changed
2014-01-12
01 Adrian Farrel Placed on agenda for telechat - 2014-01-23
2014-01-09
01 Jean Mahoney Request for Last Call review by GENART is assigned to Alexey Melnikov
2014-01-09
01 Jean Mahoney Request for Last Call review by GENART is assigned to Alexey Melnikov
2014-01-09
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2014-01-09
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Pignataro
2014-01-09
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2014-01-09
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2014-01-08
01 Adrian Farrel
(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? …
(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.html
  http://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.
2014-01-08
01 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-01-08
01 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transparent Interconnection of Lots of …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS) to Proposed Standard

The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-01-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  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 specifies the data formats and code
  points for the IS-IS extensions to support TRILL. These data formats
  and code points may also be used by technologies other than TRILL.
  This document obsoletes RFC 6326.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-isis-rfc6326bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-isis-rfc6326bis/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2159/



2014-01-08
01 Amy Vezza State changed to In Last Call from Last Call Requested
2014-01-08
01 Adrian Farrel Last call was requested
2014-01-08
01 Adrian Farrel Ballot approval text was generated
2014-01-08
01 Adrian Farrel Ballot writeup was generated
2014-01-08
01 Adrian Farrel State changed to Last Call Requested from AD Evaluation
2014-01-08
01 Adrian Farrel Last call announcement was changed
2014-01-08
01 Adrian Farrel Last call announcement was generated
2014-01-08
01 Adrian Farrel Last call announcement was generated
2014-01-08
01 Adrian Farrel
(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? …
(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.

(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.html
  http://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.

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

(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.
2014-01-08
01 Adrian Farrel Changed consensus to No from Yes
2014-01-08
01 Adrian Farrel Document shepherd changed to Adrian Farrel
2013-12-10
01 Adrian Farrel State changed to AD Evaluation from Publication Requested::Point Raised - writeup needed
2013-12-09
01 Christian Hopps Document shepherd changed to Hannes Gredler
2013-10-03
01 Adrian Farrel Need a shepherd write-up
2013-10-03
01 Adrian Farrel State changed to Publication Requested::Point Raised - writeup needed from Publication Requested
2013-10-01
01 Hannes Gredler IETF WG state changed to Submitted to IESG for Publication
2013-10-01
01 Hannes Gredler IESG state changed to Publication Requested
2013-10-01
01 Hannes Gredler State Change Notice email list changed to isis-chairs@tools.ietf.org, draft-ietf-isis-rfc6326bis@tools.ietf.org
2013-10-01
01 Hannes Gredler Responsible AD changed to Adrian Farrel
2013-10-01
01 Hannes Gredler Working group state set to Submitted to IESG for Publication
2013-10-01
01 Hannes Gredler IESG state set to Publication Requested
2013-10-01
01 Hannes Gredler IESG process started in state Publication Requested
2013-10-01
01 Hannes Gredler Intended Status changed to Proposed Standard from None
2013-10-01
01 Hannes Gredler Changed consensus to Yes from Unknown
2013-09-17
01 Hannes Gredler IETF WG state changed to In WG Last Call from WG Document
2013-07-31
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-isis-rfc6326bis-01
2013-04-09
01 Donald Eastlake New version available: draft-ietf-isis-rfc6326bis-01.txt
2012-10-15
00 Donald Eastlake New version available: draft-ietf-isis-rfc6326bis-00.txt