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

[Balazs Lengyel]

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 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: +36-70-330-7909 email: balazs.leng...@ericsson.com

<t>&lt;CODE BEGINS> file "acme-router-modules.yid"</t>
<figure align="center" anchor="Xml-Instance-Data-File-example" title="XML 
Instance Data File example">
    <artwork align="left"><![CDATA[ 
<instance-data-set xmlns=
    "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data"
    <name>acme-router-modules</name> 
    <revision>2108-01-25</revision>
    <description>Defines the minimal set of modules that any acme-router
       will contain. These modules will always be present.</description> 
  <contact>i...@acme.com</contact>
  <instance-data>
    <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
      <module-set>
        <name>basic</name>
        <module>
          <name>ietf-system</>
          <revision>2014-08-06</revision>
          <!-- description "A later revision may be used."; -->
          <namespace>urn:ietf:params:xml:ns:yang:ietf-system</namespace>
          <feature>authentication</feature>
          <feature>radius-authentication</feature>
        </module>
      </module-set>
    </yang-library>
  </instance-data>  
</instance-data-set>
          ]]></artwork>
</figure>
<t>&lt;CODE ENDS></t>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod