IANA Considerations for Connectivity Fault Management (CFM) Code Points
draft-eastlake-iana-cfm-considerations-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-07-18
|
02 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-07-14
|
02 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-07-14
|
02 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-06-03
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-06-03
|
02 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-06-03
|
02 | (System) | RFC Editor state changed to EDIT |
2014-06-03
|
02 | (System) | Announcement was received by RFC Editor |
2014-06-03
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-06-02
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-06-02
|
02 | (System) | IANA Action state changed to In Progress |
2014-06-02
|
02 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-06-02
|
02 | Amy Vezza | IESG has approved the document |
2014-06-02
|
02 | Amy Vezza | Closed "Approve" ballot |
2014-06-02
|
02 | Amy Vezza | Ballot approval text was generated |
2014-06-02
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Benson Schliesser. |
2014-05-29
|
02 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2014-05-29
|
02 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-05-28
|
02 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-05-28
|
02 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-05-28
|
02 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-05-28
|
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-05-27
|
02 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2014-05-27
|
02 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-05-27
|
02 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-05-27
|
02 | Benoît Claise | [Ballot comment] Same question as Alissa regarding BCP versus Standard Track Very valid feedback from Benson. I wanted to share my thoughts with you directly, … [Ballot comment] Same question as Alissa regarding BCP versus Standard Track Very valid feedback from Benson. I wanted to share my thoughts with you directly, in case you feel differently. Feel free to ignore this note if you wish, or forward it, or ask me to follow-up, etc. The IANA registry established by this document will maintain IEEE 802.1 CFM OpCode and TLV Type allocations for the IETF. Specifically the IEEE has delegated a range from each of these namespaces to the IETF. The IEEE has also delegated a range from each of these namespaces to the ITU-T. And of course the IEEE is using a range from each of these namespaces for their own development. As such, there are potentially 3 different standards groups that can develop extensions to the 802.1 CFM OAM. On one hand this is a good thing, because it enables IETF to directly manage our own work in this area (e.g. I imagine that TRILL is an example where this matters). On the other hand it opens the possibility of redundant / overlapping extensions. For instance, the IETF might be used for developing extensions that were rejected by the other organizations. And of course, it's possible that implementations could become confusing in the market. Simply saying that a product supports 802.1 CFM isn't adequate to guarantee interoperability, without elaborating on the specific details. This may not be a big issue for the IETF, but it comes to mind as a possible outcome we should be aware of. Not if/how we should act on it.Maybe expanding the note proposed to Stephen Farrell by Donald Eastlake: OLD: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF." NEW: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF. Note that the IEEE has kept control of the value 1 to 31, but has delegated values from 32 through 63 to ITU-T" |
2014-05-27
|
02 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2014-05-27
|
02 | Benoît Claise | [Ballot comment] Very valid feedback from Benson. I wanted to share my thoughts with you directly, in case you feel differently. Feel free to ignore … [Ballot comment] Very valid feedback from Benson. I wanted to share my thoughts with you directly, in case you feel differently. Feel free to ignore this note if you wish, or forward it, or ask me to follow-up, etc. The IANA registry established by this document will maintain IEEE 802.1 CFM OpCode and TLV Type allocations for the IETF. Specifically the IEEE has delegated a range from each of these namespaces to the IETF. The IEEE has also delegated a range from each of these namespaces to the ITU-T. And of course the IEEE is using a range from each of these namespaces for their own development. As such, there are potentially 3 different standards groups that can develop extensions to the 802.1 CFM OAM. On one hand this is a good thing, because it enables IETF to directly manage our own work in this area (e.g. I imagine that TRILL is an example where this matters). On the other hand it opens the possibility of redundant / overlapping extensions. For instance, the IETF might be used for developing extensions that were rejected by the other organizations. And of course, it's possible that implementations could become confusing in the market. Simply saying that a product supports 802.1 CFM isn't adequate to guarantee interoperability, without elaborating on the specific details. This may not be a big issue for the IETF, but it comes to mind as a possible outcome we should be aware of. Not if/how we should act on it.Maybe expanding the note proposed to Stephen Farrell by Donald Eastlake: OLD: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF." NEW: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF. Note that the IEEE has kept control of the value 1 to 31, but has delegated values from 32 through 63 to ITU-T" |
2014-05-27
|
02 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2014-05-27
|
02 | Benoît Claise | [Ballot comment] Very valid feedback from Benson. I wanted to share my thoughts with you directly, in case you feel differently. Feel free to ignore … [Ballot comment] Very valid feedback from Benson. I wanted to share my thoughts with you directly, in case you feel differently. Feel free to ignore this note if you wish, or forward it, or ask me to follow-up, etc. The IANA registry established by this document will maintain IEEE 802.1 CFM OpCode and TLV Type allocations for the IETF. Specifically the IEEE has delegated a range from each of these namespaces to the IETF. The IEEE has also delegated a range from each of these namespaces to the ITU-T. And of course the IEEE is using a range from each of these namespaces for their own development. As such, there are potentially 3 different standards groups that can develop extensions to the 802.1 CFM OAM. On one hand this is a good thing, because it enables IETF to directly manage our own work in this area (e.g. I imagine that TRILL is an example where this matters). On the other hand it opens the possibility of redundant / overlapping extensions. For instance, the IETF might be used for developing extensions that were rejected by the other organizations. And of course, it's possible that implementations could become confusing in the market. Simply saying that a product supports 802.1 CFM isn't adequate to guarantee interoperability, without elaborating on the specific details. This may not be a big issue for the IETF, but it comes to mind as a possible outcome we should be aware of. Not if/how we should act on it.Maybe expanding the note proposed to Stephen Farrell by Donald Eastlake: OLD: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF." NEW: "This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF. Note that the IEEE has kept control of the value 1 to 31, but has delegated values from 32 through 63 to ITU-T" |
2014-05-27
|
02 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-05-27
|
02 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-05-26
|
02 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-05-26
|
02 | Alissa Cooper | [Ballot discuss] Why is this BCP rather than Standards Track? |
2014-05-26
|
02 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2014-05-26
|
02 | Stephen Farrell | [Ballot comment] Would it be worth noting in the IANA registry descriptions that values outside the allocated ranges are IEEE's and not ours, i.e. not … [Ballot comment] Would it be worth noting in the IANA registry descriptions that values outside the allocated ranges are IEEE's and not ours, i.e. not available for allocation via standards action or otherwise? Its implicitly there I guess, but could be worth noting there, just to avoid a future where someone tries an end-run around IEEE via the IETF. No big deal if you'd rather not. |
2014-05-26
|
02 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-05-23
|
02 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-05-22
|
02 | Donald Eastlake | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-05-22
|
02 | Donald Eastlake | New version available: draft-eastlake-iana-cfm-considerations-02.txt |
2014-05-22
|
01 | Ted Lemon | IESG state changed to IESG Evaluation from Waiting for Writeup |
2014-05-22
|
01 | Ted Lemon | Placed on agenda for telechat - 2014-05-29 |
2014-05-22
|
01 | Ted Lemon | Ballot has been issued |
2014-05-22
|
01 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2014-05-22
|
01 | Ted Lemon | Created "Approve" ballot |
2014-05-22
|
01 | Ted Lemon | Ballot writeup was changed |
2014-05-21
|
01 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-05-18
|
01 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-05-18
|
01 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-eastlake-iana-cfm-considerations-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-eastlake-iana-cfm-considerations-01. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA understands that, upon approval of this document, there are three actions that need to be completed. First, in the IANA Matrix at: http://www.iana.org/protocols a new registry will be created using [ RFC-to-be ] as a reference. The new registry will be called the "CFM OAM IETF Parameters" Registry. QUESTIONs: 1) Should the new URL be http://www.iana.org/assignments/cfm-oam? 2) Should this new created registry be placed under the header "Transparent Interconnection of Lots of Links (TRILL) Parameters" at http://www.iana.org/protocols? Second, in the new "CFM OAM IETF Parameters" Registry created above, a new subregistry will be created called the CFM OAM IETF Op-Codes registry. Maintenance of this registry will be done via Standards Action as defined by RFC 5226. There are no initial values in this registry although IANA understands that only values 64-95 are available for registration. As an example: Registry Name: CFM OAM IETF Op-Codes Registration Procedures: Standards Action Reference: [802.1Q] [ RFC-to-be ] Note: This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF. Value Assignment Reference === ===== ====64-95 Unassigned [ RFC-to-be ] Third, also in the new "CFM OAM IETF Parameters" Registry created above, a new subregistry will be created called the CFM OAM IETF TLV Types registry. Maintenance of this registry will be done via Standards Action as defined by RFC 5226. There are no initial values in this registry although IANA understands that only values 64-95 are available for registration. As an example: Registry Name: CFM OAM IETF TLV Types Registration Procedures: Standards Action Reference: [802.1Q] [ RFC-to-be ] Note: This parameter originates with the IEEE 802.1 Working Group that has allocated the block of values from 64 to 95 to the IETF. Value Assignment Reference === ===== ====64-95 Unassigned [ RFC-to-be ] QUESTION: the term "Assignment" is used in both new created sub-registries for CFM OAM Codepoints. But, what format/data should exactly look like for "Assignments"? Is it a description, name, or reference? Or is it completely clear to any future document authors and does not concern IANA? IANA understands these three actions to be 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-05-02
|
01 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Catherine Meadows. |
2014-04-25
|
01 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
2014-04-24
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2014-04-24
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2014-04-24
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Benson Schliesser |
2014-04-24
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Benson Schliesser |
2014-04-24
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2014-04-24
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2014-04-23
|
01 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-04-23
|
01 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: RESEND: Last Call: (IANA Considerations for CFM (Continuity … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: RESEND: Last Call: (IANA Considerations for CFM (Continuity Fault Management) Codepoints) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for CFM (Continuity Fault Management) Codepoints' as Best Current Practice 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-05-21. 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 IEEE 802.1 has specified Continuity Fault Management (CFM) OAM facilities. CFM messages are structured with an Op-Code field and have provision for the inclusion of TLV (type, length, value) structured information. IEEE 802.1 has allocated blocks of CFM Op- Codes and TLV Types to the IETF. This document specifies the IANA Considerations for the assignment of values from these blocks. INTERNET-DRAFT IANA Considerations for CFM Codepoints The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-iana-cfm-considerations/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-04-23
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-04-23
|
01 | Amy Vezza | Last call announcement was changed |
2014-04-23
|
01 | Amy Vezza | Last call announcement was generated |
2014-04-23
|
01 | Amy Vezza | Last call was requested |
2014-04-23
|
01 | Amy Vezza | Ballot approval text was generated |
2014-04-23
|
01 | Amy Vezza | Ballot writeup was generated |
2014-04-23
|
01 | Amy Vezza | IESG state changed to Last Call Requested from In Last Call |
2014-04-23
|
01 | Amy Vezza | Notification list changed to : d3e3e3@gmail.com, draft-eastlake-iana-cfm-considerations@tools.ietf.org |
2014-04-23
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-04-23
|
01 | Amy Vezza | IESG state changed to Last Call Requested from In Last Call |
2014-04-23
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-04-23
|
01 | Amy Vezza | Last call announcement was generated |
2014-04-18
|
01 | Ted Lemon | IESG state changed to Last Call Requested from Publication Requested |
2014-04-18
|
01 | Ted Lemon | Last call announcement was generated |
2014-04-18
|
01 | Ted Lemon | IESG process started in state Publication Requested |
2014-04-18
|
01 | Ted Lemon | Intended Status changed to Best Current Practice from None |
2014-04-18
|
01 | Ted Lemon | Shepherding AD changed to Ted Lemon |
2014-04-18
|
01 | Ted Lemon | Notification list changed to : ted.lemon@nominum.com,sam.aldrin@gmail.com,trill-chairs@tools.ietf.org |
2014-04-18
|
01 | Ted Lemon | Document shepherd changed to Sam Aldrin |
2014-04-18
|
01 | Ted Lemon | Stream changed to IETF from None |
2014-04-18
|
01 | Ted Lemon | Changed document writeup |
2014-03-24
|
01 | Donald Eastlake | New version available: draft-eastlake-iana-cfm-considerations-01.txt |
2014-03-24
|
01 | Donald Eastlake | New version available: draft-eastlake-iana-cfm-considerations-01.txt |
2014-02-13
|
00 | Donald Eastlake | New version available: draft-eastlake-iana-cfm-considerations-00.txt |