Hi Joel, all, (removing all other @es to cci, but add opsawg as this point is relevant to the ongoing 5706 refresh)
There is an ongoing discussion about what we should say about IM and so on; hence changing the subject so that authors are aware of this thread. The changes made so far on this specific point can be seen at (section 5.2) of https://author-tools.ietf.org/diff?doc_1=rfc5706&doc_2=draft-opsarea-rfc5706bis Cheers, Med De : Joel Halpern <[email protected]> Envoyé : vendredi 16 mai 2025 01:09 À : Mahesh Jethanandani <[email protected]>; Joel M. Halpern <[email protected]> Cc : Chongfeng Xie <[email protected]>; neotec <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; markzzzsmith <[email protected]>; Linda Dunbar <[email protected]> Objet : [neotec] Re: Seek feedback on the revised Neotec charter The most common use I have seen for IMs is to enable common semantics across DMs. But we can debate their utility on other lists. Yours, Joel On 5/15/2025 6:38 PM, Mahesh Jethanandani wrote: Hi Joel, You are correct, if that is what was meant by “abstraction models”. And IM are generally developed to help define the DM, and rarely to define just a IM. On May 15, 2025, at 2:35 PM, Joel Halpern <[email protected]<mailto:[email protected]>> wrote: Just to clarify Mahesh, the IETF has sometimes developed information models to provide a common basis for multiple data models, simplifying mapping. Yours, Joel On 5/15/2025 4:49 PM, Mahesh Jethanandani wrote: Hi Chongfeng, I have looked at the charter and, in particular, the section on Work Items. For the first deliverable, IETF does not define abstraction models or APIs. What it defines are data models using YANG, which can be used to generate the APIs. Your third bullet point already mentions developing YANG models, and so the first bullet item can be folded into the third bullet item. For the second bullet item, the YANG2API effort is a separate effort and will apply to YANG models developed in any WG. They are not specific to cloud-native environments and are not neotec specific. Moreover, IETF has not standardized gRPC, so it will not develop tools to generate APIs to be consumed by gRPC. I do not know what the last statement means. The final bullet item, is a work item that Med is discussing as part of ONION. That essentially leaves you with one work item on developing YANG models. The models, as they relate to the ability of the cloud orchestrator to ask the network orchestrator to request adjustments in network services. I believe that work can happen in one of the existing WGs within the IETF if such changes are desired. I do not think you need a WG for that. I am also not convinced that the cloud and network have to be “in sync”, or in other words, that the network needs to learn the state of the cloud. If the network is not able to satisfy the needs of the cloud, it will tell the cloud as much. If it cannot, it will fail. Knowing the cloud, which is hard for any entity outside the cloud to learn, is not going to enable the network to behave any differently. Cheers. On May 8, 2025, at 9:43 PM, Chongfeng Xie <[email protected]<mailto:[email protected]>> wrote: Hi Neotec folks， Based on the comments of Med and other people, we have made revisions to the Neotec charter, here is the latest version, https://github.com/xiechf974/NeoTec/blob/main/Neotec-charter.md We sincerely hope to receive your feedback, including suggestions, questions, and critical opinions. Thanks Best regards Chongfeng, Linda _______________________________________________ neotec 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]> _______________________________________________ neotec 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.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
