Re: [secdir] review of draft-ietf-lime-yang-connection-oriented-oam-model-05

[Qin Wu <[e-mail]>]

Thanks Sandra for valuable review, see my reply inline below. Note that we have updated to v-06, some of your comments you raised are fixed.

-Qin
-----邮件原件-----
发件人: Sandra Murphy [mailto:[e-mail]] 
发送时间: 2018年2月23日 3:17
收件人: IETF Security Directorate
抄送: Sandra Murphy; [e-mail]
主题: review of draft-ietf-lime-yang-connection-oriented-oam-model-05

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.  

[Qin]: Sorry for confusion, the generic connection oriented yang model described above is the YANG generic oam model. It is superfluous to emphasize generic connection oriented yang model in everyplace.

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.

[Qin]: Yes, it does, there is two type of generic YANG oam models, one is connection-oriented, one is connectionless, this is based on WG consensus to separate one generic OAM model into two generic models.
Then technology specific OAM model can augment these two generic YANG oam models with technology specific details respectivley.

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

[Qin]:No, draft-ietf-lime-yang-oam-model has been replaced by draft-ietf-lime-yang-connection-oriented-oam-model.

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?

[Qin]: Again, YANG generic base model are referred to YANG connection oriented generic base model.
Take Trill as an example, TRILL OAM is classified as connection oriented OAM technology, therefore TRILL OAM model is the extension of YANG connection oriented generic base model.

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.

[Qin]: Thanks, it helps.

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.

[Qin]: See above.

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?

[Qin]: Will change the title to " Architecture of Generic YANG Model for connection-oriented OAM " to get the term consistent.
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?

[Qin]: Will change " The Generic YANG model for OAM provides …" into " The Generic YANG model for connection-oriented OAM provides …" to get text consistent.

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.

[Qin]: Note that TRILL OAM model is extension of both TRILL YANG model and Connection oriented gen OAM YANG model. In this document, we only shows in figure 1 that TRILL OAM YANG model is extension of Connection oriented gen OAM YANG model for simplicity and scope consideration. In other words, TRILL OAM YANG described in figure is referred to the model defined in in draft-ietf-trill-yang-oam-05.
draft-ietf-trill-yang-oam-05 needs to be updated to get consistent with draft-ietf-lime-yang-connection-oriented-oam-model-05, e.g., change prefix in the module from goam into "co-oam".
Hope this clarifies.

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?

[Qin]: each new technology extending this connection oriented base YANG model inherit these default value defined in base YANG model or redefine default values,
The default values defined in technology specific model will override the default value defined in base YANG model.

   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?

[Qin]: the previous sentence said:
"
The OAM entities in the generic YANG model defined here will be
   either explicitly or implicitly configured using any of the OAM
   tools. So "used here" means described above,
"
As clarified in the text, OAM tools not this standard is limited to the tools of RFC7276.

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.

[Qin]: See above.
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?

[Qin]: draft-ietf-lime-yang-oam-model has been replaced by draft-ietf-lime-yang-connection-oriented-oam-model. Don't worry about it any more.

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.

[Qin]: This is intended, as I clarified above, TRILL OAM YANG model is extension of both TRILL YANG model and Connection-oriented OAM YANG model. I will add a few text to make this clear.

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?

[Qin]: As you know, Deepak is an author of both draft-ietf-trill-yang-oam and draft-ietf-lime-yang-connection-oriented-oam-model.
draft-ietf-trill-yang-oam needs to be updated to replace goam with "co-oam".

—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.

[Qin]: Fixed
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”

[Qin]: Fixed in v-06 already.

Sec 2.2 pg 6

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

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

[Qin]: Fixed.

Sec 3 pg 6

   technology- specific YANG models can inherit constructs from the base

“technology-specific”

[Qin]: Fixed.

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”

[Qin]:Fixed
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?

[Qin]: In TRILL, MA is corresponding to Fine-Grained Label, will make this clear.

   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”?

[Qin]: The vertical direction is referred to management plane protocol direction(e.g., NETCONF,SNMP) which is used between the management system and managed devices.
I proposed to change as follows:
"In the management protocol direction orthogonal to the Maintenance Domain, presented are the commands."
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”

[Qin]:Fixed.
Sec 4.1 pg 8

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

“a separate list”
[Qin]:Fixed.
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”
[Qin]:Fixed.
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”?
[Qin]:Okay, accepted.
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?
[Qin]: referred to this connection-oriented base model, will make this clear in the text.
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? 

[Qin]:The text comes from RFC6371 section 5.1.1.1, will change text to make it clear.

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.

[Qin]:Will change into:
"Within the container, there is a list of fault domains. Each domain has a list of Maintenance Association(MA)."
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?

[Qin]:fault domain referred to domain, will fix this.

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.

[Qin]:Fixed.

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?
[Qin]:Fixed in v-06 already.