Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt

From: Balázs Lengyel <[email-masked]>
Date: Thu, 6 Dec 2018 10:15:30 +0000

Hello,

We uploaded a new version of the instance data draft. We tried to
address all comments and also to rework the format chapter to make
it easier to read. We omitted 2 comments:

Rob commented that YANG packages could be used for defining the
target modules for instance data: I would like to avoid that
because:

Packages are not defined for YANG. Currently they are not part
of the versioning solution even though they were discussed and
are generally a good idea.

IMHO as deviations/features are set on module level, just
specifying packages would not be enough. If we start using
package+module level deviations/features we may end up with a
more complicated hybrid solution.

Module level YANG target definitions as described in the draft
are simple and need no new design

Jürgen stated that it would be better to use the YANG XML/JSON
encoding as a format instead of referencing the get
operation/request. I might even agree with him, but for 2 reasons
I did not follow his idea:

Currently there is no RFC I could reference either for XML or
JSON. AFAIK even RFC7951 does not define how multiple modules
should be encoded side by side.

It is not the job of the instance data draft to dictate how to
encode YANG data generally e.g. on the wire.

The contents of the get operation/request are well defined

regards Balazs

-------- Forwarded Message --------

Subject:

New Version Notification for
draft-ietf-netmod-yang-instance-file-format-01.txt

Date:

Thu, 6 Dec 2018 02:12:12 -0800

From:

[email-masked]

To:

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

A new version of I-D,
draft-ietf-netmod-yang-instance-file-format-01.txt

has been successfully submitted by Balazs Lengyel and posted to
the

IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format

Revision: 01

Title: YANG Instance Data File Format

Document date: 2018-12-06

Group: netmod

Pages: 21

URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt

Status:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

Htmlized:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format

Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01

Abstract:

There is a need to document data defined in YANG models when a
live

YANG server is not available. Data is often needed already in
design

time or needed by groups that do not have a live running YANG
server

available. This document specifies a standard file format for YANG

instance data, which follows the syntax and semantic from existing

YANG models, re-using existing formats from <get>
operation/request

and decorates them with metadata.

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]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Dec 2018 13:25:23 +0100

On Thu, Dec 06, 2018 at 10:15:30AM +0000, Balázs Lengyel wrote:
> 
>    J�rgen stated that it would be better to use the YANG XML/JSON encoding as
>    a format instead of referencing the get operation/request. I might even
>    agree with him, but for 2 reasons I did not follow his idea:
> 
>      * Currently there is no RFC I could reference either for XML or JSON.
>        AFAIK even RFC7951 does not define how multiple modules should be
>        encoded side by side.
>      * It is not the job of the instance data draft to dictate how to encode
>        YANG data generally e.g. on the wire.
>      * The contents of the get operation/request are well defined
>

The first bullet needs to be taken care of but it is not too difficult
I think.

I fail to understand what bullet two is about or why it matters. We
are talking about the instance file format, no more and no less.

Yes, the contents of the get operation/request are well defined but
the definitions are not generically applicable to define instance file
formats and the dependincy of the instance file format on protocols
is problematic from a maintenance perspective.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2018 13:40:58 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> On Thu, Dec 06, 2018 at 10:15:30AM +0000, BalÃ¡zs Lengyel wrote:
> > 
> >    Jürgen stated that it would be better to use the YANG XML/JSON encoding as

I agree.

I'm not even convinced that the current text is clear and correct:

   The content-data part of the XML format SHALL follow the format
   returned for a NETCONF GET operation.  The <content-data> anydata
   node SHALL contain all elements that would be inside the <data>
   wrapper element of a reply to the <get> operation.

What exactly does "all elements that would be inside the <data>" mean?
Does it mean that if a server supports 10 modules, all 10 modules
MUST be part of all instance files?  Probably not.

Since the "content-data" is of type "anydata", I think that we don't
need much additional text.  Maybe something like:

   The "content-data" part may contain data from multiple modules, in
   any order.  For any node in "content-data", the path from the data
   model root node down to the node, including any elements
   necessary to uniquely identify the node, is included in the
   response message.

/martin