Hi Mahesh / netmod WG, Apologies for the delay on this; just revisiting the discussion of this since we haven't seen any other responses yet (apologies if we missed anyone).
The proposals look good to us; see below. On Wed Jun 11 00:42:57 2025, mjethanand...@gmail.com wrote: > [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 I think the proposed workflow with the alternative iii) looks good. > > 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. Noted, thank you. We'll maintain all previous versions. > > > > 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. > We can take this up as a project. Given it'll be a number of modules, we'll send a list identifying the module, issues and relevant erratas. Best regards, David Dong IANA Services Sr. Specialist > > > > 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
