Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

Hello Kent,

Thanks for the thorough review and sorry for my absence and hence the earlier 
slow response.

See answer below as BALAZS4. Removed already agreed parts.

What is the next step?

Regards Balazs

 

From: Kent Watsen  
Sent: 2021. április 2., péntek 2:20
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Please see below for responses.  (One question pending)

 

Kent // shepherd



On Mar 23, 2021, at 6:01 PM, Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 

Hello Kent,

I am resuming my work on draft-ietf-netmod-yang-instance-file-format. 

Regards Balazs

 

 

From: Kent Watsen mailto:kent+i...@watsen.net> > 
Sent: 2020. április 9., csütörtök 22:11
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: netmod@ietf.org  
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Hi Balazs,

 

BTW, I assume that you wish to publish this as-is and follow-up later with an 
update to adjust for the “semver” work - correct?

K.

 

BALAZS4:  Yes, correct. 

Semver will take time and may undergo changes, so it would be too early to 
adapt this draft/RFC to it. However, two items already deal with Semver:

1.  The instance data files themselves will not have a Semver revision as 
the concept of compatibility is not defined for instance data.
2.  The YANG module ietf-yang-instance-data already includes:

 “... If other methods

(e.g., revision-label) are defined to identify

individual module revisions those MAY be used

instead of using a revision date.”

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

// 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.

   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.

   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.

   o  A client SHOULD be prepared to handle more items for a list or
  leaf-list than what is defined by the model.

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.


Thanks,
Rob



From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 06 April 2021 15:10
To: 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