Kent Watsen <kwat...@juniper.net> wrote: > > 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.
and 3) it is not possible to augement 8040's yang-data. > Sure, maybe we have convinced ourselves that yang-data is not needed > to model error-info I don't think there have been any other proposal for how to model error-info that have any sort of concensus behind it. > , 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? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
