RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 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]."

Status: Held for Document Update (1)

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 5950
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tetsuya Hasegawa
Date Reported: 2019-12-30
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2020-01-05

Section 5.1. Initia says:

   7.  Devices that support decrypting SZTP artifacts MUST posses the

It should say:

   7.  Devices that support decrypting SZTP artifacts MUST possess the

Status: Rejected (3)

RFC 8572, "Secure Zero Touch Provisioning (SZTP)", April 2019

Source of RFC: netconf (ops)

Errata ID: 6685
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alex Krichevsky
Date Reported: 2021-09-14
Rejected by: Robert Wilton
Date Rejected: 2024-01-12

Section 8.3 says:

   Each URI entry in the bootstrap-server-list is structured as follows:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
    |       uri-length              |          URI                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

    * uri-length: 2 octets long; specifies the length of the URI data.
    * URI: URI of the SZTP bootstrap server.

It should say:

Multiple URI entries can be specified in a comma-separated list.

Notes:

Most of DHCP servers can be configured only with ASCII string for options.
--VERIFIER NOTES--
As discussed with the authors on the NETCONF mailing list the intent is to have one URI entry per uri-data entry (containing URI-length and the associated URI). Multiple instances of uri-data entry are permitted.

Errata ID: 6690
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alex Krichevsky
Date Reported: 2021-09-22
Rejected by: Rob Wilton
Date Rejected: 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:

Duplicate of 6684.
--VERIFIER NOTES--
Duplicate of 6684.

Errata ID: 7223
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2022-11-01
Rejected by: Rob Wilton
Date Rejected: 2022-11-02

Section 5.2 says:

    4.  Loop back to Step 1

It should say:

    4.  Loop back to Step 2

Notes:

There is no need to repeat step 1.
--VERIFIER NOTES--
As per Kent's (the author) clarification:

Per the note beneath the diagram and the last paragraph in that section (Section 5.2), alternate config mechanisms MAY be used and they SHOULD unset the "flag enabling SZTP bootstrapping", which is what Step 1 tests.

Report New Errata



Advanced Search