Subject: [Netconf] WGLC on zerotouch draft

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 21 Oct 2017 12:56:40 -0400

The zerotouch draft has had a couple of calls for consideration of LC, and has over that period cumulatively picked up votes of support. The last attempt resulted in a few more issues being raised by Martin, which Kent has addressed. That leaves the question of the definition of “hash-algorithm” as a base identity in the module and the ‘yang-data’ extension statement as it applies to a draft's use of 'choice' statement. Since there is no crypto module with “hash-algorithm" identities, Kent is leaving the definition in this draft. When and if, such a model/identity is defined, we will deprecate the definition in this draft. For ‘yang-data’ extension statement, we will go with Martin’s suggestion to add this in the yang-data-augmentation draft. Please note that that draft is an individual draft, but since it is a technical detail, whose solution has generally been agreed upon, we feel it should not hold up the LC.

Since we are dealing with an updated draft, a new LC has to be issued. We will count the previous votes of support for this draft in addition to any new ones to move the draft forward. This e-mail starts that LC and will last 2 weeks. Please indicate support for the draft by responding to the e-mails, and if you have objections, indicate why. For those that provided feedback before, please ensure your comments have been addressed by this version of the draft.

Thanks. 

Mahesh Jethanandani (as co-chair)
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 24 Oct 2017 23:25:53 +0000

Support.

As an FYI.   Below are some thoughts concluding our previous review interactions.

Eric

> From: Kent Watsen, July 19, 2017 2:31 PM
> 
> Hi Eric,
> 
> Thank you for your review.
> Below are my responses to your comments.
> 
> Thanks,
> Kent
> 
> --
> 
> Hi Kent Mikael, & Ian,
> 
> Good stuff in the draft.  Some questions (many perhaps educational for me).
> 
> (1) DDos of Bootstap server?
> In Section 6.3, #5 > can a bootstrap server be overwhelmed?  Should there be a
> back-off in the retries towards a bootstrap server?
> 
> <KENT> It is unlikely that real devices bootstrapping would DDoS a bootstrap
> server.  For extreme deployment scenarios, The deployment should ensure
> that the DNS record for a bootstrap server returns randomly-sorted IP
> addresses for some number of bootstrap servers.

ok

> (2) Future device reallocation
> Related to (1), lots of devices end up running a factory default config.  Is the
> assumption that a zero touch device will never do this, even if reallocated
> elsewhere later in its life?  Should this impact retry algorithms?
> 
> <KENT> I don't understand the question, but certainly a device
> could be reset to its factory default.  1st-time vs Nth-time,
> the bootstrapping logic is identical...

This isn't really a blocker, but I wanted to understand what happens when a device is sold.   The device might go to another entity without a bootstrapping server.  

Based on your table in 5.2, there isn't an explicit option to just let the default config be used.  But it isn't precluded either by the statement "await manual provisioning".

> (3) ANIMA differentiation
> Very glad to see the ANIMA integration, with the use of Vouchers.  In Section
> 13, you note that with draft-ietf-anima-bootstrapping-keyinfra there different
> use cases which have different value propositions.   My belief is that this could
> be read as draft-ietf-anima-autonomic-control-plane provides different types
> of location based validation than are viable with zerotouch, and therefore
> these solutions should be kept separate.  Is that a correct reading?
> 
> <KENT> I wouldn't say "location-based validation"...ANIMA is
> just different.  To be honest, I'm itching to remove this
> section, but you're saying you like it?

I did like it.  But it isn't precluded, which is fine.

> (4) Recognizing partial Bootstapping?
> My reading of Section 6.3 is that Bootstrapping as an all-or-nothing process.
> And therefore it is important that connectivity is available to desired bootstrap
> servers before configuration commences.  Is the assumption correct? I.e., do
> you ever know in this context as to whether the bootstrap was successful?  If
> no, how does the system indicate if part of the Bootstrap has failed?  Is this
> assumed to be an independent configuration audit?
> 
> <KENT> Almost all-or-nothing, in that it either works or it
> doesn't, but there is a potential that a device could install
> a boot-image and then, after reboot, it can't connect to any
> bootstrap servers again - so it's half-updated in this case.
> But, if this were to occur, the device would fall back the
> standard logic of looping forever and waiting for operator
> input.  The only mechanism defined for devices to report
> errors is for them to post them to a bootstrap server, but
> this assumes that 1) a bootstrap-server is being used and 2)
> the bootstrap server is trusted.  In all other cases, the
> device likely wrote messages to an audit-logging mechanism,
> but that's out of scope for this draft.

Ok.

Eric

> Eric

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh
> Jethanandani
> Sent: Saturday, October 21, 2017 12:57 PM
> To: [email-masked]
> Subject: [Netconf] WGLC on zerotouch draft
> 
> The zerotouch draft has had a couple of calls for consideration of LC, and has
> over that period cumulatively picked up votes of support. The last attempt
> resulted in a few more issues being raised by Martin, which Kent has
> addressed. That leaves the question of the definition of “hash-algorithm” as a
> base identity in the module and the ‘yang-data’ extension statement as it
> applies to a draft's use of 'choice' statement. Since there is no crypto module
> with “hash-algorithm" identities, Kent is leaving the definition in this draft.
> When and if, such a model/identity is defined, we will deprecate the definition
> in this draft. For ‘yang-data’ extension statement, we will go with Martin’s
> suggestion to add this in the yang-data-augmentation draft. Please note that
> that draft is an individual draft, but since it is a technical detail, whose solution
> has generally been agreed upon, we feel it should not hold up the LC.
> 
> Since we are dealing with an updated draft, a new LC has to be issued. We will
> count the previous votes of support for this draft in addition to any new ones
> to move the draft forward. This e-mail starts that LC and will last 2 weeks.
> Please indicate support for the draft by responding to the e-mails, and if you
> have objections, indicate why. For those that provided feedback before, please
> ensure your comments have been addressed by this version of the draft.
> 
> Thanks.
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf