Re: [netmod] upcoming adoptions

Robert Wilton <rwilton@cisco.com> Fri, 15 September 2017 16:02 UTC

Return-Path: <rwilton@cisco.com>
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 706D6133527 for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 09:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 96fG_2RlpxlZ for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 09:02:36 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A1D132D4B for <netmod@ietf.org>; Fri, 15 Sep 2017 09:02:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29019; q=dns/txt; s=iport; t=1505491355; x=1506700955; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6Nq8Mt5HAwKJE4Vgcjp3hQNagPFtdGgHc554S6XzTJI=; b=NAAu6RBlrlndjto9k5KG09uZ71xOLMtRx7qiEBuUDwEcSlD99FIKEMAe YgsfLYePCAg6PL+4PLMLMo3hWw7y67rNM78urCnq65Mtqk8E8Wsqi4TXr aNjJlgXhQWBsYhqaQFR456oGmNpsycuy4k3lWwvJPYxgp6jhz3TcQaNDB o=;
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800"; d="scan'208,217";a="657490033"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 16:02:33 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8FG2XkI025112; Fri, 15 Sep 2017 16:02:33 GMT
To: Andy Bierman <andy@yumaworks.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz> <D5E15F4A.C80F5%acee@cisco.com> <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com> <CABCOCHS_TDc3x3xXzo4Aafi3xmt==owQ9M0-MaV2na-qmggmQQ@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <dc87313d-ac37-5789-3ccf-a9bb7ec107af@cisco.com>
Date: Fri, 15 Sep 2017 17:02:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHS_TDc3x3xXzo4Aafi3xmt==owQ9M0-MaV2na-qmggmQQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0040993E14D25652F20C8D5A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pTD0XvcUh8W36SkGlu7DgocdtAc>
Subject: Re: [netmod] 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: Fri, 15 Sep 2017 16:02:44 -0000


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?

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.

Thanks,
Rob


>
>
> Andy
>
> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton <rwilton@cisco.com 
> <mailto:rwilton@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-bounces@ietf.org <mailto:netmod-bounces@ietf.org> on
>         behalf of lhotka@nic.cz <mailto:lhotka@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
>                 <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
>                         <https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00>
>                         2.
>                         https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>                         <https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00>
>                         3.
>                         https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>                         <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 <mailto:netmod@ietf.org>
>                         https://www.ietf.org/mailman/listinfo/netmod
>                         <https://www.ietf.org/mailman/listinfo/netmod>
>                         .
>
>
>
>                 _______________________________________________
>                 netmod mailing list
>                 netmod@ietf.org <mailto:netmod@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/netmod
>                 <https://www.ietf.org/mailman/listinfo/netmod>
>
>             -- 
>             Ladislav Lhotka
>             Head, CZ.NIC Labs
>             PGP Key ID: 0xB8F92B08A9F76C67
>
>             _______________________________________________
>             netmod mailing list
>             netmod@ietf.org <mailto:netmod@ietf.org>
>             https://www.ietf.org/mailman/listinfo/netmod
>             <https://www.ietf.org/mailman/listinfo/netmod>
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org <mailto:netmod@ietf.org>
>         https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>