Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks
RFC 4687
Yes
No Objection
No Record
Note: This ballot was opened for revision 01 and is now closed.
Lars Eggert No Objection
(Ross Callon; former steering group member) Yes
(Brian Carpenter; former steering group member) No Objection
From Gen-ART review by David Black. These would be useful improvements. Section 2.1 This requirements draft uses RFC 2119 terminology (MUST, SHOULD, etc.). In addition to incorporation of the RFC 2119 boilerplate (already done), please explain that these requirements are being stated as requirements of OAM mechanism and protocol *development*, as opposed to the usual application of RFC 2119 requirements to an actual protocol, as this draft does not specify any protocol. Section 2.3 OAM: Operations and Management OA&M: Operations, Administration and Maintenance. That's an invitation for confusion. The OA&M acronym is not used in this draft - please remove it from this section. Section 4.1 The discussion of limits on proactive OAM loading should probably explicitly say that reactive OAM (dealing with something that has gone wrong) may violate these limits (i.e., cause visible traffic degradation) if that's necessary or useful to try to fix whatever has gone wrong. Also, a wording nit: In practice, of course, the requirements in the previous paragraph may be overcome by careful specification of the anticipated data throughput of LSRs or data links, "overcome" --> "satisfied" or "met"
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Record