Contributor hat on. I agree with Michael that the tagging mechanism should be stronger (a MUST). Without that, how would you prevent drift in the repo vs. what was standardized in an RFC?
Moreover, as I read this, I wonder specifically which steps in the current RFC process VELOCE will help speed up. I’m all for faster YANG module development, but simply using an SCM doesn’t get over hurdles like WG consensus, timely PR (and issue) reviews, DIR reviews, IETF-wide reviews, etc. It would also be useful to have more than a binary success/fail. By that I mean, if a module goes through this and a module with associated RFC pop out in two years does that mean the process is good or was the module just trivial. I think part of the experiment should be observing the results and then carefully drawing conclusions (maybe even from multiple instances of the experiment). Joe — PGP Key : https://www.marcuscom.com/pgp.asc > On Mar 16, 2026, at 07:12, Michael Richardson <[email protected]> wrote: > > > 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://agilealliance.org/glossary/velocity/ > > 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] http://www.sandelman.ca/ | ruby on rails > [ > > > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] > <signature.asc> _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
