IMHO once we know whether the data is config=false or true and know the datastores the server supports the datastore the instance data is relevant to is fixed. One exception is the possible loading of dynamic datastores. However as I do not have a use-case for these and we do not have any dynamic datastores defined, IMHO we can leave the usage of these datastores out of scope. If I added the following paragraphs would that help?
"If the instance data specifies config false (state data) and the server support the operational datastore, the instance data documents the operational datastore. If the operational datastore is not supported the data documents additional state data that is stored outside the configuration datastores. The instance data MAY be used to load the relevant datastore or it MAY just be used to document its content.
If the instance data specifies config true (configuration data) the instance data documents the running datastore. The instance data MAY be used to load the running datastore or it MAY just be used to document its content. While the instance data format MAY be used to load other e.g. dynamic datastores that is out of scope for this specification."
Also further clarification may be provided for each use-case
in the relevant document.
On 2/9/2018 5:25 PM, Juergen Schoenwaelder wrote:
How do I know which datastore the data belongs to? Would it not make sense to carry that information inline? If we do not carry this information inline, how is that information supposed to be provided if for example this format is used to validate examples included in documentation?/js On Fri, Feb 09, 2018 at 04:07:11PM +0100, Balazs Lengyel wrote:Hello Jurgen, I will gladly add NMDA to the draft. However could you please be more specific. Which part of NMDA are you missing? Is it the example of yanglib that you would like updated? As the instance-data can be used to document and/or load both config=true and false data it is IMHO relevant to the candidate/running/operational datastores. However whether it should be used to just document data or also to load data, and how exactly such a load should be implemented is out of scope. And yes using one SW kit config=false data can be loaded from file too. regards Balazs On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote:[Removing NETCONF since the I-D says -netmod-.] I flipped through the I-D yesterday and I think a common format for instance data trees should be NMDA aware these days. /js On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote:Hello, With Benoit I prepared a draft about how to document and use YANG defined instance data. It could be useful for documenting server capabilities or preloading data defined in implementation time and probably for other purposes as well. regards Balazs -------- Forwarded Message -------- Subject: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt Date: Wed, 7 Feb 2018 09:28:50 -0800 From: internet-dra...@ietf.org To: Benoit Claise <bcla...@cisco.com>, Balazs Lengyel <balazs.leng...@ericsson.com> A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt has been successfully submitted by Balazs Lengyel and posted to the IETF repository. Name: draft-lengyel-netmod-yang-instance-data Revision: 00 Title: YANG Instance Data Files and their use for Documenting Server Capabilities Document date: 2018-02-06 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.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-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 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: balazs.leng...@ericsson.com References Visible links 1. mailto:internet-dra...@ietf.org 2. mailto:bcla...@cisco.com 3. mailto:balazs.leng...@ericsson.com 4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt 5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ 6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 8. mailto:balazs.leng...@ericsson.com _______________________________________________ netmod mailing list email@example.com https://www.ietf.org/mailman/listinfo/netmod-- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com _______________________________________________ netmod mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/netmod
-- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
_______________________________________________ netmod mailing list email@example.com https://www.ietf.org/mailman/listinfo/netmod