Subject: Re: [Netconf] zerotouch-02 configuration server issues

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 4 Jan 2015 19:00:37 +0000

Hi Kent,

is there a strong reason for not using YANG (instead of XSD)?
I assume we can solve the "container" issue raised for YANG usage.

Cheers, 
Mehmet 

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of ext Andy Bierman
> Sent: Friday, December 19, 2014 10:06 PM
> To: Kent Watsen
> Cc: Netconf
> Subject: Re: [Netconf] zerotouch-02 configuration server issues
> 
> On Fri, Dec 19, 2014 at 12:36 PM, Kent Watsen <[email-masked]> wrote:
> > Hi Andy,
> >
> >
> >
> >>The configuration server described in sec. 2 is going to be
> >>an important system component if it is successfully standardized.
> >
> > True.
> >
> >
> >
> >>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  ;-)
> >
> > 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.
> >
> 
> typo on my part.
> 
> 
> > 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?
> >
> >
> 
> I guess XSD is OK.  It avoids the YANG data structure controversy an
>  excludes JSON (which nay be a new controversy ;-)
> 
> 
> >
> >>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.
> >>
> 
> 
> 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.
> 
> 
> >>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.
> >
> > 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?
> >
> 
> 
> 
> 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.
> 
> 
> > [1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01
> >
> >
> >
> > Thanks,
> > Kent
> >
> >
> 
> 
> 
> Andy
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Jan 2015 15:19:52 +0000

Hi Mehmet,

The other reason was to assert the use of XML (not JSON) and thus clear
the way to using the XMLSIG and XMLENC standards.  That said, I'm
beginning to think that maybe we should NOT use the XML* standards, as
they don't seem to be very popular in my reading of online forums, and
also because they are significantly more complicated to implement
(requiring XML libraries).  A much simpler solution would be one that
could be implemented via a shell script making calls to the `openssl`
command line utility (of course we wouldn't require the use of `openssl`,
the draft would define it using PKCS terms, with maybe a non-normative
example using the `openssl` utility)

Do you think we should open one issue for moving back to YANG and another
for swapping for signing/encryption occurs?

Thanks,
Kent

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Jan 2015 16:09:03 +0000

Hi Kent,

let's discuss these issues today in the virtual meeting.

Cheers, 
Mehmet 

> From: ext Kent Watsen [mailto:[email-masked]]
> Sent: Monday, January 05, 2015 4:20 PM
> To: Ersue, Mehmet (NSN - DE/Munich); ext Andy Bierman
> Cc: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jan 2015 17:22:55 +0100

There are two issues:

1) What is the schema language used to describe the data model?
There are many choices and today you are using the XML schema.
The XML schema also happens to be encoded in XML.

Another option is also not to have a formal language at all. Just
describe it in words.

2) What is the encoding of the data sent over the wire? Currently you
are using XML for that purpose. XML-DSIG and XML-ENC is relevant for
this part.

I am not sure how Yang, OpenSSL, and some of the other things you
mention below fit into the bigger picture.

Ciao
Hannes