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

From: Balazs Lengyel <[email-masked]>
Date: Fri, 9 Mar 2018 13:24:19 +0100

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-masked] on
behalf of
[email-masked]>
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-masked] on
behalf of
[email-masked]>
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-masked]

To:

Benoit Claise <[email-masked]>,
Balazs Lengyel
<[email-masked]>

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

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