Hi, Joe: 发件人: Joe Clarke (jclarke) <[email protected]> 发送时间: 2026年5月14日 21:24 收件人: Qin Wu <[email protected]>; Mahesh Jethanandani <[email protected]> 抄送: Andy Bierman <[email protected]>; Michael Richardson <[email protected]>; [email protected]; Operations and Management Area Working Group Discussion List <[email protected]> 主题: Re: [yang-doctors] [OPSAWG]Re: Re: Re: VELOCE and YANGDOCTORS
[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? [JMC] Not sure. I’ll try to be more specific to see if we’re talking about the same thing. When I publish a GitHub new release of a draft using Martin Thompson’s Kramdown template I can fill in release notes, and then this kicks off a CI/CD process to publish the draft in DataTracker. I was suggesting the same process could also email the list with a summary of the changes (i.e., the release notes) IFF the authors want this. If they do, they’d enable this step in the CI workflow. [QW]: Yes, send an email to the list to summarize the changes to specific YANG data model draft, this is exact tool you are looking for. One such example you can reference is: https://mailarchive.ietf.org/arch/msg/quic/n-WVLSJBuHx6RoSaBoPrU33ae8s/ Today, we see more and more WGs within IETF to follow open source approach and use this weekly github summary tool to keep track of the status of the draft and open issues of the draft, not just limited to YANG data model draft. [cid:[email protected]]<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. [JMC] I think we can accelerate both, Qin. Please forgive me for what I’m about to say, but if we think of this in a more “agile” way, we can do a minimally viable YANG module for a feature and push back on requests to add the kitchen sink. Get that out the door quickly, and then iterate on version 1.1, 2.0, etc. But, authors need to have the responsible AD provide air cover in the IESG and other review processes to avoid scope creep. [QW]: it seems you are talking about YANG 1.1 and YANG 2.0. Sound to have lots of promising with excitement, If that is the case, I think some guidance for AD responsibility and WG Chairs, YANG Doctor’s responsibility should be clearly documented, e.g., what should be done? What should be in the scope? How to prioritize the work. Do you any specific suggestions to this VELOCE document? 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. [JMC] YANG is popular, and this leads to more inexperienced authors (which is good). Having a comprehensive set of tools that Just Work(tm) and provide wrapped examples (which are validated) along with tree diagrams, and linted and well-formatted modules will be super helpful to all. [QW]: I think online validation tools set low bars for inexperienced authors, encourage the team to work collaboratively in the real time collaborative working environment also can help facilitate The progress of the work, therefore what I suggest for this VELOCE document, we should make online validation in collaborative working environment mandatory, in the meanwhile, we can support Local validation in case online validation tools doesn’t work or you don’t have connection to the WG github. Here is my proposed change to VELOCE document: https://github.com/mjethanandani/veloce/pull/27 Joe
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
