Toerless,
Thanks for the summary! Agree to add that as explanatory note. We could
add in that note very explicitly "8995 does make it mandatory to include
in the Voucher Request, by the wording "is included", whereas 8366
describes it is optionally included in the Voucher."
This was a point I had previously missed. Because the Registrar doesn't
know whether the MASA needs to see idevid-issuer or not, the only option
it has is to include it.
Esko
PS I recall that the CoAP RFC 7252 also makes heavy use of lowercase
wording like 'X is included', 'X sends to Y' or 'X and Y are compared'
for most normative behaviors.
On 15-1-2026 05:46, Toerless Eckert wrote:
Rob, *:
In summary, how about you add the following note to the Errata:
The current text of RFC8995 section 5.5 is correct and normative. RFC2119
language is not mandatory to make text normative. However:
1) All the other points in section 5.5 use normative text except for this
paragraph. Hence it would be more consistent to also use it here as
suggested by the Errata.
2) The section 5.5 text does not make it clear why it is necessary: RFC8366 does
not make this field mandatory in all cases. RFC8995 section 5.5 does make it
mandatory in the context of RFC8995. Explaining that better in a document
update to RFC8995 would improve the texts quality. The reason for making
it mandatory in all cases is so that the Registrar does not have to guess
about what the MASA assumes.
In addition: The Errata recommendations are not correct: They need to be
MUST in both cases.
Hold for document update.
---
I am suggesting the option here that leaves the most explanatory trail
of the work we invested here with hopefully the least amount of work for
everybody. Alternatively, i can also open a new errata to say the same thing.
In any case, we do not have a technical issue, but "just" editorial
issues. Which to me are equally problematic because it wastes everybodies
time to not have the best explanatory RFC. As this thread showed. So i
appreciate
any outcome that tracks all the above summarized points of the discussion.
Cheers
Toerless
On Wed, Jan 14, 2026 at 11:17:31PM +0100, Esko Dijk wrote:
> 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.
The text is correct, but it has to be read along with 8366.
Agree here that the current text in RFC 8995 Section 5.5 is correct; if read
along with 8366. If the reader doesn't open 8366, it may be unclear
whether the idevid-issuer field is mandatory or optional to include.
The new text proposed by the erratum 7263 is in any case incorrect. E.g.
there's an all-caps phrasing SHOULD BE which isn't RFC 2119 language.
And the inserted MUST is wrong - not required per 8366 and not intended to
be required - and also hard to act on ("you MUST configure an appropriate
value" - but what is 'appropriate' here exactly?).
So maybe best is to reject this erratum.
I commented on the commit also
(https://github.com/anima-wg/voucher/commit/64056649c836f7b9fd4094d827e2d04860e41a3e)
- 2 changes look incorrect.
If 8366 already addresses the erratum, why do we need to mention the erratum
in 8366bis ?
Esko
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
