Hi Med, See inline with [mj]
> On May 14, 2025, at 10:27 PM, [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 > > <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 > <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 > > <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 > <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]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
