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

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Aug 2018 02:36:17 +0000

Dear WG,

Three issues with the zerotouch draft were brought to my 
attention yesterday.  As author, I noticed that the draft
was still pending shepherd write up.  I discussed the matter
with the shepherd (Mahesh), who recommended sending this
email to the list regarding the issues, with the goal of
posting a -23 that the shepherd write up would use.

All issues regard Section 5.6 (Processing Onboarding 
Information).  

The following issues are presented in order of importance.

1) Strengthen text around state retained when an error is 
   encountered.  Currently the text is weak, to the point of
   concern.  There are a few places where change would be 
   needed as follows:

 a) Fix the high-level error handling statement:

    OLD
     If the device encounters an error at any step, it MUST
     NOT proceed to the next step.

    NEW
     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.  It 
     is understood that some state may be retained from the
     bootstrapping process when the device returns to the
     bootstrapping sequence.  For instance, retained state
     may include the currently installed boot-image.  Any
     such retained state MUST NOT hinder the ability for
     the device to continue the bootstrapping sequence
     described in Section 5.2.

 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?

 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.

 d) remove the following text (it is dangerously misleading):

    If there is an error, and the device previously executed a
    pre-configuration script, the device does not need to reset
    itself in order to wipe out any state the script may have 
    left behind; this implies that the pre-configuration script
    must be idempotent.

 e) clarify that the configuration commit must be atomic.

 f) clarify that any error encountered after committing the
    configuration (e.g., in the "post-configuration-script")
    must rollback the configuration to the previous configuration.

 g) clarify that failure to successfully deliver the "bootstrap-
    complete" progress-type (i.e., the "report-progress" RPC
    returns HTTP 204) must be treated as an error.

 h) clarify that "return to bootstrapping sequence" is to be
    interpreted in the recursive context.  Meaning that the
    device rolls-back one loop, rather than start over from
    scratch.

2) Change the conformance for how the boot-image is verified.
   The text already says that the image MUST be verified, but
   then says:

     To verify the downloaded boot image, the device MUST
     check that the boot image file matches the verification
     fingerprint supplied by the onboarding information.

   Perhaps the MUST should be a MAY, as the image might
   alternatively have a built-in verification method (e.g.,
   an embedded signature)?

   We could further allow a fingerprint to NOT be supplied,
   stating that, for such devices, in case one is, the 
   device can send an "boot-image-warning" message.

   Finally, it's no longer just one fingerprint, but a list,
   so the above text is misleading.

   All put together, the above could be rewritten as:

     To verify the downloaded boot image, the device MAY
     check that the boot image file matches one of the
     verification fingerprints supplied by the onboarding
     information.  In case verification fingerprints are
     supplied, but the device doesn't use them, it SHOULD
     send a "boot-image-warning" progress report message.

3) add more zerotouch "progress-type" enums, and maybe
   make more of them mandatory?

  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.

If no objections a raised, I'll plan to make these changes
next week.

Thanks,
Kent // author