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

[Juergen Schoenwaelder <[e-mail]>]

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.

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

> > >       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.
> Probably I don't mean semantic version.  But often files have versioning, or
> revision, information associated with them.  This can be muxed into the file
> name/path, but it also seems like potentially useful metadata, and being
> able to handle this generically in a consistent way might be beneficial.
> 
> As an example, perhaps the capability information related to S/W release
> 1.2.4, etc.

We need to separate a version number of the instance data from the a
version number (or version context) that may be needed in order to
understand what a YANG (module, path) tuple means if we move to a
different YANG versioning scheme. The later I agree would be needed,
the former I am less sure of - at least if we talk semantic version
numbers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>