Re: [netconf] [Technical Errata Reported] RFC8572 (6684)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent, Alex, Ian,

Given that we have got agreement on the proposed change, I’ve just updated the text of 6684 to match Ian’s proposed text, “verified” the errata and rejected 6690 as a duplicate.

Regards,
Rob


From: Kent Watsen <[e-mail]>
Sent: 20 September 2021 17:03
To: Alex Krichevsky <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; Rob Wilton (rwilton) <[e-mail]>; Mahesh Jethanandani <[e-mail]>; [e-mail]; Ofer Rotschield <[e-mail]>; Evgeny Lischuk <[e-mail]>; Michael Freidkin <[e-mail]>; Dan Berin <[e-mail]>; Moshe Sasson <[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8572 (6684)

Hi Alex,

              The Errata system is rather particular...
              Can you file another errata with just the corrected text?

Rob,

              As AD, can you cancel https://www.rfc-editor.org/errata/eid6684?

Thanks,
Kent (all hats)



On Sep 19, 2021, at 3:18 AM, Alex Krichevsky <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ian,

Thank you very much for your response!
Agreed, your version of the correction is fine too.

Thanks,

Alex Krichevsky
Embedded Software Director
21 Hamelacha Street|Rosh Haayin, 48091|
Edan 1 Twin Building|Park Afek|P.O.Box 11459|Israel
Mobile: +972+506347290
Web: www.asocscloud.com<http://www.asocscloud.com/>|
Follow us on LinkedIn<https://www.linkedin.com/company/54063/>
<image001.png>




From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, 16 September 2021 10:48
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Alex Krichevsky <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8572 (6684)

Hi,

The intent of the text is to define how OPTION_V4_SZTP_REDIRECT when larger than 255 bytes is conveyed in the DHCP message.

RFC3396 describes how this is achieved – the >255 byte option is created, it is then split on an octet boundary into multiple instances
of, in this case, OPTION_V4_SZTP_REDIRECT options which are placed in the DHCP message.

On receipt, the client re-assembles all of the instances of OPTION_V4_SZTP_REDIRECT into a single option and then processes the resulting
payload.

The proposed wording change could be interpreted to permit multiple ‘self-contained’ (i.e. not split according to RFC396)  instances of the
option in a message, which is not generally permitted  and may not work with client implementations.

I agree that the current text can be read as contradictory. I suggest the following change to resolve this:

Original
----
   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.

Corrected
-----
The DHCPv4 server MAY include OPTION_V4_SZTP_REDIRECT in DHCP messages it sends.

As the remainder of the section explains the intended behavior referencing RFC3396, I think this removes the ambiguity.

Thanks,
Ian


From: RFC Errata System <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 14. September 2021 at 13:16
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Farrer, Ian <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Technical Errata Reported] RFC8572 (6684)
The following errata report has been submitted for RFC8572,
"Secure Zero Touch Provisioning (SZTP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6684

--------------------------------------
Type: Technical
Reported by: Alex Krichevsky <[e-mail]<mailto:[e-mail]>>

Section: 8.1

Original Text
-------------
   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.

Corrected Text
--------------
   The DHCPv4 server MAY include a single instance or multiple instances of the
   OPTION_V4_SZTP_REDIRECT option 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]."

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.

--------------------------------------
RFC8572 (draft-ietf-netconf-zerotouch-29)
--------------------------------------
Title               : Secure Zero Touch Provisioning (SZTP)
Publication Date    : April 2019
Author(s)           : K. Watsen, I. Farrer, M. Abrahamsson
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG