On 10/22/18 13:41, Andy Bierman wrote: > > > On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <[email protected] > <mailto:[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?
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 > 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 > > > > > -----Original Message----- > From: netmod <[email protected] > <mailto:[email protected]>> on behalf of Martin Bjorklund > <[email protected] <mailto:[email protected]>> > Date: Tuesday, September 11, 2018 at 4:45 AM > To: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[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] <mailto:[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= > > <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
