Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Kent Watsen <[e-mail]>]

> 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