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 <bill.wu@xxxxxxxxxx>
Date: 24/10/2017 08:21 (GMT+00:00)
To: Elwyn Davies <elwynd@xxxxxxxxxxxxxx>, gen-art@xxxxxxxx
Cc: draft-ietf-lime-yang-connectionless-oam.all@xxxxxxxx, lime@xxxxxxxx, ietf@xxxxxxxx
Subject: RE: Genart telechat review of
draft-ietf-lime-yang-connectionless-oam-13
Thank for your valuable comments.
Please see my reply inline below.
-Qin
-----邮件原件-----
发件人: Elwyn Davies [mailto:elwynd@xxxxxxxxxxxxxx]
发送时间: 2017年10月24日 8:42
收件人: gen-art@xxxxxxxx
抄送: draft-ietf-lime-yang-connectionless-oam.all@xxxxxxxx; lime@xxxxxxxx; ietf@xxxxxxxx
主题: 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.