>>> >> 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... >> >>There is a description statement. >> > > Automation tools generally use machine-readable statements, and avoid > using description-stmts. > > The yang-data extensions do not solve this "rpc/action to error-info" > mapping problem, so this problem is not a real factor here.
If subscribed-notifications doesn't use "yang-data", then it would need to use another extension statement, lest the 3 "error-info" statements it defines are misconstrued as configuration or operational state. >>> > 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 me, extensions that define new data definition statements are >> borderline. RFC 7950 has this nice statement: >> >> o extension: An extension attaches non-YANG semantics to statements. >> The "extension" statement defines new statements to express these >> semantics. >> >> This does not help since we lack a definition for 'non-YANG semantics' >> and yes I know that yang-data is today defined as an extension. But >> for me, this is a hack and instead of creating a slightly more >> generalized version of this hack, I prefer to stick to yang-data in >> favor of a proper solution as part of YANG. > > The yang-data and augment-yang-data extensions do not re-define YANG > data nodes. They define a new context for data nodes and prevent plain > YANG tools from confusing this new context with data for configuration or > operational datastores. Yes. >>> > 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. >> >> So create a container. > > I tend to agree that a top-level choice could be avoided. > This is not a really compelling use-case. From https://mailarchive.ietf.org/arch/msg/netconf/T6OgCvbF30EOoU27b3T_-dOdj2E: The zerotouch draft has way too much text invested in the "zerotouch- information" artifact being polymorphic in nature to seriously consider having two unrelated artifacts, when the easier answer is to agree that, in this case, the yang-data does in fact contain "data definition statements that result in exactly one container data node definition". We don't even need to change any text, in this document [zerotouch] or in RFC 8040, in order to have this agreement. We would only need `pyang` to stop flagging it as an error. So, yes, yang-data-ext isn't needed for zerotouch, there are options on the table. But, so long as this draft is a WIP, then it seems that zerotouch should use it. >>> - for (b), in order to augment a base yang-data "message" >>> structure with additional nodes. >> >> So you are creating another augmentation mechanism. I am concerned >> about ending up with a zoo of different mechanisms if we go down this >> path, we may end up with every project or vendor creating their own >> variants. >> >> With NMDA in place, YANG 1.1 is decribing schemas for datastores plus >> operations and notifications. It is not a protocol message description >> language or a standalone file format description language. If this is >> needed, I prefer to create YANG X.Y - and if we manage the complexity >> we have something that is ideally integrated and consistent. > > Yes it is a protocol message description language, but only > in an incomplete, hacky way. Specific subtrees within protocol messages > are defined as special YANG data-defined portions and the rest is somehow > out of scope for YANG. The way nested roots (e.g., <config> or <data>) > are handled is the worst hack of all. But IMO a new version of YANG is > needed to really fix these problems. Yes, we agree that a new version of YANG is ideal, but such is years away and the NETCONF WG is not going to block these drafts waiting for it. Do we rather the notification-messages draft define a private version of the "augment-yang-data" extension statement? >>> - 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? > > I am just voicing my opinion. It may very well be that the WG prefers > to go the route of not touching YANG 1.1 and instead patching around > its limitations with extensions. > > My concern is simply driven that some want to patch in via extensions > support for describing protocol messages and standalone documents, > others want to patch via extensions and updates a different versioning > system, and who knows what comes next. In the long run, I am afraid > this will become a mess. And yes, it is always difficult to predict > the future - we need crystal balls. Perhaps as an extension. ;-) > > This is a separate (but important) topic -- YANG 1.1 + a vendor-selected > set of optional extensions is not the same as a new version of YANG > (with mandatory-to-implement statements). > > YANG designers cannot really rely on optional extensions across tool-chains. True, but it seems that this one might hit critical mass. Even if it doesn't, scripts can auto-convert yang-data definitions into their descendent node definitions (container, or choice in zerotouch case) so existing tooling can grok them. I have scripts doing this today. Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
