Re: [netmod] Retrieving Information Pointed by leafref

[Kent Watsen]

[Sorry, fat-fingered the send button]

Here's how the paths might be altered:
-  ../../../../../explicit-paths/explicit-path/name
+ /explicit-paths/explicit-path/name

Back to your question, I guess that something could be done, but I'm unsure if 
how important it would be relative to other work going on in the NETCONF WG.  
It will be interesting to see what other opinions are.

K. // contributor




On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu"  wrote:
 
During the design team discussion for TE and MPLS YANG modeling, we have 
received a request from implementers: How to minimize the number of 
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the case 
when the operator or client software needs to retrieve the object contents 
pointed by a leafref.
For example, given the following simplified TE tunnel model,
+--rw te
    +--rw explicit-paths
    |  +--rw explicit-path* [name]
    | +--rw name  string
    |    +--rw explicit-route-object* [index]
    |   +--rw index   uint32
    |   +--rw explicit-route-usage?   identityref
    +--rw tunnels
    |  +--rw tunnel* [name]
    |  |  +--rw name   string
    |  |  +--rw paths
    |  |  |  +--rw path* [name]
|  |  | +--rw explicit-path?  -> 
../../../../../explicit-paths/explicit-path/name
 
when the client tries to retrieve a tunnel’s information based on the tunnel 
name, the “get” operation returns a list of leafref’s pointing to the paths of 
the tunnel. The client needs to issue at least one more “get” operation to 
retrieve the path information about the given tunnel. The request is to combine 
these two operations into one.
In the RDBMS SQL world, “join” can be used when SQL “select” is performed, but 
NETCONF/YANG currently does not have this capability.
We’d like to ask whether such a request is considered reasonable.
If the request is reasonable, the next question is how to proceed. This seems 
to be a protocol issue rather than YANG modeling issue. Is it acceptable to add 
a new operation to achieve such a  operation with expanded leafref’s?
Comments and suggestions are appreciated.
Thanks,
- Xufeng
 


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

Re: [netmod] Retrieving Information Pointed by leafref

[Kent Watsen]

My experience is that clients get the entire config in one call, and then can 
perform such resolutions locally.

BTW, really long relative paths are harder to read than an absolution path.
../../../../../explicit-paths/explicit-path/name
On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu" 
mailto:netmod-boun...@ietf.org> on behalf of 
xufeng.liu.i...@gmail.com> wrote:

During the design team discussion for TE and MPLS YANG modeling, we have 
received a request from implementers: How to minimize the number of 
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the case 
when the operator or client software needs to retrieve the object contents 
pointed by a leafref.
For example, given the following simplified TE tunnel model,

+--rw te

+--rw explicit-paths

|  +--rw explicit-path* [name]

| +--rw name  string

|+--rw explicit-route-object* [index]

|   +--rw index   uint32

|   +--rw explicit-route-usage?   identityref

+--rw tunnels

|  +--rw tunnel* [name]

|  |  +--rw name   string

|  |  +--rw paths

|  |  |  +--rw path* [name]

|  |  | +--rw explicit-path?  -> 
../../../../../explicit-paths/explicit-path/name

when the client tries to retrieve a tunnel’s information based on the tunnel 
name, the “get” operation returns a list of leafref’s pointing to the paths of 
the tunnel. The client needs to issue at least one more “get” operation to 
retrieve the path information about the given tunnel. The request is to combine 
these two operations into one.
In the RDBMS SQL world, “join” can be used when SQL “select” is performed, but 
NETCONF/YANG currently does not have this capability.
We’d like to ask whether such a request is considered reasonable.
If the request is reasonable, the next question is how to proceed. This seems 
to be a protocol issue rather than YANG modeling issue. Is it acceptable to add 
a new operation to achieve such a  operation with expanded leafref’s?
Comments and suggestions are appreciated.
Thanks,
- Xufeng

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

[netmod] Retrieving Information Pointed by leafref

[Xufeng Liu]

During the design team discussion for TE and MPLS YANG modeling, we have
received a request from implementers: How to minimize the number of
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the
case when the operator or client software needs to retrieve the object
contents pointed by a leafref.

For example, given the following simplified TE tunnel model,

+--rw te

+--rw explicit-paths

|  +--rw explicit-path* [name]

| +--rw name  string

|+--rw explicit-route-object* [index]

|   +--rw index   uint32

|   +--rw explicit-route-usage?   identityref

+--rw tunnels

|  +--rw tunnel* [name]

|  |  +--rw name   string

|  |  +--rw paths

|  |  |  +--rw path* [name]

|  |  | +--rw explicit-path?  ->
../../../../../explicit-paths/explicit-path/name

 

when the client tries to retrieve a tunnel's information based on the tunnel
name, the "get" operation returns a list of leafref's pointing to the paths
of the tunnel. The client needs to issue at least one more "get" operation
to retrieve the path information about the given tunnel. The request is to
combine these two operations into one.

In the RDBMS SQL world, "join" can be used when SQL "select" is performed,
but NETCONF/YANG currently does not have this capability.

We'd like to ask whether such a request is considered reasonable.

If the request is reasonable, the next question is how to proceed. This
seems to be a protocol issue rather than YANG modeling issue. Is it
acceptable to add a new operation to achieve such a  operation
with expanded leafref's?

Comments and suggestions are appreciated.

Thanks,

- Xufeng

 

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

Re: [netmod] handling module incompatibility

[Juergen Schoenwaelder]

On Fri, Oct 06, 2017 at 03:49:50PM +0100, Robert Wilton wrote:
> Hi,
> 
> On 06/10/2017 14:25, Lou Berger wrote:
> > Hi,
> > 
> >      As part of the my Routing Directorate review of
> > draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> > changes being made to the ietf-l3vpn-svc module without changing the
> > name.  I raised this with the YANG doctors and others involved with the
> > draft and it surfaced some topics which really should be discussed here
> > in NetMod.
> > 
> > The background (as explained off-list by others, so I hope I have it
> > right)  is that one of the YANG Doctors noted that RFC8049 was broken
> > and could not be implemented as defined, and therefore a fix was
> > needed.  L3SM has concluded so the fix is in the individual draft
> > draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
> > module could not be implemented, the feeling by the YANG Dr was that
> > even though the new module is incompatible with the original definition
> > the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
> > RFC 6020) didn't have to be followed and the same name could be used.
> 
> I think that this is the view that I support as well.  If something is
> clearly broken then it should be possible to fix it without requiring a new
> module name, just an updated revision.
>

The hidden question is what is 'broken' or 'clearly broken' and when
are definitions in a module broken and when is the damage so big that
the whole module is broken. Does a broken xpath statement cause the
whole module to be fundamentally flawed such that an implementation of
the rest is impossible?

It is not uncommon to find errors in data models and it is then often
a matter of a new revision or errata to address those. The question
here is when is an entire module broken up to the point that nobody
ever will have implemented it or parts of it.

I do not know the answer but I see a certain risk that minor bugs will
be used to argue none of the YANG update rules apply.

/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] handling module incompatibility

[t.petch]

- Original Message -
From: "Lou Berger" 
Sent: Friday, October 06, 2017 2:25 PM

> As part of the my Routing Directorate review of
> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> changes being made to the ietf-l3vpn-svc module without changing the
> name. I raised this with the YANG doctors and others involved with the
> draft and it surfaced some topics which really should be discussed
here
> in NetMod.
>
> The background (as explained off-list by others, so I hope I have it
> right) is that one of the YANG Doctors noted that RFC8049 was broken
> and could not be implemented as defined, and therefore a fix was
> needed. L3SM has concluded so the fix is in the individual draft
> draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc
> module could not be implemented, the feeling by the YANG Dr was that
> even though the new module is incompatible with the original
definition
> the module the rule defined in Section 11 of YANG 1.1 (or section 10
of
> RFC 6020) didn't have to be followed and the same name could be used.
>
> In the subsequent discussion with the YANG Drs., the general
discussion
> was heading down the path of using a new module name, and thereby not
> violating YANG module update rules. This lead us back to the a similar
> discussion we've been having in the context of 8022bis: how best to
> indicate that a whole module is being obsoleted. RFCs do this by
adding
> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
> help YANG tooling. For 8022, we have one approach - publishing an
> updated rev of the original module marking all nodes as deprecated -
but
> that doesn't really make sense for rfc8049bis.
>
> So the discussion for the WG is:
>
> How do we handle incompatible module changes, notably when one module
> 'obsoletes' another module -- from both the process and tooling
> perspectives?

Add a new substatement to the module statement, 'obsoletes' or
'supersedes'or such like..

And I mean write the RFC now, do not wait for a future version or
revision of RFC7950.

Tom Petch

> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>

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

Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

[Robert Wilton]

On 06/10/2017 16:32, Martin Bjorklund wrote:

Benoit Claise  wrote:

Dear all,

[including the routing and multicast YANG design teams]
Can we please finalize the discussion regarding ietf-routing versus
ietf-routing-2, sooner than later.

I care about the NMDA transition strategy.

Here are all the ietf-routing dependent YANG modules (those modules
that depend on ietf-routing)
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
So many YANG modules.

Look at the difference for ietf-routing-2:
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
Some dependent modules are compliant with ietf-routing-2, the
multicast YANG modules, but these are the only ones.

Changing the module name from ietf-routing to ietf-routing-2 implies
that the we have to warn all draft authors of ietf-routing YANG
dependent modules:
     1. to make sure they are aware of ietf-routing-2  (publishing a
RFC8022bis mentioning in the module description that this module is
not compatible with the NMDA architecture, and providing a pointer to
ietf-routing-2 ... is not an automatic way... so barely useful)
     2. to ask them to change their import to ietf-routing-2
Hopefully, in the routing case, it's mainly the IETF.
I'm glad that we didn't change the ietf-interfaces to
ietf-interfaces-2, we would have to deal with cross
SDO/consortia/opensource project issues
Note:

we're in a transition phase today, while we implement the
soon-to-be-published draft-clacla-netmod-model-catalog-02
Because of this, the SDO/consortia/opensource dependent YANG modules
will only appear in the Impact Analysis tomorrow at

https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
In the mean time, you can see all these dependent modules
Ex:

https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
         => click on "dependents"
Those dependent modules is a new feature of
draft-clacla-netmod-model-catalog-02


I'm wondering if this NMDA transition hurdle doesn't make a good
justification to keep the same module name!
We could debate whether ietf-routing is implemented or not, but the
point is moot: we don't know what we don't know.

Agreed.  I think there are no real reasons for keeping the module name
and deprecate the old defintiions.  Yes, it adds some noise to the
module but the fact is that we do deprecate all these defintions, and
I think we should not hide that.

This is also my preferred option.

I would like to just deprecate these nodes now, and then (for the 
routing module that is unlikely to have been widely implement) update it 
again in a 1-2 years time to remove the deprecated nodes (we can warn 
now that they will get removed).


Conversely, for ietf interfaces (which is much more likely to be widely 
implemented), I think that they should move to obsolete after 1-2 years 
and then hopefully be removed 1-2 years after that.


Thanks,
Rob





/martin




Regarding one point made by Andy:

I should explain the use-case for identifying NMDA vs.
NMDA-transition modules.
I do not want to present both types (for a given module) to the user.
So the tools need to know in "NMDA mode" which modules are duplicates
for NMDA-transition purpose only, so those modules can be hidden
from the user.
In "legacy mode" the NMDA modules would be hidden and the transition
modules
would be exposed to the user instead.

Guessing which is which will only cause unhappy customers so we will
force
vendors to tag the modules with our own YANG extensions to tell them
apart.

We recognized this use case and tagged the YANG module "tree-type" in
the YANG catalog.
In the soon-to-be-published but already implemented
draft-clacla-netmod-model-catalog-02 draft, you will see:

leaf tree-type {
   type enumeration {
 enum "split" {
   description
 "This module uses a split config/operational state layout.";
 }
 enum "nmda-compatible" {
   description
 "This module is compatible with the Network Management
 Datastores
  Architecture (NMDA) and combines config and operational state
  nodes.";
 }
 enum "transitional-extra" {
   description
 "This module is derived as a '-state' module to allow for
 transitioning
  to a full NMDA-compliant tree structure.";
 }
 enum "openconfig" {
   description
 "This module uses the Openconfig data element layout.";
 }
 enum "unclassified" {
   description
 

Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

[Martin Bjorklund]

Martin Bjorklund  wrote:
> Benoit Claise  wrote:
> > Dear all,
> > 
> > [including the routing and multicast YANG design teams]
> > Can we please finalize the discussion regarding ietf-routing versus
> > ietf-routing-2, sooner than later.
> > 
> > I care about the NMDA transition strategy.
> > 
> > Here are all the ietf-routing dependent YANG modules (those modules
> > that depend on ietf-routing)
> > https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
> > So many YANG modules.
> > 
> > Look at the difference for ietf-routing-2:
> > https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
> > Some dependent modules are compliant with ietf-routing-2, the
> > multicast YANG modules, but these are the only ones.
> > 
> > Changing the module name from ietf-routing to ietf-routing-2 implies
> > that the we have to warn all draft authors of ietf-routing YANG
> > dependent modules:
> >     1. to make sure they are aware of ietf-routing-2  (publishing a
> > RFC8022bis mentioning in the module description that this module is
> > not compatible with the NMDA architecture, and providing a pointer to
> > ietf-routing-2 ... is not an automatic way... so barely useful)
> >     2. to ask them to change their import to ietf-routing-2
> > Hopefully, in the routing case, it's mainly the IETF.
> > I'm glad that we didn't change the ietf-interfaces to
> > ietf-interfaces-2, we would have to deal with cross
> > SDO/consortia/opensource project issues
> > Note:
> > 
> >we're in a transition phase today, while we implement the
> >soon-to-be-published draft-clacla-netmod-model-catalog-02
> >Because of this, the SDO/consortia/opensource dependent YANG modules
> >will only appear in the Impact Analysis tomorrow at
> >
> > https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
> >In the mean time, you can see all these dependent modules
> >Ex:
> >
> > https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
> >         => click on "dependents"
> >Those dependent modules is a new feature of
> >draft-clacla-netmod-model-catalog-02
> > 
> > 
> > I'm wondering if this NMDA transition hurdle doesn't make a good
> > justification to keep the same module name!
> > We could debate whether ietf-routing is implemented or not, but the
> > point is moot: we don't know what we don't know.
> 
> Agreed.  I think there are no real reasons for keeping the module name
> and deprecate the old defintiions.

Whoops, forgot a "not", this should have been:

  I think there are no real reasons for not keeping the module name
  and deprecate the old defintiions.

> Yes, it adds some noise to the
> module but the fact is that we do deprecate all these defintions, and
> I think we should not hide that.  


/martin


> 
> 
> /martin
> 
> 
> 
> > 
> > Regarding one point made by Andy:
> > 
> >I should explain the use-case for identifying NMDA vs.
> >NMDA-transition modules.
> >I do not want to present both types (for a given module) to the user.
> >So the tools need to know in "NMDA mode" which modules are duplicates
> >for NMDA-transition purpose only, so those modules can be hidden
> >from the user.
> >In "legacy mode" the NMDA modules would be hidden and the transition
> >modules
> >would be exposed to the user instead.
> > 
> >Guessing which is which will only cause unhappy customers so we will
> >force
> >vendors to tag the modules with our own YANG extensions to tell them
> >apart.
> > 
> > We recognized this use case and tagged the YANG module "tree-type" in
> > the YANG catalog.
> > In the soon-to-be-published but already implemented
> > draft-clacla-netmod-model-catalog-02 draft, you will see:
> > 
> >leaf tree-type {
> >   type enumeration {
> > enum "split" {
> >   description
> > "This module uses a split config/operational state layout.";
> > }
> > enum "nmda-compatible" {
> >   description
> > "This module is compatible with the Network Management
> > Datastores
> >  Architecture (NMDA) and combines config and operational 
> > state
> >  nodes.";
> > }
> > enum "transitional-extra" {
> >   description
> > "This module is derived as a '-state' module to allow for
> > transitioning
> >  to a full NMDA-compliant tree structure.";
> > }
> > enum "openconfig" {
> >   description
> > "This module uses the Openconfig data element layout.";
> > }
> > enum "unclassified" {
> >   descript

Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

[Martin Bjorklund]

Benoit Claise  wrote:
> Dear all,
> 
> [including the routing and multicast YANG design teams]
> Can we please finalize the discussion regarding ietf-routing versus
> ietf-routing-2, sooner than later.
> 
> I care about the NMDA transition strategy.
> 
> Here are all the ietf-routing dependent YANG modules (those modules
> that depend on ietf-routing)
> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
> So many YANG modules.
> 
> Look at the difference for ietf-routing-2:
> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
> Some dependent modules are compliant with ietf-routing-2, the
> multicast YANG modules, but these are the only ones.
> 
> Changing the module name from ietf-routing to ietf-routing-2 implies
> that the we have to warn all draft authors of ietf-routing YANG
> dependent modules:
>     1. to make sure they are aware of ietf-routing-2  (publishing a
> RFC8022bis mentioning in the module description that this module is
> not compatible with the NMDA architecture, and providing a pointer to
> ietf-routing-2 ... is not an automatic way... so barely useful)
>     2. to ask them to change their import to ietf-routing-2
> Hopefully, in the routing case, it's mainly the IETF.
> I'm glad that we didn't change the ietf-interfaces to
> ietf-interfaces-2, we would have to deal with cross
> SDO/consortia/opensource project issues
> Note:
> 
>we're in a transition phase today, while we implement the
>soon-to-be-published draft-clacla-netmod-model-catalog-02
>Because of this, the SDO/consortia/opensource dependent YANG modules
>will only appear in the Impact Analysis tomorrow at
>
> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>In the mean time, you can see all these dependent modules
>Ex:
>
> https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
>         => click on "dependents"
>Those dependent modules is a new feature of
>draft-clacla-netmod-model-catalog-02
> 
> 
> I'm wondering if this NMDA transition hurdle doesn't make a good
> justification to keep the same module name!
> We could debate whether ietf-routing is implemented or not, but the
> point is moot: we don't know what we don't know.

Agreed.  I think there are no real reasons for keeping the module name
and deprecate the old defintiions.  Yes, it adds some noise to the
module but the fact is that we do deprecate all these defintions, and
I think we should not hide that.  


/martin



> 
> Regarding one point made by Andy:
> 
>I should explain the use-case for identifying NMDA vs.
>NMDA-transition modules.
>I do not want to present both types (for a given module) to the user.
>So the tools need to know in "NMDA mode" which modules are duplicates
>for NMDA-transition purpose only, so those modules can be hidden
>from the user.
>In "legacy mode" the NMDA modules would be hidden and the transition
>modules
>would be exposed to the user instead.
> 
>Guessing which is which will only cause unhappy customers so we will
>force
>vendors to tag the modules with our own YANG extensions to tell them
>apart.
> 
> We recognized this use case and tagged the YANG module "tree-type" in
> the YANG catalog.
> In the soon-to-be-published but already implemented
> draft-clacla-netmod-model-catalog-02 draft, you will see:
> 
>leaf tree-type {
>   type enumeration {
> enum "split" {
>   description
> "This module uses a split config/operational state layout.";
> }
> enum "nmda-compatible" {
>   description
> "This module is compatible with the Network Management
> Datastores
>  Architecture (NMDA) and combines config and operational state
>  nodes.";
> }
> enum "transitional-extra" {
>   description
> "This module is derived as a '-state' module to allow for
> transitioning
>  to a full NMDA-compliant tree structure.";
> }
> enum "openconfig" {
>   description
> "This module uses the Openconfig data element layout.";
> }
> enum "unclassified" {
>   description
> "This module does not belong to any category or can't be
> determined.";
> }
> enum "not-applicable" {
>   description
> "This module is not applicable. For example, because the YANG
> module only contains typedefs, groupings, or is a submodule";
> }
>   }
>   description
>

Re: [netmod] handling module incompatibility

[Kent Watsen]

>>  As part of the my Routing Directorate review of
>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>> changes being made to the ietf-l3vpn-svc module without changing the
>> name.  I raised this with the YANG doctors and others involved with the
>> draft and it surfaced some topics which really should be discussed here
>> in NetMod.
>>
>> The background (as explained off-list by others, so I hope I have it
>> right)  is that one of the YANG Doctors noted that RFC8049 was broken
>> and could not be implemented as defined, and therefore a fix was
>> needed.  L3SM has concluded so the fix is in the individual draft
>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
>> module could not be implemented, the feeling by the YANG Dr was that
>> even though the new module is incompatible with the original definition
>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>> RFC 6020) didn't have to be followed and the same name could be used.
>
>I think that this is the view that I support as well.  If something is 
>clearly broken then it should be possible to fix it without requiring a 
>new module name, just an updated revision.
>
>Once the modules are properly stable, have multiple implementations, 
>then I fully support the 7950 update guidelines, but I think that they 
>are a bit strict as IETF is developing brand new modules, particularly 
>those that don't necessarily have implementations behind them at the 
>point that they reach RFC.


I agree with allowing a do-over using the same module name.

With regards to how to indicate that an entire module is obsolete, I
added this entry to the yang-next tracker a while ago: 
https://github.com/netmod-wg/yang-next/issues/28.

K.  // contributor



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

Re: [netmod] handling module incompatibility

[Robert Wilton]

Hi,

On 06/10/2017 14:25, Lou Berger wrote:

Hi,

     As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.


I think that this is the view that I support as well.  If something is 
clearly broken then it should be possible to fix it without requiring a 
new module name, just an updated revision.


Once the modules are properly stable, have multiple implementations, 
then I fully support the 7950 update guidelines, but I think that they 
are a bit strict as IETF is developing brand new modules, particularly 
those that don't necessarily have implementations behind them at the 
point that they reach RFC.


Thanks,
Rob




In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)


___
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

[netmod] handling module incompatibility

[Lou Berger]

Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)


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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[t.petch]

- Original Message -
From: "Ladislav Lhotka" 
Sent: Thursday, October 05, 2017 1:52 PM
> Martin Bjorklund  writes:
>
> > This version fixes the XPath context for parent-reference.
> >
> > However, there is one more thing to discuss, which is the term
"mount
> > point".
> >
> > The current text says:
> >
> >- mount point: container or list node whose definition contains
> >  the "mount-point" extension statement. The argument of the
> >  "mount-point" statement defines the name of the mount point.
> >
> > So if we have:
> >
> >   container top {
> > container root {
> >   yangmnt:mount-point ni;
> > }
> >   }
> >
> > There is one mount point, the node /top/root, with the name "ni".
> >
> > Pretty confusing...   Does anyone have any comments around this?
>
> What about this?
>
> OLD
>
> - mount point: container or list node whose definition contains
>   the "mount-point" extension statement. The argument of the
>   "mount-point" statement defines the name of the mount point.
>
> NEW
>
> - mount point: container or list node whose definition contains
>   the "mount-point" extension statement. The argument of the
>   "mount-point" statement defines a label that is used for
>   referencing the mount point.

Lada

Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
others) wondering what is this undefined concept.  I know plenty of
languages that have the concept of a label but YANG is not one of them.

I looked to see what the ABNF says for inspiration but there isn't
any:-)  I think that there should be.

I looked for a worked example for inspiration, nope, none of them
either!   What I mean is that in e.g. A.3  mount point with name root
appears, but that is the only instance of 'root'.  The whole point is
that root should appear more than once, once for where the mount will
be, and then once or more times for the part that will be mounted, so an
example where name appears once is not an example IMHO!

Tom Petch

> Lada
>
> >
> >
> >
> > /martin
> >

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