Subject: Re: [netmod] yang-data issues

From: Kent Watsen <[email-masked]>
Date: Sat, 20 Oct 2018 12:48:56 +0000

Folks,

Can we get some quick replies to this email?

Kent // all hats

-----Original Message-----
From: netmod <[email-masked]> on behalf of Martin Bjorklund <[email-masked]>
Date: Tuesday, September 11, 2018 at 4:45 AM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] yang-data issues

Hi,

The authors of draft-ietf-netmod-yang-data-ext have been discussing
the two remaining issues on this draft; the issue of whether a
yang-data structure must have unique top-level node names or not, and
the issue of the syntax for augment-yang-data.  We haven't been able
to find agreement with the current proposal, so I have a suggestion
for a slightly modified yang-data statement (which may have been
discussed before):

The idea is to encode a yang-data extension the same way as anydata,
i.e., as a container.  For example:

  yd:yang-data modify-subscription-datastore-error-info {
      description
        "This yang-data MAY be provided as part of a subscription's RPC
        error response when there is a failure of a
        'modify-subscription' RPC which has been made against a
        datastore.  This yang-data MUST be used if hints are to be
        provides back to the subscriber.";
      leaf reason {
        type identityref {
          base sn:modify-subscription-error;
        }
        description
          "Indicates the reason why the subscription has failed to
          be modified.";
      }
      uses hints;
    }

This would be encoded as:

  <modify-subscription-datastore-error-info>
    <reason>foo</reason>
    <period-hint>42</period-hint>
    ...
  </modify-subscription-datastore-error-info>

Since the structure is always encoded as a container, it follows that
it can have any data definition statement as substatement, with no
restriction on naming and type of statement.  An instance of this can
trivially be a complete instance document in XML w/o additional
context, works well with JSON, and can appear in an error-info
structure.

Such a structure can be augemented as:

  yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
    leaf foo { ... }
  }

The drawback is that it forces the use of an extra container in the
encoding.  OTOH, most usages of current rc:yang-data follows this
pattern:

  rc:yang-data modify-subscription-datastore-error-info {
    container modify-subscription-datastore-error-info {
      ...
    }
  }

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Oct 2018 10:41:49 -0700

> Can we get some quick replies to this email?

At the last IETF there were people that said both yang-data and
augment-yang-data extensions
were needed and they wanted this work to be completed quickly.  Is that
still the case?

IMO, NMDA and yang-library-bis offer a better solution path (which has been
brought up before).
If there is a need for specialized datastores like "factory-default" then
why not have
an abstract datastore or abstract module-set?  I do not think current YANG
supports this
approach very well (because modules used outside a server do not have
yang-library)
but that could probably be fixed with yang-instance-data

Kent // all hats

Andy

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> 7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-
> j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=
>
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Joe Clarke <[email-masked]>
Date: Mon, 22 Oct 2018 16:01:13 -0400

On 10/22/18 13:41, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 

Yes.  We're now seeing people that want to augment the ANIMA voucher
artifact (draft just proposed by Eliot Lear).  I have some non-IETF work
that would also benefit.

Joe

> 
> 
> IMO, NMDA and yang-library-bis offer a better solution path (which has
> been brought up before).
> If there is a need for specialized datastores like "factory-default"
> then why not have
> an abstract datastore or abstract module-set?  I do not think current
> YANG supports this
>     From: netmod <[email-masked]
>     <mailto:[email-masked]>> on behalf of Martin Bjorklund
>     <[email-masked] <mailto:[email-masked]>>
>     To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
> 
> 
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Oct 2018 01:37:24 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2018年10月20日 20:49
收件人: [email-masked]
主题: Re: [netmod] yang-data issues

Folks,

[Qin]: I believe restconf collection work might benefit from this work as well. It follows traditional usages of rc:yang-data,
However I am not sure the benefit to remove container defined within yang-data extension, the restrict ion I see this,
In traditional usage of yang-data, we can add more than one containers, then augment-yang-data can augment from any of these containers 
defined within yang-data extension.
But with below proposal, we lose such flexibility, in my opinion.

Kent // all hats

-----Original Message-----
From: netmod <[email-masked]> on behalf of Martin Bjorklund <[email-masked]>
Date: Tuesday, September 11, 2018 at 4:45 AM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] yang-data issues

Hi,

The authors of draft-ietf-netmod-yang-data-ext have been discussing the two remaining issues on this draft; the issue of whether a yang-data structure must have unique top-level node names or not, and the issue of the syntax for augment-yang-data.  We haven't been able to find agreement with the current proposal, so I have a suggestion for a slightly modified yang-data statement (which may have been discussed before):

The idea is to encode a yang-data extension the same way as anydata, i.e., as a container.  For example:

Since the structure is always encoded as a container, it follows that it can have any data definition statement as substatement, with no restriction on naming and type of statement.  An instance of this can trivially be a complete instance document in XML w/o additional context, works well with JSON, and can appear in an error-info structure.

The drawback is that it forces the use of an extra container in the encoding.  OTOH, most usages of current rc:yang-data follows this
pattern:

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Oct 2018 09:07:43 +0200

On Mon, 2018-10-22 at 10:41 -0700, Andy Bierman wrote:
> At the last IETF there were people that said both yang-data and augment-yang-
> data extensions
> were needed and they wanted this work to be completed quickly.  Is that still
> the case?
> 
> 
> If there is a need for specialized datastores like "factory-default" then why
> not have
> an abstract datastore or abstract module-set? 

I agree, this has been my proposal all along. YANG should be able to cover such
uses out of the box. Extensions like yang-data only make the whole thing more
complicated.

Sometimes it it not even necessary to introduce an ad hoc datastore, a "schema"
entry from yang-library-bis could be sufficient.

> I do not think current YANG supports this
> approach very well (because modules used outside a server do not have yang-
> library)

In many cases yang-library(-bis) can be used without the metadata provided by
yang-instance-data. For example, my yangson library uses YANG library data
(JSON) for specifying the complete data model:

https://yangson.labs.nic.cz/cmdline.html

Pyang uses NETCONF hello (XML) for the same purpose.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67