[netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology

[Juergen Schoenwaelder]

Hi,

I just stumbled across the terminology defined in
draft-ietf-netmod-yang-instance-file-format-01 and I have several
questions:

   Design time: A time during which a YANG model and the implementation
   behind it is created.  Sometimes in other documents this period is
   divided into design and implementation time.

Assuming that design time and implementation time are the same seems
to be odd. In the IETF, it is quite common that there is a significant
difference between design time and implementation time. So what is
mean here? Since the term is rarely used (I found two occurances),
perhaps clarify what is meant where this term is used and do not
introduce a new term. However, if the term is defined, then I suggest
that we use semantics that align with the common use of the term.

   Instance Data Set: A named set of data items that can be used as
   instance data in a YANG data tree.

Why do we need this term? How is this different from data tree defined
in RFC 7950?

   o  data tree: An instantiated tree of any data modeled with YANG,
  e.g., configuration data, state data, combined configuration and
  state data, RPC or action input, RPC or action output, or
  notification.

In which sense is this a 'named set'? Or is the intention here to
define a named set of YANG data trees? If a term is needed, would
'Instance Data' not be simpler and align better with Instance Data
File? Also note that 'instance data' is defined later as 'data that
could be stored in a datastore and whose syntax and semantics is
defined by YANG models'. So how does 'instance data' related to
'instance data set' and 'data tree'? Can we simplify things?

   Target YANG Module: A YANG module for which the instance data set
   contains instance data, like ietf-yang-library in the examples.

I am not sure I like 'target'. It seems to me that instance data is
expected to conform to a schema defined by a collection of YANG
modules and you probably want to express that (but 'target' I find
misleading - data does not target a module).  Whatever we choose at
the end, we need to make sure that the terminology across related
documents (YANG, NMDA, YANG Library, ...) is consistent.

The leaf target-ptr triggers questions as well. If there is a choice
between two things, perhaps using a YANG choice is a more natural way
of expressing this than inventing special notations. I am also not
sure if it is a good idea to hardcode the name ietf-yang-library. Why
can I not just refer to any schema defining YANG modules? This way, we
have the freedom to create ietf-yang-library-2 if we ever want to. Do
implementations have to follow target-ptr arbitrarily deep? Do they
have to detect circular references (well they better do I guess).

/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

[Robert Wilton]

Hi Balazs,

Regarding identifying the instance data using a YANG package.

If the YANG packages work is liked by the WG and progresses, then it 
seems plausible that a YANG package could become a better way of 
identifying the set of modules rather than using YANG library for a 
couple of reasons:
 1) It will allow modules to be identified via semantic version rather 
than just revision date.  This will likely be more meaningful to readers.
 2) It allows for a much more concise definition.  Rather than having 
to try and infer what schema a particular set of YANG modules related to 
from the list of modules, it can instead refer to a single package 
definition and version number.
 3) YANG library (certainly RFC7895bis) defines the schema in terms of 
the datastore, so if this version of YANG library is being used then it 
is a bit more confusing as to which datastore is being referred to.  I 
appreciate that there is a datastore leaf in the instance data that can 
help mitigate this.


I also note that the draft currently binds that the only allowed inline 
schema is YANG library, but that seems somewhat overly restrictive, and 
perhaps this could be loosened to a leaf-list of inline module@revision 
definitions?


I also appreciate that you don't want to delay the instance data draft 
for YANG packages, bit I wonder whether the draft can easily facilitate 
using a YANG package definition in future if required.


Hence, rather than using a union for the "target pointer", I wonder 
whether it wouldn't be better to use a choice statement instead.


E.g. the choice statement could be something like this:

 choice "schema"
   leaf-list inline {
 type string {
   pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';
 }
   }
   leaf yang-library-ref { type uri } // Points to a instance data 
document YANG library content.

 }

In future, the package draft could then augment (or update the revision) 
with something like this :


   container package-ref {
 leaf "name" { type string; }
 leaf "version" { type yang-semver; }
 leaf-list "url" { type uri; }// Points to a instance data document 
containing YANG package content.

   }

Thanks,
Rob

On 06/12/2018 10:15, Balázs Lengyel wrote:


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,