Re: [Netconf] issues with processing onboarding information (zerotouch)

On Tue, Aug 14, 2018 at 2:17 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Kent Watsen <kwatsen@juniper.net> wrote:
> >
> > >> Perhaps.  The text could just say "the device must, on error, exit the
> > >> bootstrapping sequence leaving behind no state".
> > >
> > > But even this might not be necessary in some environments.  I think
> > > this whole notion of dealing with state associated with script
> > > execution should be left to implementations to deal with.  It would be
> > > ok if this document had some kind of Implementation Notes where things
> > > like this could be discussed (w/o any 2119 language though).
> >
> > This particular point was raised both offline as well as from the SecDir.
> > From SecDir:
> >
> >   """
> >   I think it's already clear what an error in paragraph 6 is. What I
> >   found unclear was what to do with errors in paragraphs 6 or 7. Yes,
> >   don't go on to the next step, but what about: In paragraph 6, should
> >   the device rollback any partial config update if there's an error?
> >   In paragraph 7, should the device rollback all config from paragraph
> >   6 if there's an error?
> >   """
>
> But this is a bit different than having cleanup parameters to the
> scripts.  This seems to ask for a clarification that the config must
> be committed all-or-nothing.  I think that it would be good to make
> this clarification.
>
>

I would prefer to allow vendors some implementation flexibility.
The boot procedure can be complex and the "startup" config may
be partially derived from internal components.  The bootstrap config
may in fact be invalid until the system finishes its boot sequence.
(i.e., implementation-specific stuff happens to convert <running>
to <intended>)

Andy

Also, in your original email in this thread you had
>
>  c) change how script errors are handled from being "device
>     reset" to "the script MUST not leave behind any state".
>     This removes a potentially expensive reset, by shifting
>     the onus to the script writers to do the right error
>     handling logic.  Seems dangerous, but I think that it's
>     fair to assume that the script can be written this way.
>
> Ok.  OTOH I don't think that the text "the device MUST reset
> itself in such a way that wipes out any bad state the script may have
> left behind." implies that the reset is expensive.
>
>
> /martin
>
>
>
>
> > Thus, I think we need at least the high-level statement.
> >
> >
> > Kent // author
> >
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>