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) <rwil...@cisco.com> > Sent: Wednesday, April 7, 2021 5:19 AM > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>; > netmod@ietf.org > 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 <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On > Behalf Of Sterne, Jason (Nokia - CA/Ottawa) > Sent: 06 April 2021 15:10 > To: netmod@ietf.org<mailto:netmod@ietf.org> > 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=ma7627a2ae7b770537cff5f5b89293c70 > Tap to join from a mobile device (attendees only) > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
