[Adding netmod WG] Hi David,
Sorry for the delay in responding. For the rest of the folks, David from IANA reached out seeking advice on how IANA should deal with Errata that have been verified. I am treating this thread as a discussion, not a statement on how things should be done. I would like the WG to chime in, and especially Balazs, since he has shown interest in proposing a solution by writing a draft. > On Jun 5, 2025, at 4:06 PM, David Dong via RT <iana-issues-comm...@iana.org> > wrote: > > Hi Mahesh, > > We reviewed the slides and the process as a team and had some comments: > > 1) Would it be possible to have the ops ADs be the point of contact with the > YANG Doctors? In our experience, discussions with the YANG doctors sometimes > trail off without a conclusion. > > If not, what is to be the policy for expert consensus; would it be the first > YANG doctor to respond to and approve the updated YANG module, or should we > wait for a certain number of experts to approve? I understand. The AD is already in the loop when an Errata is filed. But I am now wondering if YANG doctors should be the first point of contact, or whether it should be the authors and WG who should be the first to be contacted. YANG doctors can be a fallback option if the authors/WG are unresponsive. See updated workflow below. > > 2) Would it be possible for an updated YANG module be provided to us whenever > there is an errata that affects a YANG module, instead of the proposed > workflow? We can make the updates as proposed if they are simple and validate > the files, but in our view this would be the most efficient and least > error-prone approach to updating YANG modules, especially since as you > mentioned the errata can come in different forms. I don't believe we receive > errata affecting YANG modules very often. That is certainly an option. However, the tools do not support it. I do not believe there is a way to attach a file containing a complete model to an Errata. Therefore, to begin with, we might want to make a tool request to allow attachments to Errata. > > A proposed workflow could be: > > i) IANA receives errata notification from the RFC Editor > ii) IANA identifies YANG module(s) affected by the errata > iii) IANA notifies ops ADs of the issue and the YANG module(s) in question Alternative iii) IANA creates a review request task of the Errata that is sent to the authors with the WG in Cc. > iv) an updated YANG module is provided to IANA > v) IANA asks authors and WG chairs / ADs to approve the changes > vi) IANA uploads the updated YANG module and adds the errata as a reference > in the registry > > 3) Regarding having previous versions of YANG modules available, we had some > concerns about making a YANG module with issues (that an errata corrects) > available; while we would not delete the original YANG module from the > repository, should we only display the most current version for a module > corrected by an errata? No. Ideally, all previous versions of the model should be maintained. > > 4) Should we consider a project to check through the registry for other > modules that may be affected by errata in the same way as this module in > question? IANA wasn’t copied on errata verification notices until 2022. > Before that, we acted on errata reports only when they were brought to our > attention. Should we check for pre-2022 errata that might require YANG module > updates? Yes. Thanks. > > Thank you! > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Thu May 29 20:44:33 2025, david.dong wrote: >> Hi Mahesh, >> >> Thank you for clarifying. >> >> I'll bring this to the team and will get back to you early next week. >> We'll review the slides as well. >> >> Best regards, >> >> David Dong >> IANA Services Sr. Specialist >> >> On Thu May 29 12:24:27 2025, mjethanand...@gmail.com wrote: >>> Hi David, >>> >>> I am good. Thanks for asking. >>> >>> This is very timely. Balazs, whom I have added here, is working on a >>> draft that will describe the steps involved in making the changes. >>> His >>> presentation can be found at - >>> https://datatracker.ietf.org/meeting/122/materials/slides-122-netmod- >>> adding-errata-to-ietf-yang-modules-00. In particular, look at slide >>> #5 >>> of the presentation. The steps that I describe here will match what I >>> am hoping Balazs will put in the draft. It differs slightly from what >>> is in the slides. >>> >>>> On May 28, 2025, at 11:20 PM, David Dong via RT <iana-issues- >>>> comm...@iana.org> wrote: >>>> >>>> Hi Med, Mahesh, >>>> >>>> Hope you are doing well. >>>> >>>> We're reaching out with a YANG Module update question. Paul flagged >>>> an update for the YANG module for "ietf-ipfix-psamp", which had an >>>> errata updating the YANG Module back in 2016. >>>> >>>> The errata in question: >>>> https://www.rfc-editor.org/errata_search.php?rfc=6728 >>>> >>>> With regards to Paul's other comments (see below), we will reach >>>> out >>>> to inquire about erratas affecting YANG Modules in RFCs. However, >>>> since we decided on this relatively recently, should we go back >>>> through and check for older YANG modules needing updates? This >>>> particular errata was created long before we had established this >>>> process or IANA receiving errata notifications. >>>> >>>> Our current process to generate YANG Modules from RFCs involves >>>> using >>>> rfcstrip (https://github.com/mbj4668/rfcstrip) on the xml of the >>>> corresponding RFC, which we would download from the Datatracker. >>>> The >>>> Datatracker display incorporating erratas only gives a HTML >>>> version. >>>> >>>> How should we make these updates? Do we manually make the edits in >>>> the YANG Modules ourselves, or will an updated YANG Module be >>>> supplied to us for each errata? If so, will the ADs provide this >>>> file >>>> or should we ask the YANG doctors or another party? Should we only >>>> ask a YANG file to be provided for technical errata only, or should >>>> we ask for editorial ones as well on a case-by-case basis? >>> >>> The errata’s seem to come in different forms. Sometimes, they are in >>> the form of diffs, sometimes the diff is just described. I expect >>> that >>> the changes that have to be applied will have to be done manually. >>> Most of the times, the changes are small and therefore I am hoping >>> that IANA can take care of it with help from us, the AD’s, the >>> authors >>> who published the original YANG module, the WG where the RFC was >>> published and the YANG doctors if needed. >>> >>>> >>>> Please let us know how to proceed for these, starting with this >>>> "ietf-ipfix-psamp" YANG Module; thank you! >>> >>> For the particular YANG module in question, I would suggest that: >>> >>> - IANA make an attempt to make the changes suggested by the errata. >>> Start with the latest version of the module, and apply the changes of >>> the errata is applied. Once that is done, two things need to happen. >>> A >>> revision statement and a new file with a new date stamp. These two >>> steps are the same as the steps followed to when a IANA YANG module >>> is >>> updated. See step 2 and 3 in Slide 5 of the above presetation. >>> - Use YANG validator <https://www.yangcatalog.org/yangvalidator> to >>> validate the updated module. I would not burden IANA with downloading >>> the tools mentioned. If you run into issues, we can help, or we can >>> ask authors/WG/YANG doctorsfor help. >>> - we then publish the changes and ask the authors and WG to approve >>> the changes. This can come in the form similar to a WGLC and can be >>> run by the WG chairs. I can work with WG chairs to make it happen. >>> - Once the WG approves the changes, the module can be uploaded to the >>> same site where the original module was published. Since the module >>> will have a new file name (with a more recent time stamp) there >>> should >>> be no conflict with an existing module. >>> >>> Does this help? >>> >>>> >>>> Best regards, >>>> >>>> David Dong >>>> IANA Services Sr. Specialist >>>> >>>> On Tue May 27 20:57:53 2025, pait...@ciena.com wrote: >>>>> The issue is that the yang models provided through the "YANG >>>>> Parameters" page (and by rsync / ftp), are not updated with RFC >>>>> errata. Those who download and use these models trust IANA and are >>>>> unaware of the unapplied errata. >>>>> >>>>> It is perhaps onerous for IANA to be expected to perform the >>>>> updates, >>>>> and not unreasonable to expect the authors to correct and update >>>>> their >>>>> own yang. Or indeed, as the population ages and people move on, to >>>>> allow others to apply the errata and update the yang on their >>>>> behalf. >>>>> >>>>> In either case, who verifies the resulting yang to ensure no >>>>> accidental or malicious changes are made? I've seen cases where >>>>> people >>>>> have omitted a quote mark or a semicolon while updating, thus >>>>> accidentally rendering the yang invalid. >>>>> >>>>> P. >>>>> >>>>> >>>>> ________________________________ >>>>> The errata question may take a little longer. David Dong and >>>>> Sabrina >>>>> Tanamal are more conversant with this topic than I am, but I'm the >>>>> only one of us online today (rotating holiday coverage). There >>>>> have >>>>> been questions in the past about when/how to update for errata >>>>> that >>>>> we've discussed with the ADs/YANG doctors. >>>> >>>> >>>> On Mon May 26 12:26:14 2025, pait...@ciena.com wrote: >>>>> IANA, >>>>> >>>>> "ietf-ipfix-psamp" is listed on the "YANG Parameters" page. >>>>> >>>>> https://www.iana.org/assignments/yang-parameters/yang- >>>>> parameters.xhtml >>>>> >>>>> The yang was defined in RFC 6728, which has errata which affect >>>>> the >>>>> yang. So I've updated the yang to resolve the errata. >>>>> >>>>> What is the process for submitting the updates and updating the >>>>> "YANG >>>>> Parameters" page? >>>>> >>>>> (This must be possible because "ietf-alarms" lists "Errata 6866".) >>>>> >>>>> Thanks, >>>>> P. >>> >>> >>> Mahesh Jethanandani >>> mjethanand...@gmail.com > Mahesh Jethanandani mjethanand...@gmail.com _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
