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 . 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 Similarly, in s1, para 1, s/connections/communications/. 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 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. 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. 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. 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. 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 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 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). s2.1, last para: s/e.g. /e.g., / s3: Maybe the usage "is/are augmented to" is accepted YANG jargon but it isn't good English. "Augments" will be good instead. s3, para 1: The 'nd' prefix is part of the YANG specification in s4 and isn't known at this point. s3, para 3: s/eg.,/e.g.,/ s3, last para: s/test- point-locations/test-point-locations/ s3, most of the section, but especially the last para: I found this to be almost totally unreadable and useless. 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 s3.1, last para: s/'tp-address'grouping/'tp-address' grouping/ 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 s3.5: s/e.g.,VRF/e.g., VRF/ s3.: s/per- hop/per-hop/ 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 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/ s5, multiple places: s/bfd/BFD/g 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. 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 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 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 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 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 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 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 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.