Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
This is a minor thing, but people get really confused about it so I'd like to discuss it. This document allows for minting new "IETF Standard" tags by publishing documents that are not standards of any kind. That is, because the registry specified in 7.2 has its allocation policy as IETF Review, that means that informational documents can be used to register new "IETF Standard" tags. This seems ripe for creating further confusion about what is and is not an IETF "standard." Could these tags simply be called "IETF tags"?
I strongly encourage you to follow the advice of the Gen-ART reviewer and include a contact or change controller field in the registry defined in 7.1. For a registry where you expect other SDOs to be making registrations, this field can be critical if the registry entries need to be updated years after they are created. See RFC 8126 Section 9.5. Adam noted that RFC 8199 is now a downref, based on changes made in the -07, after IETF last call. I think this is fine and does not require another last call.
I think this document does introduce new security considerations, specifically the ability for one user to remove ("mask") tags from being visible to other users. A malicious user could interfere with the operations of other users/entities, especially in the case mentioned in an example where multiple semi-independent clients use tags to indicate modules to avoid that may be broken.
Section 2 Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better than "standard prefix". Section 2.4 Similarly, "future registration" or "future use" seem to be better fits for the intended sentiment. Section 3.2 I may be misreading, but this seems to be encouraging implementations to add new ietf:-prefixed tags that are not necessarily registered or specified in IETF-consensus documents. Section 7.2 This registry allocates prefixes that have the standard prefix "ietf:". [...] The registry name just talks about "tags"; are we really allocating *prefix*es?
This is generally a fine document, but after checking RFC 7950 syntax for strings I question why you think you need non ASCII tags. There are so many problems that can arise from that. For example, how would IANA be able to enforce uniqueness of Unicode tags written in different Unicode canonicalisation forms?
Minor comment: Maybe name the new registry "IETF YANG Module Tags" instead of "YANG Module Tags"...?
I agree with Mirja’s comment about the name of the registry.
(1) Along the same lines of Alissa's DISCUSS, which I support. §6.1: "For standardized modules new tags MUST be assigned in the IANA registry defined below, see Section 7.2." What is a "standardized module"? It sounds like a Standards Track document, but (as Alissa pointed out) the registration policy is only IETF Review. (2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this registry." That statement along with the text in §2.4: Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is reserved for future standardization. These tag values are not invalid, but simply reserved in the context of standardization. ...seem to indicate that a tag with any format can be used. Is that true? Is that the intent? If so, then it seems to me that vendor/user tags could simply forgo the standardized prefix. I guess this is ok...it just makes me wonder about the need to even define those prefixes. (3) I'm not sure what, but I think it may be wise to give the would-be DEs for the new registry in §7.1 some more guidance on the allocation of new prefixes. The only current guidance is this: "Prefix entries in this registry should be short strings consisting of lowercase ASCII alpha-numeric characters and a final ":" character."