I have reviewed this document as part of the YANG doctors directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I've already reviewed the previous revision of this document as part of WG LC, and any significant comments have already been addressed. What remains are minor nits, that would probably be spotted/addressed by the RFC editor, and I leave it to the authors discretion as to whether/how they address these: 1. It may be helpful for the introduction to state that the module conforms to NMDA (from YANG guidelines section 3.5). I.e. add the following text + reference. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. 2. Paragraph 4.1, perhaps "will be" => "is"? 3. Section 4.3, "removed with using" => "removed using" 4. The YANG module itself: 4i) NetMod => NETMOD (two places) 4ii) The RFC 2119 boilerplate should probably be updated to cover RFC 8174. 4iii) Line length is a bit long in places. I checked using pyang against 69 chars and got this, so at least line 89 should be fixed (but the RFC editor will also fix this): ietf-module-tags@2018-10-17.yang:56: warning: line length 72 exceeds 69 characters ietf-module-tags@2018-10-17.yang:57: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:63: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:64: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:86: warning: line length 72 exceeds 69 characters ietf-module-tags@2018-10-17.yang:89: warning: line length 86 exceeds 69 characters 4iv) Possibly add ", but they have no operational effect" to the end of the description of masked-tag. Although, it is pretty obvious to me that they would just be ignored. 5) Section 6. - Suggest "It's" => "It is", "2" => "two", "3" => "three". - Suggest "is classifying modules in only a logical manner" => "only classifies modules in a logical manner" 6) Section 7.1. - Since these are guidelines, I suggest "can" => "MAY". 7) Section 8.1. - I note that this section uses "SHOULD", and section 3.4 just says reserved. Should section 3.4 also use RFC2119 language to be aigned at all?