Subject: [Netconf] zerotouch-02 configuration server issues

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Dec 2014 07:55:12 -0800

Hi,

I have some concerns about interoperability for zerotouch.
The configuration server described in sec. 2 is going to be
an important system component if it is successfully standardized.
It could be useful for constrained devices as well. (e.g. using CoMI).

I do not like the XSD for the configlet.
It reminds me why we invented YANG in the first place.
(Oh yeah, XSD is unreadable. Almost forgot  ;-)

The configlets are completely opaque, except there are 2 header fields
"unique-identifier" and "software-version".  There is nothing identifying
the configuration blob.  I think "configuration-identifier" and
"configuration-version" fields are also needed.

I would prefer a more direct mapping to YANG for the "configuration" element.
It should be possible to have a "vendor-opaque" section,
but it would be nice to know if subtrees in the configlet
actually show up in the running config after booting.
The description in the XSD implies that, but nothing normative.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 19 Dec 2014 20:36:40 +0000

Hi Andy,

>an important system component if it is successfully standardized.

True.

>(Oh yeah, XSD is unreadable. Almost forgot  ;-)

We had YANG in the -00 version of this draft, it changed to XSD in the
 -01 version.  Btw, -02 hasn't been posted yet, though you reference it
in the subject line.

In addition to side-stepping the whole debate regarding the use of a YANG
"container", the draft simultaneously moved to definitively using XML, due
to the use of the XMLSIG and XMLENC standards.  Do you think this is too
onerous?  Should we track this as an issue?

>The description in the XSD implies that, but nothing normative.

We had something like this back in Feb when the draft was still an I.D.
[1].   See how the YANG imports "ietf-netconf-server" and copies selected
parts of the "ietf-system" module?  But you're saying that it's OK for
there to be vendor-opqaue values - so do you want the draft to say the
content of the Configlet MUST/SHOULD have a configuration that maps to
these ietf-netconf-server and ietf-system models?

[1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Dec 2014 13:06:23 -0800

>  -01 version.  Btw, -02 hasn't been posted yet, though you reference it

typo on my part.

> onerous?  Should we track this as an issue?

I guess XSD is OK.  It avoids the YANG data structure controversy an
 excludes JSON (which nay be a new controversy ;-)

>>"configuration-version" fields are also needed.

Do you agree these extra fields are useful?
IMO they could be optional.

Some use cases:
  - the identified device may have different config setups, based
    on factors such as licenses, device capabilities, etc. so
    "config-identifier" could identify the config variant
 - cache IDs such as "config-id" (defined in NETCONF-EX) could be mapped
   to the "config-version" field, or a revision-date could be used instead.

> these ietf-netconf-server and ietf-system models?

I would prefer if the configuration element was equivalent to
the <config> element in a <copy-config> operation.
There is no constraint on what YANG modules are present.
Whatever config is present must match YANG module schema
supported by the server.

I do not know if there is a need for additional XML in the configlet
that does not map to any advertised YANG module.  Phil mentioned
a need for this sort of bootstrap data at IETF #91.  This should
go in a different element within the configlet.

Andy