RFC Errata
Found 5 records.
Status: Verified (4)
RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019
Source of RFC: netconf (ops)
Errata ID: 6684
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-14
Verifier Name: Rob Wilton
Date Verified: 2021-09-22
Section 8.1 says:
The DHCPv4 server MAY include a single instance of the OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends. Servers MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT option.
It should say:
The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.
Notes:
The original text contradicts the statement in the same section:
"If the length of the 'bootstrap-server-list' field is too large to
fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split
into multiple instances of the option according to the process
described in [RFC3396]."
Errata ID: 6616
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Srihari Ramanathan
Date Reported: 2021-06-18
Verifier Name: Rob Wilton
Date Verified: 2021-06-21
Section 4.2.3 says:
For device-independent queries, the three bootstrapping artifacts
defined in Section 3 are encoded into the SVR records as follows.
Artifact to SRV Record Mapping:
Conveyed Information: This artifact is not supported directly.
Instead, the essence of unsigned redirect information is mapped
to SVR records per [RFC2782].
It should say:
For device-independent queries, the three bootstrapping artifacts
defined in Section 3 are encoded into the SRV records as follows.
Artifact to SRV Record Mapping:
Conveyed Information: This artifact is not supported directly.
Instead, the essence of unsigned redirect information is mapped
to SRV records per [RFC2782].
Notes:
In both places "SVR" should obviously read "SRV".
Errata ID: 6807
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2022-01-04
Verifier Name: RFC Editor
Date Verified: 2022-04-06
Section 3.3 says:
When unencrypted, the ownership voucher artifact is as defined in [RFC8366]. As described, it is a CMS structure whose topmost content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding. When encrypted, the topmost content type of the ownership voucher artifact's CMS structure MUST be the OID id-envelopedData (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding.
It should say:
When unencrypted, the ownership voucher artifact is as defined in [RFC8366]. As described, it is a CMS structure whose topmost content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1.40), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding. When encrypted, the topmost content type of the ownership voucher artifact's CMS structure MUST be the OID id-envelopedData (1.2.840.113549.1.7.3), and the encryptedContentInfo's content type MUST be the OID id-signedData (1.2.840.113549.1.7.2), whose eContentType MUST be OID id-ct-animaJSONVoucher (1.2.840.113549.1.9.16.1.40), or the OID id-data (1.2.840.113549.1.7.1). When the OID id-data is used, the encoding (JSON, XML, etc.) SHOULD be communicated externally. In either case, the associated content is an octet string containing ietf-voucher data in the expected encoding.
Notes:
The OID for id-ct-animaJSONVoucher is 1.2.840.113549.1.9.16.1.40.
--VERIFIER NOTES--
Author verified errata is correct and also appears in http://oid-info.com/get/1.2.840.113549.1.9.16.1.40
Errata ID: 6933
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dimitris Athanasopoulos
Date Reported: 2022-04-14
Verifier Name: RFC Editor
Date Verified: 2022-04-14
Section section-7.2 says:
Content-Type: application/yang.data+xml
It should say:
Content-Type: application/yang-data+xml
Notes:
Note the diff: "yang.data" vs "yang-data"
There are 5 occurrences of the same errata in Section7.2.
As per RESTCONF Protocol [rfc8040] valid Media Types are:
a) application/yang-data+xml
b) application/yang-data+json
References:
https://datatracker.ietf.org/doc/html/rfc8040#section-11.3
https://www.iana.org/assignments/media-types/media-types.xhtml
Status: Reported (1)
RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019
Source of RFC: netconf (ops)
Errata ID: 6691
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Krichevsky
Date Reported: 2021-09-22
Section 8.1 says:
The DHCPv4 server MAY include a single instance of the OPTION_V4_SZTP_REDIRECT option in DHCP messages it sends. Servers MUST NOT send more than one instance of the OPTION_V4_SZTP_REDIRECT option.
It should say:
The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.
Notes:
The original text contradicts the statement in the same section:
"If the length of the 'bootstrap-server-list' field is too large to
fit into a single option, then OPTION_V4_SZTP_REDIRECT MUST be split
into multiple instances of the option according to the process
described in [RFC3396]."