[Lime] R: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13

[Qin Wu <[e-mail]>]

Thanks Alissa.
发件人: Lime [mailto:[e-mail]] 代表 Alissa Cooper
发送时间: 2017年10月25日 22:42
收件人: Srihari Raghavan (srihari)
抄送: [e-mail]; Elwyn Davies; [e-mail]; Qin Wu; [e-mail]
主题: Re: [Lime] [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13

Elwyn, thanks for your review. Authors, thanks for your responses. I have entered a No Objection ballot.

Alissa


On Oct 24, 2017, at 8:08 PM, Srihari Raghavan (srihari) <[e-mail]<mailto:[e-mail]>> wrote:

Elwyn

Thank you very much for your time and comments.

We will address the abbreviations/expansions and fixes to the descriptions in the upcoming revisions.

Thanks
Srihari

From: Elwyn Davies <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 25 October 2017 at 4:34 AM
To: Qin Wu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Cisco Employee <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Ron Bonica <[e-mail]<mailto:[e-mail]>>, Carlos Pignataro <[e-mail]<mailto:[e-mail]>>
Resent-Date: Wednesday, 25 October 2017 at 4:44 AM

Hi, Qin.

Thanks for the quick repsonse.

The fixes look good - I'll await the new version and give it a good read.

One thing I forgot to check through was whether all tha abbreviations were either 'well known' (as documented in the RFC editor's list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) or expanded on first occurrence.

Needing expansion: DSCP (s3.1), VRF (s3.5), OWAMP/TWAMP (s4, description of grouping session-delay-statistics), MP (s4, several descriptions in grouping tp-address),  AS (s4, description of identity as-number-address-type ,  also description of as-number - in this case it might be that s/AS number/as-number/ in the description),   LSP (s4, description of lsp-id), MPLS-TE (s5.1.1.2).

Checking for this has raised some additional points....

In the descriptions items in the features section of s4, the abbreviations rpc, ptp, ntp and icmp should be in capitals (RPC, PTP, NTP, ICMP).

I think you also need references for the PTP and NTP timestamp formats.  I am not sure where the short and long NTP timestamp formats are defined!  Also I am not sure whether the PTP standard is readily accessible.  I think you may need to look at all the various timestamp fomats that are mentioned (I missed this yesterday) and ensure that there are pointers to proper definitions in all cases.

Also it would be good to explicitly mention RFC 6020 adjacent to YANG in the abstract (but not in reference format of course) and also in Section 1 as a reference.

Cheers,
Elwyn


Sent from Samsung tablet.

-------- Original message --------
From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Date: 24/10/2017 08:21 (GMT+00:00)
To: Elwyn Davies <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: RE: Genart telechat review of   draft-ietf-lime-yang-connectionless-oam-13

Elwyn:
Thank for your valuable comments.
Please see my reply inline below.

-Qin
-----邮件原件-----
发件人: Elwyn Davies [mailto:[e-mail]]
发送时间: 2017年10月24日 8:42
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13

Reviewer: Elwyn Davies
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lime-yang-connectionless-oam-13
Reviewer: Elwyn Davies
Review Date: 2017-10-23
IETF LC End Date: 2017-10-25
IESG Telechat date: 2017-10-26

Summary:Not really ready.  There are several missing references and the English needs cleaning up to make the document comprehensible. I found s3 to be almost totally opaque.  The fundamental concept of a Test Point needs a proper definition in s2 and a clearer introduction in s3.  The concept of 'neighboring test points' confused me for some time: I was thinking of neighboring nodes in the network whereas what seesm to be meant is a possibility of a multiplicity of

Major issues:
None

Minor issues:
Title and description of model:
The title refers to 'connectionless networks'.  In practice the YANG model could be used with both connectionless and connection-oriented communication technologies.  I think the intention is to be able to support the management of OAM protocols that operate in a connectionless manner (i.e., using connectionless *technologies*, as per RFC 7276) rather than connectionless networks. In the title - OLD:
      Generic YANG Data Model for Operations, Administration, and
         Maintenance(OAM) protocols for Connectionless networks
NEW:
      Generic YANG Data Model for the Management of Operations,
         Administration, and Maintenance (OAM) Protocols that
                     use Connectionless Communications END

[Qin]: Your understanding is correct, the title change in v-13 is based on one proposal from latest comments, I agree with your new proposed changes. Thanks.

Similarly, in s1, para 1, s/connections/communications/.

[Qin]: Okay.

In next to last para of s1:
OLD:
   Note that the Connection-Oriented OAM YANG DATA model is defined in
   [I-D.ietf-lime-yang-connection-oriented-oam-model].

NEW:
   Note that the YANG DATA model for OAM protcols using connection-oriented
   communications is defined in
   [I-D.ietf-lime-yang-connection-oriented-oam-model].
END

[Qin]: Accepted, thanks.

s2.1: The term 'Test point' needs some actual definition - It appears from the body of the document that a TP is effectively equated to an interface together with an associated stack layer (MAC, IP, etc) or superimposed application technology (VPN end point, etc.).  One query that came into my mind around this was what happens if the IP address associated with an interface is changed dynamically (e.g., when using IPv6 privacy addresses).  Can the YANG manager understand that it is still dealing with the same interface although the IP address has changed?  I wondered if the interfaces really needed some sort of identifier (e.g., interface number) that would tie all the pieces together as well as the intra-/inter-layer pointers.

[Qin]: I suspect interface number is local identifier, you can change your IP address of destination, that's why we can test whether the new address of destination is reachable. If IP address of source, we need to run another OAM diagnostic test. Here is the proposed definition for test point:
"
   Test point is a functional entity that is defined
   at a node in the network and can initiate and/or react to OAM
   diagnostic test.  This document focuses on the data-plane
   functionality of TPs, while TPs interact with the control plane and
   with the management plane as well.

"
s3.3:
>    OAM
>    neighboring test points are referred to a list of neighboring test
>    points in the same layer that are related to the current test point.
>    This allows users to easily navigate between related neighboring
>    layers to efficiently troubleshoot a defect.  In this model, the
>    'position' leaf defines the relative position of the neighboring test
>    point corresponding to the current test point in the same layer, and
>    is provided to allow correlation of faults at different locations.
I don't understand what is going on here.  Doesn't fault correlation require association of test points in adjacent layers up amd down the stack for the same interface rather than the same layer?  The before/after story then allows the manager to go up and down the stack looking at wat is going on in the different layers.  I can't see any likelihood of there being multiple test points in the same layer in a given interface (unless this has something to do with possible different administrative domains. Help! If this is altered, the similar text in the descriptions of oam-neighboring-tps (in s4) will need to be made consistent.

[Qin]: The latest changes in v-13 is also based on one comment we received recently, we try to fix confusion caused by 'technology-level' in v-12, so we change to 'position'. I agree with your comments above,
Neighboring Test Point more make sense for up and down layer. Here is the proposed change to section 3.3
"
3.3.  OAM neighboring test points

   As typical network communication stacks have a multi-layer
   architecture, the set of associated OAM protocols may similarly have
   a multi-layer structure; each communication layer in the stack may
   have its own OAM protocol [RFC7276] that may also be linked to a
   specific administrative domain.  Management of these OAM protocols
   will necessitate associated test points in the nodes accessible by
   appropriate management domains.  Accordingly, a given network
   interface may present several test points.

   OAM neighboring test points are referred to a list of neighboring
   test points in adjacent layers up and down the stack for the same
   interface that are related to the current test point.  This allows
   users to easily navigate between related neighboring layers to
   efficiently troubleshoot a defect.  In this model, the 'position'
   leaf defines the relative position of the neighboring test point
   corresponding to the current test point, and is provided to allow
   correlation of faults at different locations.  If there is one
   neighboring test point placed before the current test point, the
   'position' leaf is set to -1.  If there is one neighboring test point
   placed after the current test point, the 'position' leaf is set to 1.
   If there is no neighboring test point placed before or after the
   current test point, the 'position' leaf is set to 0.

                list oam-neighboring-tps {
                  key "index";
                  leaf index {
                     type uint16 {
                        range "0..65536";
                     }
                    description
                     "Index of a list of neighboring test points
                      in adjacent layers up and down the stack for the same interface
                     that are related to the current test point. ";
                  }
                  leaf position {
                      type int8 {
                           range "-1..1";
                      }
                      description
                        "The relative position
                        of neighboring test point
                        corresponding to the current
                        test point";
                  }

                  description
                     "List of related neighboring test points in adjacent
                     layers up and down the stack for the same interface
                     that are related to the current test point.";

              }

"
Sources of imported models:  It would be useful to list the RFCs/I-Ds that define the models that are imported.  Currently draft-ietf-netmod-schema-mount, draft-ietf-rtgwg-ni-model and draft-ietf-rtgwg-routing-types that are under development are not mentioned; the existing standards of RFC 6021 and RFC 7223 should also be referenced (7223 is).  They should all be normative.

[Qin]: Okay, fixed.

Nits/editorial comments:
========================

idnits: complains about some overlong lines... probably ones with 'when "derived-from-or-self(' General: As mentioned by other reviews, there area considerable number of places where it appears that " '" should really be "' "
and there are missing spaces after single quotes.


[Qin]: Okay, will fix this.

General:  The document is inconsistent in its use of connectionless/connection-less/connection less.  The preferred usage should be connectionless as is used in most cases.  Thus: Short title:
s/Connection-Less/Connectionless/ s4: OLD:
  feature connection-less {
    description
      "This feature indicates that OAM solution is connection less.";
  }

NEW:
  feature connectionless {
    description
      "This feature indicates that OAM solution is connectionless.";
  }
ENDS

[Qin]: Accepted.

s1, last para:
OLD:
   In this document, we presents a base YANG Data model for
   connectionless OAM protocols.  The generic YANG model for
   connectionless OAM only includes configuration data and state data.
   It can be used in conjunction with data retrieval method model
   [I-D.ietf-lime-yang-connectionless-oam-methods], which focuses on
   data retrieval procedures like RPC.  However it also can be used
   independently of data retrieval method model.
NEW:
   This document documents a base YANG Data model for
   connectionless OAM protocols.  This generic YANG model for
   connectionless OAM only includes configuration data and state data.
   It can be used in conjunction with data retrieval method model
   described in [I-D.ietf-lime-yang-connectionless-oam-methods], which focuses
   on data retrieval procedures such as RPC.  However it also can be used
   independently of this data retrieval method model.
ENDS

[Qin]: Fixed.

s2.1:  As mentioned above, TP needs some definition.  MAC is primarily concerned with MAC address in this document - definition: address for data link layer interface.  BFD should have a reference probably to RFC 5880.  It would probably be sensible to split the section into expanded modertely well-known abbreviations  (MAC, BFD, RPC*) and new terms (TP, CC).

[Qin]: Fixed.

s2.1, last para: s/e.g. /e.g., /

[Qin]: Fixed.

s3: Maybe the usage "is/are augmented to" is accepted YANG jargon but it isn't good English. "Augments"  will be good instead.

[Qin]: Fixed.

s3, para 1: The 'nd' prefix is part of the YANG specification in s4 and isn't known at this point.

[Qin]: Fixed.

s3, para 3: s/eg.,/e.g.,/

[Qin]: Fixed.

s3, last para: s/test- point-locations/test-point-locations/

[Qin]: Fixed.

s3, most of the section, but especially the last para: I found this to be almost totally unreadable and useless.

[Qin]: Here is the proposed change to section 3.
"
3.  Overview of the Connectionless OAM Model

   The model augments "/networks/network/node" path defined in the ietf-
   network module [I-D.ietf-i2rs-yang-network-topo] with 'test-point-
   locations' grouping defined in Section 3.5.  The network node in
   "/networks/network/node" path are used to describe the network
   hierarchies and the inventory of nodes contained in a network.

   Under the 'test-point-locations' grouping, each test point location is
   chosen based on 'tp-location-type' leaf which when chosen, leads to a
   container that includes a list of 'test-point-locations'.

   Each 'test-point-locations' list includes a 'test-point-location-info'
   grouping.  The 'test-point-location-info' grouping includes:

   o  'tp-technology' grouping,

   o  'tp-tools' grouping,

   o  and 'connectionless-oam-tps' grouping.

   The groupings of 'tp-address' and 'tp-address-ni' are kept out of
   'test- point-location-info' grouping to make it addressing agnostic
   and allow varied composition.  Depending upon the choice of the 'tp-
   location-type' (determined by the 'tp-address-ni'), the containers
   differ in its composition of 'test-point-locations' while the 'test-
   point-location-info', is a common aspect of every 'test-point-
   locations'.

   The 'tp-address-ni' grouping is used to describe the corresponding
   network instance.  The 'tp-technology' grouping indicate OAM
   technology details.  The 'connectionless-oam-tps' grouping is used to
   describe the relationship of one test point with other test
   points. The 'tp-tools' grouping describe the OAM tools supported.

   In addition, at the top of the model, there is an 'cc-oper-data'
   container for session statistics.  Grouping is also defined for
   common session statistics and these are only applicable for proactive
   OAM sessions.
"
s3.1:
This needs to be clarified.
OLD:
   In connectionless OAM, the TP address is defined with the following
   type:

   o  MAC address [RFC6136]

   o  IPv4 or IPv6 address

   o  TP-attribute

   o  System-id to represent the device or
      node.[I-D.ietf-spring-sr-yang]
NEW:
   With connectionless OAM protocols, the TP address can be one of the following
   types:

   o  MAC address [RFC6136] for link layer TPs

   o  IPv4 or IPv6 address for IP layer TPs

   o  TP-attribute identifying a TP associated with an application layer
   function

   o  System-id to represent the device or
      node.[I-D.ietf-spring-sr-yang]
ENDS

[Qin]: Accepted.

s3.1, last para: s/'tp-address'grouping/'tp-address' grouping/

[Qin]:Fixed.

s3.3:
I found this a little confusing - suggest:
OLD;
   As typical networks have a multi-layer architecture, the set of OAM
   protocols similarly take a multi-layer structure; each layer may have
   its own OAM protocol [RFC7276] corresponding to a specific
   administrative domain and has associated test points.
NEW:
   As typical network communication stacks have a multi-layer architecture,
   the set of associated OAM protocols may similarly have a multi-layer
   structure; each communication layer in the stack may have its own OAM
   protocol [RFC7276] that may also be linked to a specific administrative
   domain.  Management of these OAM protocols will necessitate associated
   test points in the nodes accessible by appropriate management domains.

   Accordingly, a given network interface may present several test points ENDS

[Qin]: Reasonable, thanks.

s3.5: s/e.g.,VRF/e.g., VRF/

[Qin]:Fixed.

s3.: s/per- hop/per-hop/

[Qin]:Fixed.

s4, Module/description:
Also needs the IETF copyright and redistribution boiler plate.
OLD:
  description
    "This YANG module defines the generic configuration,
     data model, statistics for connectionless OAM to be
     used within IETF in a protocol independent manner.
     It is assumed that each protocol maps corresponding
     abstracts to its native format. Each protocol may
     extend the YANG model defined here to include protocol
     specific extensions";
NEW:
  description
    "This YANG module defines the generic configuration,
     data model, and statistics for OAM protocols using
     connectionless communications, described in a
     protocol independent manner.
     It is assumed that each protocol maps corresponding
     abstracts to its native format. Each protocol may
     extend the YANG model defined here to include protocol
     specific extensions";
ENDS
[Qin]:Okay.

s4, module/contact, module/organization:  These need to be 'future proofed' - the WG and the draft authors are not appropriate for a standard.

s4, grouping session-jitter-statistics/description: s/e.g.,Packet/e.g., Packet/

[Qin]:Fixed.

s5, multiple places: s/bfd/BFD/g

[Qin]:Fixed.

s5, para 1: s/"ietf-connectionless-oam" model/The "ietf-connectionless-oam"
model/; s/technology-independent/a technology-independent/

s5, para 2:
OLD:
Note that, in this section, we only present several
   snippets of technology-specific model extensions for illustrative
   purposes.
NEW:
Note that, in this section, several snippets of technology-specific
   model extensions are presented for illustrative purposes.
ENDS

s5.1: I notice that RFC 7276 defines BFD as a connection-oriented protocol (that is used to monitor a connectionless protocol in the case of basic BFD for IP)! Some explanation may be appropriate.

[Qin]: Okay.

s5.1.1, para 2:
OLD:
Note that in BFD WG, there is a BFD YANG data model
   [I-D.ietf-bfd-yang] to be produced.  Users can choose to use "ietf-
   connectioless-oam" as basis and augment the "ietf-connectionless-oam"
   model with bfd specific details.  The bfd specific details can be the
   grouping defined in the BFD model.
NEW:
Note that a dedicated BFD YANG data model [I-D.ietf-bfd-yang] is also
   standardized.  Augmentation of the "ietf-connectionless-oam" model
   with BFD specific details provides an alternative approach that
   provides a unified view of management information across various OAM
   protocols.  The BFD specific details can be the grouping defined in
   the BFD model avoiding duplication of effort.
ENDS

[Qin]:Okay.

s5.1.1.1, para 2:
OLD:
The snippet below depicts an example of augmenting "bfd" type into
   the ietf-connectionless-oam":
NEW:
The snippet below depicts an example of adding the "bfd" type as an
   augment to the ietf-connectionless-oam" model:
ENDS

[Qin]: Okay.

s5.1.1.2:
OLD:
To support bfd technology, the "ietf-connectionless-oam" model can be
   extended and add bfd specific parameters under "test-point-locations"
   list and/or add new location type such as "bfd over MPLS-TE" under
   "location-type".
NEW:
To support BFD technology, the "ietf-connectionless-oam" model can be
   extended by adding specific parameters into the "test-point-locations"
   list and/or adding a new location type such as "BFD over MPLS-TE" under
   "location-type".
ENDS

[Qin]: Okay.

s5.1.1.2.1, para 1:
OLD:
In
   this section, we reuse some groupings which are defined in
   [I-D.ietf-bfd-yang] as following:
NEW:
In this section, some groupings which are defined in
   [I-D.ietf-bfd-yang] are reused as follows:
ENDS

[Qin]: Okay.

s5.1.1.2.2, para 2:
OLD:
In this section, we add a new "location-
   type" case and reuse some groupings which are defined in
   [I-D.ietf-bfd-yang] as follows:
NEW:
In this section, a new "location-type" case is added and some groupings that are defined in
   [I-D.ietf-bfd-yang] are reused as follows:
ENDS

[Qin]: Okay.

s5.1.2:
OLD:
   And another alternative method is using schema mount mechanism
   [I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam".
   Within the "test-point-locations" list, a "root" attribute is defined
   to provide a mounted point for models mounted per "test-point-
   locations".  Therefore, the "ietf-connectionless-oam" model can
   provide a place in the node hierarchy where other OAM YANG data
   models can be attached, without any special extension in the "ietf-
   connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount].
   Note that the limitation of the Schema Mount method is it is not
   allowed to specify certain modules that are required to be mounted
   under a mount point.

   The snippet below depicts the definition of "root" attribute.
NEW:
   Another alternative method is using the schema mount mechanism
   [I-D.ietf-netmod-schema-mount] in the "ietf-connectionless-oam" model.
   Within the "test-point-locations" list, a "root" attribute is defined
   to provide a mount point for models mounted per "test-point-
   locations".  Therefore, the "ietf-connectionless-oam" model can
   provide a place in the node hierarchy where other OAM YANG data
   models can be attached, without any special extension in the "ietf-
   connectionless-oam" YANG data models [I-D.ietf-netmod-schema-mount].
   Note that the limitation of the Schema Mount method is it is not
   allowed to specify certain modules that are required to be mounted
   under a mount point.

   The snippet below depicts the definition of the "root" attribute.
ENDS

[Qin]: Okay.

s5.2.1:
OLD:
   The following sections shows how the "ietf-connectionless-oam" model
   can be extended to support LSP ping technology.  For this purpose, a
   set of extension are introduced such as technology-type extension and
   test-point attributes extension.

   Note that in MPLS WG, there is a LSP Ping YANG data model
   [I-D.zheng-mpls-lsp-ping-yang-cfg] to be produced.  Users can choose
   to use "ietf-connectioless-oam" as basis and augment the "ietf-
   connectionless-oam" model with LSP Ping specific details in the model
   extension.  The LSP Ping specific details can be the grouping defined
   in the LSP ping model.

NEW:
   The following sections shows how the "ietf-connectionless-oam" model
   can be extended to support LSP ping technology.  For this purpose, a
   set of extensions are introduced such as the "technology-type" extension and
   the test-point "attributes" extension.

   Note that a LSP Ping YANG data model
   [I-D.zheng-mpls-lsp-ping-yang-cfg] has been standardized.  As with BFD,
   users can choose to use the "ietf-connectioless-oam" as basis and augment
   the "ietf- connectionless-oam" model with LSP Ping specific details in the
   model extension to provide a unified view across different technologies. The
   LSP Ping specific details can be the grouping defined in the LSP ping model
   to avoid duplication of effort..

ENDS
[Qin]: Okay.

s9:  I think I-D.ietf-i2rs-yang-network-topo is normative.  One could discuss whether the various drafts mentioned in s5 are also normative.  Some additional normative references will come form listing the sources of imported modules (see minor issues). idnits complains that RFCs 6991, 7223 and 5462 are not explicitly referenced.  6991 and 7223 are import sources (see above) 5462 is used in s3.1 but isn't marked as a reference.

[Qin]:Fixed.
_______________________________________________
Gen-art mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/gen-art