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

Tue, 26 Jun 2018 04:59:38 -0700

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.

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.

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. 

4) "YANG instance data files SHOULD be used to provide design time information about server capabilities." sounds quite strong.  I think that this should either be a MAY, or the sentence should be predicated.  E.g . "If the server provides design time information about server capabilities then YANG instance data files SHOULD be used to allow them to be easily read and consumed by clients"

BALAZS: OK.  I like your text.

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

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

Thanks,
Rob


On 13/06/2018 15:06, Balazs Lengyel wrote:

Hello,

I submitted a new version of the yang-instance-data draft updated with comments from the last IETF and others. I would like to get this adopted as a workgroup item. Please review it and if you like it please indicate that you support it as a workgroup item.

Changes:
   o  Redefined using yang-data-ext
   o  Moved meta data into ordinary leafs/leaf-lists
   o  Corrections, clarifications

regards Balazs


-------- Forwarded Message --------
Subject: New Version Notification for draft-lengyel-netmod-yang-instance-data-01.txt
Date: Wed, 13 Jun 2018 06:47:16 -0700
From: [email protected]
To: Benoit Claise <[email protected]>, Balazs Lengyel <[email protected]> 


A new version of I-D, draft-lengyel-netmod-yang-instance-data-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name:		draft-lengyel-netmod-yang-instance-data
Revision:	01
Title:		YANG Instance Data Files and their use for Documenting Server Capabilities
Document date:	2018-06-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-01.txt
Status:         https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
Htmlized:       https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lengyel-netmod-yang-instance-data-01

Abstract:
   This document specifies a standard file format for YANG instance
   data, that is data that could be stored in a datastore and whose
   syntax and semantics is defined by YANG models.  Instance data files
   can be used to provide information that is defined in design time.
   There is a need to document Server capabilities (which are often
   specified in design time), which should be done using instance data
   files.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email protected] 



_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email protected] 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to