Re: [netmod] features in import

[Andy Bierman]

Hi,

I do not agree these changes should be made at this late date.
It seems to me that in order to support a feature you have to implement it,
and therefore if any features are set then the module is implemented, not
imported.
All features should be set to false in an import-only module.

IMO this interpretation holds for typedef modules like iana-crypt-hash.
We list that as implemented (because it is) and the features that are
supported are set.


Andy

On Wed, Jan 30, 2019 at 11:03 AM Martin Bjorklund  wrote:

> Hi,
>
> Ladislav Lhotka  wrote:
> > Hi,
> >
> > unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for
> > import-only modules. But is it really so that features have no use in
> > such modules?
> >
> > For example, an enum can depend on a feature, and if it is inside a
> > typedef, it can also be in an import-only module. What if that feature
> > is defined in the same module?
>
> I think you're right, and that this is an unfortunate omission.
>
> The fix is simple though; we would have to add the leaf-list features
> to import-only.  Probably refactor the "feature" leaf-list into a
> grouping so it works like the grouping location-leaf-list:
>
>   grouping feature-leaf-list {
> leaf-list feature {
>   type yang:yang-identifier;
>   description
> "List of all YANG feature names from this module that are
>  supported by the server, regardless whether they are defined
>  in the module or any included submodule.";
> }
>   }
>
> And then "uses feature-leaf-list":
>
> OLD:
>
>   grouping module-implementation-parameters {
> description
>   "Parameters for describing the implementation of a module.";
>
> leaf-list feature {
>   type yang:yang-identifier;
>   description
> "List of all YANG feature names from this module that are
>  supported by the server, regardless whether they are defined
>  in the module or any included submodule.";
> }
>
> NEW:
>
>   grouping module-implementation-parameters {
> description
>   "Parameters for describing the implementation of a module.";
>
> uses feature-leaf-list;
>
>
> And in the list "import-only":
>
> OLD:
>
>   uses location-leaf-list;
>
>   uses feature-leaf-list;
>
>
>
> /martin
>
> ___
> 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] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman]

On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton  wrote:

>
> On 30/01/2019 17:31, Andy Bierman wrote:
>
>
>
> On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton  wrote:
>
>>
>> On 30/01/2019 15:16, Andy Bierman wrote:
>>
>>
>>
>> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton  wrote:
>>
>>> Hi Andy,
>>>
>>> Thanks for the comments.
>>> On 30/01/2019 01:22, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I originally brought up this issue in July 2015
>>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>>>
>>> Yes.
>>>
>>> The solution I propose is different in the sense that it uses YANG
>>> instance data to define YANG packages rather than new YANG keywords.   I
>>> believe that this should make it a lower cost solution to define and
>>> implement.
>>>
>>>
>>>
>> I think yangvalidator.org has a better solution that does not change
>> YANG conformance.
>>
>> Do you mean that we can just use zip files with the list of modules?
>>
>
> I don't care about the solution details yet. They are 2nd order problems.
>
> Conformance means "what modules are required to be implemented together".
> It is not clear that this problem can be solved.  The augment-stmt defines
> implicit
> multi-module conformance.  I am not convinced that the extra work of
> defining package conformance
> is worth it.
>
> So, I'm not proposing backing any sort of package conformance into the
> language at all.  A package is just metadata that defines that a set of
> modules, at particular revisions/versions, work together and can represent
> part of a YANG schema.
>
> This is equivalent to
>  - how a zip file of YANG modules provided to yangvalidator would work.
>  - getting the contents of YANG library from a server (but a YANG packages
> soln can also work offline)
>  - fetching the modules from YANG catalog (if they have been labelled
> appropriately), although I'm not convinced that this universally works
> today.
>
>
This sort of metadata could be provided by module tags.
A vendor or SDO could define module-tags that represent packages.




> But in terms of the usability of YANG, I don't think that doing
> conformance only at the module level is really sufficient.  Clients need to
> be coding against sets of modules at particular versions that are known to
> work together, and known that multiple server vendors will implement.
>
> A pick and mix appropriate to module revisions doesn't seem to help anyone.
>
>
>
I get all the different components and variables one might have for a
package.
I am not as convinced (as in 2015) that standard packages could be simple
and widely deployed..
Now it seems vendors implement an ad-hoc subset + additions to everything.
It doesn't help to define a new package variant to match the vendor
implementation.
The YANG library can do that already.

You seem more optimistic than me that the industry is actually ready,
willing, and able
to implement standard YANG packages.




> The issue of what modules does vendor A implement is not a conformance
> problem.
> It is just more metadata and YANG Catalog is focused on providing that
> data.
>
> Does YANG catalog indicate the set of IETF modules that I would need to
> implement L2VPN services on a device?
>
>
This seems like a separate problem, but actually it can help by searching a
lot of known modules.
In order to know what vendor A, B, and C have in common, you need to get
the catalog info for each vendor.

Module tags can also solve this problem.


> Module tags could be used to do this (another packaging solution), but
> this would cause a proliferation of tags when it comes to versioning, since
> I don't think that you can cleanly bake semver into module tags.
>
>
>
> I don't really see how this helps.
>>
>> Consider:
>> - server vendor A, implements some subset of the OpenConfig YANG modules,
>> each at a particular version, along with some deviations and vendor
>> augmentations.
>> - server vendor B, implements the same subset of the OpenConfig YANG
>> modules, but at different versions, along with some deviations and vendor
>> augmentations.
>> - server vendor C, implements a slightly different set of the OpenConfig
>> YANG modules, but at different versions, along with some deviations and
>> vendor augmentations.
>>
>> As a client, how do I know what module versions to code against, when I
>> want to work with devices provided by all three vendors?
>>
>
>
> The vendors publish their implementation details on yangcatalog and you
> get the info
> and see what modules are in common.
>
> There are only market requirements determining what group of modules has
> to exist
> in an implementation.  It is not clear to me that formalizing these
> requirements
> is something the industry will do effectively.  Module tags already
> provide a way
> to conceptually group modules together.
>
> Seems like every vendor has openconfig, foo-openconfig, and
> foo-openconfig-deviations
> so that there are no agreed upon subsets. Even if openconfig had properly
> docu

Re: [netmod] features in import

[Martin Bjorklund]

Hi,

Ladislav Lhotka  wrote:
> Hi,
> 
> unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for
> import-only modules. But is it really so that features have no use in
> such modules?
> 
> For example, an enum can depend on a feature, and if it is inside a
> typedef, it can also be in an import-only module. What if that feature
> is defined in the same module?

I think you're right, and that this is an unfortunate omission.

The fix is simple though; we would have to add the leaf-list features
to import-only.  Probably refactor the "feature" leaf-list into a
grouping so it works like the grouping location-leaf-list:

  grouping feature-leaf-list {
leaf-list feature {
  type yang:yang-identifier;
  description
"List of all YANG feature names from this module that are
 supported by the server, regardless whether they are defined
 in the module or any included submodule.";
}
  }

And then "uses feature-leaf-list":

OLD:

  grouping module-implementation-parameters {
description
  "Parameters for describing the implementation of a module.";

leaf-list feature {
  type yang:yang-identifier;
  description
"List of all YANG feature names from this module that are
 supported by the server, regardless whether they are defined
 in the module or any included submodule.";
}

NEW:

  grouping module-implementation-parameters {
description
  "Parameters for describing the implementation of a module.";

uses feature-leaf-list;


And in the list "import-only":

OLD:

  uses location-leaf-list;

  uses feature-leaf-list;



/martin

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

Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-00

[Robert Wilton]

Hi Lada,

Thanks for the review and comments ...

I've added some thoughts inline ...

On 30/01/2019 14:50, Ladislav Lhotka wrote:

Hi,

I think it is a good start, here are my comments (some of them were
already raised by Jason):

- I like the fact that this work doesn't require any changes to YANG,
   except perhaps semver.


RW: OK.




- I think the augments to YANG library is a separate problem that should
   perhaps be addressed in a different document. Servers supporting
   multiple package revisions may not be that common.


RW:

I completely agree that servers supporting multiple package revisions 
may not be that common, and I agree that any specification on how a 
server could support multiple packages, and perform package selection 
should be in a separate draft.


But the YANG library augmentations aren't there only to support this use 
case.  My intention is to make it easier for devices to advertise a 
package representing what each datastore schema is rather than having to 
fetch the full contents of YANG library.


E.g. a server might implement 900+ modules/sub-modules for a given 
release.  Different hardware will mostly implement the same modules, but 
there might be some differences.  If bugs have been patched then there 
might be some differences.  I'm aiming for a solution where a client 
doesn't have to fetch the full list of YANG modules for each server to 
figure out the schema for the device, which is probably the same as 
another 1000 devices in the network.


Instead, I would like the vendor to publish a package for that 
particular release, with variants depending on the hardware.  The device 
can then advertise that it uses that base package, along with the small 
set of differences (e.g. due to bug fixes).





- I was expecting that a package could specify a range of revisions for
   some modules that may be used together with teh others. This doesn't
   seem to be the case. If so, it would be somewhat unwieldy because every
   combination of module revisions would require a separate package
   revision.


RW:

Yes, this is an interesting point.

My intention is that there is a roughly linear history of package 
versions.  E.g. if there was a package of all IETF modules, then every 
time a new version of an IETF module is published, the package 
definition would be updated to a new version that includes the new 
published module revision. I think that we need to try and somewhat 
constraint the versions of modules that can sensibly be used together.





- As Jason pointed out, there seems to be no use for the package
   namespace, as packages don't define any names on their own.


Yes, I will remove the text about namespaces.  Globally unique package 
names should be sufficient.





- I would also prefer mandatory-features to be bundled with each module.

- This draft nicely shows that there is really no need for any
   "yang-data" extensions. But I also don't see any benefit from using
   ietf-yang-instance-data in this case. It would IMO be perfectly fine
   to get rid of two levels of data hierarchy:

   { "ietf-yang-package:yang-package": {
   ...
 }
   }


That's an interesting point.  My thought is that all at rest YANG data 
would be encoded in YANG instance data documents to make them more 
easily machine parse-able.


Thanks,
Rob




Thanks, Lada




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

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Robert Wilton]

On 30/01/2019 17:31, Andy Bierman wrote:



On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton > wrote:



On 30/01/2019 15:16, Andy Bierman wrote:



On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton mailto:rwil...@cisco.com>> wrote:

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:

Hi,

I originally brought up this issue in July 2015
https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/


Yes.

The solution I propose is different in the sense that it uses
YANG instance data to define YANG packages rather than new
YANG keywords.   I believe that this should make it a lower
cost solution to define and implement.



I think yangvalidator.org  has a better
solution that does not change YANG conformance.


Do you mean that we can just use zip files with the list of modules?


I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.  The augment-stmt 
defines implicit
multi-module conformance.  I am not convinced that the extra work of 
defining package conformance

is worth it.


So, I'm not proposing backing any sort of package conformance into the 
language at all.  A package is just metadata that defines that a set of 
modules, at particular revisions/versions, work together and can 
represent part of a YANG schema.


This is equivalent to
 - how a zip file of YANG modules provided to yangvalidator would work.
 - getting the contents of YANG library from a server (but a YANG 
packages soln can also work offline)
 - fetching the modules from YANG catalog (if they have been labelled 
appropriately), although I'm not convinced that this universally works 
today.


But in terms of the usability of YANG, I don't think that doing 
conformance only at the module level is really sufficient. Clients need 
to be coding against sets of modules at particular versions that are 
known to work together, and known that multiple server vendors will 
implement.


A pick and mix appropriate to module revisions doesn't seem to help anyone.




The issue of what modules does vendor A implement is not a conformance 
problem.
It is just more metadata and YANG Catalog is focused on providing that 
data.


Does YANG catalog indicate the set of IETF modules that I would need to 
implement L2VPN services on a device?


Module tags could be used to do this (another packaging solution), but 
this would cause a proliferation of tags when it comes to versioning, 
since I don't think that you can cleanly bake semver into module tags.





I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG
modules, each at a particular version, along with some deviations
and vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig
YANG modules, but at different versions, along with some
deviations and vendor augmentations.
- server vendor C, implements a slightly different set of the
OpenConfig YANG modules, but at different versions, along with
some deviations and vendor augmentations.

As a client, how do I know what module versions to code against,
when I want to work with devices provided by all three vendors?



The vendors publish their implementation details on yangcatalog and 
you get the info

and see what modules are in common.

There are only market requirements determining what group of modules 
has to exist
in an implementation.  It is not clear to me that formalizing these 
requirements
is something the industry will do effectively.  Module tags already 
provide a way

to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and 
foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had 
properly documented
subsets, would your client even be able to code to it (ignoring 
add-ons and deviations).


I think that answer will converge on yes, I don't know how long it will 
take.  It would probably be better if at the time that protocol 
specifications are written, that the authors of the specifications also 
write the YANG modules to manage them at the same time.




I might be wrong, but I think that the OC solution is use git
tags, so they tag sets of modules that are expected to work
together and also to provide a linear release history of their
sets of modules.  So, if everyone implements the module versions
associated with a git tag then it should convert a two dimensional
problem of module revisions into a linear problem.  The YANG
packages draft is aiming to provide a solution to this problem
that doesn't require the use of git, or sending zip files of
modules ar

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman]

On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton  wrote:

>
> On 30/01/2019 15:16, Andy Bierman wrote:
>
>
>
> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Thanks for the comments.
>> On 30/01/2019 01:22, Andy Bierman wrote:
>>
>> Hi,
>>
>> I originally brought up this issue in July 2015
>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>>
>> Yes.
>>
>> The solution I propose is different in the sense that it uses YANG
>> instance data to define YANG packages rather than new YANG keywords.   I
>> believe that this should make it a lower cost solution to define and
>> implement.
>>
>>
>>
> I think yangvalidator.org has a better solution that does not change YANG
> conformance.
>
> Do you mean that we can just use zip files with the list of modules?
>

I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.  The augment-stmt defines
implicit
multi-module conformance.  I am not convinced that the extra work of
defining package conformance
is worth it.

The issue of what modules does vendor A implement is not a conformance
problem.
It is just more metadata and YANG Catalog is focused on providing that data.

I don't really see how this helps.
>
> Consider:
> - server vendor A, implements some subset of the OpenConfig YANG modules,
> each at a particular version, along with some deviations and vendor
> augmentations.
> - server vendor B, implements the same subset of the OpenConfig YANG
> modules, but at different versions, along with some deviations and vendor
> augmentations.
> - server vendor C, implements a slightly different set of the OpenConfig
> YANG modules, but at different versions, along with some deviations and
> vendor augmentations.
>
> As a client, how do I know what module versions to code against, when I
> want to work with devices provided by all three vendors?
>


The vendors publish their implementation details on yangcatalog and you get
the info
and see what modules are in common.

There are only market requirements determining what group of modules has to
exist
in an implementation.  It is not clear to me that formalizing these
requirements
is something the industry will do effectively.  Module tags already provide
a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and
foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly
documented
subsets, would your client even be able to code to it (ignoring add-ons and
deviations).

I might be wrong, but I think that the OC solution is use git tags, so they
> tag sets of modules that are expected to work together and also to provide
> a linear release history of their sets of modules.  So, if everyone
> implements the module versions associated with a git tag then it should
> convert a two dimensional problem of module revisions into a linear
> problem.  The YANG packages draft is aiming to provide a solution to this
> problem that doesn't require the use of git, or sending zip files of
> modules around.
>

At the moment, it seems that everyone is doing this in different ways:
>  - Yumawork customers/servers use zip files of modules for conformance.
>

Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.


 - OpenConfig client/server implementations use git tags, or git refpoints.
>  - Cisco customers use the contents of directories on github YangModels.
>
> Finally, this draft doesn't change YANG conformance, it just expresses it
> in what is intended to be a simpler way.
>

It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to
package.
That adds more complexity. It doesn't take away any complexity.

If there was a standard to load and unload modular functionality at
boot-time or run-time,
then I could see why there is a need to have a standard to define YANG
packages.


> Thanks,
> Rob
>
>
>
Andy


>
>
> Andy
>
>
>>
>> I don't think the WG ever agreed on the problem that needs to be solved,
>> and that is still the case.
>>
>> That wasn't quite my impression.  I also think that folks were busy
>> focusing on other WG activity and didn't necessarily have the time to
>> concentrate on this.
>>
>> My draft was aiming on solving two broad problems:
>>
>>The main goals of YANG package definitions include, but are not
>>restricted to:
>>
>>o  To act as a simplified YANG conformance mechanism.  Rather than
>>   conformance being performed against a set of individual YANG
>>   module revisions, conformance could also be more simply stated in
>>   terms of YANG packages, with a set modifications (e.g. additional
>>   modules

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Robert Wilton]

On 30/01/2019 15:16, Andy Bierman wrote:



On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton > wrote:


Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:

Hi,

I originally brought up this issue in July 2015
https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/


Yes.

The solution I propose is different in the sense that it uses YANG
instance data to define YANG packages rather than new YANG
keywords.   I believe that this should make it a lower cost
solution to define and implement.



I think yangvalidator.org  has a better 
solution that does not change YANG conformance.


Do you mean that we can just use zip files with the list of modules?

I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG 
modules, each at a particular version, along with some deviations and 
vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG 
modules, but at different versions, along with some deviations and 
vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig 
YANG modules, but at different versions, along with some deviations and 
vendor augmentations.


As a client, how do I know what module versions to code against, when I 
want to work with devices provided by all three vendors?


I might be wrong, but I think that the OC solution is use git tags, so 
they tag sets of modules that are expected to work together and also to 
provide a linear release history of their sets of modules.  So, if 
everyone implements the module versions associated with a git tag then 
it should convert a two dimensional problem of module revisions into a 
linear problem.  The YANG packages draft is aiming to provide a solution 
to this problem that doesn't require the use of git, or sending zip 
files of modules around.


At the moment, it seems that everyone is doing this in different ways:
 - Yumawork customers/servers use zip files of modules for conformance.
 - OpenConfig client/server implementations use git tags, or git refpoints.
 - Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses 
it in what is intended to be a simpler way.


Thanks,
Rob





Andy



I don't think the WG ever agreed on the problem that needs to be
solved,
and that is still the case.


That wasn't quite my impression.  I also think that folks were
busy focusing on other WG activity and didn't necessarily have the
time to concentrate on this.

My draft was aiming on solving two broad problems:

The main goals of YANG package definitions include, but are not
restricted to:

o  To act as a simplified YANG conformance mechanism.  Rather than
   conformance being performed against a set of individual YANG
   module revisions, conformance could also be more simply stated in
   terms of YANG packages, with a set modifications (e.g. additional
   modules, deviations, or features).

o  To allow YANG datastore schema to be specified in a more concise
   way rather than having to list all modules and revisions.  YANG
   package definitions can be defined in documents that can be
   referenced by a URL rather than requiring explicit lists of
   modules to be shared between client and server.  Hence, a YANG
   package must contain sufficient information to allow a client or
   server to precisely construct the schema associated with the
   package.





In reality each server has 1 package -- its entire library.


This doesn't apply to all servers.  For a long time, as a vendor,
we have had separate packages that can be independently installed,
and which extend the management model to cover the new
functionality.  E.g. BNG functionality could be in a separate,
independently installable, package on top of the base router
functionality.

For a Linux server, the manageability interface will depend on
what applications have been installed.



The SEMVER work shows
that vendors are treating platforms as independent release
trains, and not really
developing loadable packages.


This depends on the vendor.  The YANG versioning work is trying to
find a solution that works across the industry.  I believe that
the versioning requirements are different for standards developed
modules, vs industry developed modules, vs vendor modules.




I think YANG 1.2 improvements for conformance (e.g.,
YANG-redirects, SEMVER import)
and  the YANG Catalog can solve the module compatibility issues.
It is more of a documentation
problem than a standards problem.


Having a standard YANG module that can be used to def

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman]

On Wed, Jan 30, 2019 at 7:16 AM Andy Bierman  wrote:

>
>
> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Thanks for the comments.
>> On 30/01/2019 01:22, Andy Bierman wrote:
>>
>> Hi,
>>
>> I originally brought up this issue in July 2015
>> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>>
>> Yes.
>>
>> The solution I propose is different in the sense that it uses YANG
>> instance data to define YANG packages rather than new YANG keywords.   I
>> believe that this should make it a lower cost solution to define and
>> implement.
>>
>>
>>
> I think yangvalidator.org has a better solution that does not change YANG
> conformance.
>
>

oops -- I meant yangcatalog.org

I don't agree that:

 (1) an instance document is easier for readers and writers.
It may be easier for tool makers, but that is subjective.
But the solution is irrelevant unless we agree on the problem first.

 (2) we need to specify YANG conformance for groups of modules

(3) it simplifies YANG to define conformance for modules and groups of
modules

(4) it is unclear how the packages are used by an operator

(5) the WG agreed on any problem to solve for which YANG packages is the
solution


Andy


> Andy
>
>
>>
>> I don't think the WG ever agreed on the problem that needs to be solved,
>> and that is still the case.
>>
>> That wasn't quite my impression.  I also think that folks were busy
>> focusing on other WG activity and didn't necessarily have the time to
>> concentrate on this.
>>
>> My draft was aiming on solving two broad problems:
>>
>>The main goals of YANG package definitions include, but are not
>>restricted to:
>>
>>o  To act as a simplified YANG conformance mechanism.  Rather than
>>   conformance being performed against a set of individual YANG
>>   module revisions, conformance could also be more simply stated in
>>   terms of YANG packages, with a set modifications (e.g. additional
>>   modules, deviations, or features).
>>
>>o  To allow YANG datastore schema to be specified in a more concise
>>   way rather than having to list all modules and revisions.  YANG
>>   package definitions can be defined in documents that can be
>>   referenced by a URL rather than requiring explicit lists of
>>   modules to be shared between client and server.  Hence, a YANG
>>   package must contain sufficient information to allow a client or
>>   server to precisely construct the schema associated with the
>>   package.
>>
>>
>>
>>
>>
>> In reality each server has 1 package -- its entire library.
>>
>> This doesn't apply to all servers.  For a long time, as a vendor, we have
>> had separate packages that can be independently installed, and which extend
>> the management model to cover the new functionality.  E.g. BNG
>> functionality could be in a separate, independently installable, package on
>> top of the base router functionality.
>>
>> For a Linux server, the manageability interface will depend on what
>> applications have been installed.
>>
>>
>> The SEMVER work shows
>> that vendors are treating platforms as independent release trains, and
>> not really
>> developing loadable packages.
>>
>> This depends on the vendor.  The YANG versioning work is trying to find a
>> solution that works across the industry.  I believe that the versioning
>> requirements are different for standards developed modules, vs industry
>> developed modules, vs vendor modules.
>>
>>
>>
>> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects,
>> SEMVER import)
>> and  the YANG Catalog can solve the module compatibility issues. It is
>> more of a documentation
>> problem than a standards problem.
>>
>> Having a standard YANG module that can be used to define packages is
>> something this is useful and should be standardized.  I believe that this
>> is better than each vendor coming up with their own solution for this
>> problem.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>
>> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <
>> jason.ste...@nokia.com> wrote:
>>
>>> Thanks Rob. Please see inline.
>>>
>>> Jason
>>>
>>>
>>>
>>> *From:* Robert Wilton 
>>> *Sent:* Thursday, January 24, 2019 1:16 PM
>>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ;
>>> netmod@ietf.org
>>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages
>>>
>>>
>>>
>>> Hi Jason,
>>>
>>> Thanks for the review and comments.
>>>
>>> I've put some responses inline ...
>>>
>>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>>>
>>> Hi guys,
>>>
>>>
>>>
>>> I've gotten most of the way through the draft and have some initial
>>> comments. I haven't digested the section 10 open issues yet or the examples.
>>>
>>>
>>>
>>> Section 5 mentions the following:
>>>
>>>YANG library is augmented to allow servers to report the packages
>>>
>>>that they implement and to associate those packages back to
>>>
>>>particular datastore schem

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Robert Wilton]

Hi Jason,

Please see inline [RW] ...

On 30/01/2019 00:55, Sterne, Jason (Nokia - CA/Ottawa) wrote:


Thanks Rob. Please see inline.

Jason

*From:*Robert Wilton 
*Sent:* Thursday, January 24, 2019 1:16 PM
*To:* Sterne, Jason (Nokia - CA/Ottawa) ; 
netmod@ietf.org

*Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

I've gotten most of the way through the draft and have some
initial comments. I haven't digested the section 10 open issues
yet or the examples.

Section 5 mentions the following:

YANG library is augmented to allow servers to report the packages

that they implement and to associate those packages back to

particular datastore schema.

Does the combination of this draft and rfc7895bis somehow allow
the same package to be advertised in 2 different datastores, but
with different deviations in each datastore? I'm thinking of a
case, for example, where a package is fully supported in the
running but the package minus a few modules (or parts of modules)
is supported in the operational datastore. There seems to be a 1:1
relationship between package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that  would implement package "foo", and 
 would implement package "modified-foo".  Package 
"modified-foo" would import package "foo" and also specify the set of 
modules that contain the deviations "foo".


I didn't want a server to be able to see that I implement package 
"foo", but then I have all these deviations that change its behavior.  
Instead, it is really implementing a different package that is based 
on "foo".


The packages draft doesn't include any specific leaf-list for
deviations. Section 7.2 mentions that deviations could be
expressed by including modules that happen to contain deviations.
That seems a bit inconsistent with rfc7895bis that has a specific
leaf-list of deviations (and NETCONF hello that specifically
explicitly labels deviation modules).

I'm conflicted on this one.  I don't really like the deviation list in 
YANG library because I regard it as a duplicate source of information, 
and then there is a question of which source of data do you trust.  
E.g. do you process a deviation in a module that is not listed in the 
deviations module list?


*/[>>JTS: ] Good point. I suppose this issue applies today already. 
i.e. what if one of the modules advertised in the  is a module 
of deviations (without having been referenced by another module as a 
deviation module)./*


[RW]: One benefit of explicitly listing deviations would be that, if a 
package wanted to deviate some nodes in modules from an imported 
package, then it would be required to explicitly list the modules that 
was being deviated (along with the deviations).  So a reader of the 
package definition would be able to easily see that it is not using a 
100% faithful implementation of the imported package.




Section 5.1 says the package must be referentially complete. I can
see the advantages of that although wondering if that might limit
flexibility of partitioning modules into packages. I could imagine
use cases for dividing a large set of modules into a few packages
that might rev independently but can still all work together
(especially if they rev in a bc manner). But maybe that just
starts to introduce too much complexity?

Yes, having partial packages may be useful.  Perhaps just adding a 
leaf to indicate whether a package is referentially complete could be 
the answer here.


I didn't understand this part of section 5.1. Can you maybe
illustrate with an example?

The version/revision of a module listed in the package module list

supercedes any version/revision of the module listed in a imported

package module list.  This allows a package to resolve any

conflicting implemented module versions/revisions in imported

packages.

Probably best to see example B.3. in the appendix because it exactly 
illustrates this point.


Basically:
1) Packages must explicitly list all versions of all modules they 
define/import.
2) If two imported packages define different versions of modules, then 
the package that is importing them needs a way to define which version 
to use.
3) A package needs a way to override the version of module specified 
in an imported package.


*/[>>JTS: ] Thx. That example does help. I suppose the designer of the 
package needs to carefully check that the version they select can be 
successfully used by all the modules in the package. /*


*/I think there is a minor typo in example B.3.  The example-3-pkg is 
importing "/* */example-import-1" but I believe you meant "/* 
*/example-import-1-pkg" (and some for import-2)./*


[RW]: I think that is an artifact

[netmod] features in import

[Ladislav Lhotka]

Hi,

unlike RFC 7895, 7895bis doesn't provide the "feature" leaf list for
import-only modules. But is it really so that features have no use in
such modules?

For example, an enum can depend on a feature, and if it is inside a
typedef, it can also be in an import-only module. What if that feature
is defined in the same module?

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman]

On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton  wrote:

> Hi Andy,
>
> Thanks for the comments.
> On 30/01/2019 01:22, Andy Bierman wrote:
>
> Hi,
>
> I originally brought up this issue in July 2015
> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>
> Yes.
>
> The solution I propose is different in the sense that it uses YANG
> instance data to define YANG packages rather than new YANG keywords.   I
> believe that this should make it a lower cost solution to define and
> implement.
>
>
>
I think yangvalidator.org has a better solution that does not change YANG
conformance.


Andy


>
> I don't think the WG ever agreed on the problem that needs to be solved,
> and that is still the case.
>
> That wasn't quite my impression.  I also think that folks were busy
> focusing on other WG activity and didn't necessarily have the time to
> concentrate on this.
>
> My draft was aiming on solving two broad problems:
>
>The main goals of YANG package definitions include, but are not
>restricted to:
>
>o  To act as a simplified YANG conformance mechanism.  Rather than
>   conformance being performed against a set of individual YANG
>   module revisions, conformance could also be more simply stated in
>   terms of YANG packages, with a set modifications (e.g. additional
>   modules, deviations, or features).
>
>o  To allow YANG datastore schema to be specified in a more concise
>   way rather than having to list all modules and revisions.  YANG
>   package definitions can be defined in documents that can be
>   referenced by a URL rather than requiring explicit lists of
>   modules to be shared between client and server.  Hence, a YANG
>   package must contain sufficient information to allow a client or
>   server to precisely construct the schema associated with the
>   package.
>
>
>
>
>
> In reality each server has 1 package -- its entire library.
>
> This doesn't apply to all servers.  For a long time, as a vendor, we have
> had separate packages that can be independently installed, and which extend
> the management model to cover the new functionality.  E.g. BNG
> functionality could be in a separate, independently installable, package on
> top of the base router functionality.
>
> For a Linux server, the manageability interface will depend on what
> applications have been installed.
>
>
> The SEMVER work shows
> that vendors are treating platforms as independent release trains, and not
> really
> developing loadable packages.
>
> This depends on the vendor.  The YANG versioning work is trying to find a
> solution that works across the industry.  I believe that the versioning
> requirements are different for standards developed modules, vs industry
> developed modules, vs vendor modules.
>
>
>
> I think YANG 1.2 improvements for conformance (e.g., YANG-redirects,
> SEMVER import)
> and  the YANG Catalog can solve the module compatibility issues. It is
> more of a documentation
> problem than a standards problem.
>
> Having a standard YANG module that can be used to define packages is
> something this is useful and should be standardized.  I believe that this
> is better than each vendor coming up with their own solution for this
> problem.
>
> Thanks,
> Rob
>
>
>
>
> Andy
>
>
>
>
> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) <
> jason.ste...@nokia.com> wrote:
>
>> Thanks Rob. Please see inline.
>>
>> Jason
>>
>>
>>
>> *From:* Robert Wilton 
>> *Sent:* Thursday, January 24, 2019 1:16 PM
>> *To:* Sterne, Jason (Nokia - CA/Ottawa) ;
>> netmod@ietf.org
>> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages
>>
>>
>>
>> Hi Jason,
>>
>> Thanks for the review and comments.
>>
>> I've put some responses inline ...
>>
>> On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>>
>> Hi guys,
>>
>>
>>
>> I've gotten most of the way through the draft and have some initial
>> comments. I haven't digested the section 10 open issues yet or the examples.
>>
>>
>>
>> Section 5 mentions the following:
>>
>>YANG library is augmented to allow servers to report the packages
>>
>>that they implement and to associate those packages back to
>>
>>particular datastore schema.
>>
>>
>>
>> Does the combination of this draft and rfc7895bis somehow allow the same
>> package to be advertised in 2 different datastores, but with different
>> deviations in each datastore? I'm thinking of a case, for example, where a
>> package is fully supported in the running but the package minus a few
>> modules (or parts of modules) is supported in the operational datastore.
>> There seems to be a 1:1 relationship between package and rfc7895bis schema.
>>
>> So, the intention is no, not directly.
>>
>> My aim here is that  would implement package "foo", and
>>  would implement package "modified-foo".  Package
>> "modified-foo" would import package "foo" and also specify the set of
>> modules that contain the deviations "foo".
>

[netmod] LL comments on draft-rwilton-netmod-yang-packages-00

[Ladislav Lhotka]

Hi,

I think it is a good start, here are my comments (some of them were
already raised by Jason):

- I like the fact that this work doesn't require any changes to YANG,
  except perhaps semver.

- I think the augments to YANG library is a separate problem that should
  perhaps be addressed in a different document. Servers supporting
  multiple package revisions may not be that common.

- I was expecting that a package could specify a range of revisions for
  some modules that may be used together with teh others. This doesn't
  seem to be the case. If so, it would be somewhat unwieldy because every
  combination of module revisions would require a separate package
  revision.

- As Jason pointed out, there seems to be no use for the package
  namespace, as packages don't define any names on their own.

- I would also prefer mandatory-features to be bundled with each module.

- This draft nicely shows that there is really no need for any
  "yang-data" extensions. But I also don't see any benefit from using
  ietf-yang-instance-data in this case. It would IMO be perfectly fine
  to get rid of two levels of data hierarchy:

  { "ietf-yang-package:yang-package": {
  ...
}
  }

Thanks, Lada


-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Robert Wilton]

Hi Andy,

Thanks for the comments.

On 30/01/2019 01:22, Andy Bierman wrote:

Hi,

I originally brought up this issue in July 2015
https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/


Yes.

The solution I propose is different in the sense that it uses YANG 
instance data to define YANG packages rather than new YANG keywords.   I 
believe that this should make it a lower cost solution to define and 
implement.





I don't think the WG ever agreed on the problem that needs to be solved,
and that is still the case.


That wasn't quite my impression.  I also think that folks were busy 
focusing on other WG activity and didn't necessarily have the time to 
concentrate on this.


My draft was aiming on solving two broad problems:

   The main goals of YANG package definitions include, but are not
   restricted to:

   o  To act as a simplified YANG conformance mechanism.  Rather than
  conformance being performed against a set of individual YANG
  module revisions, conformance could also be more simply stated in
  terms of YANG packages, with a set modifications (e.g. additional
  modules, deviations, or features).

   o  To allow YANG datastore schema to be specified in a more concise
  way rather than having to list all modules and revisions.  YANG
  package definitions can be defined in documents that can be
  referenced by a URL rather than requiring explicit lists of
  modules to be shared between client and server.  Hence, a YANG
  package must contain sufficient information to allow a client or
  server to precisely construct the schema associated with the
  package.





In reality each server has 1 package -- its entire library.


This doesn't apply to all servers.  For a long time, as a vendor, we 
have had separate packages that can be independently installed, and 
which extend the management model to cover the new functionality.  E.g. 
BNG functionality could be in a separate, independently installable, 
package on top of the base router functionality.


For a Linux server, the manageability interface will depend on what 
applications have been installed.




The SEMVER work shows
that vendors are treating platforms as independent release trains, and 
not really

developing loadable packages.


This depends on the vendor.  The YANG versioning work is trying to find 
a solution that works across the industry.  I believe that the 
versioning requirements are different for standards developed modules, 
vs industry developed modules, vs vendor modules.





I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, 
SEMVER import)
and  the YANG Catalog can solve the module compatibility issues. It is 
more of a documentation

problem than a standards problem.


Having a standard YANG module that can be used to define packages is 
something this is useful and should be standardized.  I believe that 
this is better than each vendor coming up with their own solution for 
this problem.


Thanks,
Rob





Andy




On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>> wrote:


Thanks Rob. Please see inline.

Jason

*From:*Robert Wilton mailto:rwil...@cisco.com>>
*Sent:* Thursday, January 24, 2019 1:16 PM
*To:* Sterne, Jason (Nokia - CA/Ottawa) mailto:jason.ste...@nokia.com>>; netmod@ietf.org

*Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages

Hi Jason,

Thanks for the review and comments.

I've put some responses inline ...

On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi guys,

I've gotten most of the way through the draft and have some
initial comments. I haven't digested the section 10 open
issues yet or the examples.

Section 5 mentions the following:

YANG library is augmented to allow servers to report the packages

that they implement and to associate those packages back to

particular datastore schema.

Does the combination of this draft and rfc7895bis somehow
allow the same package to be advertised in 2 different
datastores, but with different deviations in each datastore?
I'm thinking of a case, for example, where a package is fully
supported in the running but the package minus a few modules
(or parts of modules) is supported in the operational
datastore. There seems to be a 1:1 relationship between
package and rfc7895bis schema.

So, the intention is no, not directly.

My aim here is that  would implement package "foo", and
 would implement package "modified-foo".  Package
"modified-foo" would import package "foo" and also specify the set
of modules that contain the deviations "foo".

I didn't want a server to be able to see that I implement package
"foo", but then I have all these deviations that change its
behavior.  In

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Martin Bjorklund]

Amar Jadagoud  wrote:
> So do you mean that origin-filter needs to be applied on the response data
> but origin annotation should not be provided in the rpc-reply?

Yes.  The filters is a set of mechanisms to reduce the result to match
certain criteria.  "with-origin" (and "with-defaults") are separate
mechanisms to tag the resulting nodes with meta data.


/martin



> 
> On Wed 30 Jan, 2019, 4:05 PM Martin Bjorklund  
> > Amar Jadagoud  wrote:
> > > Hi Martin,
> > >
> > > Yes. I got your point. Thanks.
> > >
> > > One more question :
> > >
> > > Libyang does not return error if origin-filter is provided in the rpc
> > > request without "with-origin" parameter as ietf-netconf-nmda module does
> > > not mandate it.
> >
> > Yes, this is intentional.  "with-origin" is orthogonal from any
> > filters.
> >
> > > So we consider it as with-origin scenario and provide
> > > origin annotation in parent and child record.
> >
> > If the client didn't pass the "with-origin" parameter, the server
> > should not fill in the "origin" annotations, even if "origin-filter"
> > was passed.
> >
> >
> > /martin
> >
> >
> > > Does below point holds true
> > > for this case too?
> >
> >
> >
> > >
> > > Thanks,
> > > Amar
> > >
> > > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund  > >
> > > > Hi,
> > > >
> > > > Amar Jadagoud  wrote:
> > > > > Hi martin,
> > > > >
> > > > > Yes. I got your point. But what should be the parent record
> > annotation
> > > > > value? Whether it should be intended or origin annotation itself
> > should
> > > > not
> > > > > exist?
> > > >
> > > > I'm not sure I understand your question, but if the "with-origin"
> > > > parameter is present in the request, the reply will contain "origin"
> > > > annotations on all nodes (including ancestors) that have it.  This
> > > > handling is separate from any filters included.  So even if you filter
> > > > for "system" you might get nodes in the ancestor hierarchy with origin
> > > > "intended", if you provided "with-origin".
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Amar
> > > > >
> > > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Amar Jadagoud  wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have one doubt regarding origin-filter filtering in case of
> > > > > > parent-child
> > > > > > > hierarchy.
> > > > > > >
> > > > > > > If child class instance fields match with origin-filter value but
> > > > parent
> > > > > > > class instance fields does not, then what should be the rpc-reply
> > > > > > content?
> > > > > > > Does it need to include parent class instance record with only
> > key
> > > > fields
> > > > > > > along with child class record or it should not include both
> > parent
> > > > and
> > > > > > > child class instance record?
> > > > > >
> > > > > > This is not special for origin-filter, but applies to all filters.
> > > > > > The description of get-data says:
> > > > > >
> > > > > >Any ancestor nodes (including list keys) of nodes selected
> > by
> > > > > >the filters are included in the response.
> > > > > >
> > > > > > Hope this answers your question.
> > > > > >
> > > > > >
> > > > > > /martin
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Consider example given in 3.1.1.4 section of
> > > > > > > draft-ietf-netconf-nmda-netconf-08 :
> > > > > > >
> > > > > > >  > > > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > > > >   > > > > > >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> > > > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > > > > > >  ds:operational
> > > > > > >  
> > > > > > >  http://example.com/ns/bgp"/>
> > > > > > >  
> > > > > > >  or:intended
> > > > > > >  or:system
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > >
> > > > > > >
> > > > > > >   > > > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > > > >  
> > > > > > >  http://example.com/ns/bgp";
> > > > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > > > > > >  or:origin="or:intended">
> > > > > > >  
> > > > > > >  2001:db8::2:3
> > > > > > >  60794
> > > > > > >  established
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > >  
> > > > > > >
> > > > > > > In the above example, user has provided origin-filter as system
> > and
> > > > > > > intended in the RPC request. So rpc-reply has both parent record
> > with
> > > > > > > "intended" origin and child record with "system" origin.
> > > > > > >
> > > > > > > What if user has provided only origin-filter="system" ? Do we
> > need to
> > > > > > > provide parent record with "intended" origin in the rpc-reply or
> > > > should
> > > > > > not
> > > > > > > provide both parent and child record ?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Amar
> > > > > >
> > > >
> >

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5617)

[Ladislav Lhotka]

Hi,

this erratum should be rejected. It is a substantial technical change of the
spec, and section 9.9.2 doesn't indicate any possibility of using deref().

Lada

On Wed, 2019-01-30 at 02:35 -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5617
> 
> --
> Type: Technical
> Reported by: Marek Michalak, Pawel Koch 
> 
> Section: 14
> 
> Original Text
> -
> path-arg= absolute-path / relative-path
> 
> Corrected Text
> --
> path-arg= deref-expr / path-str
> 
> deref-expr  = deref-function-invocation *WSP "/" *WSP 
>   relative-path
> 
> path-str= absolute-path / relative-path
> 
> deref-function-invocation = deref-keyword *WSP
> "(" *WSP path-str *WSP ")"
> 
> deref-keyword   = %s"deref"
> 
> Notes
> -
> This is to allow path statement to contain also "deref" function invocation
> which is supported by pyang and Cisco compiler but for now is not supported by
> i.e. yanglint validator because of above statement which does not allow for
> it.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Amar Jadagoud]

So do you mean that origin-filter needs to be applied on the response data
but origin annotation should not be provided in the rpc-reply?

On Wed 30 Jan, 2019, 4:05 PM Martin Bjorklund  Amar Jadagoud  wrote:
> > Hi Martin,
> >
> > Yes. I got your point. Thanks.
> >
> > One more question :
> >
> > Libyang does not return error if origin-filter is provided in the rpc
> > request without "with-origin" parameter as ietf-netconf-nmda module does
> > not mandate it.
>
> Yes, this is intentional.  "with-origin" is orthogonal from any
> filters.
>
> > So we consider it as with-origin scenario and provide
> > origin annotation in parent and child record.
>
> If the client didn't pass the "with-origin" parameter, the server
> should not fill in the "origin" annotations, even if "origin-filter"
> was passed.
>
>
> /martin
>
>
> > Does below point holds true
> > for this case too?
>
>
>
> >
> > Thanks,
> > Amar
> >
> > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund  >
> > > Hi,
> > >
> > > Amar Jadagoud  wrote:
> > > > Hi martin,
> > > >
> > > > Yes. I got your point. But what should be the parent record
> annotation
> > > > value? Whether it should be intended or origin annotation itself
> should
> > > not
> > > > exist?
> > >
> > > I'm not sure I understand your question, but if the "with-origin"
> > > parameter is present in the request, the reply will contain "origin"
> > > annotations on all nodes (including ancestors) that have it.  This
> > > handling is separate from any filters included.  So even if you filter
> > > for "system" you might get nodes in the ancestor hierarchy with origin
> > > "intended", if you provided "with-origin".
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Amar
> > > >
> > > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  > > >
> > > > > Hi,
> > > > >
> > > > > Amar Jadagoud  wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I have one doubt regarding origin-filter filtering in case of
> > > > > parent-child
> > > > > > hierarchy.
> > > > > >
> > > > > > If child class instance fields match with origin-filter value but
> > > parent
> > > > > > class instance fields does not, then what should be the rpc-reply
> > > > > content?
> > > > > > Does it need to include parent class instance record with only
> key
> > > fields
> > > > > > along with child class record or it should not include both
> parent
> > > and
> > > > > > child class instance record?
> > > > >
> > > > > This is not special for origin-filter, but applies to all filters.
> > > > > The description of get-data says:
> > > > >
> > > > >Any ancestor nodes (including list keys) of nodes selected
> by
> > > > >the filters are included in the response.
> > > > >
> > > > > Hope this answers your question.
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > > >
> > > > > > Consider example given in 3.1.1.4 section of
> > > > > > draft-ietf-netconf-nmda-netconf-08 :
> > > > > >
> > > > > >  > > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > > >   > > > > >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> > > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > > > > >  ds:operational
> > > > > >  
> > > > > >  http://example.com/ns/bgp"/>
> > > > > >  
> > > > > >  or:intended
> > > > > >  or:system
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >
> > > > > >
> > > > > >   > > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > > >  
> > > > > >  http://example.com/ns/bgp";
> > > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > > > > >  or:origin="or:intended">
> > > > > >  
> > > > > >  2001:db8::2:3
> > > > > >  60794
> > > > > >  established
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >
> > > > > > In the above example, user has provided origin-filter as system
> and
> > > > > > intended in the RPC request. So rpc-reply has both parent record
> with
> > > > > > "intended" origin and child record with "system" origin.
> > > > > >
> > > > > > What if user has provided only origin-filter="system" ? Do we
> need to
> > > > > > provide parent record with "intended" origin in the rpc-reply or
> > > should
> > > > > not
> > > > > > provide both parent and child record ?
> > > > > >
> > > > > > Thanks,
> > > > > > Amar
> > > > >
> > >
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Martin Bjorklund]

Amar Jadagoud  wrote:
> Hi Martin,
> 
> Yes. I got your point. Thanks.
> 
> One more question :
> 
> Libyang does not return error if origin-filter is provided in the rpc
> request without "with-origin" parameter as ietf-netconf-nmda module does
> not mandate it.

Yes, this is intentional.  "with-origin" is orthogonal from any
filters.

> So we consider it as with-origin scenario and provide
> origin annotation in parent and child record.

If the client didn't pass the "with-origin" parameter, the server
should not fill in the "origin" annotations, even if "origin-filter"
was passed.


/martin


> Does below point holds true
> for this case too?



> 
> Thanks,
> Amar
> 
> On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund  
> > Hi,
> >
> > Amar Jadagoud  wrote:
> > > Hi martin,
> > >
> > > Yes. I got your point. But what should be the parent record annotation
> > > value? Whether it should be intended or origin annotation itself should
> > not
> > > exist?
> >
> > I'm not sure I understand your question, but if the "with-origin"
> > parameter is present in the request, the reply will contain "origin"
> > annotations on all nodes (including ancestors) that have it.  This
> > handling is separate from any filters included.  So even if you filter
> > for "system" you might get nodes in the ancestor hierarchy with origin
> > "intended", if you provided "with-origin".
> >
> >
> > /martin
> >
> >
> >
> >
> > >
> > > Thanks,
> > > Amar
> > >
> > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  > >
> > > > Hi,
> > > >
> > > > Amar Jadagoud  wrote:
> > > > > Hi,
> > > > >
> > > > > I have one doubt regarding origin-filter filtering in case of
> > > > parent-child
> > > > > hierarchy.
> > > > >
> > > > > If child class instance fields match with origin-filter value but
> > parent
> > > > > class instance fields does not, then what should be the rpc-reply
> > > > content?
> > > > > Does it need to include parent class instance record with only key
> > fields
> > > > > along with child class record or it should not include both parent
> > and
> > > > > child class instance record?
> > > >
> > > > This is not special for origin-filter, but applies to all filters.
> > > > The description of get-data says:
> > > >
> > > >Any ancestor nodes (including list keys) of nodes selected by
> > > >the filters are included in the response.
> > > >
> > > > Hope this answers your question.
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > > >
> > > > > Consider example given in 3.1.1.4 section of
> > > > > draft-ietf-netconf-nmda-netconf-08 :
> > > > >
> > > > >  > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > >   > > > >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > > > >  ds:operational
> > > > >  
> > > > >  http://example.com/ns/bgp"/>
> > > > >  
> > > > >  or:intended
> > > > >  or:system
> > > > >  
> > > > >  
> > > > >  
> > > > >
> > > > >
> > > > >   > > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > > >  
> > > > >  http://example.com/ns/bgp";
> > > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > > > >  or:origin="or:intended">
> > > > >  
> > > > >  2001:db8::2:3
> > > > >  60794
> > > > >  established
> > > > >  
> > > > >  
> > > > >  
> > > > >  
> > > > >
> > > > > In the above example, user has provided origin-filter as system and
> > > > > intended in the RPC request. So rpc-reply has both parent record with
> > > > > "intended" origin and child record with "system" origin.
> > > > >
> > > > > What if user has provided only origin-filter="system" ? Do we need to
> > > > > provide parent record with "intended" origin in the rpc-reply or
> > should
> > > > not
> > > > > provide both parent and child record ?
> > > > >
> > > > > Thanks,
> > > > > Amar
> > > >
> >

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

[netmod] [Technical Errata Reported] RFC7950 (5617)

[RFC Errata System]

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5617

--
Type: Technical
Reported by: Marek Michalak, Pawel Koch 

Section: 14

Original Text
-
path-arg= absolute-path / relative-path

Corrected Text
--
path-arg= deref-expr / path-str

deref-expr  = deref-function-invocation *WSP "/" *WSP 
  relative-path

path-str= absolute-path / relative-path

deref-function-invocation = deref-keyword *WSP
"(" *WSP path-str *WSP ")"

deref-keyword   = %s"deref"

Notes
-
This is to allow path statement to contain also "deref" function invocation 
which is supported by pyang and Cisco compiler but for now is not supported by 
i.e. yanglint validator because of above statement which does not allow for it.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Amar Jadagoud]

Hi Martin,

Yes. I got your point. Thanks.

One more question :

Libyang does not return error if origin-filter is provided in the rpc
request without "with-origin" parameter as ietf-netconf-nmda module does
not mandate it. So we consider it as with-origin scenario and provide
origin annotation in parent and child record. Does below point holds true
for this case too?

Thanks,
Amar

On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund  Hi,
>
> Amar Jadagoud  wrote:
> > Hi martin,
> >
> > Yes. I got your point. But what should be the parent record annotation
> > value? Whether it should be intended or origin annotation itself should
> not
> > exist?
>
> I'm not sure I understand your question, but if the "with-origin"
> parameter is present in the request, the reply will contain "origin"
> annotations on all nodes (including ancestors) that have it.  This
> handling is separate from any filters included.  So even if you filter
> for "system" you might get nodes in the ancestor hierarchy with origin
> "intended", if you provided "with-origin".
>
>
> /martin
>
>
>
>
> >
> > Thanks,
> > Amar
> >
> > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  >
> > > Hi,
> > >
> > > Amar Jadagoud  wrote:
> > > > Hi,
> > > >
> > > > I have one doubt regarding origin-filter filtering in case of
> > > parent-child
> > > > hierarchy.
> > > >
> > > > If child class instance fields match with origin-filter value but
> parent
> > > > class instance fields does not, then what should be the rpc-reply
> > > content?
> > > > Does it need to include parent class instance record with only key
> fields
> > > > along with child class record or it should not include both parent
> and
> > > > child class instance record?
> > >
> > > This is not special for origin-filter, but applies to all filters.
> > > The description of get-data says:
> > >
> > >Any ancestor nodes (including list keys) of nodes selected by
> > >the filters are included in the response.
> > >
> > > Hope this answers your question.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > Consider example given in 3.1.1.4 section of
> > > > draft-ietf-netconf-nmda-netconf-08 :
> > > >
> > > >  > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >   > > >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > > >  ds:operational
> > > >  
> > > >  http://example.com/ns/bgp"/>
> > > >  
> > > >  or:intended
> > > >  or:system
> > > >  
> > > >  
> > > >  
> > > >
> > > >
> > > >   > > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >  
> > > >  http://example.com/ns/bgp";
> > > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > > >  or:origin="or:intended">
> > > >  
> > > >  2001:db8::2:3
> > > >  60794
> > > >  established
> > > >  
> > > >  
> > > >  
> > > >  
> > > >
> > > > In the above example, user has provided origin-filter as system and
> > > > intended in the RPC request. So rpc-reply has both parent record with
> > > > "intended" origin and child record with "system" origin.
> > > >
> > > > What if user has provided only origin-filter="system" ? Do we need to
> > > > provide parent record with "intended" origin in the rpc-reply or
> should
> > > not
> > > > provide both parent and child record ?
> > > >
> > > > Thanks,
> > > > Amar
> > >
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Juergen Schoenwaelder]

On Wed, Jan 30, 2019 at 03:16:33PM +0530, Amar Jadagoud wrote:
> 
> Yes. I got your point. But what should be the parent record annotation
> value? Whether it should be intended or origin annotation itself should not
> exist?
>

The origin annotation on a non-presence container has no meaning other
than providing a default that is inherited downwards. In general,
multiple representations are possible that all have the same meaning
(but may take different amounts of space on the wire).

/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] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Martin Bjorklund]

Hi,

Amar Jadagoud  wrote:
> Hi martin,
> 
> Yes. I got your point. But what should be the parent record annotation
> value? Whether it should be intended or origin annotation itself should not
> exist?

I'm not sure I understand your question, but if the "with-origin"
parameter is present in the request, the reply will contain "origin"
annotations on all nodes (including ancestors) that have it.  This
handling is separate from any filters included.  So even if you filter
for "system" you might get nodes in the ancestor hierarchy with origin
"intended", if you provided "with-origin".


/martin




> 
> Thanks,
> Amar
> 
> On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  
> > Hi,
> >
> > Amar Jadagoud  wrote:
> > > Hi,
> > >
> > > I have one doubt regarding origin-filter filtering in case of
> > parent-child
> > > hierarchy.
> > >
> > > If child class instance fields match with origin-filter value but parent
> > > class instance fields does not, then what should be the rpc-reply
> > content?
> > > Does it need to include parent class instance record with only key fields
> > > along with child class record or it should not include both parent and
> > > child class instance record?
> >
> > This is not special for origin-filter, but applies to all filters.
> > The description of get-data says:
> >
> >Any ancestor nodes (including list keys) of nodes selected by
> >the filters are included in the response.
> >
> > Hope this answers your question.
> >
> >
> > /martin
> >
> >
> > >
> > > Consider example given in 3.1.1.4 section of
> > > draft-ietf-netconf-nmda-netconf-08 :
> > >
> > >  > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >   > >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> > >  ds:operational
> > >  
> > >  http://example.com/ns/bgp"/>
> > >  
> > >  or:intended
> > >  or:system
> > >  
> > >  
> > >  
> > >
> > >
> > >   > >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >  
> > >  http://example.com/ns/bgp";
> > >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> > >  or:origin="or:intended">
> > >  
> > >  2001:db8::2:3
> > >  60794
> > >  established
> > >  
> > >  
> > >  
> > >  
> > >
> > > In the above example, user has provided origin-filter as system and
> > > intended in the RPC request. So rpc-reply has both parent record with
> > > "intended" origin and child record with "system" origin.
> > >
> > > What if user has provided only origin-filter="system" ? Do we need to
> > > provide parent record with "intended" origin in the rpc-reply or should
> > not
> > > provide both parent and child record ?
> > >
> > > Thanks,
> > > Amar
> >

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

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Amar Jadagoud]

Hi martin,

Yes. I got your point. But what should be the parent record annotation
value? Whether it should be intended or origin annotation itself should not
exist?

Thanks,
Amar

On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund  Hi,
>
> Amar Jadagoud  wrote:
> > Hi,
> >
> > I have one doubt regarding origin-filter filtering in case of
> parent-child
> > hierarchy.
> >
> > If child class instance fields match with origin-filter value but parent
> > class instance fields does not, then what should be the rpc-reply
> content?
> > Does it need to include parent class instance record with only key fields
> > along with child class record or it should not include both parent and
> > child class instance record?
>
> This is not special for origin-filter, but applies to all filters.
> The description of get-data says:
>
>Any ancestor nodes (including list keys) of nodes selected by
>the filters are included in the response.
>
> Hope this answers your question.
>
>
> /martin
>
>
> >
> > Consider example given in 3.1.1.4 section of
> > draft-ietf-netconf-nmda-netconf-08 :
> >
> >  >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >   >  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
> >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> >  ds:operational
> >  
> >  http://example.com/ns/bgp"/>
> >  
> >  or:intended
> >  or:system
> >  
> >  
> >  
> >
> >
> >   >  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >  
> >  http://example.com/ns/bgp";
> >  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> >  or:origin="or:intended">
> >  
> >  2001:db8::2:3
> >  60794
> >  established
> >  
> >  
> >  
> >  
> >
> > In the above example, user has provided origin-filter as system and
> > intended in the RPC request. So rpc-reply has both parent record with
> > "intended" origin and child record with "system" origin.
> >
> > What if user has provided only origin-filter="system" ? Do we need to
> > provide parent record with "intended" origin in the rpc-reply or should
> not
> > provide both parent and child record ?
> >
> > Thanks,
> > Amar
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Martin Bjorklund]

Hi,

Amar Jadagoud  wrote:
> Hi,
> 
> I have one doubt regarding origin-filter filtering in case of parent-child
> hierarchy.
> 
> If child class instance fields match with origin-filter value but parent
> class instance fields does not, then what should be the rpc-reply content?
> Does it need to include parent class instance record with only key fields
> along with child class record or it should not include both parent and
> child class instance record?

This is not special for origin-filter, but applies to all filters.
The description of get-data says:

   Any ancestor nodes (including list keys) of nodes selected by
   the filters are included in the response.

Hope this answers your question.


/martin


> 
> Consider example given in 3.1.1.4 section of
> draft-ietf-netconf-nmda-netconf-08 :
> 
>   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
>  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>  ds:operational
>  
>  http://example.com/ns/bgp"/>
>  
>  or:intended
>  or:system
>  
>  
>  
> 
> 
>xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>  
>  http://example.com/ns/bgp";
>  xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>  or:origin="or:intended">
>  
>  2001:db8::2:3
>  60794
>  established
>  
>  
>  
>  
> 
> In the above example, user has provided origin-filter as system and
> intended in the RPC request. So rpc-reply has both parent record with
> "intended" origin and child record with "system" origin.
> 
> What if user has provided only origin-filter="system" ? Do we need to
> provide parent record with "intended" origin in the rpc-reply or should not
> provide both parent and child record ?
> 
> Thanks,
> Amar

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