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

Fri, 09 Mar 2018 04:25:36 -0800

Hello Kent,

I understand your issue with the RestConf format. It is very relevant to my Use Case 2: Preloading Data.
However I wrote: 

The JSON format SHALL follow the format of the reply returned for a
   RESTCONF GET request directed at the datastore resource:
   {+restconf}/data.
This should solve the problem that we always have the "full path" in the instance data. It would be possible to allow specifying the beginning of the path that would be in the request URL as metadata on the instance-data container. Would that be better. In this case we could add example validation as a 3rd use case.

regards Balazs

On 2/12/2018 6:22 PM, Kent Watsen wrote:

[removing netconf]

 

 

On 2/12/18, 12:20 PM, "Netconf on behalf of Kent Watsen" <[email protected] on behalf of [email protected]> wrote:

 

Hi Balazs,

 

I'm unclear about the scope of the problem.  Is it limited to server capabilities?    It seems that the idea is to move from having a stateful connection to a live server to having a way to pass the equivalent state even when not connected to the server.

 

Related, but probably not what you're angling for, I've been having issues with validating RESTCONF examples.  The issue is that the RESTCONF documents are context specific.  For instance, GET /widgets/ returns a document that might have an outermost element called "widgets", whereas GET /widgets/widget=foo returns a document that might have an outermost element called "widget".   In order to validate the second document, my code first wraps the "widget" element with a "widgets" element, and then the validation tools work.  

 

Perhaps a more generalized instance data mechanism could include where in the tree the data is situated?   For example, it would be helpful if an action's instance data could provide more context (e.g., the input/output documents could indicate the name of the action, the object that the action was invoked on, etc.).  

 

Generally, there is some state being held by the protocols that complicates examining instance data outside of the protocol, as extra bits of state need to be passed around separately.  It would be nice if the documents were (or at least could be) more self-contained.

 

Kent // contributor

 

 

On 2/8/18, 4:17 AM, "netmod on behalf of Balazs Lengyel" <[email protected] on behalf of [email protected]> 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:

[email protected]

To:

Benoit Claise <[email protected]>, Balazs Lengyel <[email protected]>

 

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: [email protected] 

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