IETF Logo Mail Archive

Re: [netmod] two options for removing /foo-state trees?

Kent Watsen <kwatsen@juniper.net> Thu, 07 September 2017 23:28 UTC

Return-Path: <kwatsen@juniper.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 6AD1D133030 for <netmod@ietfa.amsl.com>; Thu, 7 Sep 2017 16:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.011
X-Spam-Level:
X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 j1A17lfADJMM for <netmod@ietfa.amsl.com>; Thu, 7 Sep 2017 16:28:27 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0108.outbound.protection.outlook.com [104.47.42.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF2113302F for <netmod@ietf.org>; Thu, 7 Sep 2017 16:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6nnjfXdN0OO+kIBgCSvMqCxv4B/BmLHkn9n/RowhsEw=; b=E7si0g2h7nDkCzYopvinm7XI725dZVLz3BcDIjRm06o1XgDAqz2vjwslgvloHiykJw0TZSrvtzbQXQ2miUtJzj0YNglXXTqLGQuKQE3a162CbJTaLc5BxIJw6460Wfh3NpQGPZ24JP0LyJC8oATcDjMz2EJ9TTSyjYTfojbDii0=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1348.namprd05.prod.outlook.com (10.160.183.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 7 Sep 2017 23:28:26 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Thu, 7 Sep 2017 23:28:26 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, Lou Berger <lberger@labn.net>, Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] two options for removing /foo-state trees?
Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoJxiAgAFZEgCAAAPFAIAACi2AgABGtYD///u2AA==
Date: Thu, 07 Sep 2017 23:28:26 +0000
Message-ID: <6A207CF2-8130-477C-8A19-4285756490E2@juniper.net>
References: <D94B3E90-8676-4790-A186-84CB7DC18B49@juniper.net> <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net> <D5D6D48D.C6D1C%acee@cisco.com> <B0660268-33F0-4EA0-82D7-516811C0E406@juniper.net> <D5D71767.C6E17%acee@cisco.com>
In-Reply-To: <D5D71767.C6E17%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1348; 6:9lrOdvACOpoh3tQiTZ8PsxPt1hG2kbJ2TFDup9UMnLKXWcT0Qi2lCYQEH4AxagU3+XmjWIOQXS+MB3pdUT5qo8kLxbId7WZoR7BPoZcBLQSOSyvp7XqhIuiNK1MFDYnWVP2iG6KZlJQ5fcWjuUx//YkFGMvpZH/J4Cabqm6Rtf2oxPuF3YQ+UClqPZwD+NtVepLfOo04wowHdkTbs8Al2LjOcBySJlFZzyngdtkZJ3fw1pbLzAcwNs5/MThWQXgHZSUaOuGttzDuUU/cEceVb0gwzAUJB3aAyARTf74Is+QV3tw5MUHc+aNwPax0S8ng4y+SE1YnPTz0Hn9Msx903g==; 5:fEz7osCBDvtiWNZNOjrlXiA77YRM+nFfvEcB7+L1cnvuOOuRLKF8HhO4hxcHhHVnjcNYfXqGfv1pMofXuyiIXXyfaKFwSWUjYbAZocoeQuEX4J97+WFN8LtUvzuBhYBxzCcrWFJhhn3UkjsrgJcabg==; 24:OGXQeFJ5JciuBxEyUP3yKEsR9k/YAN+miFiG6kY7Lx5qrmSe8CjPMPCv75JRjpZ9ALiAEKve3sh480clBdSaXclGkzdXkQdBtaQ0rAJHRc8=; 7:x7to+WVYcRWPY+JVLzTI2ZWCaZTx/bnq6zArgCzDx8oya7EYeDgvIPKlToGSC9jMv4giGS37txlOYyC1KREuuC2CJDa6GDWfu2if7+YUmiRvJB3GLped7cFWCyQkfWAF8HYBrUf8TckK9sWDv+MesEZ1f4U9PoUfk6KomJTXC49LpvOUveSKwKipuaAbCsYL4BXRhMw2SzkOSxCokeaGfM3IiCbcLXMgy5Rb8zaGICg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2d8aed29-7e84-4af3-ba7d-08d4f64823a1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1348;
x-ms-traffictypediagnostic: BN3PR0501MB1348:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <BN3PR0501MB13483A886F9890EC0F3EFD6AA5940@BN3PR0501MB1348.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1348;
x-forefront-prvs: 04238CD941
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(6512007)(3846002)(102836003)(6116002)(66066001)(8936002)(6506006)(83716003)(77096006)(93886005)(2950100002)(8676002)(99286003)(229853002)(83506001)(81166006)(81156014)(68736007)(6436002)(6486002)(478600001)(7736002)(82746002)(305945005)(97736004)(53936002)(4001350100001)(25786009)(4326008)(14454004)(6246003)(105586002)(189998001)(3280700002)(3660700001)(33656002)(2900100001)(86362001)(106356001)(5660300001)(50986999)(54356999)(101416001)(76176999)(2906002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1348; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <7D7C198016B7084DA0C63103DBF1B87B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 23:28:26.1024 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1348
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/y5QRHfSyV9L5gx-H2Q4L-ovVUKI>
Subject: Re: [netmod] two options for removing /foo-state trees?
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, 07 Sep 2017 23:28:29 -0000

>>Does this mean you're okay reposting your ID similar to Martin's?
>>I ask as a chair interested in starting the adoption process on
>>these nmda-update drafts.
>
> I would hope this is not a prerequisite? We are evaluating how bad this
> will be. I’d ask how many implementations there are of ietf-routing?

Yes, please provide this info when you have it.


>>> However, what about secondary and tertiary implications of moving to
>>> NDMA? If we change a path from “interface-state-ref” to “interface-ref”
>>> to reference an interface, I’d hope no one would expect the old
>>> statement to be kept around…
>>
>>But the old statement would be kept around, in its deprecated form.
>>Of course, the nmda-guidelines should cause those downstream modules
>>to be updated to NMDA as well, so hopefully just a short-lived issue.
>
> This could be really ugly and cascade if we are just using a different
> path for a reference. Hopefully, all the old references are in deprecated
> trees. Otherwise, I guess the new data leaf would need a unique name.

Indeed.  Let's see what the analysis reveals.

Kent

v2.23.0 | Report a Bug | By Email