IANA Considerations for Connectivity Fault Management (CFM) Code Points
draft-eastlake-iana-cfm-considerations-02

[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"

[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"

[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"

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

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.

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.