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

Tue, 10 Oct 2017 03:01:38 -0700 


On 09/10/2017 22:06, Benoit Claise wrote:

On 10/6/2017 6:01 PM, Robert Wilton wrote:



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

Benoit Claise <bcla...@cisco.com> 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).

According to Acee, there is one ietf-routing implementation (based on 
an old draft version). If the point is that we don't want ietf-routing 
implementations to implement "deprecated" leaves, can we "obsolete" 
them now.

RFC 7950:

    7.21.2. The "status" Statement

        The "status" statement takes as an argument one of the strings
        "current", "deprecated", or "obsolete".

        o  "current" means that the definition is current and valid.

        o  "deprecated" indicates an obsolete definition, but it permits
           new/continued implementation in order to foster interoperability
           with older/existing implementations.

        o  "obsolete" means that the definition is obsolete and SHOULD NOT be
           implemented and/or can be removed from implementations.

Advantages:
    - we keep the same ietf-routing YANG module names
    - new implementations don't implement the "obsolete" parts.



For 8022bis, I would also support keeping the existing module name, and 
moving the existing state leaves directly to obsolete.  This is with the 
justification that this draft has only recently been published, and we 
do not expect there to be many implementations yet.



For RFC 7223, I think that the state leaves should move to deprecated 
then obsolete in a later revision, because the model is much older and 
hence likely to be much more established.


Thanks,
Rob




Regards, Benoit



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

                 "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

             "The type of data element tree used by the module as 
it relates to

             the
              Network Management Datastores Architecture.";

           reference "draft-dsdt-nmda-guidelines Guidelines for 
YANG Module

           Authors (NMDA)";
         }
         description

           "Grouping of YANG module metadata that extends the 
common list

           defined in the YANG
            Module Library (RFC 7895).";
    }


If not convinced already, I hope that you start to see the YANG
catalog value for the industry.
Let's keep in mind that automation is key. Therefore, YANG modules
without module details (metadata) and related tools is not sufficient
for the industry.

Regards, Benoit

Andy Bierman <a...@yumaworks.com> writes:


On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <rwil...@cisco.com>
wrote:


On 15/09/2017 16:23, Andy Bierman wrote:

Hi,

So are you saying the NMDA transition strategy should be ignored?

My personal preference for the routing modules would be to keep the
same
module name and deprecate the old nodes.


However, I doubt that there are many implementations of this 
8022 yet,

and
if the authors prefer to use a new namespace without the old nodes
then I'm
fine with that also.  Are you opposed to this approach?



A new module name mandates a new namespace, so they go together.
Abandoning the old module is fine, except leaving that module with
status
"current" is not fine.
IMO you need to republish the old module as well, with everything
status
obsolete.

I don't agree with this. The "status" tag is justified for subsequent
revisions of the same module so as to aid old clients.

But if the module name and namespace URI are different, there is no
such
concern. Modules contained in RFCs 7223, 8022 etc. just define some
schemas that happen to be good for my purposes. So I want to be able
to

continue using them, and don't want tools to issue useless 
warnings or

even refuse to process such modules.

I am fine though with making a new revision of ietf-routing
etc. mentioning in the module description that this module is not
compatible with the NMDA architecture, and providing a pointer to
ietf-routing-2.

Lada




E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
probably

much more widely implemented then I think that the modules 
should be

updated in place with the existing state tree deprecated.  I.e. I
support
what Martin has done in his IDs, and don't want this to change.

What is the problem with deprecated nodes?


Nothing really, but I guess that they are likely to be baggage 
that is

going to be around for a long time even if very few people ever
implement
the deprecated nodes.


Why aren't you following your own transition strategy?

Really because I'm not an author, both solutions seem valid, and I
actually think just reaching a conclusion quickly is more important
than
which particular solution is chosen.  I don't see any advantage is
pushing
back the adoption call - it seems like it will probably just delay
when we
can do WG LC.


I actually think that the bigger question that needs to be 
resolved is

whether we need an optional extension to mark a module as NMDA
compatible,

or for the extra NMDA state module, as I think that both you and 
Tom

have
been asking for.


I am no fan of YANG conformance.
The WG does not seem to understand the difference between
     (A) what a server is supposed to do
     (B) what a server claims to do

There is no way to express (A) in a YANG module, just (B) in the new
yang-library.


Andy




Thanks,
Rob




Andy

On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton <rwil...@cisco.com>
wrote:


On 15/09/2017 15:52, Acee Lindem (acee) wrote:


Hi,


With respect to WG adoption, we will do whatever the WG 
decides for

the

RFC 8022 model. We have a strong preference toward not 
carrying the
deprecated nodes forward and new module versions appears to be 
a good

way
to achieve this.


Can we not adopt regardless?  We know that we are going to bis 
8022,

and

having an adopted draft gives it a bit more legitimacy and 
helps other

folks to migrate.


Or perhaps we can start the call for adoption and continue to 
try and

resolve this issue at the same time ;-).  I think that it would be
good to
try and get the updated model drafts to WG LC by Singapore.


I know that it hasn't been asked yet, but I support adoption of 
any

8022
bis draft that (i) provides the correct NDMA combined tree (ii)
removes or
deprecates the old state nodes :-)

Sorry, if I'm being pushy :-)
Rob




I agree with Lada that deprecating all the schema nodes is
unnecessary.

However, we’ll do what it takes to reach consensus and satisfy 
the

most
pedantic among us.

Thanks,
Acee

On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:

Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:

rfc8022bis-02 signals the intent to ditch the
current/soon-to-be-legacy
module, but does it actually say it?  (I can't find it)


The modules contained therein have different names and 
namespaces, so

there is

no formal ancestry. I would prefer to keep the modules from 
RFC 8022

as
they are
- some weirdos may still want to use them.


The draft does say that it obsoletes 8022, but I'm unsure if 
that's

going to

have a meaningful impact in the wild.  I think Juergen said 
they had

this

issue with MIB2 and only after a couple years of misuse did 
they

republish the
legacy MIBs with deprecated status.

I'm okay with this change being made after adoption, so long as
there's

general agreement to do it.  Are the authors okay with it, 
or are

there
any
better suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a
substatement [I

just added this omission to the yang-next tracker].  I think 
the only

way to
"deprecate a module" is to instead deprecate the all the

nodes/rpcs/notifications in the module.  Kind of ugly, but 
it's for a

deprecated module, so who care, right?  ;)


I think it is unnecessary. If somebody needs adding such a 
module to

the
data

model, he/she should probably have a reason to do so, such as 
data

implemented
on the server.

Lada

Kent

--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:


Hi Kent & Lou,


When do you think that it will be possible to start the 
adoption



process


on these drafts?

I think that the first two at least would seem to be ready for
adoption.  For the 3rd draft, there still seems to be an open


question


of what to do with the old state tree, but presumably that 
could be

solved after the draft has been adopted?


I see an update for the third was published yesterday

(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02) 
that
clarifies the intent is to replace the current modules, and 
presumably
obsolete 8022.  And now that this intended direction is 
clear in the

draft we could poll it.


I think this still doesn't address if we need to indicate 
that the
rfc8022 defined modules are deprecated by some other 
mechanisms than
just replacing the RFC, e.g., by updating the old modules 
with all

nodes

marked as deprecated.  I think you're right that this could 
be done

post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou

Thanks,

Rob


On 30/08/2017 00:46, Kent Watsen wrote:


Hey folks,

As discussed at the last meeting, we are heading to revising


existing RFCs

to align them with NMDA.  The first batch have been 
published as

individual drafts:


1. 
https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 

2. 
https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 

3. 
https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00


Please take a look (comments welcome!) and stay tuned for the


related
adoption calls.

Thanks,
Kent (and Lou)


_______________________________________________
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


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

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
























					Reply via email to