Re: [netmod] yang-data issues

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