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) <[email protected]> > 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 <[email protected] <mailto:[email protected]>> > Date: Wednesday, 25 October 2017 at 4:34 AM > To: Qin Wu <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Cc: "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Subject: RE: Genart telechat review of > draft-ietf-lime-yang-connectionless-oam-13 > Resent-From: <[email protected] <mailto:[email protected]>> > Resent-To: <[email protected] <mailto:[email protected]>>, > <[email protected] <mailto:[email protected]>>, <[email protected] > <mailto:[email protected]>>, <[email protected] <mailto:[email protected]>>, > Cisco Employee <[email protected] <mailto:[email protected]>>, > <[email protected] <mailto:[email protected]>>, <[email protected] > <mailto:[email protected]>>, <[email protected] > <mailto:[email protected]>>, <[email protected] <mailto:[email protected]>>, > Ron Bonica <[email protected] <mailto:[email protected]>>, Carlos > Pignataro <[email protected] <mailto:[email protected]>> > 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 > <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 <[email protected] <mailto:[email protected]>> > Date: 24/10/2017 08:21 (GMT+00:00) > To: Elwyn Davies <[email protected] <mailto:[email protected]>>, > [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>, [email protected] > <mailto:[email protected]>, [email protected] <mailto:[email protected]> > 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:[email protected] > <mailto:[email protected]>] > 发送时间: 2017年10月24日 8:42 > 收件人: [email protected] <mailto:[email protected]> > 抄送: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > 主题: 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 > <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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
