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

[Balazs Lengyel]

On 6/26/2018 3:52 PM, Juergen Schoenwaelder wrote: On Tue, Jun 26, 2018 at 02:37:21PM +0100, Robert Wilton wrote: On 26/06/2018 13:11, 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. An example could be wanting to provide a single file that holds the capabilities for all different linecard types for a particular type of device, rather than providing them as a set of files. Of course, this could also be achieved using a meta YANG module (e.g. the top level module could have a list of linecard types, which each linecard type contains the capabilities for that linecard).  Whether this make sense probably depends on the underlying YANG modules and how they are constructed. Of just using separate files, in which case the meta information can just be managed into the file name, and the file can be provided as a zip. I am left puzzled. There is instance data (in a datastore) and you serialize (perhaps filtered) the instance data into a file. Instance data in general has data that conforms to multiple YANG modules, in particular also due to augments. I think we need to solve the general problem, not an isolated linecard problem. BALAZS: The point of this draft is to allow us to document instance-data in files. The full content of the datastore may be (will be) broken up into multiple instance-data-sets to allow different groups to work on each.  One group might be defining access control rules while the other will be defining documentation for the implemented modules (ietf-yang-library). Each will define its own instance-data-set. The question is: Shall we allow two of these sets to be in one file? Naturally you can put anything that follows the models into a single data-set, but if you decide to use multiple separate sets IMHO you should put each of these into a separate file (or maybe allow multiple sets in a single file). 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. Whitespace must also be handled as defined by the encoding rules. I thought the 2nd and 3rd sentence would be not needed but checking RFC 7951 I see no mentioning that values must be in canonical format. I guess this is an omission of RFC 7951 - perhaps I should open an errata. RFC 7950 says this clearly in section 9.1: When a server sends XML-encoded data, it MUST use the canonical form defined in this section. Looks like an omission in RFC 7951. BALAZS: I did not find anything about leading/trailing whitespace e.g. for an integer in RFC 7950 either. Is it allowed/prohibited? -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com

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