Hi Michael, On the question about the right place, ideally opsarea would be more appropriate as this is an effort that will impact the work done in many WGs and even areas, however we can't adopt documents there. With that in mind and given that opsawg is the main entry for the area, developing the effort here would allow to uplevel a bit the effort. Like the work on 5706bis, I do we expect the work is also highlighted/discussed as part of opsarea sessions, though.
No matter where this will be developed, there is a need to socialize and reach out various WGs/areas about this work. Cheers, Med > -----Message d'origine----- > De : Michael Richardson <[email protected]> > Envoyé : lundi 16 mars 2026 07:12 > À : [email protected] > Objet : [OPSAWG]VELOCE document > > > Mahesh, I've read your draft-mahesh-opsawg-veloce-yang, and I'm > looking forward to discussion at OPSAWG meeting. My high- > level/most-significant-bit comment is that this is very good. > > Is opsawg@ the right place to discuss? > > Some comments/question: > 0. VELOCE... need to backronym it to VELOCITY: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > agilealliance.org%2Fglossary%2Fvelocity%2F&data=05%7C02%7Cmohamed. > boucadair%40orange.com%7C02ceedbd042549cbb59208de82e84f7f%7C90c7a2 > 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639092131434992751%7CUnknown% > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yatQ7o > bo2XWvZgHOJUTuhzU9XmjQ%2FoxjMzc6MFDNdTI%3D&reserved=0 > > 1. Section 2 -- details are good, but many too much? Can the repo > be the > same as is used for a WG I-D? > > 2. tree diagrams seem useful to have in the main document, and > nice to > automate. > > 3. I had heard that the IETF LLC had a gitlab license, and I think > that this > is a place where we ought to think hard about this. The > friction is low > as one can login with github or via DT. > > 4. Is this an RFC3933 Process Experiment? > It seems like it, but it doesn't say, and doesn't reference > 3933. > > 5. " A release tagging mechanism should be defined to track the > intermediate versions referenced by WG I-Ds and by the RFC, > once > published. This can come in the form of a 'git tag' or by > having a > branch that corresponds to the version of the draft." > > I think that this text should be significantly stronger. > > a. git tag -s -a. Signed and annotated. > > b. need to figure out who signs at what point > > c. one of these tags ought to come from the RPC, I think. > (Requires someone to figure out how the signing key is > maintained) > > d. how are minor revisions (errata) to the module approved after > publication? > > e. how are major revisions to the module approved? Assume that no > semantic > changes occur, but there are not-backwards-compatible changes > necessary > due to the world progressing. That is, no -bis for the RFC is > considered > necessary. Do we need to structure that decision process? > > f. Is there a process for a module to update what it's > dependancies are? > Such as because a dependant module went through (e). > > section 3: " YANG modules have traditionally taken a long time to > develop, > sometimes taking over four years. However, for the purpose of > this > experiment, and since the idea is to demonstrate a faster way > for a > new YANG module to be developed, the experiment should not take > more > than two years to develop." > > I think that this misses the point. > It's not how long it takes to develop the first version of a YANG > module, it's how long it might take to revise one to make the > second version. > It's this second interval that we want to optimize. > > I would make the experiment six years long, with an evaluation > after three years. > > -- > ] Never tell me the odds! | ipv6 > mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] > https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > ww.sandelman.ca%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C02ceedbd042549cbb59208de82e84f7f%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639092131435011732%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j6lGqNxe6xmcSW3Q0HVTOpZGJozvFJ > W%2BJQc%2FLQttf5Q%3D&reserved=0 | ruby on rails [ > > > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT > consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > ____________________________________________________________________________________________________________ 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]
