IANA Considerations for Connectivity Fault Management (CFM) Code Points
RFC 7319

Note: This ballot was opened for revision 01 and is now closed.

(Jari Arkko; former steering group member) Yes

Yes ()
No email
send info

(Ted Lemon; former steering group member) Yes

Yes ( for -01)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ()
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ()
No email
send info

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ()
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection (2014-05-27)
No email
send info
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"

(Joel Jaeggli; former steering group member) No Objection

No Objection ()
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ()
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ()
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection ()
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-05-26)
No email
send info
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.