Re: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt

[Balazs Lengyel <[e-mail]>]

On 6/26/2018 2:11 PM, Juergen Schoenwaelder wrote:

On Tue, Jun 26, 2018 at 01:58:44PM +0200, Balazs Lengyel wrote:

   Thanks for the comments and support. See answers below.
   Balazs

   On 6/13/2018 4:40 PM, Robert Wilton wrote:

     Hi,

     I would support this draft (if/when a call for adoption is made).

     A few comments from a quick review :

     1) I think that it would be useful to allow a file to contain multiple
     "instance data sets".  I could easily imagine that multiple different
     blocks of instance data may need to be provided and allowing these to be
     carried within a single file seems helpful.

   BALAZS: We allow multiple YANG modules in a file, but I have never seen it
   used. Actually my model/tool designers asked me to prohibit multiple YANG
   modules (YAMs) in one file at least within Ericsson. So if the group
   decides so it can be allowed, however I think it is not a good idea.

What exactly is "multiple YANG modules in a file"? I am confused and
you may be talking past each other.

BALAZS: https://tools.ietf.org/html/rfc7950#section-5.2" rel="nofollow">https://tools.ietf.org/html/rfc7950#section-5.2 states:

YANG modules and submodules are typically stored in files, one
   "module" or "submodule" statement per file.

To me this means it is allowed to have multiple module statements in a file, multiple YANG modules in a file. AM I wrong?

     2) I wonder whether these instance-data blocks could be used to hold
     examples in drafts/RFCs.  It would be nice if the examples could be
     automatically extracted and validated.  Possibly this draft could help
     with this, although I appreciate it is not its main focus.

   BALAZS: It could be easily added. All we need is a pair of tags like <CODE
   BEGINS> we could call it <INSTANCE DATA BEGINS> <INSTANCE DATA ENDS>
   After that we need to create the tools to extract and validate the
   instance data.

Why is instance data node code? Why do we need new tags? The tags are
there to extract 'stuff' - what 'stuff' is should be clear from
'stuff'. (RFC 7950 uses CODE BEGINS for yang.abnf for example.)

BALAZS: "stuff" in this case would be an instance-data-set formatted according to this draft and used as an example in some other draft/RFC. As I understand the use case: this could be extracted by some tool and validated against this draft for the format of the instance-data-set and validated against the YANG modules used by the instance data inside. See attachment as an example. However the use case came from Rob, so he might know better.

     3) Possibly a comment should be made about whitespace, although I think
     that it is fairly obvious how whitespace would be handled, i.e. as
     defined by the encoding.

   BALAZS: OK. How about:
   Leading and trailing whitespace before and after the actual value MUST NOT
   be present for data based on types string or binary, but MAY be present
   for data based on integer types, decimal64, boolean,  enumeration, bits,
   identityref, instance-identifier. For leafrefs leading or trailing
   whitespace MAY or MUST NOT be present based on the referenced data type.
   For data based on a union type leading or trailing whitespace MUST NOT be
   present if it is not allowed for any of the member types.

Why do we need new rules? Should the artwork wrapping solution not be good
enough?

BALAZS: Please explain. In the normal case an instance-data-set is a standalone instance-data-file that is not part of any artwork. Where can I see the artwork wrapping solution?
I just wanted to be liberal, to make writing and reading easy, so I would allow both
<myleaf>23.3</myleaf>
and
<myleaf>
  23.3
</myleaf>
unless the data is of type string in which case the whitespace has an actual meaning.

     5) I'm wondering whether there needs to be some sort of identifier about
     what type data is held.  E.g. does it represent data that can be
     consumed as part of one of the configuration datastores, or does it
     represent the equivalent of operational state, or is it data for an RPC,
     etc.

   BALAZS: For config=false data that's trivial.
   For config=true data I don't see a use-case for providing operational
   state data.  IMHO  If we just say that config=true data can be loaded into
   the running/candidate datastore that is enough.  We had a similar debate
   with Jurgen (?) but I still do not see the use case. Maybe if there will
   be dynamic datastores it would be more meaningful. If you see a use-case
   that needs this please describe it.

Trivial use case is an example that shows how content of <running> and
<operational> can differ. I see use cases where you snapshot the
status of <operational> and <running> for post mortem analysis. It is
easy to come up with use cases. We have datastores, so we should be
clear to which datastore instance data relates.

     6) If this data is to be stored in a file, should it state that it must
     be stored as UTF-8 character encoding?

   BALAZS: Good idea. Maybe a more general statement like:
   Instance data MUST follow the XML and JSON encoding rules defined in
   RFC7950 and 7951. Data MUST be present in canonical form or where that is
   not defined in lexical representation.
   It is more then just UTF-8. All stuff about encoding the different
   statements and types also applies.

So we do not need all the rules you mentioned above concerning white space
etc.

BALAZS: Maybe, please help here. If I have a leaf defined as an integer, is the following XML correct as a YANG based XML representation?
<myleaf>
  23.3
</myleaf>
There is whitespace before and after the number. I did not find in RFC7950 whether this is allowed.

     7) It might want to include a semantic version number for an
     instance-data-set, depending on whether the YANG versioning discussions
     ends up.

   BALAZS: Yes I would like to. However I am not exactly clear on what does
   backwards compatibility mean for instance data.
   Data MAY NOT be removed or changed only added.  ???
   Who would use the semver numbers ???

What does the version number mean? Every change of instance data in an
instacne-data-set leads to a new version number? What is a bug fix in
this sense? What is a non-backwards compatible change of instance data?
I am left a bit puzzled.

BALAZS: Ask Rob, it was his idea :-)
But seriously we would first need to define what backwards compatibility means in this case and who would use the version number. I think its worth thinking about, but at this point I don't have a good use case or solution.

/js

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]