Hi Esko, > On Jan 13, 2026, at 12:32 AM, Esko Dijk <[email protected]> wrote: > > Hi, > > I can understand why this erratum is filed: the (imported) YANG definition > from RFC 8366 defines "idevid-issuer" as optional, with a "MUST include" only > for cases where serial-numbers are not unique in MASA scope. > That is not so clear from the RFC 8995 text. So the answer is not option 1, > which would imply that "is included" == mandatory to include, which it is not. > > So the existing text is not wrong but for some readers it's hard to puzzle > all this together. Also there's normative text missing for this item while > other items around it do have that. > The proposed new text is not correct IMO. So we could hold it for editorial > clarification in a new revision of 8995?
If the existing text is not correct, then it does create a problem marking it HFDU. I would rather just reject it, and have a new errata filed or just wait for a new version of 8995 to address it. Thanks > > https://www.rfc-editor.org/errata/eid7263 > > Esko > > > On 13-1-2026 06:22, Mahesh Jethanandani wrote: >> I am picking up some of the backlog on the Errata. Rob suggested two >> options. I am inclined to go with his first option. Does anyone have any >> objection or would prefer the second option? If I do not hear in the next >> two weeks, I am going to go with the first option. >> >> Thanks. >> >>> On Jan 17, 2024, at 8:39 AM, Michael Richardson <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> >>> Rob Wilton (rwilton) <[email protected]> <mailto:[email protected]> wrote: >>>> Okay, I can add a clarification to the errata to indicate that RFC 2119 >>>> language is not required for the text to still be normative, and if >>>> this text is updated, the other sections should be updated in a >>>> consistent fashion. >>> >>> If you like. >>> I don't have a strong opinion. Probably we should have used BCP14 language >>> there. >>> >>>> An alternative resolution here is for me to reject the errata, >>>> indicating that the text is still a normative requirement even though >>>> it doesn’t use RFC 2119 language. Specifically, I don’t think that the >>>> existing text is wrong, but consistently using RFC 2119 keywords may >>>> add clarity. >>> >>> >>> -- >>> Michael Richardson <[email protected]> <mailto:[email protected]> >>> . o O ( IPv6 IøT consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >>> >> >> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Anima mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > -- > IoTconsultancy.nl | Email/Teams: [email protected] > <mailto:[email protected]> | +31 6 2385 8339 > Mahesh Jethanandani [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
