Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
draft-ietf-lime-yang-connection-oriented-oam-model-07

Note: This ballot was opened for revision 05 and is now closed.

(Benoît Claise) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-02-21 for -05)
No email
send info
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!

Mirja Kühlewind No Objection

Comment (2018-02-19 for -05)
No email
send info
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.“

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2018-02-21 for -05)
No email
send info
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."

Adam Roach No Objection

Comment (2018-02-21 for -05)
No email
send info
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..."

(Eric Rescorla) No Record

Comment (2018-02-22 for -06)
No email
send info
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.