Skip to main content

Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
RFC 8531

Yes

(Benoît Claise)

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Kathleen Moriarty)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

No Record


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

Alvaro Retana No Objection

Comment (2018-02-21 for -05)
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

Comment (2018-02-21 for -05)
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

Yes (for -05)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2018-02-21 for -05)
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

No Objection (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -05)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -05)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -05)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2018-02-19 for -05)
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

No Objection (for -05)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -05)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -05)

                            

(Eric Rescorla; former steering group member) No Record

No Record (2018-02-22 for -06)
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.