Hi all, The proposed text still needs some work here; I would urge the WG not to accept this in current form. That said, using normative language in this specific part certainly helps to clarify the requirements for implementers.
As a side question to all about IETF requirements language - what is the difference between "X is included." and "X MUST be included." ? For many years I have read sentences like "X is included" or "X is set to Y" as equivalent to a MUST. And such sentences are used a lot in RFCs. Surely we don't want to replace all of these cases by normative language? But if it helps to clarify things for this specific case, then fine to do it. The erratum motivation / note was not saying why this particular case needs normative language. A few points: * corrected text has "SHOULD BE" which isn't RFC 2119 compliant. * actually, the Registrar MUST include the idevid-issuer field, not intended as a "SHOULD". Reason: the Registrar wouldn't know if the MASA would need this field or not -- there is no signaling in-protocol by MASA to tell whether it wants this field -- so the only thing the Registrar can do is include it to cover all cases. There is no reason for the Registrar to exclude it. Or at least, I don't know one and no reason is given in the erratum note. Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of RFC Errata System Sent: Friday, December 9, 2022 16:21 To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [Anima] [Technical Errata Reported] RFC8995 (7263) The following errata report has been submitted for RFC8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7263 -------------------------------------- Type: Technical Reported by: Rufus Buschart <[email protected]> Section: 5.5 Original Text ------------- idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure unique interpretation of the serial-number. In the case of a nonceless (offline) voucher-request, an appropriate value needs to be configured from the same out-of-band source as the serial-number. Corrected Text -------------- idevid-issuer: The Issuer value from the pledge IDevID certificate SHOULD BE included to ensure unique interpretation of the serial- number. In the case of a nonceless (offline) voucher-request, an appropriate value MUST be configured from the same out-of-band source as the serial-number. Notes ----- The current language is no language according to RFC 2119. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45) -------------------------------------- Title : Bootstrapping Remote Secure Key Infrastructure (BRSKI) Publication Date : May 2021 Author(s) : M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen Category : PROPOSED STANDARD Source : Autonomic Networking Integrated Model and Approach Area : Operations and Management Stream : IETF Verifying Party : IESG _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
