Re: [Netconf] Mirja Kühlewind's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Mirja,

I assume you're happy with the Github commit, but what about the [uncommitted] proposal to add something like ", thus ensuring all possible bootstrapping options are attempted before starting over." to the end of the text in Section 5.6 discussed below?

Kent



-----Original Message-----
From: "Mirja Kuehlewind (IETF)" <[e-mail]>
Date: Thursday, December 6, 2018 at 10:49 AM
To: Kent Watsen <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, NETCONF Working Group <[e-mail]>
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-netconf-zerotouch-25: (with COMMENT)

Thanks! That helps!


> Am 06.12.2018 um 02:40 schrieb Kent Watsen <[e-mail]>:
> 
> Hi Mirja,
> 
> Thanks for your review!
> Please see below for responses.
> 
> Kent // principle author
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>> Thanks for this well-written doc.
>> 
>> One quick question which wasn't fully clear to me from the text
>> in the doc: If onboarding fails at some point, is the device
>> supposed to iterate over another bootstrapping source or stop
>> completely?
> 
> The device is to never stop trying to bootstrap, even in case of
> a failed attempt.  The hope is that that the device's failed
> attempts will be noticed and rectified by an administrator of
> the operator's orchestrator/NMS system.
> 
> Checking the text to ensure this intent is conveyed, we find in
> Section 5.3:
> 
>   Otherwise, the device MUST attempt to process the onboarding
>   information as described in Section 5.6.  In either case, success or
>   failure, the device MUST exit the recursive algorithm, returning to
>   the bootstrapping sequence described in Section 5.2, the only
>   difference being in how it responds to the "Able to bootstrap from
>   any source?" conditional described in the figure in the section.
> 
> So, in your case, it is a "failure" and thus the answer to the
> conditional is "No".  However, to your point, the current s5.2 
> text says "Loop and/or wait for manual provisioning", which 
> isn't quite right.  I have fixed this in the Github commit 
> link provided below.
> 
> Continuing checking the text, we also find in Section 5.6:
> 
>   If the device encounters an error at any step, it MUST stop
>   processing the onboarding information and return to the bootstrapping
>   sequence described in Section 5.2.  In the context of a recursive
>   algorithm, the device MUST return to the enclosing loop, not back to
>   the very beginning.
> 
> Which I think is pretty good as is, though it might help to tack
> onto the end of the last sentence ", thus allowing the logic to
> attempt all possible bootstrapping options before starting over."
> Thoughts?
> 
> 
> 
>> One minor comment:
>> Maybe spell out TPM and provide a reference.
> 
> Fixed all three instances of "TPM".
> 
> 
> 
> Here is the Github commit for the above changes, as well as a
> minor/unrelated RFC4408-reference issue reported by Adam:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netconf-2Dwg_zero-2Dtouch_commit_0e86ec25f0f83c49dc1ec37e2b9f20bdec874a6f&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=tdPa_tMXTHo9_nEeMuGHsRyflARVGiqV5uz_oxwxZcg&s=IUawZTPKc9rN7G2W3eQO0S-BxaBUz8M1jWwj1GaprCI&e=
> 
> Thoughts?
> 
> Kent
> 
> 
> 
>