Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-23.txt

[David Mandelberg <[e-mail]>]

On 08/27/2018 01:22 PM, Kent Watsen wrote:
>> Section 5.6: "Hinder[ing] the ability for the device to continue the
>> bootstrapping sequence" was only part of why I asked about the error
>> cases. The other part is that I think there's a security risk in leaving
>> bootstrapping enabled after the device is partially/mostly configured,
>> since bootstrapping opens the possibility for various parties to change
>> the configuration. Is there a reason not to require devices to fully
>> rollback the configuration if there's an error after it's applied?
> 
> Why do you think the document allows this?  The beginning of s5.6 says:
> 
>     Some state MAY be retained from the bootstrapping process (e.g., updated boot
>     image, logs, remnants from a script, etc.), however, the retained state MUST
>     NOT hinder the ability for the device to continue the bootstrapping sequence
>     (i.e., process onboarding information from another bootstrap server).
> 
> Are you thinking that the MAY needs to be a MUST NOT?  This text (s5.6) used to
> be much more explicit but need to undo the  configuration (I think I sent you
> that version), but others felt that it  was too proscriptive and, as the
> Implementation Notes section (at the very end of 5.6) says, the device may have
> other ways to reset itself (e.g., relaunch a VM).  Thoughts?

I think it's fine if boot images and logs are retained, and allowing for 
variation in how the device resets itself makes sense. I think the MUST 
NOT covers only half of what shouldn't be retained though. What do you 
think of this? (Feel free to change my wording, especially if you can 
think of something less vague than "behave as if".)

Some state MAY be retained from the bootstrapping process (e.g., updated 
boot image, logs, remnants from a script, etc.). However, the retained 
state MUST NOT hinder the ability for the device to continue the 
bootstrapping sequence (i.e., process onboarding information from 
another bootstrap server), and MUST NOT enable the device to behave as 
if it were successfully configured.


-- 
https://david.mandelberg.org/