Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework
Note: This ballot was opened for revision 11 and is now closed.
(Stewart Bryant) Yes
(Mark Townsley) Yes
(Jari Arkko) No Objection
(Ron Bonica) (was Discuss) No Objection
(Ross Callon) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was No Record, Yes) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
(Russ Housley) (was Discuss) No Objection
(Chris Newman) No Objection
(Tim Polk) (was Discuss) No Objection
I would suggest replacing the first paragraph of the security considerations with something along the following lines: This specification assumes that L2VPN components within the OAM domain are mutually trusted. Based on that assumption, confidentiality issues are fully addressed by filtering to prevent OAM frames from leaking outside their OAM domain. Similarly, authentication issues are addressed by preventing OAM frames generated outside from entering the OAM domain. Requirements to prevent OAM messages from leaking outside an OAM domain and for OAM domains to be transparent to OAM frames from higher OAM domains are specified in Section 6.10 and 7.10. I think this is a bit clearer than "This document takes into account the security considerations and ..."
(Dan Romascanu) (was Discuss) No Objection
Because of the interdependencies of this work with work and documents published in the IEEE 802.1 WG, ITU-T and MEF I believe it would have been better if these SDOs have been notified and asked to review this work.
(Peter Saint-Andre) No Objection
(Robert Sparks) No Objection
(David Ward) No Objection
Comment (2007-12-19 for -)
It is interesting that this document has no normative language whatsoever but, definitely alludes to preferred choices. I found the meat of the doc to be in Section 9 where [IEEE 802.1ag] and [ITU-T Y.1731] were attempted to be elevated to the protocols of choice (though using the word choice "can"). It was mentioned that VCCV and BFD "can" be used in the interim until [IEEE 802.1ag] and [ITU-T Y.1731] are available. Should a document that goes into such detail and intending to recommend protocol choice be so vague as not use normative language?