IANA Considerations for Connectivity Fault Management (CFM) Code Points
RFC 7319
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
(Jari Arkko; former steering group member) Yes
(Ted Lemon; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
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
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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.