Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework
RFC 6136

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

Comment (2010-11-18)
No email
send info
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

Comment (2010-10-25)
No email
send info
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 -)
No email
send info
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?