Thanks Adrian for valuable review, I have integrated your comments in https://github.com/billwuqin/draft-ietf-netmod-node-tags/blob/main/draft-ietf-netmod-node-tags-07.txt Please also see my reply inline below.
-Qin 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Adrian Farrel 发送时间: 2022年4月13日 5:36 收件人: 'Kent Watsen' <kent+i...@watsen.net>; netmod@ietf.org 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06 Hi, I had previously provided a review of this document (at revision -04), and the authors worked to address my comments through the subsequent revisions. I have now re-read this document during WG last call. Most of my comments are nits, but there are a few suggestions of substance. Once these are all resolved the document will, in my opinion, be ready for publication. Best, Adrian ==== The document needs a note somewhere near the top. [RFC Editor Note: Please replace XXXX in the text with the RFC number assigned to this document, and remove this note.] [Qin Wu] thanks, have added them in several places. --- Abstract s/characteristics/characteristic/ s/the module definition/the definition of the module/ [Qin Wu] Fixed, thank. --- Introduction s/represent a portion/represent only a portion/ OLD there is no consistent classification criteria or representation NEW there are no consistent classification criteria or representations END This document defines self-describing data object tags and associates them with data objects within a YANG module, which: I think that may be s/associates them/shows how they may be associated/ s/by the NETCONF/by a NETCONF/ [Qin Wu] Good wording and proposed changes, have accepted them all. --- 4. All data object tags SHOULD begin with a prefix indicating who owns their definition. An IANA registry (Section 9.1) is used to register data object tag prefixes. Initially, three prefixes are defined. I'm not sure who you are binding with this use of uppercase SHOULD or what variance you are allowing. I think you are probably giving instructions to the authors of future documents that define new tags (since the ones you define do all have a prefix - ietf:, vendor:, and user:). But the reason you have "SHOULD" not "MUST" is because of the text in 4.3 (and see below for a comment on that). So how about being more explicit with something like: All data object tags (except in some cases of user tags as described in Section 4.3) begin with a prefix indicating who owns their definition. An IANA registry (Section 9.1) is used to register data object tag prefixes. Initially, three prefixes are defined. [Qin Wu] Your understanding is correct, the proposed change looks good. --- 4.2 These tags are defined by the vendor that implements the module, and are not registered with IANA. However, it is RECOMMENDED that the vendor includes extra identification in the tag to avoid collisions, such as using the enterprise or organization name following the "vendor:" prefix (e.g., vendor:example.com:vendor-defined- classifier). I'm still not really happy with the disambiguation achieved using "the enterprise or organization name". There is no registry of enterprise or organisation names, so there is no way to be sure of uniqueness. But if you recommended the use of an enterprise number (possibly with the secondary prefix entno:) then things would be cleaner. This would also enable you to have an example that did not use a URN which is not really an example of an enterprise name or organization name. (There is an enterprise number reserved for documentation - 32743) [Qin Wu] Good improvement, I am happy to replace the original text With “vendor:entno:vendor-defined-classifier”, yes, RFC5612 provides Enterprise Number for Documentation Use, which is 32743. --- 4.3 The ambiguity in this section needs to be sorted out. It's clear to me that you: - prefer user tags to have the prefix "user:" - you allow user tags without that prefix provided they do not contain a colon However, you have... A user tag is any tag that has the prefix "user:". For the avoidance of confusion, the colon (":") when it appears for the first time, is always assumed to be the separator between a prefix and the rest of the tag. And so, when a user tag does not have a prefix, it MUST NOT contain a colon. These tags are defined by a user/administrator and are not meant to be registered with IANA. Users are not required to use the "user:" prefix; however, doing so is RECOMMENDED as it helps avoid collisions. The first sentence defines a user tag to have the prefix "user:" which is then contradicted. Further, I don't think that there will be collisions because of the no-colon rule. Maybe this could be sorted out by replacing the text as: User tags are defined by a user/administrator and are not registered by IANA. Any tag with the prefix "user:" is a user tag. Furthermore, any tag that does not contain a colon (":", i.e., has no prefix) is also a user tag. Users are not required to use the "user:" prefix; however, doing so is RECOMMENDED. [Qin Wu] Thanks, the proposed change looks good. --- 4.4 conflicts with 4.3. That is, 4.3 says that tags can start without any of those three prefixes without being reserved. I don't think "reserved in the context of specifications" has a clear meaning. I think you need... 4.4. Reserved Prefixes Section 9.1 describes the IANA registry of tag prefixes. Any prefix not included in that registry is reserved for future use, but tags starting with such a prefix are still valid tags. [Qin Wu] Accepted, thanks. --- 5.2 An implementation MAY include additional tags associated with data objects within a YANG module. These tags SHOULD be IETF (Section 4.1) or vendor tags (Section 4.2). The use of "SHOULD" is fine, but you need to give the alternative and the reason for choosing the alternative. [Qin Wu] I think IETF tag is register while vendor tag not, I will add text to clarify. --- 7. multi-source-tag s/'non-aggregated' multi-source/'non-aggregated' multi-source/ [Qin Wu] Accepted. --- 8. This section updates [RFC8407]. A fine statement as far as it goes, but probably should say just a little more. Maybe, This section updates [RFC8407] by providing text that may be regarded as a new subsection to Section 4 of that document. It does not change anything already present in [RFC8407]. [Qin Wu] works for me. --- 8.1 s/Section Section 9.2/Section 9.2/ [Qin Wu] Fixed. --- 9.1 This registry allocates tag prefixes. All YANG Data Object Tags should begin with one of the prefixes in this registry. That's not quite true, is it? [Qin Wu] I think this is recommendation for all YANG data node tags beginning with one of prefixed in this registry, Maybe we should use RFC2119 language,e.g., replace ‘should’with ‘SHOULD’? --- 9.2 Figure 6 Table 2 There are some formatting errors in the Metric Type Tag part of the table. Also a couple of minor ones in Multiple Source Tag. [Qin Wu] Fixed. --- OLD Appendix C. Targeted data object collection example NEW Appendix C. Targeted Data Object Collection Example END [Qin Wu] Fixed, thanks. From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On Behalf Of Kent Watsen Sent: 08 April 2022 19:10 To: netmod@ietf.org<mailto:netmod@ietf.org> Subject: [netmod] WGLC on draft-ietf-netmod-node-tags-06 This message begins a Working Group Last Call (WGLC) on draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session (minutes<https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>). The WGLC will close in two-weeks (Apr 22). Here is a direct link to the HTML version of the draft: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time. Please be aware that this draft has declared IPR<https://datatracker.ietf.org/ipr/4216> indicating that license may entail possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 (mailman<https://mailarchive.ietf.org/arch/msg/netmod/SC6zfdYVmvlkquWOzP1qZszxWgs/>): [Lou] Since this work is derived from work that I contributed to, I'd be interested in hearing what new mechanism(s) is/are covered by the IPR disclosure prior to supporting WG adoption. I'm not asking in order to debate this, as that is something for other venues, I'm merely asking that you state for the record what new mechanism is covered. [Qin] Thanks for asking, different from module level tag defined in draft-ietf-netmod-module-tags , this work provide data node level tag definition, use these data node level tag definition to provide hint or indication to selection filter in the YANG push and tell the collector or subscriber which specific category data objects needs to fetched. Kent (as co-chair)
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
