[netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-07.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   : Common YANG Data Types
Author  : Juergen Schoenwaelder
Filename: draft-ietf-netmod-rfc6991-bis-07.txt
Pages   : 41
Date: 2021-07-09

Abstract:
   This document introduces a collection of common data types to be used
   with the YANG data modeling language.  This document obsoletes RFC
   6991.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-07


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] yang-instance-file include-defaults leaf

[Andy Bierman]

On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) 
wrote:

> Andy,
>
>
>
> Yes, when I suggested this, I was thinking that a boolean flag might be
> sufficient.  My point being that automatically filtering out default values
> isn’t always the right thing to do.
>
>
>
> E.g., something along these lines:
>
>
>
> leaf exclude-defaults {
>
>   type boolean;
>
>   default true;
>
>   description
>
> “Can be used to reduce the size of the content data file.
>
>
>
>   When unset or set to true, data nodes that have a default defined and
>
>   where the actual value is the default value are excluded from the
> content
>
>   data.
>
>
>
>   When set to false, data nodes with default value are not filtered,
> and
>
>   may appear in the content data.”
>
> }
>
>
>
> Would this satisfy your concern?
>


no.

I am confused as to what problem you are trying to solve here.
There does not seem to be one.

Maybe it is "The reader needs to know if the writer reported defaults or
not".
What problem is solved because the reader knows this info?

There has always been confusion between implementing YANG default behavior
and a protocol that allows a client to request how defaults are handled in
the response.
RFC 6243 is a hack needed because the WG never actually agreed on how
defaults should be treated within a server.

A YANG default is the value that MUST be used in the event the leaf or
leaf-list instance
does not exist.  So the term "defaults present" only really applies to
reporting YANG defaults.
The YANG default behavior is always in effect. Unlike SMIv2 DEFVAL, it is
mandatory to support.

The with-defaults parameter is optional to implement, so it is not even
true to say that
all servers report defaults, let alone say that all YANG instance files are
from NC/RC servers.

For basic-style=report-all, there is never any default suppression.  Every
value, including
missing nodes with YANG defaults, are reported as if they are nodes which
exist.
For this mode, the leafs in this draft are useless.

For basic-style=trim there is default suppression.  A node is considered
not present if it has the YANG default value, even if a client sets it to
the default value.
For this mode, the leafs in this draft are useless. Any leaf that contains
the default value is a YANG default that is being reported.

For basic-style=explicit there is default suppression.  A node is considered
not present if it has not been set by a client, ignoring the YANG default
value.
For this mode, the data reported in the content for this draft are useless.
Any leaf that contains the default value could be a default but it is not if
it was set by a client.  The 'default' attribute must be added to the node
to
identify it as a reported default.

https://datatracker.ietf.org/doc/html/rfc6243#section-6




>
>
> Regards,
> Rob
>
>
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* 08 July 2021 18:16
> *To:* NetMod WG 
> *Subject:* [netmod] yang-instance-file include-defaults leaf
>
>
>
> Hi,
>
>
>
> The module has this object:
>
>
>
> leaf includes-defaults {
>
>type enumeration {
>
>  enum report-all {
>
>value 1;
>
>description
>
>  "All data nodes SHOULD be included independent of
>
>any default values.";
>
>  }
>
>  enum trim {
>
>value 2;
>
>description
>
>  "Data nodes that have a default defined and where
>
>the actual value is the default value SHOULD
>
>NOT be included.";
>
>  }
>
>  enum explicit {
>
>value 3;
>
>description
>
>  "Data nodes that have a default defined and where
>
>the actual value is the default value SHOULD NOT be
>
>included. However, if the actual value was set by
>
>a NETCONF client or other management application
>
>by the way of an explicit management operation the
>
>data node SHOULD be included.";
>
>  }
>
>}
>
>default trim;
>
>
>
> The draft is extremely server-centric, like most IETF standards, but this
>
> leaf is too server-centric to ignore.
>
>
>
> Consider the possibility that the source of the file is NOT a NETCONF
> server.
>
> This data may not be known so the default of "trim" may not be correct.
>
>
>
> IMO this leaf is noise because any tool that knows the schema will also
>
> know the YANG defaults.  The solution is incomplete anyway because
>
> the presence of a leaf that has a YANG default is not enough.
>
> The  "report-all-tagged" mode must be used to identify defaults.
>
> IMO this leaf should be removed, but at least add an enum called "unknown".
>
>
>
>
>
> Andy
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Juergen,

Yes, I agree that is a better phrasing.

Thanks for suggesting it.
Rob


> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 09 July 2021 12:50
> To: Rob Wilton (rwilton) 
> Cc: Balázs Lengyel ; Andy Bierman
> ; netmod@ietf.org; Benoit Claise
> 
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> On Fri, Jul 09, 2021 at 09:10:34AM +, Rob Wilton (rwilton) wrote:
> >
> > "YANG modules that are only required to satisfy import-only dependencies
> MAY be excluded from the leaf-list.  If they are excluded then the consumer
> of the instance data file can choose any versions of the YANG modules that
> satisfy the import dependency."
> >
> 
> Sorry, this wording is a bit wrong or possibly misleading. I assume
> your intention was this:
> 
> OLD:
> 
> If they are excluded then the consumer of the instance data file can
> choose any versions of the YANG modules that satisfy the import
> dependency.
> 
> NEW:
> 
> If they are excluded then the consumer of the instance data file has
> to apply the YANG language rules to resolve the imports.
> 
> /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] yang-instance-file include-defaults leaf

[Rob Wilton (rwilton)]

Andy,

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.

E.g., something along these lines:

leaf exclude-defaults {
  type boolean;
  default true;
  description
“Can be used to reduce the size of the content data file.

  When unset or set to true, data nodes that have a default defined and
  where the actual value is the default value are excluded from the content
  data.

  When set to false, data nodes with default value are not filtered, and
  may appear in the content data.”
}

Would this satisfy your concern?

Regards,
Rob


From: netmod  On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG 
Subject: [netmod] yang-instance-file include-defaults leaf

Hi,

The module has this object:


leaf includes-defaults {

   type enumeration {

 enum report-all {

   value 1;

   description

 "All data nodes SHOULD be included independent of

   any default values.";

 }

 enum trim {

   value 2;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD

   NOT be included.";

 }

 enum explicit {

   value 3;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD NOT be

   included. However, if the actual value was set by

   a NETCONF client or other management application

   by the way of an explicit management operation the

   data node SHOULD be included.";

 }

   }

   default trim;


The draft is extremely server-centric, like most IETF standards, but this
leaf is too server-centric to ignore.

Consider the possibility that the source of the file is NOT a NETCONF server.
This data may not be known so the default of "trim" may not be correct.

IMO this leaf is noise because any tool that knows the schema will also
know the YANG defaults.  The solution is incomplete anyway because
the presence of a leaf that has a YANG default is not enough.
The  "report-all-tagged" mode must be used to identify defaults.
IMO this leaf should be removed, but at least add an enum called "unknown".


Andy


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

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Juergen Schoenwaelder]

On Fri, Jul 09, 2021 at 08:57:34AM +, tom petch wrote:
> From: netmod  on behalf of Juergen Schoenwaelder 
> 
> Sent: 08 July 2021 11:13
> 
> On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote:
> > It is perhaps worth noting that the NETCONF copy-config allows for the 
> > configuration to be specified using any URI, but the server capabilities 
> > announce which URI schemes are supported.
> >
> > Hence, I think that it is okay for the YANG model to use URI, but I think 
> > the draft, and data node description should constrain the URI schemes that 
> > allowed (perhaps file:// and https://).  This would allow support for 
> > future URI schemes to be added in a future revision of the YANG instance 
> > data module, if required.
> >
> 
> I think it is not "allowed" but "mandatory to implement". We should
> allow implementations to support an ftps:// scheme as long as there
> is a common baseline.
> 
> 
> I am confused.  Is ftps: intended to be an existing scheme or a hypothetical 
> one that may appear in the future.  I do not see it in the IANA registry
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1
> 
> sftp: appears as a provisional entry in the IANA registry but AFACT did not 
> get specified.  I recall a debate about ftps: v sftp:  I favoured the former 
> but lost but then I did not see any further work on either.
>

I used 'ftps:' as an example, I should have taken the time to find RFC
4395 and then I should have picked 'example:'.

/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] AD review of draft-ietf-netmod-yang-instance-file-format

[Juergen Schoenwaelder]

On Fri, Jul 09, 2021 at 09:10:34AM +, Rob Wilton (rwilton) wrote:
> 
> "YANG modules that are only required to satisfy import-only dependencies MAY 
> be excluded from the leaf-list.  If they are excluded then the consumer of 
> the instance data file can choose any versions of the YANG modules that 
> satisfy the import dependency."
>

Sorry, this wording is a bit wrong or possibly misleading. I assume
your intention was this:

OLD:

If they are excluded then the consumer of the instance data file can
choose any versions of the YANG modules that satisfy the import
dependency.

NEW:

If they are excluded then the consumer of the instance data file has
to apply the YANG language rules to resolve the imports.

/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] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt

[Balázs Lengyel]

Hello Rob,
I included all comments from the AD review and associated mails. I stored an
updated version of the draft.
Thanks for all the comments.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of internet-dra...@ietf.org
Sent: 2021. július 9., péntek 12:37
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action:
draft-ietf-netmod-yang-instance-file-format-15.txt


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-15.txt
Pages   : 28
Date: 2021-07-09

Abstract:
   There is a need to document data defined in YANG models at design,
   implementation time or when a live server is unavailable.  This
   document specifies a standard file format for YANG instance data,
   which follows the syntax and semantics of existing YANG models, and
   annotates it with metadata.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-f
ormat-15

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


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


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

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Andy Bierman]

On Fri, Jul 9, 2021 at 1:58 AM Balázs Lengyel 
wrote:

> Hello Andy,
>
> In the name of simplification, I will add the following to the URI method:
>
>
>
> Referenced files using  "inline" or the "simplified-inline" methods MUST
> be supported.
>
> Referenced files using the "URI method" MAY be supported.
>
>
>

This is a good compromise.
Although it may seem that mandating everything will increase
interoperability,
it actually has the opposite effect. Companies decide to implement
everything,
but "in phases".  This is code for "phase 1 will implement the parts we
need.
Phase 2 will never happen."

There is plenty of implementation experience with the first 2 methods,
and good reason to think they will be supported.  The draft details for the
URI
method clearly lack any meaningful implementation feedback.
There are so many problems with this approach, especially for the reader.
Storing passwords in cleartext is just the easiest to spot.


> This means the tool does not need to be prepared for chains or loops. I
> think chains and loops are something we should discourage.
>
> (Referenced files using the “external Method” make no sense anyway. If I
> don’t tell you the schema of the referenced file, there is no sense in
> referencing them)
>


One purpose of a standard is to assign blame when it doesn't work.
If the writer generates a series of URIs that form a loop, then the reader
will
not be able to find the file that has the Simplified Inline or Inline  info.
That is clearly the fault of the writer, not the reader.


Regards Balazs
>

Andy


>
>
> *From:* netmod  *On Behalf Of *Balázs Lengyel
> *Sent:* 2021. július 9., péntek 9:39
> *To:* Andy Bierman ; Rob Wilton (rwilton) <
> rwil...@cisco.com>
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] AD review of
> draft-ietf-netmod-yang-instance-file-format
>
>
>
> Hello Andy,
>
> See below.
>
> Balazs
>
>
>
> *From:* Andy Bierman 
> *Sent:* 2021. július 8., csütörtök 18:55
> *To:* Rob Wilton (rwilton) 
> *Cc:* Juergen Schoenwaelder ;
> Balázs Lengyel ; netmod@ietf.org; Benoit
> Claise 
> *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
>
>
>
>
>
>
> On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) 
> wrote:
>
> Hi Juergen,
>
> I believe that having the simple form is worth the extra complexity.
>
>
>
>
>
> I believe it is the only option that does not have too much complexity.
>
>
>
> The inline form seems to imply that the NMDA version of the YANG library
> is used.
>
> Only 1 module set is ever shown, but of course the actual schema allows
>
> for much more complex instances than that, which the reader must support.
>
>
>
> Does this mean NMDA must be used or else a YANG data file cannot be saved?
>
> So the reader is expected to look for the 'current' /yang-library and then
> the 'deprecated' /modules-state?
>
> And then fish the anydata for whatever non-standard solution is in use?
>
> The procedures should be explained better so there is a better chance of
> interoperability.
>
> BALAZS: No NMDA is not required. If it would there would be a clear
> statement about it. Even in section 2.2.1.  Documentation of server
> capabilities the new (NMDA compatible) yang-library is used, but the simple
> (non- NMDA) modules-state branch.
>
>
>
> For the URI method, the reader must check for a broken chain of reference
> and loops.
>
> The draft should say the uri references across N files MUST NOT create a
> loop
>
> (similar language is in YANG wrt import loops).
>
> BALAZS: Someone (don.t know who) asked for longer reference chains.
> However, I don’t see them as a common use-case. IMHO the most common
> use-case for the URI method will be, when the consumer knows the
> content-schema apriori, it only needs a reference to check that the schema
> is what it expected.
>
>
>
> For conformance purposes, I think YANG features are appropriate.
>
> IMO simplified-inline is mandatory-to-implement but the rest should
>
> be optional. This way a tool can claim conformance and also the standard
>
> will provide a minimum level of interoperability.
>
> BALAZS: There are very different views about the preferred/required
> methods. Also the needs of different use-cases are different. That’s why we
> need all 3.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
> I think that you are right to be concerned that it should not expand into
> a separate parallel format.  Overtime, I would like the simple form to be
> able to use revision labels instead of revision dates, but beyond this I
> think that it should just be a flat list of modules that defines the
> schema.  If a subset of features, or datastores, or import-only modules are
> needed then the YANG library version (or URIs) can and should be used.
>
>
>
> This can be done with augment if and when the versioning draft reaches RFC
>
>
>
> Another example of where I expect it to be useful is in YANG packages.
> Looking at the examples at the end of
> 

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.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-15.txt
Pages   : 28
Date: 2021-07-09

Abstract:
   There is a need to document data defined in YANG models at design,
   implementation time or when a live server is unavailable.  This
   document specifies a standard file format for YANG instance data,
   which follows the syntax and semantics of existing YANG models, and
   annotates it with metadata.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-15

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


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] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Andy,

Yes, the intention is that the YANG packages work covers exactly the use case 
that you describe below.

Regarding using JSON, my expectation is that the package would get consumed by 
tools as YANG instance data (i.e., similar to how yang library data is fetched 
from a running server).

I would think that extra metadata in the package definition could be expressed 
using regular YANG augmentations.

E.g., the simplified-inline schema for the instance data file containing the 
definition of a specific YANG package instance could be something like:
Ietf-yang-packages@...mailto:Ietf-yang-packages@...%3c/module>>
foo-yang-pkg-augmentations@...mailto:foo-yang-pkg-augmentations@...%3c/module>>

// Content data contains base package information and extra data that conforms 
to the additional schema elements defined by foo augmentations.


I’ve not thought about it, but perhaps YANG metadata annotations would also 
work (RFC 7952).

Regards,
Rob


From: Andy Bierman 
Sent: 08 July 2021 21:38
To: Rob Wilton (rwilton) 
Cc: Juergen Schoenwaelder ; Balázs 
Lengyel ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format



On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Juergen,

I believe that having the simple form is worth the extra complexity.

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

https://datatracker.ietf.org/doc/html/draft-bierman-netmod-yang-conformance-00

An original use-case in my 2013 draft was to allow a vendor to define a package
that represented the entire server. Then the entire  and YANG library can
be replaced by one package-id in this case. This is reasonable for embedded 
devices
that have a fixed YANG library (expected for CORECONF).

BTW, the main reason I proposed the YANG syntax (your version has a JSON 
document)
is that these files are needed by automation tools, and YANG allows extensions
(and other things like augment). Automation tools cannot work without extensions
so not sure how JSON package files will be useful to them.


Regards,
Rob

Andy



> -Original Message-
> From: Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel 
> mailto:balazs.leng...@ericsson.com>>
> Cc: Andy Bierman mailto:a...@yumaworks.com>>; Rob Wilton 
> (rwilton)
> mailto:rwil...@cisco.com>>; 
> netmod@ietf.org; Benoit Claise
> mailto:benoit.cla...@huawei.com>>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
> The question I asked is "how much simpler is it and does that saving
> justify the introduction of a new rather limited format (that may risk
> to grow over time and become a second citizen)".
>
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would
> roughly look this (please correct what I messed up, I am writing this
> by hand):
>
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
>
> Yes, this is a bit longer, but it also conveys more information (note
> that your datastore leaf in the header would likely not be needed
> anymore).
>
> I am concerned that we start creating another format to define schemas
> that is very limited and people later come with extension proposals to
> address some of the limits and at the end we have multiple formats to
> maintain and deal with. So the question is whether people think this
> is worth it. (Note that the felt overhead goes down with every
> additional module used by your instance file, so the example above is
> really the most extreme case. And if you have many modules 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Balazs,

Thanks.  That sounds fine.   Please can you add a sentence to the description 
of the simplified-inline in the YANG model to state this, which I think may be 
something like:

"YANG modules that are only required to satisfy import-only dependencies MAY be 
excluded from the leaf-list.  If they are excluded then the consumer of the 
instance data file can choose any versions of the YANG modules that satisfy the 
import dependency."

Regards,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 09 July 2021 08:25
> To: Rob Wilton (rwilton) ; Juergen Schoenwaelder
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello,
> A single line is enough.
> As long as ietf-yang-types is change in a backward compatible way, I don't
> care which version of yang-types is imported. Also, we only use a single
> type 'yang:xpath1.0' from yang-types. The rules for this type  are described
> by W3C and not changing.
> Balazs
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 8., csütörtök 15:49
> To: Balázs Lengyel ; Juergen Schoenwaelder
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Balazs,
> 
> Would your inline schema not also need to specify the ietf-yang-types
> dependency?
> 
> E.g., should it be:
> ietf-netconf-acm@2018-02-14
> ietf-yang-types@2013-07-15
> 
> Thanks,
> Rob
> 
> 
> > -Original Message-
> > From: Balázs Lengyel 
> > Sent: 08 July 2021 12:48
> > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder
> > 
> > Cc: Andy Bierman ; netmod@ietf.org; Benoit
> Claise
> > 
> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > Hello,
> > I would like to keep simplified inline. If I ask my developers (not
> > experts) which one do they want? I am pretty sure they opt for the
> > shorter/simpler one.
> >
> > ietf-netconf-acm@2018-02-14
> >
> > OR
> >
> > 
> >   
> > m
> > 
> >   ietf-netconf-acm
> >   2018-02-14
> >   uri1
> > 
> > 
> >   ietf-yang-types
> >   uri2
> >   
> > 
> >   
> >   
> > s
> > m
> >   
> >   
> > running
> > s
> >   
> > 
> >
> > Regards Balazs
> >
> > -Original Message-
> > From: Rob Wilton (rwilton) 
> > Sent: 2021. július 8., csütörtök 12:59
> > To: Juergen Schoenwaelder ;
> > Balázs Lengyel 
> > Cc: Andy Bierman ; netmod@ietf.org; Benoit
> Claise
> > 
> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > Hi Juergen,
> >
> > I believe that having the simple form is worth the extra complexity.
> >
> > I think that you are right to be concerned that it should not expand
> > into a separate parallel format.  Overtime, I would like the simple
> > form to be able to use revision labels instead of revision dates, but
> > beyond this I think that it should just be a flat list of modules that
> > defines the schema.  If a subset of features, or datastores, or
> > import-only modules are needed then the YANG library version (or URIs)
> can
> and should be used.
> >
> > Another example of where I expect it to be useful is in YANG packages.
> > Looking at the examples at the end of
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages,
> > then some of those files (which currently aren't defining any schema,
> > but should) would almost double in size if they represented the schema
> > inline using YANG library, which I think would make the files harder
> > for humans to read/parse.
> > Using URIs could help mitigate this, but then we would need to find a
> > place to publish the file containing the YANG package schema
> > (presumably somewhere in IANA), and it not obvious to me that adding
> > the dependency on the URL is really as helpful.
> >
> > Regards,
> > Rob
> >
> >
> > > -Original Message-
> > > From: Juergen Schoenwaelder 
> > > Sent: 08 July 2021 11:35
> > > To: Balázs Lengyel 
> > > Cc: Andy Bierman ; Rob Wilton (rwilton)
> > > ; netmod@ietf.org; Benoit Claise
> > > 
> > > Subject: Re: AD review of
> > > draft-ietf-netmod-yang-instance-file-format
> > >
> > > The question I asked is "how much simpler is it and does that saving
> > > justify the introduction of a new rather limited format (that may
> > > risk to grow over time and become a second citizen)".
> > >
> > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> > > from ietf-yang-types (at the time of publication that resolves to
> > > ietf-yang-types@2013-07-15. So the YANG Library instance data would
> > > roughly look this (please correct what I messed up, I am writing
> > > this by hand):
> > >
> > > 
> > >   
> > > m
> > > 
> > >   ietf-netconf-acm
> > >   2018-02-14
> > >   uri1
> > > 
> > > 
> > >   ietf-yang-types
> > >   uri2
> > >   
> > > 
> > >   
> > >   
> > > s
> > >

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Only https and file schemes will be mentioned in the draft.
Balazs

-Original Message-
From: netmod  On Behalf Of tom petch
Sent: 2021. július 9., péntek 10:58
To: Rob Wilton (rwilton) ; Juergen Schoenwaelder

Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of
draft-ietf-netmod-yang-instance-file-format

From: netmod  on behalf of Juergen Schoenwaelder

Sent: 08 July 2021 11:13

On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote:
> It is perhaps worth noting that the NETCONF copy-config allows for the
configuration to be specified using any URI, but the server capabilities
announce which URI schemes are supported.
>
> Hence, I think that it is okay for the YANG model to use URI, but I think
the draft, and data node description should constrain the URI schemes that
allowed (perhaps file:// and https://).  This would allow support for future
URI schemes to be added in a future revision of the YANG instance data
module, if required.
>

I think it is not "allowed" but "mandatory to implement". We should allow
implementations to support an ftps:// scheme as long as there is a common
baseline.


I am confused.  Is ftps: intended to be an existing scheme or a hypothetical
one that may appear in the future.  I do not see it in the IANA registry
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1

sftp: appears as a provisional entry in the IANA registry but AFACT did not
get specified.  I recall a debate about ftps: v sftp:  I favoured the former
but lost but then I did not see any further work on either.

Tom Petch

/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

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


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

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Andy,

In the name of simplification, I will add the following to the URI method:

 

Referenced files using  "inline" or the "simplified-inline" methods MUST be 
supported. 

Referenced files using the "URI method" MAY be supported.

 

This means the tool does not need to be prepared for chains or loops. I think 
chains and loops are something we should discourage. 

(Referenced files using the “external Method” make no sense anyway. If I don’t 
tell you the schema of the referenced file, there is no sense in referencing 
them)

Regards Balazs

 

From: netmod  On Behalf Of Balázs Lengyel
Sent: 2021. július 9., péntek 9:39
To: Andy Bierman ; Rob Wilton (rwilton) 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

 

Hello Andy,

See below.

Balazs

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >; 
netmod@ietf.org  ; Benoit Claise 
mailto:benoit.cla...@huawei.com> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

 

 

I believe it is the only option that does not have too much complexity.

 

The inline form seems to imply that the NMDA version of the YANG library is 
used.

Only 1 module set is ever shown, but of course the actual schema allows

for much more complex instances than that, which the reader must support.

 

Does this mean NMDA must be used or else a YANG data file cannot be saved?

So the reader is expected to look for the 'current' /yang-library and then the 
'deprecated' /modules-state?

And then fish the anydata for whatever non-standard solution is in use?

The procedures should be explained better so there is a better chance of 
interoperability.

BALAZS: No NMDA is not required. If it would there would be a clear statement 
about it. Even in section 2.2.1.  Documentation of server capabilities the new 
(NMDA compatible) yang-library is used, but the simple (non- NMDA) 
modules-state branch.

 

For the URI method, the reader must check for a broken chain of reference and 
loops.

The draft should say the uri references across N files MUST NOT create a loop

(similar language is in YANG wrt import loops).

BALAZS: Someone (don.t know who) asked for longer reference chains. However, I 
don’t see them as a common use-case. IMHO the most common use-case for the URI 
method will be, when the consumer knows the content-schema apriori, it only 
needs a reference to check that the schema is what it expected.

 

For conformance purposes, I think YANG features are appropriate.

IMO simplified-inline is mandatory-to-implement but the rest should 

be optional. This way a tool can claim conformance and also the standard

will provide a minimum level of interoperability.

BALAZS: There are very different views about the preferred/required methods. 
Also the needs of different use-cases are different. That’s why we need all 3.

 

 

Andy

 

 

 

 

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

 

This can be done with augment if and when the versioning draft reaches RFC

 

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder   >
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel   >
> Cc: Andy Bierman mailto:a...@yumaworks.com> >; Rob 
> Wilton (rwilton)
> mailto:rwil...@cisco.com> >; netmod@ietf.org 
>  ; Benoit Claise
> mailto:benoit.cla...@huawei.com> >
> Subject: Re: AD review of 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[tom petch]

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 08 July 2021 11:13

On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote:
> It is perhaps worth noting that the NETCONF copy-config allows for the 
> configuration to be specified using any URI, but the server capabilities 
> announce which URI schemes are supported.
>
> Hence, I think that it is okay for the YANG model to use URI, but I think the 
> draft, and data node description should constrain the URI schemes that 
> allowed (perhaps file:// and https://).  This would allow support for future 
> URI schemes to be added in a future revision of the YANG instance data 
> module, if required.
>

I think it is not "allowed" but "mandatory to implement". We should
allow implementations to support an ftps:// scheme as long as there
is a common baseline.


I am confused.  Is ftps: intended to be an existing scheme or a hypothetical 
one that may appear in the future.  I do not see it in the IANA registry
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1

sftp: appears as a provisional entry in the IANA registry but AFACT did not get 
specified.  I recall a debate about ftps: v sftp:  I favoured the former but 
lost but then I did not see any further work on either.

Tom Petch

/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

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

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Andy,

See below.

Balazs

 

From: Andy Bierman  
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) 
Cc: Juergen Schoenwaelder ; Balázs 
Lengyel ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

 

 

I believe it is the only option that does not have too much complexity.

 

The inline form seems to imply that the NMDA version of the YANG library is 
used.

Only 1 module set is ever shown, but of course the actual schema allows

for much more complex instances than that, which the reader must support.

 

Does this mean NMDA must be used or else a YANG data file cannot be saved?

So the reader is expected to look for the 'current' /yang-library and then the 
'deprecated' /modules-state?

And then fish the anydata for whatever non-standard solution is in use?

The procedures should be explained better so there is a better chance of 
interoperability.

BALAZS: No NMDA is not required. If it would there would be a clear statement 
about it. Even in section 2.2.1.  Documentation of server capabilities the new 
(NMDA compatible) yang-library is used, but the simple (non- NMDA) 
modules-state branch.

 

For the URI method, the reader must check for a broken chain of reference and 
loops.

The draft should say the uri references across N files MUST NOT create a loop

(similar language is in YANG wrt import loops).

BALAZS: Someone (don.t know who) asked for longer reference chains. However, I 
don’t see them as a common use-case. IMHO the most common use-case for the URI 
method will be, when the consumer knows the content-schema apriori, it only 
needs a reference to check that the schema is what it expected.

 

For conformance purposes, I think YANG features are appropriate.

IMO simplified-inline is mandatory-to-implement but the rest should 

be optional. This way a tool can claim conformance and also the standard

will provide a minimum level of interoperability.

BALAZS: There are very different views about the preferred/required methods. 
Also the needs of different use-cases are different. That’s why we need all 3.

 

 

Andy

 

 

 

 

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

 

This can be done with augment if and when the versioning draft reaches RFC

 

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder   >
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel   >
> Cc: Andy Bierman mailto:a...@yumaworks.com> >; Rob 
> Wilton (rwilton)
> mailto:rwil...@cisco.com> >; netmod@ietf.org 
>  ; Benoit Claise
> mailto:benoit.cla...@huawei.com> >
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> The question I asked is "how much simpler is it and does that saving
> justify the introduction of a new rather limited format (that may risk
> to grow over time and become a second citizen)".
> 
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would
> roughly look this (please correct what I messed up, I am writing this
> by hand):
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Yes, this is a bit longer, but it also conveys more information (note
> that your datastore leaf in the header would likely not be needed
> anymore).
> 
> I am concerned that we start creating another format to define schemas
> that is very limited and people 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello,
A single line is enough.
As long as ietf-yang-types is change in a backward compatible way, I don't
care which version of yang-types is imported. Also, we only use a single
type 'yang:xpath1.0' from yang-types. The rules for this type  are described
by W3C and not changing. 
Balazs

-Original Message-
From: Rob Wilton (rwilton)  
Sent: 2021. július 8., csütörtök 15:49
To: Balázs Lengyel ; Juergen Schoenwaelder

Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise

Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Balazs,

Would your inline schema not also need to specify the ietf-yang-types
dependency?

E.g., should it be:
ietf-netconf-acm@2018-02-14
ietf-yang-types@2013-07-15

Thanks,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 08 July 2021 12:48
> To: Rob Wilton (rwilton) ; Juergen Schoenwaelder 
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise 
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello,
> I would like to keep simplified inline. If I ask my developers (not 
> experts) which one do they want? I am pretty sure they opt for the 
> shorter/simpler one.
> 
> ietf-netconf-acm@2018-02-14
> 
> OR
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Regards Balazs
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 8., csütörtök 12:59
> To: Juergen Schoenwaelder ; 
> Balázs Lengyel 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise 
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Juergen,
> 
> I believe that having the simple form is worth the extra complexity.
> 
> I think that you are right to be concerned that it should not expand 
> into a separate parallel format.  Overtime, I would like the simple 
> form to be able to use revision labels instead of revision dates, but 
> beyond this I think that it should just be a flat list of modules that 
> defines the schema.  If a subset of features, or datastores, or 
> import-only modules are needed then the YANG library version (or URIs) can
and should be used.
> 
> Another example of where I expect it to be useful is in YANG packages.
> Looking at the examples at the end of
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, 
> then some of those files (which currently aren't defining any schema, 
> but should) would almost double in size if they represented the schema 
> inline using YANG library, which I think would make the files harder 
> for humans to read/parse.
> Using URIs could help mitigate this, but then we would need to find a 
> place to publish the file containing the YANG package schema 
> (presumably somewhere in IANA), and it not obvious to me that adding 
> the dependency on the URL is really as helpful.
> 
> Regards,
> Rob
> 
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 08 July 2021 11:35
> > To: Balázs Lengyel 
> > Cc: Andy Bierman ; Rob Wilton (rwilton) 
> > ; netmod@ietf.org; Benoit Claise 
> > 
> > Subject: Re: AD review of 
> > draft-ietf-netmod-yang-instance-file-format
> >
> > The question I asked is "how much simpler is it and does that saving 
> > justify the introduction of a new rather limited format (that may 
> > risk to grow over time and become a second citizen)".
> >
> > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports 
> > from ietf-yang-types (at the time of publication that resolves to 
> > ietf-yang-types@2013-07-15. So the YANG Library instance data would 
> > roughly look this (please correct what I messed up, I am writing 
> > this by hand):
> >
> > 
> >   
> > m
> > 
> >   ietf-netconf-acm
> >   2018-02-14
> >   uri1
> > 
> > 
> >   ietf-yang-types
> >   uri2
> >   
> > 
> >   
> >   
> > s
> > m
> >   
> >   
> > running
> > s
> >   
> > 
> >
> > Yes, this is a bit longer, but it also conveys more information 
> > (note that your datastore leaf in the header would likely not be 
> > needed anymore).
> >
> > I am concerned that we start creating another format to define 
> > schemas that is very limited and people later come with extension 
> > proposals to address some of the limits and at the end we have 
> > multiple formats to maintain and deal with. So the question is 
> > whether people think this is worth it. (Note that the felt overhead 
> > goes down with every additional module used by your instance file, 
> > so the example above is really the most extreme case. And if you 
> > have many modules defining NACM rules, then you put the above into a 
> > separate file and use the URI to point to the schema, no?
> >
> > /js
> >
> > On Thu, Jul 08, 2021 at 09:27:52AM +, Balázs Lengyel wrote:
> > > Hello Jurgen,
> > > Inline:
> > > This complex