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

From: Balázs Lengyel <[email-masked]>
Date: Mon, 5 Jul 2021 12:47:13 +0000

Hello Rob,
Thanks for the review.  Here are my answers below. I will also upload the
new version asap.
Regards Balazs
-----------------------------------------------------------
Hi,

Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.

Thanks for this document, I think that it represents important useful work
for advancing the YANG ecosystem.

This document is in good shape, and I mostly have minor comments but with a
few more significant comments.

Main comments:

1.
   An instance data set MAY contain data for any number of YANG modules;
   if needed it MAY carry the complete configuration and state data for
   a server.  Default values SHOULD NOT be included.

This document recommends that default values SHOULD NOT be included, but
there are cases where they are useful, and e.g., NMDA recommends that
"in-use" values (effectively including default values) are returned.
Further, there is no way for a consumer of the file to know whether default
values are included or not.

Hence, I would recommend that the instance-data-set defines an
"includes-defaults" leaf that indicates whether default values are included
in the dataset, the leaf can default to them not being included in the
dataset.

Further, I would suggest weakening "Default values SHOULD NOT be included"
to something like:
"Default values should be excluded where they do not provide additional
useful data."
BALAZS: Section 2 states that a default attribute may be specified,
following the with-defaults capability. 
However, your proposal is better. I will include it. 
Added leaf includes-defaults.

2.
In the YANG Module:
     feature inline-content-schema {
       description
         "This feature indicates that inline content-schema
          option is supported. Support for this feature might
          be documented only via out-of-band documentation.";
     }
	 
What is the benefit of having 'inline-content-schema' as a feature?  It
seems to potentially add complexity without any benefit, given that the
device originating the instance data file would effectively choose whether
to use the inline-content-schema, hence I suggest that it might be simpler
just to remove the feature definition.
BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).
The system can declare supported/not-supported in design documentation.
In a use-case when a client or a design department is sending data to a
server this is needed. E.g. in UC2, Preloading Default Configuration the
designer preparing instance data, can decide to use or not use the
inline-content-schema based on this.
   
3.
In the YANG Module:

	"case inline", description:
                    The first item is either ietf-yang-library or
                    some other YANG module that contains a list of
                    YANG modules with their name, revision-date,
                    supported-features, and deviations.
                    The usage of revision '2019-01-04' of the
                    'ietf-yang-library' module MUST be supported.
                    Using other modules, module versions MAY also
                    be supported.

This seems to make interop for consumers of instance data files hard, since
the schema can be defined by any arbitrary YANG module without updating this
module.  I would suggest that it is safer to limit this to the two currently
published versions of YANG library.
BALAZS:  I fully agree, however this was explicitly requested by some
reviewer earlier (Juergen ?) Shall I simplify this or not?

If additional modules are supported in future, then I think that it would be
safer to create a new version of this YANG module that documents what other
module formats can be used.

4.
In the YANG Module:
	list "revision"

Is revision expected to be unique, if provided? If so, should this be
explicitly stated in the YANG module description?
BALAZS: I don't think I understand your comment. There may be multiple list
entries for revision. The 'leaf date' is a key, so it is inherently unique.
The description may or may not be unique.

5.
In the YANG Module:

Is an instance-data file allowed to contain both a revision and also a
timestamp?  If so, is there any constraints on the values.  If not, then
would it make sense to put them under a choice?
BALAZS:  It is allowed to have both. There is some recommendation text about
when to use each. However I can see some corner cases, when using both in
the same file would be useful, E.g. we want a timestamp including hour,
minutes, but we also want the history of the instance data set, including
multible revision/descriptions.
I propose to add: if both are included the timestamp, SHOULD contain
the same date as the latest revision statement.

6.
References:
- RFC 6020 needs to be normative for the IANA YANG module registration.
BALAZS: OK

Minor comments:

7. 
Abstract:

   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is often needed at design or
   implementation time or needed when a live running 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.
   
I suggest combining the first 2 sentences to:

There is a need to document data defined in YANG models at design,
implementation time or when a live server is unavailable.
BALAZS: OK

8.
Sec 1. Introduction:
I suggest tweaking 2nd sentence to:
	Data is often needed at design, implementation time, or when a live
	running server is unavailable. 
BALAZS: OK

9.   
Sec 2. Instance Data File Format:

   o  a default attribute as defined in [RFC6243] section 6. and in
      [RFC8040] section 4.8.9.
	  
I would suggest putting default in quotes.  E.g., "a 'default' attribute, as
defined ...".
BALAZS: OK

For the two other bullets in the list, it might read better as "metadata, as
defined ..." and "origin metadata, as specified ..."
BALAZS: OK

10.
Sec 2. Instance Data File Format:
	instance-data-set-name ['@' ( revision-date / timestamp ) ]
(i) Possibly helpful to clarify that the revision-date and timestamp take
the same format  as they are encoded in the equivalent leaves in the YANG
file. 
(ii) Would it be helpful to include an example without a revision-date?
(iii) I also note that no recommendation is made as to whether a date or
timestamp is
   included (which I think is okay).
BALAZS:  OK, Added text for (i). Added example for (ii)

11.
Sec: 2.2 Examples
(i) Should the module name start with example-acme-system-ext and
acme.example.com
BALAZS: IMHO the use of "acme" as a company name already indicates this is
an example. "E.g." and the word "example" is also included in the text in a
number of places.

(ii) Would it be helpful for some/all of the examples to also give the
filename that they would be expected to use?
BALAZS: OK. Actually, they already have filenames, but it is only visible in
the XML not in the TXT format. If you export the files with rfcstrip these
filenames will be used. I added the filenames into the text too.

12.
YANG Module:
(i) I note that the module only indicates Balazs as an author and not Benoit
(which 
   differs from the draft authors).
BALAZS: OK. added Benoit

(ii) "format-version"
Please ensure that there is an RFC editor note to update this value if the
module gets changed in anyway during reviews or RFC editor process.
BALAZS: OK. added

(iii)
"case simplified-inline", description:

                  The value SHALL start with the module name.
                  If the module contains a revision statement the
                  revision date SHALL be included in the leaf-list
                  entry. If other methods (e.g., revision-label) are
                  defined to identify individual module revisions
                  those MAY be used instead of using a revision date.

I wonder whether it would be clearer to merge the second and third sentences
into one:

                  The value SHALL start with the module name.
                  If the module contains a revision statement the
                  revision date SHALL be included in the leaf-list
                  entry, unless other methods (e.g., revision-label) are
                  defined to identify individual module revisions, when
                  those MAY be used instead of using a revision date.

If you agree to this change, then please update the equivalent text in the
inline case as well.				  
BALAZS: OK, changed

(iv)
Should the example version of YANG library used match the mandatory to
support version (in the YANG module)?
BALAZS: OK, changed. But I will still use the old modules-state branch
because its simpler

(v)
I also note that the content schema case statement order differs from how
they are described earlier in the document.  Does it make sense to align
them?  Is one of the content-schema-specs the default approach, i.e., does
it make sense to specify a default for the choice statement?
BALAZS: IMO default should not be specified. In chapter 2.1 we have:
"External Method: Do not include the "content-schema" node; the
      user needs to obtain the information through external documents."
In this case, none of the "cases" are used.
Reordered items in section 2.1. IMHO the simplified inline will be the most
used method.

13.
IANA section

	5.2.  YANG Module Name Registration

	   This document registers one YANG module in the YANG Module Names
	   registry [RFC6020].
   
Please change to:
   
   This document registers a YANG module in the YANG Module Names
   registry [RFC6020].  Following the format in [RFC6020], the following
   registrations are requested:
BALAZS: OK, changed

Grammar Warnings (generated, by tool):
Section: 2, draft text:
Later as other YANG encodings (e.g., CBOR) are defined, further instance
data formats may be specified. 
Warning:  Comparison requires than, not 'then' nor 'as'.
Suggested change:  "Later, as other ..."
BALAZS: OK

Section: 2.1.1, draft text:
 The anydata inline-schema carries instance data (conforming to the
inline-modules) that actually specifies the content defining YANG modules
including revision, supported features, deviations and any relevant
additional data (e.g., revision labels, described by [REF]) as alternative
to the revision date). 
Warning:  Unpaired symbol: '(' seems to be missing
BALAZS: OK, actually there was one to many ")"

Section: 4, draft text:
Because of this the the security considerations template for YANG models in
section 3.7.1 in [REF] is not followed. 
Warning:  Maybe you need to remove one determiner so that only the or the is
left.
Suggested change:  "the"
BALAZS: OK

Section: 4, draft text:
Depending on the nature of the instance data, instance data files MAY need
to be handled in a secure way. 
Warning:  Consider replacing this phrase with the adverb securely to avoid
wordiness.
Suggested change:  "securely"
BALAZS: OK

Section: C.1, draft text:
Server capabilities include: 
-  data defined in "ietf-yang-library": YANG modules, submodules, features,
deviations, schema-mounts, and datastores supported ([REF])
- alarms supported ([REF])
- data nodes and subtrees that support or do not support on-change
notifications ([REF])
- netconf-capabilities in ietf-netconf-monitoring

Warning:  Please add a punctuation mark at the end of paragraph.
Suggested change:  "ietf-netconf-monitoring."
BALAZS: OK
Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 6 Jul 2021 15:14:47 +0000

Hi Balazs,

To follow up with our conversation earlier.  Andy and Juergen explicitly copied because they may have previously commented on these issues during WG LC.

I think that my comment regarding the "feature statement" and the flexibility of the inline-method are closely related.  I find the definition of the inline-content-schema to be so generic that it effectively allows anything.  E.g., the drafts would allow me to publish a file that has an inline-content-schema based on [email-masked], and it would be very difficult for consumers of the associated instance data file to understand the file schema.

Similarly, I find that allowing revision labels (as examples to avoid a normative reference to the module versioning draft), makes it hard for a generic implementation reader of a instance data file to know how to interpret an inline schema.  I suspect that this issue could cause problems in the IESG reviews.

Hence, my preference, for this RFC, that defines version 1 of the instance file format, would be to more heavily constrain how the schema is allowed to be specified in the inline-method.  Specifically, I think that it would be better to:
 - restrict the inline schema to only be defined using ietf-yang-library@2019-01-04
 - only allow revision-dates, not revision labels.

I would like to understand from Andy, whether he still thinks with these restrictions whether the inline-schema method should still be under a YANG feature statement?

If/when the revision labels draft gets standardized, and perhaps also after YANG packages, then we could do a bis version of this document to define a v2 of the instance file format that potentially allows YANG packages to be used to define the schema, and potentially allows modules to be identified using revision labels as well as revision dates.

Balazs, I'm good with most of your proposed resolutions, but have answered one further question inline below.

> -----Original Message-----
> From: Balázs Lengyel <[email-masked]>
> Sent: 05 July 2021 13:47
> To: [email-masked]' <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>
> Cc: Benoit Claise <[email-masked]>
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello Rob,

> The description may or may not be unique.

I would suggest changing:

For every published editorial change, a new one SHOULD be added
 in front of the revisions sequence so that all

to:

For every published editorial change, a new unique revision SHOULD
be added in front of the revisions sequence so that all

I.e., to also make it clear in the description that revisions dates are required to be unique.

> the same date as the latest revision statement.

Okay.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Jul 2021 09:42:39 -0700

On Tue, Jul 6, 2021 at 8:14 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> Hi Balazs,
>
> To follow up with our conversation earlier.  Andy and Juergen explicitly
> copied because they may have previously commented on these issues during WG
> LC.
>
> I think that my comment regarding the "feature statement" and the
> flexibility of the inline-method are closely related.  I find the
> definition of the inline-content-schema to be so generic that it
> effectively allows anything.  E.g., the drafts would allow me to publish a
> file that has an inline-content-schema based on
> [email-masked], and it would be very difficult for
> consumers of the associated instance data file to understand the file
> schema.
>
> Similarly, I find that allowing revision labels (as examples to avoid a
> normative reference to the module versioning draft), makes it hard for a
> generic implementation reader of a instance data file to know how to
> interpret an inline schema.  I suspect that this issue could cause problems
> in the IESG reviews.
>
> Hence, my preference, for this RFC, that defines version 1 of the instance
> file format, would be to more heavily constrain how the schema is allowed
> to be specified in the inline-method.  Specifically, I think that it would
> be better to:
> I would like to understand from Andy, whether he still thinks with these
> restrictions whether the inline-schema method should still be under a YANG
> feature statement?
>

I do not remember asking for this feature statement.
Who is the client and who is the server, for a YANG instance file, sitting
on a hard drive?

IMO the 4 separate ways to identify the schema are 3 too many, but that
is what the WG wants.  It seems obvious that any reader of the file
has to implement all 4 methods and any writer of the file is free to pick
just one.
So the feature does not really help.

Andy

> If/when the revision labels draft gets standardized, and perhaps also
> after YANG packages, then we could do a bis version of this document to
> define a v2 of the instance file format that potentially allows YANG
> packages to be used to define the schema, and potentially allows modules to
> be identified using revision labels as well as revision dates.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2021 19:42:08 +0200

> So the feature does not really help.

The feature statements declare that implementation won't work
together. Back in a day, the IETF was all about interoperability (and
implementation costs). Nowadays we seem to be fine if implementations
declare that they won't work together. Well, still slightly better
than having implementations fail arbitrarity.

/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: Andy Bierman <[email-masked]>
Date: Tue, 6 Jul 2021 10:56:48 -0700

> than having implementations fail arbitrarity.

This is a text file stored on a USB stick.
There is no client or server. Just readers and writers.
So how does a YANG feature work here?
The reader is supposed to know how to find out if this feature is set
before opening the file?

I don't see how server capabilities discovery is relevant to a
YANG instance file.
The reader code will simply attempt to read the file and fail if it
encounters
a format that is not implemented.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jul 2021 20:19:33 +0200

> a format that is not implemented.

I assumed that the features are carried in the instance file, i.e.,
the file declares that it uses way X to announce the schema and then
the parser can fail with a suitable error message. If the features are
not carried in the file, then they indeed seem to be useless.

Perhaps there are Y different ways to announce the features of the
instance file as well, I did not check. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Jul 2021 12:28:08 -0700

> instance file as well, I did not check. ;-)
Now you made re-read the entire draft :-(
I cannot find any text how the reader knows if this feature is set before
reading the
file and finding out.

I do not see any significant use-case for the Inline method and none for
the Uri method.
Nor do I see any reason why the Simplified-Inline method should not be
mandatory
to use and always present.

If the use-case is offline server validation then the YANG library details
need to be known.
The entire YANG library for the server (or relevant parts) are recorded in
the Inline method.
Except it is complicated to store the info about how to interpret YANG
schema by
reading instance files and guessing what the "anydata" contains.

I actually prefer a simple string based on RFC 6020 URI method, since it can
be easily integrated into the Simplified Inline form and can be parsed
without guessing
anything about the contents of anydata.

https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4

e,g,

OLD:
         case simplified-inline {
               leaf-list module {
                  type module-with-revision-date;
                  ...
                }
          }

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {
                       type module-with-revision-date;
                       type string;
                   }
                   ...
                }
          }

Example module leaf-list entry:

 ietf-interfaces?revision=2018-02-20&features=if-mib,arbitrary-names&deviations=acme-deviations

IMO Simplified Inline SHOULD be the only format, and the other methods can
be removed.

/js

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 7 Jul 2021 07:49:08 +0000

Hello Rob,
I would be happy to simplify the draft. Just we are restarting debates which
were settled earlier. This can lead to a never-ending cycle.

So, I propose to:
- remove all mention of the revision-label
- remove the feature
- for the inline method allow just ietf-yang-library@2019-01-04 as a
_single_ file. This also means that I should remove the leaf inline-module
as there is no need for it anymore. We know the single YANG module it would
define.
Is that acceptable?
Regards Balazs

P.S. The feature was possible to use. 
It could be read from " out-of-band documentation" As indicated in the YANG
module. For some use-cases (E.g. Use Case 2: Preloading Data) when the
operator/designer is sending data to the server (not receiving it), it is
useful to know whether the inline method is supported or not.

In case the file comes from the server the feature is less useful.

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2021. július 6., kedd 17:15
To: Balázs Lengyel <[email-masked]>; [email-masked]'
<[email-masked]>; [email-masked]; Juergen Schoenwaelder
<[email-masked]>
Cc: Benoit Claise <[email-masked]>
Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Balazs,

I think that my comment regarding the "feature statement" and the
flexibility of the inline-method are closely related.  I find the definition
of the inline-content-schema to be so generic that it effectively allows
anything.  E.g., the drafts would allow me to publish a file that has an
inline-content-schema based on [email-masked], and it would
be very difficult for consumers of the associated instance data file to
understand the file schema.

Hence, my preference, for this RFC, that defines version 1 of the instance
file format, would be to more heavily constrain how the schema is allowed to
be specified in the inline-method.  Specifically, I think that it would be
better to:
 - restrict the inline schema to only be defined using
ietf-yang-library@2019-01-04
 - only allow revision-dates, not revision labels.

If/when the revision labels draft gets standardized, and perhaps also after
YANG packages, then we could do a bis version of this document to define a
v2 of the instance file format that potentially allows YANG packages to be
used to define the schema, and potentially allows modules to be identified
using revision labels as well as revision dates.

Balazs, I'm good with most of your proposed resolutions, but have answered
one further question inline below.

> Thanks for the review.  Here are my answers below. I will also upload 
> the new version asap.
> Regards Balazs
> Thanks for this document, I think that it represents important useful 
> work for advancing the YANG ecosystem.
> 
> This document is in good shape, and I mostly have minor comments but 
> with a few more significant comments.
> 
> Main comments:
> 

> What is the benefit of having 'inline-content-schema' as a feature?  
> It seems to potentially add complexity without any benefit, given that 
> the device originating the instance data file would effectively choose 
> whether to use the inline-content-schema, hence I suggest that it 
> might be simpler just to remove the feature definition.
> In a use-case when a client or a design department is sending data to 
> a server this is needed. E.g. in UC2, Preloading Default Configuration 
> the designer preparing instance data, can decide to use or not use the 

> This seems to make interop for consumers of instance data files hard, 
> since the schema can be defined by any arbitrary YANG module without 
> updating this module.  I would suggest that it is safer to limit this 
> to the two currently published versions of YANG library.
> If additional modules are supported in future, then I think that it 
> would be safer to create a new version of this YANG module that 
> documents what other module formats can be used.
> 
> 
> 4.
> In the YANG Module:
> 	list "revision"
> 
> BALAZS: I don't think I understand your comment. There may be multiple 
> list entries for revision. The 'leaf date' is a key, so it is inherently
unique.

For every published editorial change, a new one SHOULD be added  in front of
the revisions sequence so that all

to:

For every published editorial change, a new unique revision SHOULD be added
in front of the revisions sequence so that all

I.e., to also make it clear in the description that revisions dates are
required to be unique.

> timestamp?  If so, is there any constraints on the values.  If not, 
> then would it make sense to put them under a choice?
> BALAZS:  It is allowed to have both. There is some recommendation text 
> about when to use each. However I can see some corner cases, when 
> using both in the same file would be useful, E.g. we want a timestamp 
> including hour, minutes, but we also want the history of the instance 
> data set, including multible revision/descriptions.

Okay.

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 7 Jul 2021 08:00:59 +0000

Hello Andy,

There are many different use-cases for instance-data-files, each with slightly different requirements. 

Inline method is needed, if you want to indicate that the file was generated by someone who uses some YANG modules with deviations and some features are not-supported. There is no way to indicate feature-support and deviations with the simplified-inline method.

The URL method was requested for the use-case when you generate instance-data-sets repeatedly e.g. every minute with the same schema. You don’t want to include the content-schema in every file, so you just include a single URL reference. (Note the content schema may be a longer piece of text, not just a single YANG module+revision)

Regards Balazs

From: Andy Bierman <[email-masked]> 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder <[email-masked]>; Andy Bierman <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Balázs Lengyel <[email-masked]>; [email-masked]; Benoit Claise <[email-masked]>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> [email-masked] <mailto:[email-masked]> > wrote:
> 

I cannot find any text how the reader knows if this feature is set before reading the

file and finding out.

I do not see any significant use-case for the Inline method and none for the Uri method.

Nor do I see any reason why the Simplified-Inline method should not be mandatory

If the use-case is offline server validation then the YANG library details need to be known.

The entire YANG library for the server (or relevant parts) are recorded in the Inline method.

Except it is complicated to store the info about how to interpret YANG schema by

be easily integrated into the Simplified Inline form and can be parsed without guessing

e,g,

OLD:

         case simplified-inline {
               leaf-list module {

                  ...

                }

          }

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {

                       type string;

                   }

                   ...

                }

          }

 

IMO Simplified Inline SHOULD be the only format, and the other methods can be removed.

/js

Andy

-- 
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/ <https://protect2.fireeye.com/v1/url?k=1b82dc7c-4419e639-1b829ce7-867b36d1634c-3d395fcf11781013&q=1&e=ce6dbbb8-8693-4ac8-abbf-4a2014b77b32&u=https%3A%2F%2Fwww.jacobs-university.de%2F> >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 7 Jul 2021 09:02:12 +0000

Hi Balazs, Netmod WG,

Yes, broadly that would be acceptable to me. I would actually suggest keeping the "inline-module" leaf, since I think that makes it easier to extend the format in future and I think that it makes the file a bit more explicit/readable, but don't feel strongly on this latter point, so happy to leave this to the authors discretion.

I do understand Andy's point that having a single method of defining the schema makes interop easier, but I agree with your comment as for there being valid reasons why supporting these different formats is useful for the different use cases, and with the simplification of the inline schema method, I don't see supporting any of the defined schema options as being particularly hard to implement (i.e., beyond what is required to reading/understanding YANG library anyway).

As for the feature statement, I think that when it specified that it has to be communicated via "out-of-band documentation" then it doesn't seem to hold that much value.  E.g., it is probably just as easy for the out of band documentation to say that the provided file must use the simplified-inline schema definition, as it is to say the server doesn't support the inline-content-schema feature.

Given that there was WG consensus for defining 4 different schema encoding methods before, then does anyone in the WG strongly object to the changes that Balazs has proposed below?

Regards,
Rob

> Sent: 07 July 2021 08:49
> To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]'

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jul 2021 11:12:06 -0700

> slightly different requirements.

I don't agree that the solution requires 3 ways to do the same thing.
Well, 4 if you count External which means Proprietary and Not Standard At
All.

Inline method is needed, if you want to indicate that the file was
> generated by someone who uses some YANG modules with deviations and some
> features are not-supported. There is no way to indicate feature-support and
> deviations with the simplified-inline method.
>
>
>

The Inline anydata solution is very heavyweight.
Before the YANG library there was a simple URI that is easier to use
and takes up much less storage.

> The URL method was requested for the use-case when you generate
> instance-data-sets repeatedly e.g. every minute with the same schema. You
> don’t want to include the content-schema in every file, so you just include
> a single URL reference. (Note the content schema may be a longer piece of
> text, not just a single YANG module+revision)
>

The solution is very complex and it will not get implemented correctly, or
at all.
IMO this damages interoperability and prevents some companies from using
the solution
at all, because a reader tool has so much complexity to implement.  The
real-world result
will be tools that can only read the files they wrote (not written by
another tool).

Regards Balazs

Andy

> *From:* Andy Bierman <[email-masked]>
> *Sent:* 2021. július 6., kedd 21:28
> *To:* Juergen Schoenwaelder <[email-masked]>; Andy
> Bierman <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>;
> Balázs Lengyel <[email-masked]>; [email-masked]; Benoit
> Claise <[email-masked]>
> *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
>
>
>
>
>
>
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
> <https://protect2.fireeye.com/v1/url?k=1b82dc7c-4419e639-1b829ce7-867b36d1634c-3d395fcf11781013&q=1&e=ce6dbbb8-8693-4ac8-abbf-4a2014b77b32&u=https%3A%2F%2Fwww.jacobs-university.de%2F>
> >
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jul 2021 11:49:52 -0700

Hi,

I have some questions about the same-schema-as-file leaf:

       leaf same-schema-as-file {
             type inet:uri;
             description
               "A reference to another YANG instance data file.
                This instance data file uses the same
                content schema as the referenced file.";
           }

The type is an unconstrained URI.
Is this the intent?
The tool that writes the file can pick any scheme - any valid URI at all.
The reader must support every known URI scheme in existence? Is that the
intent here?

Sec. 4 contains this line:

    The header part is not security sensitive.

Is this really true if a URI is present in this leaf that contains a
username and password
in cleartext?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jul 2021 21:25:34 +0200

> and takes up much less storage.

The inline content schema is super generic since it supports an open
ended set of schema defining modules. While you can use it with say
ietf-yang-library@2019-01-04, you can use anything else as well. In
other words, two implementations supporting inline content schema may
not interoperate. I do not think there is a schema format that is
mandatory to implement for inline content schema.

So here is my assessment of what we have in terms of interoperability:

- Simplified-Inline comes with notable restrictions, interoperable
- Inline is an open ended content schema, not necessarily interoperable
- URI method pushes the problem to another instance file, interoperable
- External is by desing not interoperable

On the server side, we have YANG Library. Perhaps RFC 8525 has some
complexity that is useful for supporting large servers with multiple
datastores and not needed for small instance files (I understand that
an instance file is always tied to a single datastore?).

To me, it feels that reusing RFC 8525 design is actually a good
thing. Being able to dump a live server datastore into an instance
file seems like a very valid use case to me and ideally this is
possible without having to rewrite the schema part. Well, you could go
and trim unused datastore schemas and from there unused module sets
etc but that can all be done by an external tool trimming the schema
part, i.e., it does not need to be done by a tool that just dumps a
server datastore.

What is the actual value of simplified inline? How much do you really
save compared to the simplest equivalent RFC 8525 representation? And
does that saving justify to start engineering another schema
specification format?

I guess my choice would have been to just have

       +-- content-schema
       |  +-- (content-schema-spec)?
       |     +--: (yang-library)
       |     +--: (uri)

but others obviously want much more choice (but lets note that
everything sits in a choice, so everything is extensible in case
other schema definition formats are out there).

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 8 Jul 2021 09:10:47 +0000

Hello,

*	Inline is needed because you might want to specify dozens of YANG modules with all their features and deviations. That is a lot of information,  so yes it will take some effort to read and understand it; real life nodes do contain many YAMs, features, deviations. 
*	Simplified-inline is needed, because it is self-contained and often an instance data set only contains info for 1 or 2 YANG modules without deviations or feature issues
*	URL is required because it is self-describing at least via reference. It might describe big, complicated schemas with a single URI. Most useful when many files with the same complex schema are processed. 
*	External method is needed because in many environments the schema is already known, so it does not need to be included

The workgroup has agreed that all 4 methods are needed for some use-cases. We can restart that debate, but I hope not.

Regards Balazs

From: Andy Bierman <[email-masked]> 
Sent: 2021. július 7., szerda 20:12
To: Balázs Lengyel <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]; Benoit Claise <[email-masked]>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

Hello Andy,

 

Well, 4 if you count External which means Proprietary and Not Standard At All.

 

 

The solution is very complex and it will not get implemented correctly, or at all.

IMO this damages interoperability and prevents some companies from using the solution

at all, because a reader tool has so much complexity to implement.  The real-world result

will be tools that can only read the files they wrote (not written by another tool).

Regards Balazs

Andy

From: Andy Bierman <[email-masked] <mailto:[email-masked]> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> >; Andy Bierman <[email-masked] <mailto:[email-masked]> >; Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]> >; Balázs Lengyel <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Benoit Claise <[email-masked] <mailto:[email-masked]> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

file and finding out.

e,g,

OLD:

         case simplified-inline {
               leaf-list module {

                  ...

                }

          }

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {

                       type string;

                   }

                   ...

                }

          }

 

 

/js

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 8 Jul 2021 09:17:01 +0000

See inline, Balazs

Sent: 2021. július 7., szerda 20:50

Hi,

Is this the intent?

The reader must support every known URI scheme in existence? Is that the intent here?

BALAZS: As the number of URI schemes is growing with new URI schemes introduced from time to time, that is clearly impossible. On the other hand, we don’t want to constrain URI schemes. This draft is not about selecting the best URI schemes for referencing a file, it only about providing a common format for metadata about instance files. The set of usable/used URI schemes will have to be communicated using some other method. You could ask a similar question: does a Netconf client need to be prepared for any YANG model? No just for the ones he is interested in.

Is this really true if a URI is present in this leaf that contains a username and password

in cleartext? 

BALAZS: Clear text passwords are not the intention. Shall I  add a statement about this to the security considerations?

Andy

Hello Andy,

Regards Balazs

 

file and finding out.

e,g,

OLD:

         case simplified-inline {
               leaf-list module {

                  ...

                }

          }

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {

                       type string;

                   }

                   ...

                }

          }

 

 

/js

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 8 Jul 2021 09:27:52 +0000

Hello Jurgen,
Inline:
This complex form of inline was requested and not objected earlier by other
reviewers. 
Based on Rob's and others' proposal inline will be simplified to use only
ietf-yang-library@2019-01-04 as you suggest.

Simplified inline:
In Ericsson we already use simplified inline a lot, it is the most common
format. 
If you are providing data only for one or a few YANG modules and don't have,

don't care about features/deviations it is the easiest, shortest method to
use.
 Our most common use-case is to provide preconfigured access control rules
for new nodes. 
When a YANG modeler designs a new module, he immediately provides a set of
NACM rules 
for the readOnly and the SystemAdmin roles/groups.
In this case you only need to specify "ietf-neconf-acm@2012-02-22" No
deviations, no features to indicate.
Regards Balazs

Regards Balazs

-----Original Message-----
From: Juergen Schoenwaelder <[email-masked]> 
Sent: 2021. július 7., szerda 21:26
To: Andy Bierman <[email-masked]>
Cc: Balázs Lengyel <[email-masked]>; Rob Wilton (rwilton)
<[email-masked]>; [email-masked]; Benoit Claise
<[email-masked]>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> > generated by someone who uses some YANG modules with deviations and 
> > some features are not-supported. There is no way to indicate 
> > feature-support and deviations with the simplified-inline method.
> 

The inline content schema is super generic since it supports an open ended
set of schema defining modules. While you can use it with say
ietf-yang-library@2019-01-04, you can use anything else as well. In other
words, two implementations supporting inline content schema may not
interoperate. I do not think there is a schema format that is mandatory to
implement for inline content schema.

On the server side, we have YANG Library. Perhaps RFC 8525 has some
complexity that is useful for supporting large servers with multiple
datastores and not needed for small instance files (I understand that an
instance file is always tied to a single datastore?).

To me, it feels that reusing RFC 8525 design is actually a good thing. Being
able to dump a live server datastore into an instance file seems like a very
valid use case to me and ideally this is possible without having to rewrite
the schema part. Well, you could go and trim unused datastore schemas and
from there unused module sets etc but that can all be done by an external
tool trimming the schema part, i.e., it does not need to be done by a tool
that just dumps a server datastore.

What is the actual value of simplified inline? How much do you really save
compared to the simplest equivalent RFC 8525 representation? And does that
saving justify to start engineering another schema specification format?

       +-- content-schema

but others obviously want much more choice (but lets note that everything
sits in a choice, so everything is extensible in case other schema
definition formats are out there).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103
<https://protect2.fireeye.com/v1/url?k=fe85c8e6-a11ef1cd-fe85887d-866038973a
15-19e5dad375af0063&q=1&e=3637406d-f774-4073-80ee-a7431111e9bc&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Jul 2021 09:30:27 +0000

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.

Regards,
Rob

Sent: 08 July 2021 10:17

See inline, Balazs

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 2021. július 7., szerda 20:50
To: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Cc: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Benoit Claise <[email-masked]<mailto:[email-masked]>>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

Hi,

Andy

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:
Hello Andy,
There are many different use-cases for instance-data-files, each with slightly different requirements.

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Balázs Lengyel <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Benoit Claise <[email-masked]<mailto:[email-masked]>>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> [email-masked]<mailto:[email-masked]>> wrote:
>

e,g,

OLD:
         case simplified-inline {
               leaf-list module {

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {

/js

Andy

--
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/<https://protect2.fireeye.com/v1/url?k=1b82dc7c-4419e639-1b829ce7-867b36d1634c-3d395fcf11781013&q=1&e=ce6dbbb8-8693-4ac8-abbf-4a2014b77b32&u=https%3A%2F%2Fwww.jacobs-university.de%2F>>

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 8 Jul 2021 09:59:18 +0000

A sentence about the security risk of a username/password in the URI will be added to the security considerations.

Balazs

From: netmod <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 2021. július 8., csütörtök 11:17
To: Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

See inline, Balazs

From: Andy Bierman <[email-masked] <mailto:[email-masked]> > 
Sent: 2021. július 7., szerda 20:50
To: Balázs Lengyel <[email-masked] <mailto:[email-masked]> >
Cc: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> >; Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Benoit Claise <[email-masked] <mailto:[email-masked]> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

Hi,

Is this the intent?

in cleartext? 

Andy

Hello Andy,

Regards Balazs

 

file and finding out.

e,g,

OLD:

         case simplified-inline {
               leaf-list module {

                  ...

                }

          }

NEW:

         case simplified-inline {
               leaf-list module {
                  type union {

                       type string;

                   }

                   ...

                }

          }

 

 

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jul 2021 12:13:26 +0200

> 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 wo…

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.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Jul 2021 10:25:46 +0000

Yes, I would be okay with that too.

Regards,
Rob

> Sent: 08 July 2021 11:13
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Balázs Lengyel <[email-masked]>; Andy Bierman
> <[email-masked]>; [email-masked]; Benoit Claise
> > 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.
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jul 2021 12:35:28 +0200

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):

<yang-library>
  <module-set>
    <name>m</name>
    <module>
      <name>ietf-netconf-acm</name>
      <revision>2018-02-14</revision>
      <namespace>uri1</namespace>
    </module>
    <import-only-module>
      <name>ietf-yang-types</name>
      <namespace>uri2</namespace>
      <revision/>
    </import-only-module>
  </module-set>
  <schema>
    <name>s</name>
    <module-set>m</module-set>
  </schema>
  <datastore>
    <name>running</name>
    <schema>s</schema>
  </datastore>
</yang-library>

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Jul 2021 10:58:37 +0000

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

> Sent: 08 July 2021 11:35
> Cc: Andy Bierman <[email-masked]>; Rob Wilton (rwilton)

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 8 Jul 2021 11:47:32 +0000

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.
 
<module>ietf-netconf-acm@2018-02-14<module>

OR

<yang-library>
  <module-set>
    <name>m</name>
    <module>

Regards Balazs

-----Original Message-----
From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2021. július 8., csütörtök 12:59
To: Juergen Schoenwaelder <[email-masked]>; Balázs
Lengyel <[email-masked]>
Cc: Andy Bierman <[email-masked]>; [email-masked]; Benoit Claise
<[email-masked]>
Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Juergen,

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

> > This complex form of inline was requested and not objected earlier 
> > by
> other
> > reviewers.
> > In Ericsson we already use simplified inline a lot, it is the most 
> > common format.
> > If you are providing data only for one or a few YANG modules and 
> > don't
> have,
> >
> > don't care about features/deviations it is the easiest, shortest 
> > method to use.
> > In this case you only need to specify "ietf-neconf-acm@2012-02-22" 
> > No deviations, no features to indicate.
> > Regards Balazs
> >
> > Regards Balazs
> >
> > Cc: Balázs Lengyel <[email-masked]>; Rob Wilton 
> > (rwilton) <[email-masked]>; [email-masked]; Benoit Claise 
> > Subject: Re: AD review of 
> > draft-ietf-netmod-yang-instance-file-format
> >
> > > > Inline method is needed, if you want to indicate that the file 
> > > > was generated by someone who uses some YANG modules with 
> > > > deviations
> and
> > > Before the YANG library there was a simple URI that is easier to 
> > > use and takes up much less storage.
> > >
> >
> > other words, two implementations supporting inline content schema 
> > may not interoperate. I do not think there is a schema format that 
> > is mandatory to implement for inline content schema.
> >
> > datastores and not needed for small instance files (I understand 
> > that an instance file is always tied to a single datastore?).
> >
> > possible without having to rewrite the schema part. Well, you could 
> > go and trim unused datastore schemas
> and
> > from there unused module sets etc but that can all be done by an 
> > external tool trimming the schema part, i.e., it does not need to be 
> > done by a tool that just dumps a server datastore.
> >
> > What is the actual value of simplified inline? How much do you 
> > really save compared to the simplest equivalent RFC 8525 
> > representation? And does
> that
<https://protect2.fireeye.com/v1/url?k=7edafb8e-2141c2bf-7edabb15-86e2237f51
fb-eceadf4f1dc08461&q=1&e=09140141-b70c-44c9-9909-048d736efebf&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jul 2021 14:33:16 +0200

> 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 d…

A tool that does something useful, such as checking an instance file
against a schema, likely needs to have more information than just a
module name with a revision identifier to do the job well. Anyway, if
people feel strongly that this optimization is essential, I will shut
up and watch what happens to this over time. ;-)

> 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 tho…

Once there are YANG packages and there is a new way to describe a
schema, you likely want to augment in a new choice. So I am not
convinced by this argument.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Jul 2021 13:49:01 +0000

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

> Sent: 08 July 2021 12:48
> To: Rob Wilton (rwilton) <[email-masked]>; Juergen Schoenwaelder

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jul 2021 09:54:43 -0700

> 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.

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).

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.

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

> 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
>
>
> common
> method to
> ended
> an
> external
> save
> everything

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jul 2021 13:37:55 -0700

> 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 <hello> 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,

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 9 Jul 2021 07:24:52 +0000

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) <[email-masked]> 
Sent: 2021. július 8., csütörtök 15:49
To: Balázs Lengyel <[email-masked]>; Juergen Schoenwaelder

Hi Balazs,

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

E.g., should it be:

Thanks,
Rob

> 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.
> 
> To: Juergen Schoenwaelder <[email-masked]>; 
> Balázs Lengyel <[email-masked]>
> 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.
> 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
> 
> 
> > justify the introduction of a new rather limited format (that may 
> > risk to grow over time and become a second citizen)".
> >
> > roughly look this (please correct what I messed up, I am writing 
> > this by hand):
> >
> > <yang-library>
> >   <module-set>
> >     <name>m</name>
> >     <module>
> > 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
> >
> > >  Our most common use-case is to provide preconfigured access 
> > > control
> > rules
> > > for new nodes.
> > > When a YANG modeler designs a new module, he immediately provides 
> > > a
> > set of
> > > NACM rules
> > > The inline content schema is super generic since it supports an 
> > > open ended set of schema defining modules. While you can use it 
> > > with say ietf-yang-library@2019-01-04, you can use anything else 
> > > as well. In other words, two implementations supporting inline 
> > > content schema may not interoperate. I do not think there is a 
> > > schema format that is mandatory to implement for inline content
schema.
> > > On the server side, we have YANG Library. Perhaps RFC 8525 has 
> > > some complexity that is useful for supporting large servers with 
> > > multiple datastores and not needed for small instance files (I 
> > > understand that an instance file is always tied to a single
datastore?).
> > > possible without having to rewrite the schema part. Well, you 
> > > could go and trim unused datastore schemas
> > and
> > > external tool trimming the schema part, i.e., it does not need to 
> > > be done by a tool that just dumps a server datastore.
> > >

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 9 Jul 2021 07:38:53 +0000

Hello Andy,

See below.

Balazs

From: Andy Bierman <[email-masked]> 
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; Balázs Lengyel <[email-masked]>; [email-masked]; Benoit Claise <[email-masked]>
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Juergen,

 

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

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

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

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.

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

 

Regards,
Rob

> From: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> >
> Sent: 08 July 2021 11:35
> Cc: Andy Bierman <[email-masked] <mailto:[email-masked]> >; Rob Wilton (rwilton)
> <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Benoit Claise
> <[email-masked] <mailto:[email-masked]> >
> > From: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> >
> > To: Andy Bierman <[email-masked] <mailto:[email-masked]> >
> > Cc: Balázs Lengyel <[email-masked] <mailto:[email-masked]> >; Rob Wilton (rwilton)
> > <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Benoit Claise
> > <[email-masked] <mailto:[email-masked]> >
> > %2Fwww.jacobs-university.de <https://protect2.fireeye.com/v1/url?k=fe25a02c-a1be992c-fe25e0b7-86fc6812c361-d087929e1674b3a3&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=http%3A%2F%2F2fwww.jacobs-university.de%2F> %2F>
> 
> 
> 
> --
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://protect2.fireeye.com/v1/url?k=ebc4e571-b45fdc71-ebc4a5ea-86fc6812c361-21325e0a2fa737df&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=https%3A%2F%2Fwww.jacobs-university.de%2F> >

---

From: tom petch <[email-masked]>
Date: Fri, 9 Jul 2021 08:57:34 +0000

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 08 July 2021 11:13

<tp>
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

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 9 Jul 2021 08:58:11 +0000

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 <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 2021. július 9., péntek 9:39
To: Andy Bierman <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

Hello Andy,

See below.

Balazs

From: Andy Bierman <[email-masked] <mailto:[email-masked]> > 
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]> >
Cc: Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> >; Balázs Lengyel <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Benoit Claise <[email-masked] <mailto:[email-masked]> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Juergen,

 

 

Andy

 

Regards,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 9 Jul 2021 08:59:38 +0000

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

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of tom petch
Sent: 2021. július 9., péntek 10:58
To: Rob Wilton (rwilton) <[email-masked]>; Juergen Schoenwaelder
<[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] AD review of
draft-ietf-netmod-yang-instance-file-format

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder
<[email-masked]>
Sent: 08 July 2021 11:13

>
> 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.

<tp>
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
<https://protect2.fireeye.com/v1/url?k=1331221a-4caa185f-13316281-867b36d163
4c-8ea285db675ba1d4&q=1&e=efba30f7-bcd0-4939-aca8-b110f4ee6fd0&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 9 Jul 2021 09:10:34 +0000

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

> Sent: 09 July 2021 08:25

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 9 Jul 2021 09:21:31 +0000

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:
<module>Ietf-yang-packages@...</module<mailto:Ietf-yang-packages@...%3c/module>>
<module>foo-yang-pkg-augmentations@...</module<mailto:foo-yang-pkg-augmentations@...%3c/module>>
<content-data>
// Content data contains base package information and extra data that conforms to the additional schema elements defined by foo augmentations.
</content-data>

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

Regards,
Rob

Sent: 08 July 2021 21:38

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Juergen,

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 <hello> 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

> From: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
> Sent: 08 July 2021 11:35
> Cc: Andy Bierman <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton)
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Benoit Claise
> <[email-masked]<mailto:[email-masked]>>
> > From: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
> > To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
> > Cc: Balázs Lengyel <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton)
> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Benoit Claise
> > <[email-masked]<mailto:[email-masked]>>
> > %2Fwww.jacobs-university.de<http://2Fwww.jacobs-university.de>%2F>
>
>
>
> --

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Jul 2021 03:39:23 -0700

>             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 <[email-masked]> *On Behalf Of *Balázs Lengyel
> *Sent:* 2021. július 9., péntek 9:39
> *To:* Andy Bierman <[email-masked]>; Rob Wilton (rwilton) <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] AD review of
> *Sent:* 2021. július 8., csütörtök 18:55
> *To:* Rob Wilton (rwilton) <[email-masked]>
> *Cc:* Juergen Schoenwaelder <[email-masked]>;
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>
>
>
>
>
>
>
> > > %2Fwww.jacobs-university.de
> <https://protect2.fireeye.com/v1/url?k=fe25a02c-a1be992c-fe25e0b7-86fc6812c361-d087929e1674b3a3&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=http%3A%2F%2F2fwww.jacobs-university.de%2F>
> %2F>
> >
> >
> >
> > --
> <https://protect2.fireeye.com/v1/url?k=ebc4e571-b45fdc71-ebc4a5ea-86fc6812c361-21325e0a2fa737df&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=https%3A%2F%2Fwww.jacobs-university.de%2F>
> >
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jul 2021 13:49:39 +0200

> "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 version…

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jul 2021 14:01:13 +0200

> 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…

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

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 9 Jul 2021 12:25:40 +0000

Juergen,

Yes, I agree that is a better phrasing.

Thanks for suggesting it.
Rob

> Sent: 09 July 2021 12:50
> > "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."
> >
>