Subject: [Netconf] yang-data encoding issue

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Jul 2017 17:36:31 +0000

Following is the tail end of an offline thread I was having with Martin/Andy regarding the zerotouch draft.  Bringing to list now for wider review.

Kent

Kent Watsen <[email-masked]> wrote:
> Back to yang-data, I've been meaning to raise an issue, which is that
> the encoding does not include a module "revision".  Because the data
> is separated from a server, and hence no yang-library to query, it's
> currently not possible for a parser to know what version of the module
> was used to encode the yang-data artifact.

Good point.

> One fix is to have every instance of yang-data have a required leaf
> called e.g. "revision".  Another would be to allow the revision to be
> encoded into the container's identifier:
> 
> OLD
> 
>   XML
>   <redirect-information
>   xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-information">
>     ...
>   </redirect-information>
> 
>   JSON
>     {
>         ietf-zerotouch-information:redirect-information : {
>            ...
>         }
>     }
> 
> NEW
> 
>   XML
>   <redirect-information
>   xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-information@2017-07-03">

I don't like this.  

<KENT> I'm not thrilled by this XML either.  The JSON (at bottom) looks better,
but we can't have one without the other...

*maybe* introduce a meta-data annotation that is
always used on the top-level container:

   <redirect-information
     xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-information"
     xmlns:yd="..."
     yd:revision="2017-07-03">

<KENT> This is better and at least symmetric between XML and JSON.

But even this seems wrong...

<KENT> I can almost sense what you mean, but I can't put my finger
on it, can you articulate why it seems wrong?

I think the description of yang-data should mention this problem.  In
some cases the revision is known outside the yang data structure, and
in other cases maybe a revision leaf is the best solution.

<KENT> 80480 errata, or track it for a future 8040bis or 7950bis?

> JSON
>    {
>        ietf-zerotouch-information@2017-07-03:redirect-information : {
>           ...
>        }
>    }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Jul 2017 10:51:30 -0700

Hi,

Now you know why I wanted a enum for leaf conformance called 'other'.
(But Martin insisted we just needed enums implement and import).

Why not just put the module revisions in the YANG module library
instead of inventing hacks? (Set the conformance to 'import' for now).

Since these yang-data constructs are extremely implementation-dependent
it is not clear that there are even any problems wrt/ different parts of
the implementation knowing what YANG module revision to load for
a particular yang-data.

Andy

On Mon, Jul 10, 2017 at 10:36 AM, Kent Watsen <[email-masked]> wrote:

>
> Following is the tail end of an offline thread I was having with
> Martin/Andy regarding the zerotouch draft.  Bringing to list now for wider
> review.
>
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 10 Jul 2017 18:03:48 +0000

Hi Andy,

> instead of inventing hacks? (Set the conformance to 'import' for now).

Per the first part of my previous message:

   Because the data is separated from a server, and hence no yang-library to
   query, it's currently not possible for a parser to know what version of the
   module was used to encode the yang-data artifact.

> Since these yang-data constructs are extremely implementation-dependent

I'm not following, how are they implementation-dependent?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Jul 2017 11:18:39 -0700

> I'm not following, how are they implementation-dependent?

Because we define no standard purpose for these data structures, especially
file artifacts.
We assume all parts of the implementation have been properly configured
(out of scope) to use the correct YANG module revisions.

If you want to define additional encoding rules to support "file to YANG"
conversion,
we can discuss that.  This is a general problem with all YANG data that is
saved
as a file and then later consumed and parsed against YANG modules.

Does this problem really matter because we assume:
 (1) updated revisions are newer than the version previously in use
 (2) new module revisions follow the YANG update rules

(1) is generally true and (2) is usually not true in the IETF

It might be a good idea to save the revision-date as an attribute in a
top-level yang-data node.
The XML namespace + the revision-date should be sufficient to find the
correct YANG module.

Andy