[resurrecting this thread]
Currently the zerotouch draft has a normative reference to this draft.
I will this week post an update to the zerotouch draft to resolve the
netconf list thread "a couple zerotouch-21 issues". It would be easy
for me to also switch back to using rc:yang-data, but I won't do so if
this draft remains an active work-in-progress.
Please see below for more.
On Wed, 2018-05-02 at 11:36 +0200, Juergen Schoenwaelder wrote:
>On Wed, May 02, 2018 at 11:25:06AM +0200, Martin Bjorklund wrote:
>>
>> The primary use case is not "generic RPC messages", but standalone
>> instance documents, error-info structures, etc.
>
> The proper solution for rpcs and actions is to define error
> information as part of the rpc/action. YANG 1.1 does not support
> this but this is where it should be fixed.
Agreed, but note that the subscribed-notifications draft (both the
published -12 and unpublished -13) are relying on being able to do
just this, and YANG-next is years away...
> Standalone instance documents (not tied to datastores) may have their
> use cases as well but it feels odd to create support for standalone
> instance documents as extensions and then to create even more
> extensions to support augmentation of these instance documents and
> whoever knows what comes next.
What feels "odd" about this? Is it not using the extension statement
as it was intended?
> For short-term needs, there is yang-data defined in RFC 8040.
To be clear, the "short-term needs" are:
a) zerotouch: to define a standalone instance document
b) notification-messages: to define a new notification message
c) subscribed-notifications: to define error-info structures
As I recall, this draft (not RFC 8040) is needed:
- for (a), because rc:yang-data doesn't support a top-level
"choice" statement spanning "container" statements.
- for (b), in order to augment a base yang-data "message"
structure with additional nodes.
- AFAIAA, RFC 8040 is sufficient for (c)
Has anything changed? I don't think that we can un-adopt this
draft with said dependencies, right?
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
