Subject: Re: [Netconf] zerotouch-14 comments

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Jul 2017 19:24:55 +0000

Andy et. al.,

As a follow-up to my email before, attached is an updated secure zerotouch presentation

PS: it's fairly light, but I think it's better that way.  Just the same, please let me know if you think anything should be improved.

Regards,
Kent

On 7/7/17, 5:47 PM, "Netconf on behalf of Kent Watsen" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

> I am reading the draft over and over until I get it ;-)

It's meant to be a fairly simple thing, but I appreciate that a draft's length is
linearly proportional to its complexity, and this isn't a short draft at all...

> The draft is well written but there are a few terminology cleanups
> left to do.  e.g., when you say "device sends notifications"
> that means the device does a POST on the /device/notification action. right?

Correct, and I agree that it's confusing, as it sounds like netconf notifications,
which is not the intent.   I made a note to fix this for the next update.

> I need to figure out how to implement the bootstrap server in 5.4
> in a way that multiple vendors could use. (Yes, that means I
> support publication of this draft and plan to implement it).
> This draft is attempting to standardize quite a lot of functionality.

The draft defines a YANG module that defines the bootstrap-server's
southbound/device-facing interface.  This API is intended to not need
any customization to be run by vendors, or even to support devices
from different vendors.  That said, the draft doesn't define any sort of
northbound/user-facing API for configuring the data.  This is code
that each vendor may have need for some customization.  Is this what
you meant?

Related, I imagine that you are also thinking about how to write the code
that would run on different vendor's devices (i.e. the NC/RC servers).
Most of the customization will be setting the factory-default configuration
(section 7.1), and configuring which sources of bootstrapping information
(section 5) are supported.

> The Enrollment (6.1) and Staging (6.2) are usually very proprietary.
> I think every vendor will have their own system. The interactions between
> the Manufacturer and Prospective Owner are described but not defined,
> also between PO and NMS.

Indeed, section 6 starts off:

   The zero touch solution presented in this document is conceptualized
   to be composed of the workflows described in this section.
   Implementations MAY vary in details.

> Is the intent to fully standardize the NMS functionality for 6.1 and 6.2?

No.  Section 6 is not normative.

> The ietf-zerotouch-information model seems to provide partial
> standardization, but the protocol interactions in 6.1. and 6.2 seem to
> be completely out of scope for the standard.

Agreed (see above).

> I wonder if the draft should just focus on fully standardizing 6.3 (Device Powers On)?

Note that non-normative Section 6.3 says essentially the same thing as the text in normative Sections 7.2 to 7.6.  So, yes, the draft does standardize this algorithm, or did you mean something else?

> It should at least be more clear that the bootstrap (or DNS, DHCP) server
> is set up in advance somehow and the procedures in 6.1 and 6.2 are not normative.

Agreed, Section 6 is not meant to be normative.

> The NMS could be the bootstrap server right?
> I don't think that configuration is shown in 6.2.

Yes, and Section 6.2, step #2 says:

    Illustrated here as an external component, the bootstrap server
    MAY be implemented as an internal component of the NMS itself.

> Where are the NETCONF slides that explain the ZTP architecture?
> I know you have presented them a few times. Which IETF?

I just looked through all of the zerotouch presos to date.  The current
solution grew somewhat organically and hence there isn't a single
preso that seems to have it all.  I'll send out an update early next week.

> Andy

Kent