Summary: This document defines a method to tag data objects associated with operation and management data in YANG Modules. This YANG data object tagging method can be used to classify data objects from different YANG modules and identify characteristics data. Nits /subobjects/sub-objects/g Comments: If the document updates RFC 8407, it needs to mention that in the Abstract. Also the abstract can be shortened to what the document defines, and move everything else into the introduction. The document says "This document defines an extension statement ...". Is only extension statement defined? Text like "data object tags may be registered as well as assigned during module definition" follow the pattern of RFC 8819 and should be referred to rather than duplicated. If assigned during implementation, is there a possibility that the same tag is assigned by two different implementations? What is the scope of a given data object tag? Similarly, the draft says "objects can be one of container, leaf-list and list". Did you mean to say "objects can be one of type container, leaf-list and list"? The example in Figure 2 can be improved. For example, if all the data objects are for the module name "tunnel-pm", do you need the last column. More importantly, it is not clear why tunnel-src/max-latency (why a gap between / and max-latency), is not an object tag? Can a sub-object tag exist if the node is not an object tag? In Section 4, Data Object Tag Values, it says tags can be any value except carriage-returns, newlines and tabs. Does it mean spaces are allowed? Can a data object have multiple tags? What does it mean "No further structure is imposed ..."? Section 4.2 introduces the concept of vendor prefix for tags. It says vendors include extra identification in the tag to avoid collision. But what is to say that two organizations may not use the same identification? And is this identifier part of the tag or is separated from the tag with a :. Similarly, it says that user prefix is RECOMMENDED. If not using it can cause collision, why is use prefix RECOMMENDED and not a MUST? The draft has just one example. And it shows mostly ietf prefixed tags. More examples showing use of different types of tags are needed. It would be helpful to know how tags can be removed. Section 5 - YANG Module. The section does not reference the RFCs that it imports modules from, e.g. ietf-netcom-acm. Inside the YANG model, import statements need to carry reference statement. The WG link needs to refer to datatracker.ietf.org and not tools.ietf.org The Copyright statement has 2021 as the year. Line length should be limited to 72 columns. No need to repeat parent name in child node, e.g. object-name -> name. Indentation is off in places, specially in the example. A pyang compilation of the model with —ietf and —lint option was clean. A idnits run of the draft reveals a few issues. Please address them. draft-ietf-netmod-node-tags-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ------------------------------------------------------------------- ** There are 70 instances of too long lines in the document, the longest one being 15 characters in excess of 72. -- The draft header indicates that this document updates RFC8407, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 404 has weird spacing: '...ct-name nac...' == Line 493 has weird spacing: '...dentify multi...' == Line 656 has weird spacing: '...resents a pro...' == Line 999 has weird spacing: '...dentify multi...' -- The document date (November 2021) is 77 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.netconf-notification-capabilities' is mentioned on line 139, but not defined == Missing Reference: 'I-D.ietf-netmod-yang-instance-file-format' is mentioned on line 1106, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above.