[Anima] Re: [Technical Errata Reported] RFC8995 (7263)

[Mahesh Jethanandani <[e-mail]>]

Hi Esko,

> On Jan 13, 2026, at 12:32 AM, Esko Dijk <[e-mail]> 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 <[e-mail]> <mailto:[e-mail]> wrote:
>>> 
>>> 
>>> Rob Wilton (rwilton) <[e-mail]> <mailto:[e-mail]> 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 <[e-mail]> <mailto:[e-mail]>   . o O ( IPv6 IøT consulting )
>>>           Sandelman Software Works Inc, Ottawa and Worldwide
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> Mahesh Jethanandani
>> [e-mail] <mailto:[e-mail]>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Anima mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> -- 
> IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]> | [phone]
> 


Mahesh Jethanandani
[e-mail]