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 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]> 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
