Hi Lionel, all, The practice so far is that yang modules are published in PS track. This is for obvious interoperability considerations.
The intended track can be revisited anyway by the IESG. From a logistic standpoint, if you ship this doc as info but the IESG thinks this is more a PS, then you will have to run an IETF. However, if you go with PS and the IESG decides that info is more appropriate, the status can be changed without having to go back to IETF LC. Cheers, Med De : Satoru Matsushima <[email protected]> Envoyé : jeudi 22 mai 2025 06:40 À : Lionel Morand <[email protected]> Cc : Kaippallimalil John <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; dmm <[email protected]>; dmm-chairs <[email protected]>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]> Objet : Re: revisions in draft-ietf-dmm-tn-aware-mobility-19 Thanks Lionel, that looks make sense. I agree with that. Best regards, --satoru On Thu, May 22, 2025 at 1:34 PM Lionel Morand <[email protected]<mailto:[email protected]>> wrote: Hi Satoru, I have reminded the IANA rules below: * IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688] * Registration Procedure(s): Specification Required * IANA is requested to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG parameters" registry. * Registration Procedure(s): RFC Required This applies to any registration of YANG module. Therefore, no need for STD RFC. Informational RFC are Regards, Lionel From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: jeudi 22 mai 2025 06:27 To: Lionel Morand <[email protected]<mailto:[email protected]>> Cc: Kaippallimalil John <[email protected]<mailto:[email protected]>>; Mr. Mohamed Boucadair <[email protected]<mailto:[email protected]>>; dmm <[email protected]<mailto:[email protected]>>; dmm-chairs <[email protected]<mailto:[email protected]>>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> Subject: Re: revisions in draft-ietf-dmm-tn-aware-mobility-19 Yes, but I just concern what if a yang module which has ietf prefix in the module name should be STD, beyond the corresponding IANA standard action. Best regards, --satoru On Thu, May 22, 2025 at 1:18 PM Lionel Morand <[email protected]<mailto:[email protected]>> wrote: I think that we can all safely agree that Informational RFC is the right track. And using this draft to define this extension is OK as the registry will use the RFC as reference. Regards, Lionel From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: jeudi 22 mai 2025 06:11 To: Kaippallimalil John <[email protected]<mailto:[email protected]>> Cc: Lionel Morand <[email protected]<mailto:[email protected]>>; Mr. Mohamed Boucadair <[email protected]<mailto:[email protected]>>; dmm <[email protected]<mailto:[email protected]>>; dmm-chairs <[email protected]<mailto:[email protected]>>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> Subject: Re: revisions in draft-ietf-dmm-tn-aware-mobility-19 Hi John, I'm fine that the draft has a yang module. But I think that it should not be the reason to make this draft to be STD. Best regards, --satoru On Thu, May 22, 2025 at 11:34 AM Kaippallimalil John <[email protected]<mailto:[email protected]>> wrote: Hi Satoru, The ACaaS draft had progressed to the point where the layer 3 bearer could not be added. Only layer 2 bearer was in the ACaaS at that point. The authors worked with Med (author of the ACaaS Yang modules) to have the hooks to introduce this Yang module and we explained this process during the last couple of IETF meetings. Copying Med here if more context on why and how this split was done is helpful Best Regards, John . From: Satoru Matsushima <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 21, 2025 9:25 PM To: Lionel Morand <[email protected]<mailto:[email protected]>> Cc: Kaippallimalil John <[email protected]<mailto:[email protected]>>; dmm <[email protected]<mailto:[email protected]>>; dmm-chairs <[email protected]<mailto:[email protected]>>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> Subject: Re: revisions in draft-ietf-dmm-tn-aware-mobility-19 I agree with Lionel on the document status, it should be INFO. In addition, the yang module, "l3-tunnel-service" to be able to configure UDP src port range, seems very much generic, and not necessarily to be defined in the draft against the scope of the draft. If we think that any yang modules which have ietf prefix name should be STD, this small yang module would be better to get a more appropriate draft, e.g., an ACasS related draft. Best regards, --satoru On Thu, May 22, 2025 at 9:35 AM Lionel Morand <[email protected]<mailto:[email protected]>> wrote: Hi John, For the question regarding Informational vs Standards, there are two aspects: A/ there are two requested IANA actions: * IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688] * Registration Procedure(s): Specification Required * IANA is requested to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG parameters" registry. * Registration Procedure(s): RFC Required For both cases, Information RFC is enough. B/ Regarding the scope of the document, it is clearly for information. Therefore my conclusion is that this draft should be published as Informational RFC, as initially intended by the authors. Hope it clarifies my comment raised at the last IETF meeting. Regards, Lionel From: Kaippallimalil John <[email protected]<mailto:[email protected]>> Sent: jeudi 22 mai 2025 02:08 To: dmm <[email protected]<mailto:[email protected]>>; dmm-chairs <[email protected]<mailto:[email protected]>>; Satoru Matsushima <[email protected]<mailto:[email protected]>>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>>; Lionel Morand <[email protected]<mailto:[email protected]>> Subject: revisions in draft-ietf-dmm-tn-aware-mobility-19 Hi, Thanks to Satoru and Lionel for the detailed comments and reviews, and Luis for a good proposal to resolve it. Posted version 19 with all the updates proposed in the WG mailing list (links below for reference). Perhaps the only issue at this point is clarify the Information/Standards status for the draft. All other comments from the working group have been addressed and this draft is ready in our view to progress to the next step. Regards, John Links: URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-dmm-tn-aware-mobility-19.txt&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C292251687851402ef6c008dd98c2c68a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638834684521447573%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g6wj3OKoZS6cRixZF%2BvIH3OOT6ttRoFG%2FEcWDsBUrWc%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-19.txt> Diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-19&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C292251687851402ef6c008dd98c2c68a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638834684521499049%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m1o9sFkIDPH8%2B7%2Bz1bSCRL05lpgWdfUtJT51WQ0HlXg%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-19> ____________________________________________________________________________________________________________ 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.
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
