In addition to what Med has already mentioned, here are a couple of things to watch out for.
- An update to the currently published draft on VELOCE - https://datatracker.ietf.org/doc/draft-mahesh-opsawg-veloce-yang/. The update will take into consideration the discussion on the [email protected] mailing list as well as the discussion in IETF 125. If you have comments, start a new thread on the opsawg mailing list to discuss the draft or open a issue or PR at https://github.com/mjethanandani/veloce - A meeting will be set up to meet regularly to discuss the process-level issues as they relate to VELOCE. Thanks. > On Apr 7, 2026, at 11:53 PM, [email protected] wrote: > > Hi CCAMP/LSR/TEAS, > > As you know, there are several issues with the current operation mode for > developing YANG modules within the IETF. Also, experience with some recent > bis doc in teas (for example) further revealed to need for a different > approach to handle such maintenance effort. As an attempt to address some > those, OPSAWG is considering a process experiment called VELOCE for > developing YANG modules [1]. > > There is on overall sketch of the new VELOCE process, but not all details are > set. We still need to agree collectively on the goals of this effort (whether > we are aiming for speed, quality, or enabling others with distinct skills to > contribute). There are different perspectives from those who write the > specifications vs those who code or review code, so we should consider a > range of criteria. The experiment may not be necessarily about doing things > faster, but differently. We need to find the right balance and frame these > goals clearly. I don’t expect we will resolve all issues with the first > version of VELOCE, but we need to start at some point and iterate. The > tooling is also important here. This is why we started by providing > IETF-OPS-AD/I-D-with-yang-template: A template repository for Internet-Draft > with YANG Modules management > <https://github.com/IETF-OPS-AD/I-D-with-yang-template>. > > Given the LSR/CCAMP/TEAS experience in defining/maintaining YANG modules and > that you are familiar with issues with developing YANG modules in RFCs, your > perspective and inputs are highly welcomed. > > In order to have the new process right, we are looking for candidates of bis > documents but also completely new modules who are willing to exercise the new > process and help adjust it as needed. Hence, this call for interest and > volunteers. I already noted that Italo/Aihua/Oscar has some ideas. > > If you are interested to contribute, please send a note to OPSAWG or directly > to Mahesh or myself. > > Cheers, > Med > > [1] https://datatracker.ietf.org/meeting/125/materials/minutes-125-opsawg-00 > > ____________________________________________________________________________________________________________ > 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. Mahesh Jethanandani [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
