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

Lou Berger <lberger@labn.net> Thu, 12 October 2017 14:31 UTC

Return-Path: <lberger@labn.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD23134501 for <netmod@ietfa.amsl.com>; Thu, 12 Oct 2017 07:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6b24cvbL8rt for <netmod@ietfa.amsl.com>; Thu, 12 Oct 2017 07:31:02 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0F413432D for <netmod@ietf.org>; Thu, 12 Oct 2017 07:31:02 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 566ED215DCD for <netmod@ietf.org>; Thu, 12 Oct 2017 08:31:01 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id LeWx1w00j2SSUrH01eX0lh; Thu, 12 Oct 2017 08:31:01 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=RpNjiQI2AAAA:8 a=48vgC7mUAAAA:8 a=fgQY2a2vf2jjLDN9BBkA:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=QEXdDO2ut3YA:10 a=cAcMbU7R10T-QSRYIcO_:22 a=vJuR_VyAocOa-HWBgGQO:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=71WT5/Zs5TX7HlSONaMcQ8j8KlphJwZD4ixrUM3rHJU=; b=1cX7damq7alJ74BHKtbYLqauhd ZK9OE6pC7GjETqBONkt+t/19RluF8+74HSw6LpSdRxWeDJoRCbqrzQlCkB8VZ5CKes4Rt7ygLykb6 jMNypaYLlqCeWyxFYqUraezV/;
Received: from [172.58.184.22] (port=30369 helo=[IPV6:2607:fb90:644a:40a7:0:4d:7e34:b301]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1e2eVl-002D4D-Aq; Thu, 12 Oct 2017 08:30:57 -0600
From: Lou Berger <lberger@labn.net>
To: Kent Watsen <kwatsen@juniper.net>, Martin Bjorklund <mbj@tail-f.com>, <rwilton@cisco.com>
CC: <rtg-dt-yang-arch@ietf.org>, <netmod@ietf.org>
Date: Thu, 12 Oct 2017 10:30:55 -0400
Message-ID: <15f10fecd18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <424B35F1-CA91-44B7-902C-478AFD16008B@juniper.net>
References: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com> <fe00b981-b993-e492-fe21-a1598dda60b7@cisco.com> <20171010.121338.957274767620281285.mbj@tail-f.com> <424B35F1-CA91-44B7-902C-478AFD16008B@juniper.net>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.184.22
X-Exim-ID: 1e2eVl-002D4D-Aq
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:644a:40a7:0:4d:7e34:b301]) [172.58.184.22]:30369
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Jxwgwl_p62NSC-bpTnD-UbyMKs0>
Subject: Re: [netmod] [Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 14:31:11 -0000

As it was unclear if/that Kent was stating a position as chair: it looks 
like the consensus position of the working group is that we should keep the 
old name and mark nodes that are no longer needed due to nmda as obsolete.

Lou
As co-chair


On October 11, 2017 10:26:29 AM Kent Watsen <kwatsen@juniper.net> wrote:

> I agree - let's keep the module name and mark the nodes obsolete.
>
> Kent // any hat
>
>
>
> Robert Wilton <rwilton@cisco.com> wrote:
>>
>>
>> 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 <bclaise@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://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=PEvVi2dNF5_gICJ7X97iuctNaAyUV5Pgnsr2LiDLFEA&e=
>> >>>> So many YANG modules.
>> >>>>
>> >>>> Look at the difference for ietf-routing-2:
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-2D2-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=ISgVe_scuCOokfsF8C62oeiGhfTWMjlAXiS7bnS4cpc&e=
>> >>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Dinterfaces-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=V7trpGHuvRSOwmb0ppL7GoztsKSUJI3yWJ-jxeSHTXs&e=
>> >>>> Â Â Â  In the mean time, you can see all these dependent modules
>> >>>> Â Â Â  Ex:
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-3Dietf-2Dinterfaces&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=euRn2n-i8nQZX5Y-ZieREslwccv7DJBS6L8jlNBA3TM&e=
>> >>>> Â Â Â Â  Â Â Â  Â Â Â  => 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.
>
> This is fine with me as well.
>
>> 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.
>
> Agreed.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=z1FXjDcWCxsDTbtcLAATaD4vb3tJHL5GhZ8ufDlZLIw&e=
>
>
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch