Subject: Re: [Netconf] notes to draft-ietf-netconf-zerotouch-14

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Jul 2017 17:06:28 +0000

[CC-ing NETCONF WG]

Hi Radek,

Thank-you for your review.  Please see below for my responses.  

Kent

--

Hi Kent,
being after the last call, I'm not sending this into the netconf mailing-list, but feel free to resend it. As we were discussing in Prague, we are going to implement zerotouch, so I just went through the draft and here are several comments. I've also encouraged my colleague working on this to send you his feedback as well.

draft-ietf-netconf-zerotouch-14

- section 7.2 seems as, kind of, duplication ofsection 6.3

<KENT> True, but the one in 6.3 includes e.g. the "NMS" to tie it into the workflow examples in Section 6.  There is a separate discussion regarding if Section 6 should be moved to the Appendix, since it's not normative, but some prefer it in the draft.  My only thought here is that, if Section 6 were moved to the Appendix, would it then be okay to keep this workflow?

- IDevID - not sure if the draft expects something about its uniqueness. From my perspective, vendor is actually allowed to put the same IDevID into all its devices and there will not be any (security) issue, right? It just means that bootstrap server cannot distinguish such device so they all get the same data. Or am I missing something? Anyway, I would appreciate some explicit note about IDevID uniqueness.I know that in the most cases there is some unique number hardcoded in the device, but in some cases the device can miss something like this and then vendor would have to modify the software of each of them.

<KENT> IDevID is defined by IEEE 802.1AR-2009 as an X.509 certificate that encodes "globally unique per-device identifiers".  In particular, it's a 2-tuple of a manufacturer-id field and a serial-number field.  Two devices claiming to have the same IDevID would be a security issue, as one could then impersonate the other.  All this to say, IDevID is very much unique and also very much a hardware thing.  That said, since the IDevID is being used to enable a device to authenticate itself to a bootstrap server, for which options may exist.  For instance, while not described by the draft, because it's not technically *zero* touch, a software-based solution could prompt the installer for something like a password that the device uses to authenticate itself to the bootstrap server with instead...

- at several places there is a note about sending notification about the bootstrap process to the bootstrap server. I was wondering how RESTCONF client is sending notification to the RESTCONF server, finally at one place there is note that it sends "notification" action, so then I was clear, but naming action "notification" maybe confusing :)It would be great if some other name could be used for that.

<KENT> yes, this was mentioned by others as well, but your idea to rename the action is new.  I think the action was called "progress-notification" before, which I had shortened for brevity.  Other ideas might be "bootstrap-status" or maybe "status-update".  Do you have a suggestion?

- as Robert Wilton already stated, a lot of text, mainly regarding trusted/untrusted, signed/unsigned, repeats quite lot, so some optimization would be great

- sec 11.5 - s/are are/are/

[email-masked]

- onboarding-information/boot-image/* - is it necessary to have it mandatory? I can imagine use cases when there is no boot image and the only bootstrap dataneeded is the configuration anydata content.

<KENT> I think that it needs to be mandatory because how scripts are written and configuration is constructed may depend on the version of software running on the device.  Of course, if the software running on the device already matches the expected software-version, then the software-update progress would be a no-op.  Maybe we could provide the match as a regex instead to, for instance, say that any minor-version of a specific major-release is okay  (see next comment)

- onboarding-information/boot-image/name - there is a note about regexp - no, the naming convention can very vary for different vendors/use cases, keep it without pattern

<KENT> The idea of the regex is to be able to match any vendor-specific format.  For instance, for JUNOS, I might write "17.2R[1-4].*" to match all 17.2-based 'R' release between 1 and 4.

- onboarding-information/boot-image/uri - since it is ordered list, declare it using the ordered-by statement

<KENT> fixed.

[email-masked]

- /device/unique-id - is the unique really necessary? I mean ID is widely understood as unique and in the schema it is defined as key, so I believe that just id would be fine

<KENT> this field-name is a somewhat a holdover from before.  Since then, the draft has essentially turned to using "serial number" as its unique id (per DevID).  But, since serial-numbers may not be unique across manufacturers, a unique-id may be to be constructed using the 2-tuple [manufacturer, serial-number].  It is up to each manufacturer to determine if this is needed for themselves.

Regards,
Radek