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
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
