Lada writes: > Andy writes: >>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it >>is sufficient for that purpose, which is a YANG representation of >>an instance document (such as a protocol message or file). > > The same is basically true even without the extension. For example, I > fail to see any benefit from using yang-data in a module like > ietf-zerotouch-information.
I don't understand this, how else would you propose to define the JSON-or-XML encoded payload of the CMS structure? >> I am in favor if keeping the yang-data in RFC 8040 and not >> creating a new version of it that is unconstrained. >> There does not seem to be consensus on how to do this, >> or even consensus that it is a good idea. > > If the extension is deemed necessary, I would also prefer this > approach to making the extension a Proposed Standard. I don't understand talk about abandoning this draft. There is no question that it is needed (e.g., anima vouch, zerotouch, tail-f's "structure"), and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level 'choice' between two containers and 2) it requires drafts to reference RFC 8040, even though the drafts may have nothing to do with RESTCONF. Sure, maybe we have convinced ourselves that yang-data is not needed to model error-info, but that doesn't negate the other use case. We need a way to indicate that some data-model represents a stand-alone data structure. It is not configuration, operational state, an RPC, or a notification. It can only appear as a descendent of the 'module' statement. All 'action', 'notification', 'config', and 'if-feature' descendent statements are ignored. For the purpose of 'must' and ' when' statements, the yang-data structure is its own context root. It has a namespace and a unique local name (unique only to other yang-data defined within the same module; it's okay if an RPC, notification, or top-level data node has the same name). Anything else? Kent // contributor _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
