Hi, Thanks for this document which I found clear and easy to read. I think you have defined a small, but particularly valuable feature.
I have a few comments and a large number of nits (sorry). Best, Adrian == Major == There is some contradiction between and within sections 4.3 and 4.4 1. If a user tag is defined as any tag that has the prefix "user:" how can you then day that users are not required to use the "user:" prefix? That would mean that a user tag is any tag that does or does not have the prefix "user:" 2. If any tag not starting with "ietf:", "vendor:", or "user:" is reserved, how can a user create a tag that doesn't start with "user:"? 3. Section 4.4 could usefully point at Section 9.1 and say that "further tags may be assigned by future specifications". --- Section 9.1 reasonably uses the "Specification Required" assignment policy. But, according to 8126, that policy requires the appointment of a designated expert. According to section 5.3 of 8126... When a designated expert is used, the documentation should give clear guidance to the designated expert, laying out criteria for performing an evaluation and reasons for rejecting a request. So you need to add a section to cover this. It can be simple if the rule is "read the specification, check it is permanent and readily available, and watch for inappropriate use of language." Or it might be more complex if you want the DE to check more stuff. == Minor == The Abstract need to explicitly call out "This document updates RFC 8407 by <doing what?> The Introduction should repeat that statement and add some detail. In fact we don't even find a mention of 8407 until Section 8, and even then there is no hint about what the "update" is. Although, in Section 1 you have Section 8 provides guidelines for authors of YANG data models. That would be the ideal place to describe the update. --- Figure 1 and its text are a little confusing. 1. It would help to lift the top Object Tag one line so there is a pipe ('|') to separate it from Data Object 1 2. The term "have" is not explained. Given the direction of the arrow, I think this means "is contained by". 3. The text says "In Figure 1, data objects can contain other data objects called subobjects." That's fine, but it would be easier to read the figure is data objects 2, 3, and 4 were marked as sub-objects. 4. The text has: A data object may contain one single object tag, or one single property tag, or one single metric tag. In many cases, a data object only contains one single metric tag. That's a bit odd. I mean, the first sentence says, "A, B, or C", and the second sentence says "In many cases C". How does the second sentence add anything? 5. The text has: the data object tagged with the metric tag also can have one or multiple MetricType tags and/or one single multi-source tag. These additional tags are not shown on the figure. --- Section 5 has As the main consumer of data object tags are users, users may also remove any tag from a live server, no matter how the tag became associated with a data object within a YANG module. Suppose there are two users accessing the same YANG data objects on a live server. This doesn't seem unreasonable in the case of different users or monitoring tools reading data about the network or devices. Doesn't this text lead to "warring tag removal" where one user adds a tag, and another user removes it? Maybe this is limited to user tags so that each user may have their own tags. But, in this case, it needs to be clearer what a user tag contains and how it is used. It would still be pretty annoying is Benoit added user:benoit to some data objects, and I went and removed them. (See also section 5.3) ...Reading the YANG module itself, I wonder whether "add" and "remove" are ambiguous. Sometimes you may mean adding or removing a tag to/from a data object. Sometimes you may mean adding or removing to/from a filter. --- 9.1 OLD Other standards organizations (SDOs) wishing to allocate their own set of tags should allocate a prefix from this registry. NEW Other standards organizations (SDOs) wishing to allocate their own set of tags should request the allocation of a prefix from this registry. END --- 9.2 Each YANG data object can have one 'opm' tag, zero or one metric-type tag, zero or one multi-source tag. Is this an instruction for IANA for the management of the registry? I don't think it is, and so it should be removed from this section. --- 9.3 and 9.4 These sections include the text "the following registration has been made:", but it hasn't been (yet). You just need to phrase this text as a request. --- Should section 10 talk about the risks associated with an attacker adding or removing tags so that a requester gets the wrong data? Should the section also talk about how the presence of tags may reveal information about the way in which data objects are used and so providing access to private information or revealing an attack vector? == Nits == Throughout You need to choose between "self describing" and "self-describing". The hyphenated version is probably correct. --- Abstract s/input, instruction, indication/input, instructions, indications/ s/selection filter/selection filters/ s/is very large/are very large/ --- 1. s/associated only with a module/associated with a module/ --- 1. At the time of writing this document (2020), there are many data models that have been specified or are being specified by various SDOs and the Open Source community. How about... Many data models have been specified by various SDOs and the Open Source community and it is likely that many more will be specified. --- 1. OLD management categories information at different locations in various different ways. NEW management information at different locations and categorised in various different ways. END OLD Let alone lack consistent classification criteria and representation for a specific service, feature, or data source. NEW Further, there is no consistent classification criteria or representation for a specific service, feature, or data source. END --- 1. s/Indicate relationship/Indicate a relationship/ s/identify characteristics data/identify characteristic data/ s/In addition, it can provide/In addition, they can provide/ s/input, instruction, indication/input, instructions, indications/ s/selection filter/selection filters/ --- 1. e.g., return specific object type of operational state related to system-management. I think this may be meant to say e.g., return specific objects containing operational state related to system-management. --- 1. s/of <get-schema>/of the <get-schema>/ --- 1. or some place where offline document are kept I don't think a "place" advertises. Maybe "an application or server where offline documents are kept" --- 1. This document defines a YANG module [RFC7950] which augments the module tag model Would another reference to 8819 be appropriate? --- 2.2 OPM Object Property Metric Should that be OPM Object, Property, Metric --- 3. OLD Among data object tags, the 'opm' (object, property, metric) tags can be used to tackle massive data objects collection, indicate relationship between data objects and only capture YANG data objects associated with performance metrics data modelled with YANG (Figure 1). NEW Among data object tags, the 'opm' (object, property, metric) tags can be used to tackle massive data object collections, indicate relationships between data objects, and capture YANG data objects associated with performance metrics data modelled with YANG (as shown in Figure 1). END OLD Figure 1: The Relation between Object, Property and Metric NEW Figure 1: The Relation between Object, Property, and Metric END --- 3. s/In Figure 2, 'tunnel-/In Figure 2, the 'tunnel-/ --- 3. OLD Consider 'tunnel-svc' data object and tunnel-svc/name data object as an example, 'tunnel-svc' data object has one single object tag (i.e., 'ietf:object') while tunnel-svc/name data object has one single property subobject tag (i.e., 'ietf:property'). NEW Consider the 'tunnel-svc' data object and the tunnel-svc/name data object as an example: the 'tunnel-svc' data object has one single object tag (i.e., 'ietf:object') while the tunnel-svc/name data object has one single property subobject tag (i.e., 'ietf:property'). END OLD e.g., only specific category such as loss-related metric subobjects need to be tagged with metric- type tag which can further reduce amount data to be fetched. NEW e.g., specific categories, such as loss-related metric subobjects, need to be tagged with a metric-type tag which can further reduce amount data to be fetched. END --- 5. s/the need of live server/the need of a live server/ s/main consumer of/main consumers of/ --- 3. has "MetricType tags" 5.1 has "Metric type tag" 9.2 has "IETF Metric Type Tags" --- 5.1 s/data objects classification/data object classifications/ s/related to metric subobject/related to a metric subobject/ s/. 'aggregated' multi-source/. The 'aggregated' multi-source/ s/being combined/to be combined/ s/. 'non-aggregated'/. The 'non-aggregated'/ s/interface) be/interface) to be/ s/correlate data object/correlate data objects/ s/defined in Section 9/defined in Section 9.2/ --- 5.2 s/or vendor specific tags/or vendor tags/ --- 7. Given that the YANG module is extractable and standalone, you should probably expand "opm" somewhere near the top. --- 7. opm-tag OLD Opm Tag is used to classify operation and management data object into object, property, and metric three categories. NEW 'opm-tag' is used to classify operation and management data objects into the three categories, object, property, and metric. END s/list. Data Object/list. The Data Object/ s/node. Data Object/node. The Data Object/ s/belonging to specific/belonging to a specific/ s/contain One single object tag or/contain one single object tag, or/ s/tag (These/tag (these/ s/As such the/As such, the/ --- 7. multi-source-tag s/identify multi-source/identify a multi-source/ s/'aggregated' multi-source/The 'aggregated' multi-source/ s/being combined/to be combined/ s/and report as/and reported as/ s/'non-aggregated' multi-source/The 'non-aggregated' multi-source/ s/interface) be/interface) to be/ --- 8.1 There needs to be a mention of Figure 3 in the text. s/defined below, see Section Section 9.2/defined in Section 9.2/ --- Appendix C The figure should have a figure number and caption, and should be referred to by the figure number from the text. --- Appendix D I think you want to include a note to the RFC Editor to remove this appendix before publication. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod