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

[Ballot comment]
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.

[Ballot comment]
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..."

[Ballot comment]
§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..."

[Ballot comment]
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."

[Ballot comment]
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."

[Ballot comment]
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!

[Ballot comment]
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.“

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-lime-yang-connection-oriented-oam-model-04. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has completed its review of draft-ietf-rtgwg-ni-model-06. If any part of this review is inaccurate, please let us know.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-connection-oriented-oam
URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. If there is no expert designated for the registry, we will work with the IESG to have one assigned. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-connection-oriented-oam
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
Prefix: co-oam
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for this new YANG module?

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-19):

From: The IESG
To: IETF-Announce
CC: bclaise@cisco.com, rbonica@juniper.net, lime-chairs@ietf.org, lime@ietf.org, draft-ietf-lime-yang-connection-oriented-oam-model@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard


The IESG has received a request from the Layer Independent OAM Management in
the Multi-Layer Environment WG (lime) to consider the following document: -
'Generic YANG Data Model for Connection Oriented Operations,
  Administration, and Maintenance(OAM) protocols'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document presents a base YANG Data model for connection oriented
  OAM protocols.  It provides a technology-independent abstraction of
  key OAM constructs for such protocols.  The model presented here can
  be extended to include technology specific details.  This guarantees
  uniformity in the management of OAM protocols and provides support
  for nested OAM workflows (i.e., performing OAM functions at different
  levels through a unified interface)

  The YANG model in this document conforms to the Network Management
  Datastore Architecture defined in
  [I-D.ietf-netmod-revised-datastores].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6905: Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) (Informational - IETF stream)