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

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"

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.