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.
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.)
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?
If the draft has text about it following the encoding (e.g. as proposed
below, then this may not be required at all), although it be useful to
explicitly highlight that whitespace is also coded by the encoding. It
seems like something that could possibly be overlooked otherwise.
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.
Agreed, although I still think that explicitly mentioning whitespace
might be helpful. I'm not sure that I care too strongly on this point.
E.g.
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.
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.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
