Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Thanks for taking a look Juergen.

Note that the first part of Rob's email was the *old* text that he suggests replacing with the bullets in the second part.  But some of your comments in the old text probably also apply to the new text.

The root of this section in our draft is that we wanted to clarify how to decide if a change is BC vs NBC for *state* data (config false).  Our feeling is that we may want to refine some of the rules in 7950 for state.  

One key example is this:  7950 says that adding another enum to an enumeration leaf is NBC (and that applies to state). But that may not really be how most implementations would want to treat state. Would we really want to flag a module as non backwards compatible when a state leaf gets an additional enum?  Wouldn't that create a lot of unnecessary noise?

Jason 

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Thursday, April 8, 2021 2:51 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
> Subject: Re: [netmod] Client validation text [was RE: YANG Versioning
> Weekly Call Minutes - 2021-04-06]
> 
> Some of these make no sense to me and I wonder whether we really need
> to define these.
> 
> On Thu, Apr 08, 2021 at 05:58:58PM +0000, Sterne, Jason (Nokia - CA/Ottawa)
> wrote:
> > Hi Rob,
> > I like the reformulation of this.
> > Jason
> >
> > From: Rob Wilton (rwilton) <[e-mail]>
> > Sent: Wednesday, April 7, 2021 5:19 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>;
> [e-mail]
> > Subject: Client validation text [was RE: YANG Versioning Weekly Call
> Minutes - 2021-04-06]
> >
> > // As a contributor
> >
> > Hi Jason, all,
> >
> > In yesterday's meeting there was a discussion on this text, and Joe pointed
> out that any sensible client must validate its input.
> >
> >    While incoming configuration data is checked according to YANG
> >    constraints, constraints on state data sent by the server MAY or MAY
> >    NOT be enforced.  The following guidelines are provided for client
> >    application designers to allow a smooth interworking with servers.
> >
> >    o  A client MUST tolerate any data received (or not received) without
> >       crashing.
> 
> What is 'tolerate', what is 'without crashing'? Are we talking about
> buggy parsers or buggy backend logic or backend logic fooled by
> inconsistent values?
> 
> >    o  A client MUST be able to discard any data that is not part of the
> >       model but is sent by the server additionally (e.g.  XML elements
> >       or attributes, JSON properties).
> >
> >    o  A client SHOULD be able to handle valid parts of a received data
> >       set even if it discards other parts as invalid.
> 
> In all cases?
> 
> >    o  A client SHOULD be able to handle data that is outside the
> >       valuespace defined, as long as it is of the same basic type.
> 
> Really? What does 'handle' mean? If a value makes no sense at all,
> what should the client do other than discarding the value (and logging
> an error)? Or is this 'handling'?
> 
> >    o  A client SHOULD be prepared to handle more items for a list or
> >       leaf-list than what is defined by the model.
> 
> Again, what does 'handle' mean???
> 
> > Based on Joe's comments, I suggest that this text could potentially be
> written as something like:
> >
> >
> >
> >
> >    Client applications are expected to perform sanity checking of data
> >
> >    received from a server and to handle unexpected or missing data
> >
> >    gracefully, e.g., this could include ignoring unexpected data, or
> >
> >    logging unexpected values for further analysis.  Clients SHOULD NOT
> >
> >    discard an entire response from a server because some data contained
> >
> >    within the response is not expected.  Examples of well-encoded but
> >
> >    unexpected data received from a server may include:
> >
> >
> >
> >    o  Values that are outside the value space of a data node defined
> >
> >       in the YANG schema, but that are within the value space of the
> >
> >       underlying base type, e.g., if the value represents an unexpected
> >
> >       error condition on the server.
> >
> >
> >
> >    o  Additional data nodes, e.g., if the server implements a
> >
> >       different, but compatible, version of a YANG module.
> >
> >
> >
> >    o  A greater or lesser number of list or leaf-list items than the
> >
> >       permitted range defined in the YANG module.
> >
> >
> >
> >    o  Non mandatory data nodes that are sometimes missing from the
> >
> >       response.  Noting that the server is expected to deviate any data
> >
> >       nodes for which it will never return values for.
> >
> >
> >
> >    o  Values that do not conform to the semantic constraints of the schema.
> >
> >
> >
> >    o  Additional YANG meta data in the encoding (e.g., XML elements or
> >
> >       attributes, JSON properties).
> >
> >
> >
> >    NMDA [RFC 8342], section 5.3, provides additional constraints on the
> >
> >    data that a server can return from the operational state datastore.
> 
> It might be necessary to write the security considerations text for
> this.  From a security perspective, being lenient is often a
> mistake. For example, if a leaf is of type inet-address, I rather not
> have clients accepting any garbage strings as IP addresses.
> 
> I am not sure why we go into this. Which problem are we solving by
> requiring clients to accept any garbage?
> 
> /js
> 
> > Thanks,
> > Rob
> >
> >
> >
> > From: netmod <[e-mail]<mailto:netmod-
> [e-mail]>> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
> > Sent: 06 April 2021 15:10
> > To: [e-mail]<mailto:[e-mail]>
> > Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06
> >
> > YANG Versioning Weekly Call Minutes - 2021-04-06
> >
> > Focus for this meeting was going through Jason's review comments for
> section "3.1.2 Backwards-compatibility rules for config false and output data"
> of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02.
> >
> > (A)
> > Valuespace:
> > - value space (with a space between the words): use 7950
> meaning/definition (remove the definition in our draft)
> > - make "must" its own bullet
> > - don't particularly address "description"
> > - Balazs propose updated text
> >
> > (B)
> > replace this:
> >
> > "an additional state leaf can easily be discarded"
> >
> > with this:
> >
> > "the presence of an unexpected state leaf is not typically a problem and
> may be ignored by the client"
> >
> > (C)
> > replace "config=false data" in the 1st paragraph with the following (and
> keep the quotes - that is how RFC8342 presents it):
> >                 "config false" data
> >
> > (D)
> > Lots of debate about the "client" bullets in 3.1.2.  Didn't conclude.  Perhaps
> just summarize and say clients need to sanitize data (give examples of data
> they might get, values outside range)
> >
> > ACTION: focus on reviewing section 3.1.2
> >
> > ----------------------------------------------
> > Weekly webex call details:
> > Meeting number (access code): 171 069 0374
> > Meeting password: semver?
> > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday,
> August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US &
> Canada)
> > 9:00 am  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr
> >
> https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293
> c70
> > Tap to join from a mobile device (attendees only)
> > [phone],,1710690374## Call-in toll number (US/Canada)
> 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>