Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol
draft-ietf-trill-vendor-channel-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-05-15
|
01 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-24
|
01 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-04-23
|
01 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-03-26
|
01 | Gunter Van de Velde | Closed request for Telechat review by OPSDIR with state 'No Response' |
2018-03-15
|
01 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2018-03-14
|
01 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-03-14
|
01 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-03-14
|
01 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-03-13
|
01 | (System) | IANA Action state changed to In Progress |
2018-03-12
|
01 | (System) | RFC Editor state changed to EDIT |
2018-03-12
|
01 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-12
|
01 | (System) | Announcement was received by RFC Editor |
2018-03-12
|
01 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-03-12
|
01 | Amy Vezza | IESG has approved the document |
2018-03-12
|
01 | Amy Vezza | Closed "Approve" ballot |
2018-03-12
|
01 | Amy Vezza | Ballot approval text was generated |
2018-03-09
|
01 | Alia Atlas | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-03-09
|
01 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-03-09
|
01 | Cindy Morgan | New version available: draft-ietf-trill-vendor-channel-01.txt |
2018-03-09
|
01 | (System) | Secretariat manually posting. Approvals already received |
2018-03-09
|
01 | Cindy Morgan | Uploaded new revision |
2018-03-08
|
00 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-03-08
|
00 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-03-07
|
00 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-03-07
|
00 | Ben Campbell | [Ballot comment] Apologies, I ran out of time for this one. |
2018-03-07
|
00 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2018-03-07
|
00 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-03-07
|
00 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-03-07
|
00 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-03-07
|
00 | Kathleen Moriarty | [Ballot comment] Could you please expand the text in the security considerations section as to why security properties (integrity, authentication, and encryption since they are … [Ballot comment] Could you please expand the text in the security considerations section as to why security properties (integrity, authentication, and encryption since they are not part of RBridge Channel messages except when explicitly added on in the extension draft) were not built in? I'm assuming it is the limited scope of use for the protocol. I am glad that options exist to add it in, but wish the text were a bit more encouraging so that would actually happen. Vendors need to be motivated to provide these options for customers who may want to use them, without that motivation, the features won't be provided. |
2018-03-07
|
00 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2018-03-07
|
00 | Kathleen Moriarty | [Ballot comment] Could you please expand the text int he security considerations section as to why security properties (integrity, authentication, and encryption since they are … [Ballot comment] Could you please expand the text int he security considerations section as to why security properties (integrity, authentication, and encryption since they are not part of RBridge Channel messages except when explicitly added on in the extension draft) were not built in? I'm assuming it is the limited scope of use for the protocol. I am glad that options exist to add it in, but wish the text were a bit more encouraging so that would actually happen. Vendors need to be motivated to provide these options for customers who may want to use them, without that motivation, the features won't be provided. |
2018-03-07
|
00 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-03-07
|
00 | Alissa Cooper | [Ballot comment] Thanks for answering my DISCUSS question. I agree with the Gen-ART reviewer that the text in the Acknowledgements section is not appropriate. See … [Ballot comment] Thanks for answering my DISCUSS question. I agree with the Gen-ART reviewer that the text in the Acknowledgements section is not appropriate. See RFC 7322. |
2018-03-07
|
00 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2018-03-07
|
00 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-03-06
|
00 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-03-06
|
00 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-03-06
|
00 | Alissa Cooper | [Ballot comment] I agree with the Gen-ART reviewer that the text in the Acknowledgements section is not appropriate. See RFC 7322. |
2018-03-06
|
00 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2018-03-06
|
00 | Alissa Cooper | [Ballot discuss] I'm having trouble understanding what function this specification serves given that the RBridge Channel Protocol registry has a range reserved already for private … [Ballot discuss] I'm having trouble understanding what function this specification serves given that the RBridge Channel Protocol registry has a range reserved already for private use and that the document doesn't specify any requirements around vendor-specific protocol semantics. So any implementation of this that needs to interoperate with another implementation will need to do so according to some specification generated by the vendor, and that specification can select a code point from the private use range. What does allocating a single code point for all such vendor-specific protocols achieve, aside from specifying a structured way of conveying the OUI/CID (which seems superfluous anyway for multiple implementations from a single vendor interoperating with each other)? |
2018-03-06
|
00 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2018-03-06
|
00 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-03-06
|
00 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-03-02
|
00 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-02
|
00 | Alia Atlas | Ballot has been issued |
2018-03-02
|
00 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2018-03-02
|
00 | Alia Atlas | Created "Approve" ballot |
2018-03-02
|
00 | Alia Atlas | Ballot writeup was changed |
2018-02-26
|
00 | Joel Halpern | Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2018-02-26
|
00 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-02-26
|
00 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2018-02-23
|
00 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-02-23
|
00 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-23
|
00 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-trill-vendor-channel-00. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-trill-vendor-channel-00. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the RBridge Channel Protocols registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at: https://www.iana.org/assignments/trill-parameters/ a single new registration is to be made as follows: Protocol: [ TBD-at-Registration ] Description: Vendor Specific RBridge Channel Reference: [ RFC-to-be ] Second, a new registry called Vendor RBridge Channel Error Codes will be created. The new registry is to be on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at: https://www.iana.org/assignments/trill-parameters/ The new registry will be managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: Code Description Reference ---------+-------------------------------+------------- 0 No error [ RFC-to-be ] 1 Message too short [ RFC-to-be ] 2 Unknown OUI/CID [ RFC-to-be ] 3 Unknown Sub-Protocol [ RFC-to-be ] 4 Unknown Sub-Version [ RFC-to-be ] 0x05-0x0F Unassigned 0x10-0xFE Reserved for vendor use [ RFC-to-be ] 0xFF Reserved [ RFC-to-be ] IANA Question --> Should the first five values in the new registry be changed as follows: from 0 to 0x00 from 1 to 0x01 from 2 to 0x02 from 3 to 0x03 from 4 to 0x04 The IANA Services Operator understands that these are the only actions required 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 meant only to confirm the list of actions that will be performed. Thank you, Amanda Baber Lead IANA Services Specialist |
2018-02-22
|
00 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Dacheng Zhang |
2018-02-22
|
00 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Dacheng Zhang |
2018-02-21
|
00 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Will LIU |
2018-02-21
|
00 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Will LIU |
2018-02-20
|
00 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-02-20
|
00 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-03-06): From: The IESG To: IETF-Announce CC: draft-ietf-trill-vendor-channel@ietf.org, Susan Hares , akatlas@gmail.com, trill-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2018-03-06): From: The IESG To: IETF-Announce CC: draft-ietf-trill-vendor-channel@ietf.org, Susan Hares , akatlas@gmail.com, trill-chairs@ietf.org, trill@ietf.org, shares@ndzh.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TRILL: Vendor Specific TRILL Channel Protocol) to Proposed Standard The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Vendor Specific TRILL Channel Protocol' 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 2018-03-06. 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 is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor specific messages over the RBridge Channel facility. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-20
|
00 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-02-20
|
00 | Alia Atlas | Last call was requested |
2018-02-20
|
00 | Alia Atlas | Last call announcement was generated |
2018-02-20
|
00 | Alia Atlas | Ballot approval text was generated |
2018-02-20
|
00 | Alia Atlas | Ballot writeup was generated |
2018-02-20
|
00 | Alia Atlas | IESG state changed to Last Call Requested from Publication Requested |
2018-02-20
|
00 | Susan Hares | Shepherd write-up version: 2/24/2012. (1) RFC type: Proposed standard status: On header. Why? (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide … Shepherd write-up version: 2/24/2012. (1) RFC type: Proposed standard status: On header. Why? (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 is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor specific messages over the RBridge Channel facility. Working Group Summary Working group pushed for this draft even though it came at the end of work. It provides a way for TRILL vendors to send vendor specific messages. This feature will allow the vendors to innovate and then come back to IETF with "baked" features for standardizing. Document Quality No protocol implementations, but it is an Personnel Who is the Document Shepherd? Who is the Responsible Area Director? (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. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This is an extension of an earlier idea discussed by WG at length. It would be good to get the normal reviews (OPS-DIR, RTG-DIR, SEC-DIR, and GEN-ART). (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. This is a TRILL mechanisms so normal reviews will be fine. (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? This is a good draft for the WG to end its work on. It allows vendors to develop new features without returning immediately to the IETF standardization. (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. Donald Eastlake https://mailarchive.ietf.org/arch/msg/trill/-HQ8v6g9G6LOfLbiNwI094H5nFY Ayan Banerjee https://mailarchive.ietf.org/arch/msg/trill/XgNgozYhRTNJagX9TEWj11dlYBE Yizhou Li + Weiguo Hao (These two author was on Chinese New Year Holiday during the end of the WG LC. This author will probably respond within a few days). (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no (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 because the vendors (IPInfusion and Huawei) and some other vendors want a path forward for additions. (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 - the push to get this in came from many directions. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (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. (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? No changes to exisitng RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. IANA is requested to allocate TBD for the Vendor Specific RBridge Channel Protocol from the range of RBridge Channel protocols allocated by Standards Action. IANA is requested to establish a registry as follows on the TRILL Parameters web page indented under RBridge Channel Error Codes after RBridge Channel SubError Codes: Registry: Vendor RBridge Channel Error Codes Registration Procedures: Standards Action Reference: (This document) Code Description Reference ---- ----------- --------- 0 No error This document 1 Message too short This document 2 Unknown OUI/CID This document 3 Unknown Sub-Protocol This document 4 Unknown Sub-Version This document 0x05-0x0F Unassigned - 0x10-0xFE Reserved for vendor use This document 0xFF Reserved This document (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. IANA is requested to establish a registry as follows on the TRILL Parameters web page indented under RBridge Channel Error Codes after RBridge Channel SubError Codes: Registry: Vendor RBridge Channel Error Codes Registration Procedures: Standards Action Reference: (This document) Code Description Reference ---- ----------- --------- 0 No error This document 1 Message too short This document 2 Unknown OUI/CID This document 3 Unknown Sub-Protocol This document 4 Unknown Sub-Version This document 0x05-0x0F Unassigned - 0x10-0xFE Reserved for vendor use This document 0xFF Reserved This document (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 additional reviews needed. |
2018-02-20
|
00 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-02-20
|
00 | Susan Hares | IESG state changed to Publication Requested |
2018-02-20
|
00 | Susan Hares | IESG process started in state Publication Requested |
2018-02-20
|
00 | Susan Hares | Changed document writeup |
2018-02-20
|
00 | Susan Hares | Changed document writeup |
2018-02-20
|
00 | Susan Hares | Changed document writeup |
2018-02-20
|
00 | Susan Hares | Changed document writeup |
2018-02-20
|
00 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-02-20
|
00 | Alia Atlas | Shepherding AD changed to Alia Atlas |
2018-02-20
|
00 | Alia Atlas | Placed on agenda for telechat - 2018-03-08 |
2018-01-22
|
00 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2018-01-15
|
00 | Donald Eastlake | Changed consensus to Yes from Unknown |
2018-01-15
|
00 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2018-01-15
|
00 | Donald Eastlake | Notification list changed to Susan Hares <shares@ndzh.com> |
2018-01-15
|
00 | Donald Eastlake | Document shepherd changed to Susan Hares |
2018-01-15
|
00 | Donald Eastlake | This document now replaces draft-eastlake-trill-vendor-channel instead of None |
2018-01-15
|
00 | Donald Eastlake | New version available: draft-ietf-trill-vendor-channel-00.txt |
2018-01-15
|
00 | (System) | New version approved |
2018-01-15
|
00 | Donald Eastlake | Request for posting confirmation emailed to submitter and authors: Hao Weiguo , Ayan Banerjee , Donald Eastlake , Li Yizhou |
2018-01-15
|
00 | Donald Eastlake | Uploaded new revision |