Hi Mahesh, Yes, that’s it!
Made few edits for better clarity as you can see at: https://github.com/netmod-wg/rfc8407bis/commit/194a1f7303371b67528064eb62431fff4eaba9db. Let me know if we need to say more/less. Cheers, Med (as editor) De : Mahesh Jethanandani <[email protected]> Envoyé : jeudi 15 mai 2025 22:14 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : Kent Watsen <[email protected]>; [email protected] Objet : Re: [netmod] 1-week WGLC on rfc6020-iana-update Hi Med, See inline with [mj] On May 14, 2025, at 10:27 PM, [email protected]<mailto:[email protected]> wrote: Hi Kent, Please see inline. Cheers, Med (as editor) De : Kent Watsen <[email protected]<mailto:[email protected]>> Envoyé : mercredi 14 mai 2025 23:57 À : [email protected]<mailto:[email protected]> Objet : [netmod] Re: 1-week WGLC on rfc6020-iana-update Hi Med, If this document, in Section 3.1, moves https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-25#section-5.2, [Med] This one is not moved. It is still in 8407bis. This is a refresh of https://datatracker.ietf.org/doc/html/rfc8407#autoid-83(same purpose, same reasoning) how come it doesn't also move "the template necessary for registration in Appendix B"? [mj] I think the reason for the confusion is multifold. For one, in rfc8407bis, Section 5.2, the reason given for why the IANA registry should “point to the RFC number that will be assigned to this document”, i.e., rfc8407bis, is that it contains a template necessary for registration in Appendix B. But in rfc6020-iana-update document, no such reasoning is given. I imagine that is because it is mandating the uniqueness of module/submodule names, not because of the template. If you state that as the reason, it will be clear. What that means is that instead of the two references that are there currently in the IANA registry for RFC6020 and RFC8407, there will be three. Finally, when you say, "registry group to point to the RFC number that will be assigned to this document”, what you are implying is that the IANA registry will add the RFC number that will be assigned to the document. You are not intending for references that are currently there, e.g., RFC6020 or RFC8407, to be removed/replaced. Thanks. Also, where in rfc8407bis is Section 3.2 coming from? [Med] Please check https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-rfc8407bis-23&url2=draft-ietf-netmod-rfc8407bis-24&difftype=--html. This used to be Section 5.3. Kent // contributor On May 14, 2025, at 5:50 PM, Kent Watsen <[email protected]<mailto:[email protected]>> wrote: This email begins a 1-week WGLC on: Update to YANG Module Names Registration https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020-iana-update If this draft seems unfamiliar to you, it is because it skipped the adoption process and became a WG document yesterday. Please note that this document extracts content from 8407bis, which is already submitted to IESG for publication, and hence why Mahesh felt 1-week would be okay. Please send comments to the list by May 21. Kent // chair _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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 -- [email protected] To unsubscribe send an email to [email protected]
