Hi Mahesh, Great to see that we converged on the next step for this.
Offloaded that part and integrated your comments at: https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc6020-iana-update.html Even if we maintain both initial and revised versions in the registry, the uniqueness requirement is still applied when first a module is registered. Let me know if we need to tweak any of this for better clarity. Thanks. Cheers, Med De : Mahesh Jethanandani <mjethanand...@gmail.com> Envoyé : vendredi 18 avril 2025 21:00 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : draft-ietf-netmod-rfc8407...@ietf.org; NETMOD Group <netmod@ietf.org> Objet : Re: AD review of draft-ietf-netmod-rfc8407bis-22 Hi Med, See inline with [mj1]. On Apr 18, 2025, at 1:17 PM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Mahesh, You may try: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-rfc8407bis&url_2=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt [mj1] Much better. Please see inline. Section 5.2, paragraph 0 > Also, this document requests IANA to update the reference for the > "YANG Module Names" registry under the "YANG Parameters" registry > group to point to the RFC number that will be assigned to this > document as it contains the template necessary for registration in > Appendix B. I am not sure that the reference to the "YANG Modules Names" registry should be moved from RFC6020 to this document, even if it contains a template for registration. That template is much like any other YANG module, and even RFC7950 decided to leave the registry in RFC6020. [Med] The request is not to change 6020 but 8407 mention: CURRENT: YANG Module Names Registration Procedure(s) RFC Required Reference [RFC6020<https://www.iana.org/go/rfc6020>][RFC8407<https://www.iana.org/go/rfc8407>] Updated the text accordingly. [mj] You are right. The text in question is actually in the Abstract, where this document, a BCP, is updating RFC 6020, a Standards Track document. That is normally not done. For one, it creates a downref, which has not been captured in the Shepherd's writeup. For another, I am not sure if providing clarification is updating a document. It is not changing how modules are named. At a minimum, we need to remove text related to this document updating RFC 6020. [Med] The text updating 6020 is related to id uniqueness (see below). We need to fix that. If you prefer, we can offload that to a simple STD doc that has only the 6020 update. This would avoid us the struggle of bcp updating an STD. As that content passed the WGLC and so on, I guess that content does not need to go through the full WG process again. Let me know your preference. [mj1] Ok. My preference is to do this outside of this BCP. Section 5.3, paragraph 7 > OLD: > > All module and submodule names in the registry MUST be unique. > > All XML namespaces in the registry MUST be unique. > > NEW: > Modules and their revisions are maintained in the registry. > > A module and all its revisions MUST have the same name and > namespace. [mj1] I get this. You are emphasizing that the revisions have to maintain the same name and namespace. I would prefer to add submodules to the sentence. How about this: "All modules and submodules revisions MUST have the same name as the one in the initial version of the module and submodule. All module revisions MUST have the same namespace as the initial version of the module. " > > All initial version module and submodule names in the registry > MUST be unique. [mj1] I find this sentence confusing. Does it mean that only the initial version module and submodule names in the registry need to be unique? Can revisions of the module and submodule not be unique?? I do not think that is what you mean. Since the sentence above already covers all versions of the module, I would remove this sentence. > > All XML namespaces of initial version modules in the registry MUST > be unique. [mj1] And modify this statement much like the one above to say: "All module revisions MUST have the same XML namespaces as the initial version of the module." Thanks. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
