Re: [netmod] 'status' statement needed on every node

Kent Watsen <kwatsen@juniper.net> Tue, 05 September 2017 22:50 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 47B02132E37 for <netmod@ietfa.amsl.com>; Tue, 5 Sep 2017 15:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_H4=-0.01, 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 eNYkfxOWkgye for <netmod@ietfa.amsl.com>; Tue, 5 Sep 2017 15:50:04 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2541320D9 for <netmod@ietf.org>; Tue, 5 Sep 2017 15:50:04 -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=Hb97lrN5OrLzjDdakD/gZ6fTHQQv4EGRH4U8NFtqtlo=; b=ZkBDDL6dkS0CrGIklhr8sjKyLeiQk6+QQLZhDjkL6lUmXh25ztT3pnXFDv8SPEna5pjDVYAvF70Oreki5tAew+vrjJW0saing+W30VGlHgPashLs/5j1JHGaLbh3ryvZCzGS8se3raiBq29va1bBm7BGbzrFZ9tyKWje504ctqI=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1411.namprd05.prod.outlook.com (10.160.117.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 5 Sep 2017 22:50:03 +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.0035.010; Tue, 5 Sep 2017 22:50:03 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] 'status' statement needed on every node
Thread-Index: AQHTJm4NQwnHS69prEmUfJVnsti896KmmNYAgAAIUICAAATagP///LMA
Date: Tue, 05 Sep 2017 22:50:03 +0000
Message-ID: <B1BB11D4-9051-458E-ACCE-991ADEA4884A@juniper.net>
References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> <CABCOCHS59CLdCHxZHvJr7LSRXH4m1iVpf6GctchYCZjVrLuvGw@mail.gmail.com> <20170905190151.fizr5dljufbyuyty@elstar.local>
In-Reply-To: <20170905190151.fizr5dljufbyuyty@elstar.local>
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; BN3PR0501MB1411; 6:jy5Pq3A3iNObXp48GO8jXSgWR7lrBAizbI0FFbLyk2HyKUCn3hcA2qMm/yo/wNgCuMHWSFw0p4UzX63/2Sdl80PC1WNWIDOqyrZIApJFxYB3Zzq510VbkQKWzh8xfnl/zQH5Hg4SKPMv12nQIgMpwDaUDhP5ZfVTOwa+DFcCm5NeAEc7GpK02EaxXxqMMgOtnnL56v315UwY5GhsLaQeYXCJ7nrG2bKR/rLBGdEoDK70624c+gYmpHUf+g+y6Zu2egiMw5XQyYvvJLiFY2fWZ6Kuxm8ounyZgrmU0ue6clrhFTPOEEWrEKjs/FWls+GaMKbIvv5a/iIZv9Ifg80z6A==; 5:GOjwsePG7AlQEQl7A/VYliuv7+O4pnE1971Sg38Zc93H9S0ZXcvUqx17exuIWLtPKC3BTo81NJoTNNdzQRjNBHe2pqtbtwhdCIexA94TG4timvJJcXh2ir3Ab5C2Ng2FYc9XMyBVFCaCeLof3gbKqQ==; 24:0kbl2oXZ89VWaa4UN1U5X+KBOcdloxIpmWMwNUo2ymH/XGe6BSdyKn6izaqVQwufTWr67X4RNkWfrjyZTe6lkp+Z0SbYfgJA/fCm7ZN6HQ0=; 7:qDy8ARTQ/qqH6/Hye+OCoq0A/RSS2z0Hc2EHVpN/7VyWbwMppkpEybrKeg0rMdb+NQ9frwQuoiAs4ues70Trpd6mfVBOAx94k7DE77J7Arr1JyB0SbVd2z8dM4iIaT+hbGHCQ4rYvL9HJVAA3IdWCbcd0zfk/xspY/BCeOOEYiZnIPhYszMoaWQcbhkGraRvtASFVUBoQ1UoQv1LXNxUk5f9rluK3i/eh5fmWwUb1DU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 5b2581ad-5cee-486b-8983-08d4f4b07213
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1411;
x-ms-traffictypediagnostic: BN3PR0501MB1411:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <BN3PR0501MB1411CAC0EE12860B846F1EDDA5960@BN3PR0501MB1411.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1411; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1411;
x-forefront-prvs: 0421BF7135
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(4326008)(229853002)(54356999)(76176999)(50986999)(3280700002)(36756003)(101416001)(6512007)(25786009)(7736002)(82746002)(3660700001)(305945005)(33656002)(2900100001)(5660300001)(2950100002)(14454004)(99286003)(102836003)(106356001)(53936002)(478600001)(105586002)(8676002)(6506006)(4001350100001)(97736004)(83506001)(81156014)(81166006)(2906002)(3846002)(6436002)(83716003)(66066001)(8936002)(93886005)(77096006)(6246003)(6486002)(68736007)(6116002)(86362001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1411; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: <24792E11A18802428DBE344F14D490B7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2017 22:50:03.0762 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1411
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OV4a-h7-WcOcYSk5_34diYJEbYk>
Subject: Re: [netmod] 'status' statement needed on every node
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: Tue, 05 Sep 2017 22:50:06 -0000



>> I still don't know what it means to define hierarchical data and say the
>> parent is deprecated but not the descendant nodes.
>
> It is odd but can happen anyway. A current augmentation of something
> that got deprecated likely stays current. I would hope that tools warn
> if they see this but that's it.

This example seems to provide support for saying status should be
inherited.  But, to be clear, you agree that if a parent is deprecated,
than its decedents should be deprecated as well, right? 



>> This is rather non-intuitive, as is the idea that all descendant
>> nodes need to be manually edited (status is not inherited).
>
> Not a big deal. The benefit is that a reader like me knows clear that
> the definition I am look at is deprecated, no need to search backwards
> to find out.

tree diagrams do this too, though I like Martin's approach of removing
the deprecated -state trees from the tree diagram altogether.



>> It also means the objects expanded from groupings cannot ever be
>> changed (clearly a bug in YANG).
>
> Yes, bug in YANG.

Is this the same issue I raised?

  import ietf-foo {
    prefix f;
  }

  container bar {
    uses f:foo;
  }

  container baz {
    status deprecated;
    uses f:foo;            <-- oops, descendants not deprecated!
  }                           (not a problem if status inherited)


K.