Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

tom petch <ietfc@btconnect.com> Fri, 27 September 2019 10:06 UTC

Return-Path: <ietfc@btconnect.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 245A4120113 for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 03:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.222
X-Spam-Level:
X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 vkFeXCq8LIYW for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 03:06:12 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50106.outbound.protection.outlook.com [40.107.5.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5F2120125 for <netmod@ietf.org>; Fri, 27 Sep 2019 03:06:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkbbUkrJqLsWB2M2w37Nsuvps5ZUXcDLFbdNk5ZH+XxHoOnlKtfFjQRAJ+ZSGNtDhSLA1Gs1eCozRyKYoJmcZq9nMlTRCbzProh7TXXfO5S9aSiX/yrucMk6sgutkzWUDtihgJJrp9wtbcbhIhLZGtFw5pgk4xOK+veLujAQjK1LZI5pKr6ue4hZC7ckXVha8Ya7/QHE3KUNOFu16LM9I3Di6JPTlSlpTD4G6zX5VSV+KgmEo1ZQGA13g5Pzc68Ose41oeNgEplsSjx13Mt1EH3Ix5o8gb7eoDgj0OjBex3XaOXzobEU4UaMDhMRQ2+KgXqN9iBGpw/r3WQ78Qcfmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QOrb/JV8pYey07QuudLuTPSeG2N2t44q0eSFmiJIKlg=; b=Uh6vT5XT1OLI9krQyd0PvaBEDriwtcA3LKkRJSZxrSN9GCqG3vyB5QJ//S9DraIU1PwBHpT4Jp/+/AqrJhDh9KtpadI2RX9SEFVvJRQC7hhGze6fATtaLtCu2sedeuB7+kxnZ1ZhLl46aRFNIU3pvua98uBQw17g9LEZsyMPSOyrKoKA5XIGjgCB8uiG+5axp0FKIeU6VkviEkZ8K65WoaK5FXzqj958ao7ZMxuNMfZZXRROZX9bXJWpbG5ampxmtemLBh1nVALbd3CYst5FZOarMYd+GkySZbATcAJFMzIpfJ63EHwxn1TTZ8rrp50mB7037arU1DvbtwxwPFuceA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QOrb/JV8pYey07QuudLuTPSeG2N2t44q0eSFmiJIKlg=; b=BXkUoUcWWFDQj8oxb9Rue6L5BT72j/88URwFbxCdQzR+qnqqWxybNBYCV4cFTTskE8OHVxudRhdiR/YxR85AYFCotiIwhph3EK7DnHvc5wE7Lo3sdn4P4XkfFdtJvVtumeqTUbdZdW6RKUK4kCnnUtHjnIv99blVzRzL2zhcBm4=
Received: from AM0PR07MB5940.eurprd07.prod.outlook.com (20.178.23.32) by AM0PR07MB6129.eurprd07.prod.outlook.com (20.178.115.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Fri, 27 Sep 2019 10:06:08 +0000
Received: from AM0PR07MB5940.eurprd07.prod.outlook.com ([fe80::6091:ebf9:c327:1c60]) by AM0PR07MB5940.eurprd07.prod.outlook.com ([fe80::6091:ebf9:c327:1c60%5]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 10:06:08 +0000
From: tom petch <ietfc@btconnect.com>
To: Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: =?utf-8?B?V2hhdCdzIHRoZSBwcm9ibGVtIHdpdGggTk1EQT8gd2FzIFJlOiBbbmV0bW9k?= =?utf-8?B?XSDnrZTlpI06IOetlOWkjTogUGxlYXNlIGNsYXJpZnkgaW1wbGVtZW50YXRp?= =?utf-8?B?b24gYWJvdXQg4oCYd2hlbuKAmQ==?=
Thread-Index: AQHVdRsui+z1X74d5kGqOVr2DkzJuQ==
Date: Fri, 27 Sep 2019 10:06:08 +0000
Message-ID: <01c201d5751a$ead932c0$4001a8c0@gateway.2wire.net>
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz> <20190926.094526.272771637371098799.mbj@tail-f.com> <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHQzmDjH+7wqFmrSsnaD0T_Q1LPsDi0yuY9Ow2gSvef4SA@mail.gmail.com> <01c701d57485$400d8d40$4001a8c0@gateway.2wire.net> <CABCOCHRse2RJkoQ1r6pf+F4qP8MUn+4ypBY3M5zH+0QWoqBpuQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0116.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::32) To AM0PR07MB5940.eurprd07.prod.outlook.com (2603:10a6:208:103::32)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.211.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9bd4f4df-3c4a-4c31-d28f-08d74332511e
x-ms-traffictypediagnostic: AM0PR07MB6129:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR07MB6129AD4BB0B9610CB7A33B59A0810@AM0PR07MB6129.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0173C6D4D5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(346002)(136003)(396003)(13464003)(189003)(199004)(51914003)(486006)(66066001)(6506007)(66446008)(81156014)(8936002)(256004)(14444005)(86362001)(26005)(446003)(305945005)(7736002)(14454004)(71190400001)(966005)(50226002)(478600001)(1556002)(61296003)(44716002)(62236002)(81166006)(5660300002)(224303003)(186003)(81686011)(4326008)(2906002)(6306002)(81816011)(6512007)(316002)(4720700003)(99286004)(71200400001)(6436002)(66556008)(6916009)(76176011)(52116002)(6116002)(3846002)(9686003)(64756008)(6486002)(25786009)(44736005)(53546011)(66946007)(66476007)(386003)(229853002)(102836004)(14496001)(6246003)(476003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6129; H:AM0PR07MB5940.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rels6f2RAl5dkihqCYxiMyUf5qWoM70xX0twj8aiGYF8n4L5TKhiC1pjZdu/PaYmgGkbiIARH9jPoTsj8Ji+Fa0pIObNvVyGM9MnGztNkzB7UJbOhy88Om7Hyqer+xPGgDBR/6cM2WmZeHgztcnOsO8nMSSSVS6kEtr1Bw81+WTV7qdZYi7WL+DRfq1sA5unbjmNP0J6Gl0lEMXbR2NyDGLL4SzPQ8fYvDYHCpzUzx7kUorjvGcC0yleWSXQLqO+iMhFqtdmQaJAVct2gK+oerpIlABMqqsyl+yJN6HP5/3So2s/bA+gN4ttFpxS+ZJ88PJXmxAyiATe6o1+YkLCSrpkLO6WCZ9qoGxXeE0AF/Xo4YDh9diwMBqz7Znk+PT2i30JILW4Fp7nmplRSzU3uF2B5SumOP8h3UnoHR72Pb1Y3vUj+4F1nkaqfoNXU5unf4UgGmYFVdhyiZA3b9g42Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <9247AE6A07B8AD43BC14CAC638730DBD@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bd4f4df-3c4a-4c31-d28f-08d74332511e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 10:06:08.6483 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZKMpJ7Y62fyOqzKN/EwQA2Ad/DWgKypen/QJKVgZRUsY5xHJ7adxEXarPZzh+zp0m5sPr+Z3XbYG0N16qA7EPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6129
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/uIMmhoWA67Ig2uHzlA3YAWUdlxk>
Subject: Re: [netmod] =?utf-8?q?What=27s_the_problem_with_NMDA=3F_was_Re=3A__?= =?utf-8?b?562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGltcGxlbWVudGF0aW9u?= =?utf-8?b?IGFib3V0IOKAmHdoZW7igJk=?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Sep 2019 10:06:14 -0000

Andy

Thanks for the explanation - makes sense to me.

Tom Petch


----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "tom petch" <ietfc@btconnect.com>
Cc: <netmod@ietf.org>
Sent: Thursday, September 26, 2019 6:44 PM


Hi,


On Thu, Sep 26, 2019 at 9:14 AM tom petch <ietfc@btconnect.com> wrote:

> Inline
>
> Tom Petch
>
> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
> Cc: <netmod@ietf.org>rg>; <yangang@huawei.com>
> Sent: Thursday, September 26, 2019 3:33 PM
>
> On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton)
<rwilton@cisco.com>
> wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin
Bjorklund
> > > Sent: 26 September 2019 08:45
> > > To: lhotka@nic.cz
> > > Cc: yangang@huawei.com; netmod@ietf.org
> > > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > > ‘when’
> > >
> > > > >
> > > > > It also says in 8.2:
> > > > >
> > > > >    o  If a request modifies a configuration data node such
that
> any
> > > > >       node's "when" expression becomes false, then the node in
> the
> > > data
> > > > >       tree with the "when" expression is deleted by the
server.
> > > >
> > > > Right. But the request won't modify a configuration data node
> because
> > > > it is rejected. So the premise of the above implication doesn't
> hold,
> > > > and the conclusion doesn't apply.
> > >
> > > With the same logic you can claim conformance if you reject a
> request to
> > > create nodes under a case if another case is active.  I think it
is
> quite
> > > clear that this auto-deletion is part of the spec, and something
> clients
> > > can rely on.  If the intention had been that this was optional to
> > > implement, it would have been clearly stated, and there would have
> been
> > > mechanism present for clients to detect this.
> > >
> > I don't like the 'when' behaviour, I would have rather that clients
> were
> > forced to delete the configuration explicitly (or pass an option for
> an
> > implicit delete).
>
> I hear the opposite from customers.
> They insist that the server implement every last detail of the
> machine-readable YANG,
> especially when-stmt auto-deletion. The auto-cleanup is seen as a
> feature.
>
> > However, I do agree with Martin & Juergen, that the intent of the
spec
> is
> > that servers perform the 'when' auto-delete behaviour, and clients
> must be
> > able to rely on compliant servers behaving this way.
> >
>
> agreed.
> It is hard to argue against consistent, predicable server behavior
> for datastore editing.  (NP containers and NMDA are also causing
> problems,
> and should be fixed in yang-next if that ever happens).
>
> <tp>
>
> Andy
>
> This caught my eye.  What is the problem with NMDA? Anything specific?
>
> My own problem is that it is different to what has been proposed as
> suitable for the previous 12 years but I doubt if many customers would
> think that.
>
>
My comments are in the context of operator expectations for consistent
implementations.

The first problem with NMDA is the new YANG library.
There is an assumption that the client can and will change from an
architecture
where there is 1 schema tree per server to an architecture where there
can
be a completely
different schema tree for configuration vs operational datastores.
There
is no such desire
or willingness on the client side to properly address this complexity.
IMO
NMDA is going to
need to function without this complexity. The benefits of <operational>
are
not hindered
at all (in a properly implemented server) if /yang-library is left out.

The IETF has completely punted the problem of converting data for a
configuration datastore
to the schema tree for <operational>. Deviations may be different.  A
leaf
may
be string in 1 tree and decimal64 in the other. There is an incorrect
assumption
that software developers will deal with these corner-cases (correctly
and
consistently).

The other big problem is an untested NMDA transition strategy that is
not
well understood by vendors.
Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?
Using the YANG library to separate the modules relies on the assumption
that
the client is capable of managing each datastore independently (instead
of
1 schema tree per server).



> Tom Petch
>
>
Andy


> Thanks,
> > Rob
> >
> >
>
> Andy
>
>
> >
> > >
> > > /martin
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
>
>