> From the 5000 foot view, this looks to me like the description changing > the behavior of what a system should do.
Correct. > What am I missing? I think you are asking, how is this different than the current draft's approach, right? The primary distinction is that this approach doesn't break legacy clients. All existing operations (backup/restore) continue to work. The issue was never that new semantics were being added; we do that all the time (e.g., opstate). The issue was that the new semantics were being added without a strong mechanism to prevent legacy clients from doing something bad (i.e. a description statement alone isn't sufficient). By example, note that YANG extensions, which includes metadata per RFC 7952, also are used to introduce new semantics, but they cannot do so is a non backwards compatible manner. RFC 7950 Section 6.3.1 says: The processing of extensions depends on whether support for those extensions is claimed for a given YANG parser or the tool set in which it is embedded. An unsupported extension appearing in a YANG module as an unknown-statement (see Section 14) MAY be ignored in its entirety. and also: Care must be taken when defining extensions so that modules that use the extensions are meaningful also for applications that do not support the extensions. So, for instance, if we wanted to have a "server-provided" metadata annotation, we'd have to introduce it along with an explicit client request, somewhat like the <with-defaults> parameter added by RFC 6243. We could go that route here if needed, but I first want to see if the idea posted early is sufficient... Kent
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
