On 26/06/2018 14:52, 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.
OK, so I wasn't assuming that instance data necessarily corresponds to
instance data coming from a datastore (or an entire datastore). I was
thinking that it can be any data that has a well defined YANG schema
associated with it. E.g. perhaps it could use to represent the YANG
data sent or received in a YANG encoded RPC.
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.
Yes, I agree with the need for the latter, that may entail listing the
versions of the modules in the meta-data.
But what I was actually referring to was the former, and thinking more
of it is just being a string field in the meta-data with a well defined
name, that is optional to populate. Actually, I see the current
definition already has a revision with a date and description string.
This is roughly along the lines of what I was thinking of for versioning
(although I'm not sure why this should be a list rather than just a pair
of leaves).
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
