Re: [netmod] yang-data issues

On Mon, 2018-10-22 at 10:41 -0700, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <kwatsen@juniper.net> wrote:
> > Folks,
> > 
> > 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 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)
> but that could probably be fixed with yang-instance-data

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

> 
> 
> > Kent // all hats
> > 
> > 
> 
> 
> Andy
>  
> > 
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> on behalf of Martin Bjorklund <
> > mbj@tail-f.com>
> > Date: Tuesday, September 11, 2018 at 4:45 AM
> > To: "netmod@ietf.org" <netmod@ietf.org>
> > 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
> > netmod@ietf.org
> > 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=
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67