Re: [Netconf] Shepherd review of draft-ietf-netconf-zerotouch-22

[Kent Watsen <[e-mail]>]

Hi Mahesh,

Thanks for your review, comments below.

Kent // author


----- original message -----

Hi Kent,

I am aware that you just published another version of the document. Most of this review was done for -22 version of the document. 

In Section 5.6, in paragraph 6 the document talks about initial configuration being applied. If an error occurs, is that initial configuration removed? If so, how? It also says that the device may not (did you mean RFC 2119’s MAY NOT?) reset itself in order to wipe out any state the preconfigure script may have left behind. That means in case of an error not only will there be initial configuration left on the device, but any state left behind by the preconfigured script. With post-configured script, the device is supposed to reset itself, removing any pre-configured state and also any initial configuration. I do not understand why with initial configuration this exception is being made (of not resetting the device and clearing any state left behind by the current or previous step).

<KW> Please read Section 5.6 in -23.  This section was significantly rewritten specifically to address this issue.


Section 6.3. You need to add references to the RFCs that you import or reference in the YANG model, e.g. RFC 6991.

<KW> I think that this is already the case.  Please see the 2nd paragraph in Section 6.3.  Is there a particular issue?


leaf-list download-uri:

I am confused by the last sentence in the description. “If a secure scheme (e.g. https) is provided, a device may (again, did you mean RFC 2119’s MAY) establish an untrusted connection to the remote server to obtain the boot-image.”  Are you suggesting that the device (client) does not need to authenticate itself to the server? 

<KW> No, I mean that the device MAY blindly authenticate the server's end-entity certificate. Also, that MAY is capitalized already, right?


Most of the draft talks about the need for the device to authenticate itself for the server to validate the device-id of the requestor. 

<KW> Correct.


Also, are you suggesting that a untrusted connection is fine because the image returned will be a signed image only? 

<KW> No, the text is not trying to suggest that, though it is somewhat true.  More specifically, the draft says that either signed data, of either type (redirect or onboarding information), or (likely more) unsigned redirect information, can be returned.


This was made somewhat clear only after seeing Appendix B diagram.

<KW> Gotcha.  We can fix the description, by adding "by blindly accepting the server's end-entity certificate".  Below is the resulting text.  This text also accommodates other comments Mahesh had a couple days ago.

          leaf-list download-uri {
            type inet:uri;
            ordered-by user;
            description
              "An ordered list of URIs to where the same boot image
               file may be obtained.  How the URI schemes (http, ftp,
               etc.) a device supports are known is vendor specific.
               If a secure scheme (e.g., https) is provided, a device
               MAY establish an untrusted connection to the remote
               server, by blindly accepting the server's end-entity
               certificate, to obtain the boot image.";
          }


s/This doesn’t affect Security so much as Privacy/This doesn’t affect security as much as privacy/
s/the device is being directed/the device is being directed to/
s/server tis time/server this time/

<KW> All fixed.


Appendix C.3:

In the diagram, step 3, it says that “only if source is a bootstrap server, send progress updates”. Shouldn’t it be a “trusted bootstrap server”? The description for step 3 clarifies it.

<KW> Good catch!  fixed.