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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Kent,

sorry I didn’t read this as a question. However, looking at this again, I actually think the text is pretty clear as it is and I must have overlooked this on my first read. So I guess no further action needed. Thanks for engaging!

Mirja



> Am 06.12.2018 um 17:40 schrieb 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
>> 
>> 
>> 
>> 
> 
>