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

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Aug 2018 19:05:49 +0000

Dear WG,

Following up on this thread, I'm beginning to make the changes,
but there are a couple items where input would be helpful:

1) regarding this:

   > b) Clarify that the scripts MUST also be idempotent, in case
   >    the bootstrapping process falls into a loop.  Alternatively,
   >    we could introduce a requirement on the scripts to supply
   >    some sort of clean-up command; then the only state retained
   >    would ever be the currently running boot-image, which is 
   >    fine.  Thoughts?

What's being discussed here is the case where the script succeeds, 
but a subsequent step (e.g., commit) fails.  In this case, do we
say:

 a) scripts MUST be idempotent.  This sounds good, but I wonder
    how possible this is.

 b) scripts MUST supply a clean-up command that removes all state
    created by a successful execution of the script.  This seems
    easier to code.

Note: if no objections, I'll go with (b).

2) regarding this:

   > Should we add more zerotouch "progress-type" enums, and maybe
   > make more of them mandatory?
   >
   > Details: module ietf-zerotouch-bootstrap-server contains the 
   > RPC report-progress, which has input leaf "progress-type",
   > which is an enumeration.  Currently, the enums follow
   > this pattern:
   >
   > - bootstrap-initiated
   > - bootstrap-complete
   > - <step>-warning
   > - <step>-error
   > - informational
   >
   > where <step> has values: parsing, boot-image, pre-script,
   > config, and post-script.
   > 
   > a) Should we add additional well-typed values for visibility
   >    reasons (i.e. more debug information sent to the bootstrap
   >    server)?  Specifically, these two:
   >
   >     - <step>-initiated
   >     - <step>-success
   > 
   > b) assuming (a), should we make more of the reporting of
   >  progress mandatory?  Currently only "bootstrap-complete"
   >  is mandatory, with everything else being a SHOULD.

That kind of says it all, any thoughts on (a) and (b)?

Note: if no objections, I'll go with (a) only and, for (b), just
make "bootstrap-initiated" mandatory.

Thanks,
Kent // author

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Aug 2018 01:30:31 +0000

Dear WG,

One last follow-up, I realized when updating the "progress-type"
enums that our plan to just have a "boot-image-success" was not
enough, because with boot images, there is the huge question of:

  was the boot image already installed, or was a new boot image
  installed and a reboot is eminent.

It matters because, in the latter case, the sequence to progress-
reports that bootstrap server is effectively ended, whereas they
more are expected in the former case.

This being the case, I'm thinking to exchange the single enum:

  boot-image-success

with the pair of enums:

  boot-image-already-installed
  boot-image-installed-reboot-eminent

and define that the device MUST send the latter if the case arises.
I'm open to less-verbose naming suggestions but, more importantly,
are there any objections to this proposal?  [I'll assume that this
is okay if no objections are raised.]

PS: once I post -23, so that the diffs can seen, I think the WG
    should be given one more chance to review the changes, before
    falling back to Mahesh to push the button.

PPS: I also received an early Security Directorate review that
     has some overlapping concerns (i.e. the error handling in
     Section 5.6), but also some other things (mostly Security
     Considerations).  I'll be sure to run any non-editorial
     changes past the WG as well, before also going into -23.

Thanks,
Kent // author

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Aug 2018 12:36:01 +0200 (CEST)

Hi,

>     created by a successful execution of the script.  This seems

Do you mean that each script takes some kind of (conceptual) input
parameter that tells it to clean up the state produced by the previous
invocation?

Could we instead leave this to implementations?  In some environments
the server might be able to do the cleanup itself (which would be less
error prone).  In some other environments the scripts might not even
create any state.

/martin

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Aug 2018 15:15:40 +0000

> parameter that tells it to clean up the state produced by the previous

Yes, exactly, it would be written as such, so implementations can choose
how to do it.

> error prone).  In some other environments the scripts might not even

Perhaps.  The text could just say "the device must, on error, exit the
bootstrapping sequence leaving behind no state".  It would be good, I
believe, to mention that some implementations may achieve this thru 
infrastructure, whereas others may require scripts to 1) leave behind
no state on error, and 2) provide a conceptual "clean up" parameter 
for when an error occurs after a script had executed successfully.

What do you think?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Aug 2018 12:10:24 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 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).

> It would be good, I

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Aug 2018 20:07:18 +0000

> 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?
  """

Thus, I think we need at least the high-level statement.

Kent // author

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Aug 2018 23:17:20 +0200 (CEST)

>   In paragraph 7, should the device rollback all config from paragraph

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.

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Aug 2018 15:40:16 -0700

> be committed all-or-nothing.  I think that it would be good to make

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