Last Call Review of draft-ietf-lime-yang-connection-oriented-oam-model-05
review-ietf-lime-yang-connection-oriented-oam-model-05-secdir-lc-murphy-2018-03-01-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: This draft presents a generic connection oriented yang model.

I am a novice on YANG models.  I did some review to try to analyze this draft,
but any comments I make must take into account my lack of background.

I did review the IETF tutorial on YANG, which was helpful.  I also looked at
draft-ietf-netmod-revised-datastores-07,
draft-ietf-netmod-yang-tree-diagrams-02, draft-ietf-trill-yang-oam-05,
draft-ietf-lime-yang-connectionless-oam-18, RFC7276, to varying levels of
depth.  This gives you an idea of what fundamental concepts I might have missed.

The security considerations section discusses the protocol protections provided
by the underlying transport layers’ security.  It also points out that NETCONF
“provides the means to restrict access” and then describes the subtrees and
data nodes of the model that are particularly sensitive or vulnerable.  The
dual draft for connectionless oam does the same.  The outline seems adequate, I
have no way to judge if the list is sufficient.

Subtree hierarchies down to data nodes are described.  I’m not sure why the
tree hierarchy is described - perhaps the protections for each lower levels of
the hierarchy is increasingly sensitive and would need protections that exceed
the parent’s.

One of the examples of a sensitive component is a data node that is taken from
the TRILL extensions provided in Section 7.  Later working group completion of
the TRILL data model might change that data node.

I believe that a generic YANG cam model also exists, defined in
draft-ietf-lime-yang-oam-model, which appears in a “reference” in a “revision”
definition. Is this connection oriented model an extension of the YANG generic
oam model.  The document talks of this model as if it is a new model; it refers
to itself as a “generic base model”.   Note my back of background - I might not
understand the YANG hierarchy.

This document does not address its relationship to the generic YANG oam model,
although it does address the dual connectionless model
draft-ietf-lime-yang-connectionless-oam-18.

At any rate, draft-ietf-lime-yang-oam-model should be explicitly mentioned and
added to the reference list.

It is not clear to me what the relationship is between models that are
extensions of the YANG generic base model, and those that are extensions to
this YANG connection oriented generic base model.  For example, a TRILL
extension to the generic base model exists, but this document defines
“snippets” of TRILL extensions of this connection oriented generic base model. 
Should tools implement both?

I found many nits, and gave up on finding them all.  The RFC Editor will find
them, I’m sure.  I’ve put a list at the end.

I have some most substantive comments and confusion about Sections 3, 4, and 7.

Section 3

This section is describing the connection oriented generic base YANG model, but
continually mixes in the term generic YANG model.  Since a generic YANG model
seems to exist, this is confusing.

e.g.

3.  Architecture of Generic YANG Model for OAM

but then the first sentence says

   In this document we define a generic YANG model for connection
   oriented OAM protocols.

and then
      The Generic YANG model acts as the root for other OAM YANG
   models.

Is that describing this model, or the generic YANG model of
draft-ietf-lime-yang-oam-model?

and

                         Figure 1 depicts the relationship of different
   OAM YANG models to the Generic YANG Model for connection oriented
   OAM.  The Generic YANG model for OAM provides …

Is the second Generic YANG model this model or the truly generic yang model?

The figure starts with "Connection Oriented gen OAM YANG” with “TRILL OAM YANG”
underneath.  But the figure title is "Relationship of OAM YANG model to generic
(base) YANG model”.  Also, TRILL has an extension of the truly generic yang
model in draft-ietf-trill-yang-oam-05.  Does the diagram refer to that model or
to the extension “snippets” defined in Section 7 of this document.

Sec 4 pg 8

                                                      The default
   mode of OAM is referred to as the Base Mode and specifies default
   values for each of model parameters.
   . . .
   on.  The default values of these depend on the technology.  Base Mode
   for TRILL is defined in [RFC7455].  Base mode for other technologies
   and future extensions developed in IETF will be defined in their
   corresponding documents.

So each new technology extending this connection oriented base YANG model must
redefine the default values for the model parameters?

   tools.  The OAM tools used here are limited to OAM toolset specified
   in section 5.1 of [RFC7276].

What is meant by “used here”?  Is this standard limited to the tools of RF7276?

Section 7

This section "demonstrates the usability of the connection-oriented YANG OAM
data model” by supplying “snippets of technology-specific model extensions for
illustrative purposes”.  It notes that this is not a complete extension, which
would have to come from the working groups.  There is continued lack of
distinction between this documents connection oriented base YANG model and the
generic base YANG model.

I am confused about what it means to have a model that extends the generic base
YANG model and one that extends the connection oriented generic base model of
this document.  How are the two extensions related?  Can they be used
simultaneously in the same network?  Would they both be implemented on a device?

Sec 7.1 pg 41

   The TRILL YANG module is augmenting connection oriented OAM module
   for both configuration and RPC commands.

This is not clear.  Does this mean "The TRILL connection oriented YANG module
described in this section augments the connection oriented OAM module of this
document…"

   The TRILL YANG module requires the base TRILL module ([I-D.ietf-
   trill-yang])

This is not in the reference list.  It is perhaps intended to be
draft-ietf-trill-yang-oam-05.

Sec 7.1.1.1 pg 42

      identity trill{
       base co-oam:technology-types;
       description
        "trill type";
      }

In draft-ietf-trill-yang-oam-05, the similar definition is:

   identity trill {    base goam:technology-types;    description
   "trill type";  }

So draft-ietf-trill-yang-oam-05 does extend the “goam” model and this draft
extend the “co-oam” model.  Correct?

Would both identities be used in managing a device?

—Sandy

Nits

Sec 1 pg 3

                                        ITU-T
   [G.8013], MEF Service OAM, MPLS-TP [RFC6371], TRILL [RFC7455] all

missing an “and” in there somewhere, I think.

Sec 2.2 pg 5

   Connectivity Verification  - Connectivity Verification are used to
      verify that a destination is connected.  It are also referred to

“is used” and “is also referred”

Sec 2.2 pg 6

      diagnostics.  On-demand OAM method requires only transient
      configuration.

“A On-demand OAM” or “The On-demand OAM”

Sec 3 pg 6

   technology- specific YANG models can inherit constructs from the base

“technology-specific”

Sec 4 pg 7

   Under each Maintenance Domain there is one or more Maintenance
   Association (MA).  In TRILL this can be per Fine-Grained Label.

“Associations”

It is not clear about TRILL - are multiple MA’s defined per Fine-Grained Label?
 If so, are there multiple Fine-Grained Labels under the Maintenance Domain? 
What is the MD - FGL - MA structure?

   In the vertical direction orthogonal to the Maintenance Domain,
   presented are the commands.

I do not understand this, particularly the “presented are the commands” part. 
That is not usual word order and I can not rearrange the sentence to make
sense.  And what is meant by “vertical direction”?

Sec 4 pg 8

   tools.  The OAM tools used here are limited to OAM toolset specified
   in section 5.1 of [RFC7276].

“to the OAM toolset”

Sec 4.1 pg 8

   module.  Within the container "domains", separate list is maintained

“a separate list”

Sec 4.4 pg 10

   The RPC model facilitates issuing commands to a "server" (in this
   case to the device that need to execute the OAM command) and obtain a

“needs”

“and obtaining”

Sec 4.5 pg 13

   Notification is sent on defect condition and defect clears with
   Maintenance Domain Name, MA Name

“Notification is sent on detecting a defect condition and on clearing the
defect”?

Sec 4.6 pg 13

   Grouping for monitoring statistics is to be used by YANG modules
   which Augment YANG to provide statistics

what does the “Augment YANG” mean here? What is being augmented - the generic
base model or this connection oriented base model?

Sec 5 pg 20

    description
      "If no proactive Continuity Check (CC)
       OAM packets from the source Maintenance End Point
       (MEP) (and in the case of Connectivity
       Verification , this includes the
       requirement to have the expected unique,
       technology dependent source MEP
       identifier) are received within the interval.”;

This is unclear.  “to have the … identifier” - to possess it?  not received
packets from it?

Sec 5 page 29

  container domains {
    description
      "Contains configuration related data. Within the container
       is list of fault domains. Within each domian has List of
       Maintenance Association (MA).”;

what does the “Within each domian has List” part mean?  Within each domain
there is a list”

“list” not “LIST”, unless that’s a identifier somewhere.

and
      description
        "Define the list of fault Domains within the
         ietf-connection-oriented-oam module.”;

This is the only place “fault domain” is used.  Should that term be defined
somewhere?

Sec 7.2 pg 44

   The MPLS-TP OAM YANG module can augment connection oriented OAM
   Module with some technology-specific details.

“the” or “this” “connection oriented OAM module”

Other places, the text says “connection oriented base model”.  Consistency
could help.

Sec 7.2.2 pg 46

   can be inherited in the MPLS-TP OAM model and set by Connection
   Oriented base model as default values.

Why is connection oriented capitalized here?