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

[Balázs Lengyel]

  
  
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: 
internet-dra...@ietf.org
  
  
To: 
Benoit Claise , Balazs Lengyel
  
  

  
  
  
  
  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 
  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: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-01.txt
Pages   : 21
Date: 2018-12-06

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  operation/request
   and decorates them with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Thu, Dec 06, 2018 at 10:15:30AM +, 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 06, 2018 at 10:15:30AM +, 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.

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  anydata
   node SHALL contain all elements that would be inside the 
   wrapper element of a reply to the  operation.

What exactly does "all elements that would be inside the " 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod