Subject: [Netconf] send 'version' in zerotouch url?

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Aug 2017 14:52:19 +0000

It has come to my attention that the zerotouch draft is missing the ability for a device to inform a bootstrap-server what version of software the device is currently running.  Doing so would allow the server to potentially return a response specialized for the version of software the device says it is running.

The proposed change is to add a query-parameter called 'version' that the device can put into its GET request.  For example:

  GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:device=<unique-id>?version=<version> HTTP/1.1

One question might be if its mandatory to implement on the device or on the server.  Another question is if it matters if the device trusts the server of not.  

Currently the draft prevents devices from sending their IDEVID certificates, and also from POST-ing progress updates, to untrusted servers.  We can discuss if this is important or not.  If it is, then we should also discuss having devices send a hash of their serial-numbers, not their raw serial-numbers, since serial-numbers are very identifying.  Otherwise, if it's not important, we should discuss maybe allowing the devices to their IDEVID certs to untrusted servers too.

BTW, the draft used to have 'unique-id' everywhere, to allow for the possibility for the hashing of the serial-number, a manufacturer decision.  In my last update, I tried to make the draft align more with the fact that the IDEVID certificate and also the Ownership Voucher (from anima draft) both have *serial-numbers* in them.  But it seems that I also touched the bootstrap server API, the leaf is still called "unique-id", but the value is stated elsewhere to be the device's serial number.  I should back that change out so again it's a manufacturer-decision for how to encode 'unique-id'.  Tying this into the previous paragraph, this question is if the draft should make hashing a MUST, for privacy reasons

Any thoughts on any of this?

Thanks,
Kent  // contributor