Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
RFC 8531
Yes
No Objection
No Record
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
It seems to me that the reference to IEEE802.1ag should be Normative. " In this document, we take the CFM [IEEE802.1ag] model and extend it to a technology independent framework and define the corresponding YANG model accordingly."
Warren Kumari No Objection
I am balltoing NoObj, trusting the Responsible AD to do the right thing. Joe Clarke's OpsDir review (review-ietf-lime-yang-connection-oriented-oam-model-05-opsdir-lc-clarke-2018-02-10) has some important comments which should be addressed. Thanks to Joe for the review!
(Benoît Claise; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
I found some small editorial nits while reviewing this document.
§2.2:
> Connectivity Verification - Connectivity Verification are used to
> verify that a destination is connected. It are also referred to
"...is used to..."
§3:
> In this document we define a generic YANG model for connection
> oriented OAM protocols. The YANG model defined here is generic in a
Hyphenate "connection-oriented".
> sense that other technologies can extend it for technology specific
> needs.
Hyphenate "technology-specific".
> Figure 1 depicts relationship of different YANG modules.
This sentence seems redundant with the earlier "Figure 1 depicts..." statement.
> | | |
> +-------------------------------------------------------+
> | Uniform API |
> +-------------------------------------------------------+
>
> Relationship of OAM YANG model to generic (base) YANG model
I presume this is Figure 1. It probably should say so.
In the module:
> typedef ma-name-string {
> type string;
> description
> "Generic administrative name for an
> Maintenance Association (MA).";
> }
"...for a Maintenance..."
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
One question: Does this YANG model somehow relate to the lmap YANG model (RFC8194)? I mean at least one could probably also use lmap to configure a traceroute in some intervals… One editorial comment: sec 1: This sentence is superfluous as inherently true: „All implementations that follow the YANG framework presented in this document MUST implement the generic connection oriented YANG model presented here.“
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Record
I didn't really get through this, but I had a few editorial points. It's almost certainly my unfamiliarity with the setting, but I found it a bit hard to understand the context of this document. I think there were two things I found a bit confusing: 1. Why you need a separate model for connectionless and connection-oriented OAM? 2. What sort of concepts should I be having in my head for MD, MA, and MEP? Are these kind of like "site", "link", and "endpoint"? This may all be completely clear to people with OAM experience in these settings, in which case feel free to ignore me. But it did make it a bit hard for this layperson to read.