Subject: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts?

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jan 2017 22:32:07 +0000

Hi All,

Here is the issue mentioned in my comments just now when posting -12 of the zerotouch draft, which is how to encode YANG-modeled artifacts? (e.g., files, not used for configuration).  To be clear, https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-12#section-4.1 says:

   The information type artifact is YANG modeled data formally defined
   by the "information-type" choice node in Section 9.2 and can be
   encoded using any standard YANG encoding (e.g., XML, JSON).  This
   artifact is formatted the same as if returned by a RESTCONF server
   for an HTTP GET request for the specific information-type resource.
   Examples of this artifact's encoding are provided in Appendix B.

and Appendix B provides an example like:

   <redirect-information
     xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
     <bootstrap-server>
       <address>phs1.example.com</address>
       <port>8443</port>
       <trust-anchor>
         ...
       </trust-anchor>
     </bootstrap-server>
     <bootstrap-server>
       <address>phs1.example.com</address>
       <port>8443</port>
       <trust-anchor>
         ...
       </trust-anchor>
     </bootstrap-server>
   </redirect-information>

And the same construct is used again in Sections 4 and 5 of the ANIMA voucher draft here: https://tools.ietf.org/html/draft-ietf-anima-voucher-00.

Unfortunately, RFC 7950 says:

   YANG is a data modeling language used to model configuration data,
   state data, Remote Procedure Calls, and notifications for network
   management protocols.

which implicitly excludes using YANG this way.

So, what to do?  Here are some options (additional options welcomed):

1) leave the draft language as is (quirky, but expedient)
2) write a short draft that defines how to do this
3) switch from using YANG to something else (see below)

Regarding option #3 above:

A) Not using YANG in the ANIMA draft would be a fairly straightforward to do, though it should be noted that a recent ANIMA DT meeting concluded with the feeling that YANG SHOULD be used, since there no better DML for JSON documents and since YANG is prevalent within the IETF.  Furthermore, is was felt that this might become a comment need in time, as JSON is popular in several WGs.

b) Not using YANG in the zerotouch draft would be messy, as YANG is used to define these artifacts also for when they’re returned by a RESTCONF server (defined via YANG).  We could use another DML to define these artifacts *just* for when NOT returned by a RESTCONF server, but that would be terribly redundant.  We also could also use another DML to define these artifacts for all uses, and then for the RESTCONF server, define these as having type anydata or binary.

Any other ideas?

Kent