Subject: [Netconf] review of draft-ietf-netconf-zerotouch-00

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jul 2014 19:01:10 -0400 (EDT)

Hi,

I have reviewed draft-ietf-netconf-zerotouch-00 and here are my
comments:

o  sec. 1.4

         Vendors are the de facto Configuration Signer
         for the devices it manufactures, but may delegate that role to
         external Configuration Signers.

  What eactly do you mean with "de facto Configuration Signer" in this
  case?

o  sec. 1.4

  Also mention boot images in your list and in the diagram.

o  sec. 2

     This section describes the service
     interface a Configuration Server must implement as well as what's
     needed for transport security.

  s/must/MUST/ ?

o  sec 2.1

  The term IDevID is used for the first time here.  It would probably
  be a good idea to mention this term in a Terminology section.

o  sec 2.3

   Therefore, it is RECOMMENDED for
   Configuration Servers to support transport-level encryption.

  Doesn't this contradict section 2.1 which says that https MUST be
  supported?

  Maybe you mean that it is RECOMMENDED that _devices_ use
  transport-level encryption?

o  sec 2.4

    An expiration policy is needed to limit how long a Configuration
    Server needs to retain a configuration and, in turn, how many
    configurations it might need to retain at a given time.

  I do not understand this sentence.  Why is the expiration policy
  needed?  What does the number of configs it retains has to do with
  anything?

o  sec 3.

  Terminology:  "Configuration Signer" vs. "Configlet Signer".

o  sec 4.2

  The picture says "IDevID entity".  What is this entity?

o  sec 4.2

   Devices supporting ZeroTouch MUST be pre-provisioned with one or more
   URIs for Internet-based Configuration Servers.

 Why is this a MUST?  (or why "one or more"?).  It seems to me that
 the DHCP option could be used instead of manual pre-provisioning.

 Do you expect these config server URIs to be part of the normal
 config?  See more below.

o  sec 4.2

    confidentially and not available outside the DevID module

  What is "DevID module"?

o  sec 4.3

  The test is: [if running config != factory default, boot normally]

  So if the user has done any local configuration, e.g. configured the
  Configuration Servers, it means that zerotouch won't be used?

o  sec 4.3

  I think that the picture and text could use some numbering of the
  steps to make it easier to follow, i.e., number ot match the text
  with the diagram.

o  sec 4.3

  You introduce the term GUID w/o explanation.

o  sec 4.3

   However, since the Configlet configured
   the device to "call home," upon entering its normal operating mode,
   the device immediately begins trying to establish a call home
   connection, as specified by the Configlet.

s/However, since the Configlet configured/
  However, if the Configlet configured/ ?

It seems to me this process can be used w/o call home as well.

o  sec 5.1

  You have the list of expected device identifiers in immutable
  storage - that seems to indicate that it not possible to ever add a
  new device!

o  sec 6.1.

  s/preconfigure/configure/ ?

o  sec 6.2

  Should this step also be in the diagram in 1.4?

o  sec 7.1.

  The second paragraph should probably be removed.

o  sec 7.2

  The term "unique-identifier" is pretty generic.  Should it simply be
  "device-identifier" instead?

  Also, here you are using "DevID".  Did you mean "IDevID"?  If not,
  you need to explain the difference.

o  sec 7.2

         If the device finds that it is
         not running the correct version of software, it can pull the
         correct version from the Configuration Server.

  "can pull" - section 4.3 had "MUST".

o  sec 7.5

  You define a "container configlet".  With YANG version 1, I think it
  is better to follow the restconf example and define a grouping with
  this container:
 
     grouping configlet {
       container configlet { ... }
     }

  and explain that the grouping is not intended to be used.

  (side note: maybe we should have an explicit statement for this in
  YANG 1.1; it seems we have the need for it, since we use this hack
  already in several places)

o  sec 7.5, leaf unique-identifier

  This means that it is not possible to have a single configlet for
  all devices of a certain type.  Is this necessary?

o  sec 7.5, leaf software-version

             "The device MUST must be running this version of software.
              The value for this field is device-specific, but it MUST
              be an exact match (e.g., 14.1R2.5)";

  Why is this MUST be exact match?  It seems inflexible to me.  Since
  the field is vendor specific anyway, why not let the match
  algorithm be vendor specific as well?

  Also, should this really be mandatory?

o  sec 8.2

  Remove the text about how a timestamp *could* be used?

o  signing / encrypting configlets

  I think you need to specify somewhere how the signature is inserted
  into the configlet XML document.  Currently the only hint the reader
  get is from an example...

  Same for encryption, and in this case the example is also tbd.

o  sec A.1

  This comment is related to the netconf-server data model.

  In this example teh configlet pushes a config with host keys,
  referred to by file name.   How does the device get these keys?

Editorial:
----------

o  sec. 1.4

OLD:

         The device
         is preconfigured with a secure device identity, for
         Configuration Servers URIs, and certificates for Configuration
         Signers and Configuration Servers it trusts by default.

NEW:

         The device
         is preconfigured with a secure device identity,
         Configuration Servers URIs, and certificates for Configuration
         Signers and Configuration Servers it trusts by default.

o  sec 2

  s/The unique identifies/The unique identifier/

o  sec 2.2

OLD:

   The Configuration server SHOULD to provide some user-facing interface
   to enable to the end-user to provide a Configlet and, optionally, an
   bootimage file.

NEW:

   The Configuration server SHOULD provide some user-facing interface
   to enable the end-user to provide a Configlet and, optionally, a
   bootimage file.

o  sec 3.4

s/may prefer a this role be/may prefer that this role be/

o  sec 4.3

   s/MAY also try both the raw/MAY also try the raw/

o  sec 5.1

s/either a SSH/either SSH/

o  sec 7.5, leaf configuration

OLD:
              support both the following standard data-models:

NEW:

              support the following standard data-models:

/martin