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

[Rob Wilton (rwilton)]

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 robs-random-schema-format@1.0.0, 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 
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org' ; Rob Wilton (rwilton)
> 
> Cc: Benoit Claise 
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> 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:
> 

> 
> 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"
> 
> I

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

[Andy Bierman]

On Tue, Jul 6, 2021 at 8:14 AM Rob Wilton (rwilton) 
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
> robs-random-schema-format@1.0.0, 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?
>


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.
>
> Balazs, I'm good with most of your proposed resolutions, but have answered
> one further question inline below.
>
>
> > -Original Message-
> > From: Balázs Lengyel 
> > Sent: 05 July 2021 13:47
> > To: 'netmod@ietf.org' ; Rob Wilton (rwilton)
> > 
> > Cc: Benoit Claise 
> > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > 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:
> >
>
> >
> > 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 s

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

[Juergen Schoenwaelder]

On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> 
> 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.
>

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 

___
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 Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> >
> > 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.
> >
>
> 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.
>
>

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


>
> --
> 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 Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
> 
> 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.

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

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

[Andy Bierman]

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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.
> > >
> > >
> >
> > 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.
>
> 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. ;-)
>
>
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



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

[Balázs Lengyel]

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)  
Sent: 2021. július 6., kedd 17:15
To: Balázs Lengyel ; 'netmod@ietf.org'
; a...@yumaworks.com; Juergen Schoenwaelder

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

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 robs-random-schema-format@1.0.0, 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 
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org' ; Rob Wilton (rwilton) 
> 
> Cc: Benoit Claise 
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> 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:
> 

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

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

[Balázs Lengyel]

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  
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder ; Andy Bierman 
; Rob Wilton (rwilton) ; Balázs Lengyel 
; netmod@ietf.org; Benoit Claise 

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

 

 

 

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
>  > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
> 
> 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.

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

 

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

 

 


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
 >

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

[Rob Wilton (rwilton)]

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


> -Original Message-
> From: Balázs Lengyel 
> Sent: 07 July 2021 08:49
> To: Rob Wilton (rwilton) ; 'netmod@ietf.org'
> ; a...@yumaworks.com; Juergen Schoenwaelder
> 
> Cc: Benoit Claise 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> 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) 
> Sent: 2021. július 6., kedd 17:15
> To: Balázs Lengyel ; 'netmod@ietf.org'
> ; a...@yumaworks.com; Juergen Schoenwaelder
> 
> Cc: Benoit Claise 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> 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 robs-random-schema-format@1.0.0, 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---

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

[Andy Bierman]

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel 
wrote:

> Hello Andy,
>
> There are many different use-cases for instance-data-files, each with
> 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 
> *Sent:* 2021. július 6., kedd 21:28
> *To:* Juergen Schoenwaelder ; Andy
> Bierman ; Rob Wilton (rwilton) ;
> Balázs Lengyel ; netmod@ietf.org; Benoit
> Claise 
> *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
>
>
>
>
>
>
> On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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.
> > >
> > >
> >
> > 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.
>
> 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. ;-)
>
>
>
> 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-

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

[Andy Bierman]

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


On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel 
wrote:

> 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 
> *Sent:* 2021. július 6., kedd 21:28
> *To:* Juergen Schoenwaelder ; Andy
> Bierman ; Rob Wilton (rwilton) ;
> Balázs Lengyel ; netmod@ietf.org; Benoit
> Claise 
> *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
>
>
>
>
>
>
> On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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.
> > >
> > >
> >
> > 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.
>
> 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. ;-)
>
>
>
> 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;
>
>   ...
>
> }
>
>

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

[Juergen Schoenwaelder]

On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> 
> > 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 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

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

[Balázs Lengyel]

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  
Sent: 2021. július 7., szerda 20:12
To: Balázs Lengyel 
Cc: Juergen Schoenwaelder ; Rob Wilton 
(rwilton) ; netmod@ietf.org; Benoit Claise 

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

 

 

 

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

There are many different use-cases for instance-data-files, each with 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 mailto:a...@yumaworks.com> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman 
mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com> >; 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 Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
>  > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
> 
> 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.

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

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

[Balázs Lengyel]

See inline, Balazs

 

From: Andy Bierman  
Sent: 2021. július 7., szerda 20:50
To: Balázs Lengyel 
Cc: Juergen Schoenwaelder ; Rob Wilton 
(rwilton) ; netmod@ietf.org; Benoit Claise 

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

 

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?

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.

 

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? 

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

 

Andy

 

 

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

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 mailto:a...@yumaworks.com> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman 
mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com> >; 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 Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
>  > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
> 
> 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.

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

 

Now you made re-read the entire draft :-(

I cannot find an

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

[Balázs Lengyel]

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  
Sent: 2021. július 7., szerda 21:26
To: Andy Bierman 
Cc: Balázs Lengyel ; Rob Wilton (rwilton)
; netmod@ietf.org; Benoit Claise

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103



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

[Rob Wilton (rwilton)]

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


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

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

See inline, Balazs

From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 2021. július 7., szerda 20:50
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 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

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

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?
BALAZS: Clear text passwords are not the intention. Shall I  add a statement 
about this to the security considerations?

Andy


On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
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 mailto:a...@yumaworks.com>>
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Andy Bierman mailto:a...@yumaworks.com>>; Rob Wilton 
(rwilton) mailto:rwil...@cisco.com>>; 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 Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>
>  wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
>
> This is a text file st

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

[Balázs Lengyel]

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

Balazs

 

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

 

See inline, Balazs

 

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

 

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?

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.

 

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? 

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

 

Andy

 

 

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

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 mailto:a...@yumaworks.com> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman 
mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >; 
netmod@ietf.org <mailto:netmod@ietf.org> ; Benoit Claise 
mailto:benoit.cla...@huawei.com> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
> <mailto:j.schoenwael...@jacobs-university.de> > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > 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.
> > >
> >
> > 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.
> >
> >
> 
> This is a text file stored on a USB stick.
> There is no client or server. Just readers and writer

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

[Juergen Schoenwaelder]

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.

/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

[Rob Wilton (rwilton)]

Yes, I would be okay with that too.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 08 July 2021 11:13
> 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 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.
> 
> /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]

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 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  
> Sent: 2021. július 7., szerda 21:26
> To: Andy Bierman 
> Cc: Balázs Lengyel ; Rob Wilton (rwilton)
> ; netmod@ietf.org; Benoit Claise
> 
> 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:
> > 
> > > 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 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
>  

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

[Rob Wilton (rwilton)]

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 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 
> > Sent: 2021. július 7., szerda 21:26
> > To: Andy Bierman 
> > Cc: Balázs Lengyel ; Rob Wilton (rwilton)
> > ; netmod@ietf.org; Benoit Claise
> > 
> > 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:
> > >
> > > > 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 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

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

[Balázs Lengyel]

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 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 
> > Sent: 2021. július 7., szerda 21:26
> > To: Andy Bierman 
> > Cc: Balázs Lengyel ; Rob Wilton 
> > (rwilton) ; netmod@ietf.org; Benoit Claise 
> > 
> > Subject: Re: AD review of 
> > draft-ietf-netmod-yang-instance-file-format
> >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierm

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

[Juergen Schoenwaelder]

On Thu, Jul 08, 2021 at 10:58:37AM +, Rob Wilton (rwilton) 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.
>

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

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

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

[Rob Wilton (rwilton)]

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

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

[Andy Bierman]

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.

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


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

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

[Andy Bierman]

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

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 f

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 lat

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,

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 <mailto: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  <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> >;

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

___
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

[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

[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 defin

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 revi

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

[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