Hi, Joe and all: 发件人: Joe Clarke (jclarke) [mailto:[email protected]] 发送时间: 2026年4月30日 0:29 收件人: Mahesh Jethanandani <[email protected]> 抄送: Andy Bierman <[email protected]>; Michael Richardson <[email protected]>; Qin Wu <[email protected]>; [email protected]; Operations and Management Area Working Group Discussion List <[email protected]> 主题: Re: [yang-doctors] [OPSAWG]Re: Re: Re: VELOCE and YANGDOCTORS
As I said in my email before 125, I think the experiment can “fail” with respect to allotted time, but it may have proven successful in the SCM aspects. The timing failure may be due to other process issues, and a report can help illuminate those. One thing I’ve struggled with in prose development in GitHub is still the duality of discussion points to reach consensus. One thing that may help the consensus process is for the CI/CD process (when a release is created) would summarize changes to the mailing list to both ensure a more universally accessible record and perhaps alleviate some manual burden on the author. I have struggled with how much guidance SHOULD be mandated by this experimental draft. For now, I have relied on the principal that the consensus process has to be verified on the WG email, leaving it up to the WG to decide how to “implement” the process. It could vary from, send every git update to the mailing list, to what you suggest, which is summarize the changes on the mailing list. [JMC] I personally think “release notes” make for a nice digest. And, I agree that this may be a preference. That could be an optional part of the CI that authors could choose to enable. [QW] Are you talking about using weekly github digest to keep track of status update of Experimental work in a weekly basis. Suppose you already create WG github to develop or maintain YANG module, what you need to do is to add your WG github to ietf-github-services/activity-summary https://github.com/ietf-github-services/activity-summary/blob/main/mls.json What else do we need if IETF weekly github digest is not sufficient? [14.png]<https://github.com/mjethanandani/veloce/issues/14> How much guidance should be mandated by this draft? ・ Issue #14 ・ mjethanandani/veloce<https://github.com/mjethanandani/veloce/issues/14> github.com<https://github.com/mjethanandani/veloce/issues/14> The idea of “two years” for a module is rather arbitrary. As I said before, a simple module might otherwise get published in a year. A more complicated or contentious module may take longer. One thing that might help this experiment is to somehow declare that one of its goals is to not make perfect the enemy of good. That is, with YANG Semver/Module Versioning plus a more open source-like flow to module development, modules that seem “good enough” can be released/RFC’d earlier knowing that revisions can happen quickly. All this is fine and dandy. The question is how do we enforce this? The only reason to put a timeline is that is a measureable quantity. How else do we decide the model is “good enough”? [JMC] You’re right: tough to answer. One thought I have (based on syslog at least) is air cover to have authors say, “no, we’re not going to do this right now” when certain requests for features are raised in broader reviews (think DISCUSSes). For example, empower them to say, we’ll fix anything clearly broken but if you’re asking to support X, Y, and Z, that can wait. [QW] One different point I want to make here is I am not sure we can accelerate the progress of a new YANG module experimental work using VELOCE process and SCM, comparing with Developing a new YANG module work without VELOCE process, the only difference is to move YANG module in a separate IETF hosted repository and integrate YANG tools into the repo. But for updated YANG module or bis version of existing YANG module RFC, I hope this VELOCE process can make difference, one bold thought I have, is, e.g., 1. Can we update YANG model without republishing RFC? 2. Can we update YANG model in the same way as IANA-maintained module? As we know, IANA maintains the initial version of YANG module, for any changes to IANA-maintained Module, for any changes to the initial version of YANG Module, IANA automatically generates a new revision of the corresponding YANG module, increments the revision statement with the current date, logs the change, and hosts the updated .yang file directly in the IANA YANG Parameters Registry. Since we have IETF hosted repository for YANG module, we can use WG github to maintain the initial version of YANG module, for the updated YANG module, the changes to the initial version of YANG module, WG github can record all the changes including change history, IANA registry might consider to include the URL to such WG github from where to retrieve the latest version of the module. However I am not sure republishing RFC for the updated module is needed every time, e.g., editorial or explanatory text fixes in the RFC If republishing RFC for the updated module is needed everytime, maintaining the same URL for each updated module doesn’t make sense. I like the callout about a container. I just built one with latest pyang, libyang, and yangson for the IEEE to play with in xorrkaz/docker-yang. This is needed for people to consistently and easily test modules, and I think this should be a MUST of the experiment. I have one too, and it goes beyond just validating the YANG module. It can be used to “build” a complete draft, including building the tree diagrams and inserting them into the draft. See mjethanandani/build-yang<https://github.com/mjethanandani/build-yang> github.com<https://github.com/mjethanandani/build-yang> [apple-touch-icon-180x180-a80b8e11abe2.png]<https://github.com/mjethanandani/build-yang> and this. The two can be used in conjunction to build a new draft. mjethanandani/ietf-id-template: A template that can be used to write a new IETF draft.<https://github.com/mjethanandani/ietf-id-template> github.com<https://github.com/mjethanandani/ietf-id-template> [apple-touch-icon-180x180-a80b8e11abe2.png]<https://github.com/mjethanandani/ietf-id-template> I wish there was a way to consolidate these different containers capabilities into a single repository. [JMC] Don’t see why we can’t have a common repo with a Dockerfile we can contribute to. This could be published to an IETF Docker Hub org. [QW] The tools to build tree diagram and validate YANG file and other artifacts are useful and should be integrated into I-D with yang template. However we feel these toolchains we discussed are more designed for xml source file in the local/offline development environment, not suitable For markdown source file or the online Collaborative Environment, In IETF, I see markdown toolchains (https://authors.ietf.org/en/drafting-in-markdown) become more and more popular and have been widely used for I-D development. https://github.com/martinthomson/internet-draft-template https://github.com/IETF-OPS-AD/I-D-with-yang-template/tree/main/yang For online collaboration environment, I am in favor of using markdown template. I see I-D-with-yang-template also support YANG validation and YANG tree diagram generation. Joe
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
