On Mon, 2018-10-22 at 10:41 -0700, Andy Bierman wrote: > > > On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <[email protected]> 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 <[email protected]> on behalf of Martin Bjorklund < > > [email protected]> > > Date: Tuesday, September 11, 2018 at 4:45 AM > > To: "[email protected]" <[email protected]> > > 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 protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
