On Thu, May 22, 2025 at 2:29 AM <[email protected]> wrote:
> Re-, > > > > :-) > > > > As you mentioned 3GPP, the comment you may get is whether 3GPP asked for > this or was involved, etc. > > > > To anticipate those, we pushed for an LS to 3GPP (and incldued dmm :-)) to > avoid last minute comments: > https://mailarchive.ietf.org/arch/msg/dmm/A74TYA9zITID6MeoyZrrvLNHZAw/. I > lost the context if finally dmm signed this. > > > > Cheers, > > Med > > > > *De :* Lionel Morand <[email protected]> > *Envoyé :* jeudi 22 mai 2025 09:20 > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>; Satoru > Matsushima <[email protected]> > *Cc :* Kaippallimalil John <[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 > > > > Hi Med, > > > > Thank you for the clarification. > > It is weird to have a "practice" not reflected by the current IANA policy. > > > > I think that going to STD might be more tricky when considering the 3GPP > related aspects contained in the draft. > > > > Maybe we should collect the feedback from IESG before deciding the > direction to take. > > > > But any direction is fine for me. It is just to avoid useless discussion > at next stage. > > ------------------------------ > > > Lionel Morand > Mobile: +33-763471941 > Mail: [email protected] > > *From:*mohamed.boucadair <[email protected]> > > *To:*Satoru Matsushima <[email protected]>;Lionel Morand < > [email protected]> > > *Cc:*Kaippallimalil John <[email protected]>;dmm < > [email protected]>;dmm-chairs <[email protected]>;LUIS MIGUEL CONTRERAS > MURILLO <[email protected]> > > *Date:*2025-05-22 15:43:40 > > *Subject:*RE: revisions in draft-ietf-dmm-tn-aware-mobility-19 > > > > 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]> > 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]> > *Sent:* jeudi 22 mai 2025 06:27 > *To:* Lionel Morand <[email protected]> > *Cc:* Kaippallimalil John <[email protected]>; Mr. > Mohamed Boucadair <[email protected]>; dmm <[email protected]>; > dmm-chairs <[email protected]>; LUIS MIGUEL CONTRERAS MURILLO < > [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]> > 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]> > *Sent:* jeudi 22 mai 2025 06:11 > *To:* Kaippallimalil John <[email protected]> > *Cc:* Lionel Morand <[email protected]>; Mr. Mohamed Boucadair < > [email protected]>; dmm <[email protected]>; dmm-chairs < > [email protected]>; LUIS MIGUEL CONTRERAS MURILLO < > [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]> 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]> > *Sent:* Wednesday, May 21, 2025 9:25 PM > *To:* Lionel Morand <[email protected]> > *Cc:* Kaippallimalil John <[email protected]>; dmm < > [email protected]>; dmm-chairs <[email protected]>; LUIS MIGUEL CONTRERAS > MURILLO <[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]> > 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]> > *Sent:* jeudi 22 mai 2025 02:08 > *To:* dmm <[email protected]>; dmm-chairs <[email protected]>; Satoru > Matsushima <[email protected]>; LUIS MIGUEL CONTRERAS MURILLO < > [email protected]>; Lionel Morand < > [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. > > ____________________________________________________________________________________________________________ > 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] Since neither INFO nor PS seem to work, I suggest experimental which describes it even better. Behcet
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
