Kent Watsen <kwat...@juniper.net> wrote:
>
> > People want to use YANG to define the schema for an XML or JSON
> > representation of a stand-alone document.
>
> Agreed
>
>
> > The only data needed must be module + local-name.
>
> Or maybe: module + local-name + context, where context is one of:
>
> - data nodes
> - RPC/actions
> - notifications
> - standalone artifacts (files)
I don't think we should use yang-data to model notifications.
Presumably you meant error-info from rpc or action.
And my point it is that I think that we should make yang-data
flexible enoough in itself, and not constrain it to the one or two use
cases we know now.
> At least, it seems that these are different things.
>
> [Note: RESTCONF places some of the context into the URL; two different
> data node resources can have identical module + local-name.]
>
> It would be bad if two stand-alone artifacts had the same
> module+local-name (foo:bar). However, it's okay to have a matching
> top-level data node called "foo:bar", since it is used in a different
> context. Just like yang-data cannot be accessed as data via a
> protocol like NC or RC, so it is that traditionally-defined data nodes
> cannot be accessed as a stand-alone artifact (unless you’re a
> draft-author and need an instance document for an example).
>
>
> > Defining an extension that maps error-info data for a specific RPC
> > might be
> > something worth standardizing. It should not be done with yang-data,
> > but rather a different extension just for this purpose.
>
> Martin wrote before:
>
> (maybe in the future we could even have a YANG extension statement
> to
> formalize the description:
>
> rpc my-first-rpc {
> ...
> opx:error-info-structure my-first-rpc-error-info;
> }
>
> but this is not point now.)
>
> I imagined that he was hoping to limit what's needed to get
> draft-ietf-netconf-notification-messages out the door now, but I think
> another I-D should be proposed to augment the 'rpc' and 'action'
> statements with an anydata called "error-info-structure" so the YANG
> would be more like this:
>
> rpc my-first-rpc {
> ...
> opx:error-info-structure my-first-rpc-error-info {
> …
> }
> }
No I was thinking along the lines of:
ydx:yang-data my-first-rpc-error-info {
...
}
rpc my-first-rpc {
...
opx:error-info-structure my-first-rpc-error-info;
}
I.e., use yang-data to define a structure, and use another statement
to tie them together.
If we define special statements with inline structures, we probably
also need special augment statements; with your example:
rpc my-first-rpc {
...
opx:error-info-structure my-first-rpc-error-info {
...
}
}
opx:augment-error-info-structure '/m:my-first-rpc'
+ '/m:my-first-rpc-error-info {
...
}
/martin
> That is, to your point, with no reference to a yang-data data
> structure.
>
>
> > Andy
>
> Kent // contributor
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
