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 |