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

tom petch <ietfc@btconnect.com> Thu, 26 September 2019 16:14 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 59DF8120A50 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 09:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 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, 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 YztqejGL4IwN for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 09:14:48 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743C6120A4B for <netmod@ietf.org>; Thu, 26 Sep 2019 09:14:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K0z7xdbtIWawbu0xYxHSwzobqwHqHLzvwOs38wcOJj1g/kVdcT+KmGHmTvl12X6NcR5K9/qGWDJq6NOG20PBxUHiGn3Jq24wi5ksbICGgiAgjszdoj7gcN1w5gKr++kvljOJK+raBxNh88WiZCR84XA+5tZ2oT8jw29RfZypah7CE8tieArVLe6bgzHfeT+zUiCv7DIsgzd6bFBuBoE7t/QU2Peas565jsQXd0Y+7rO6epi11gTukaJBHF/1+pTHJJ3270iDHBOJbx8cIL2j3xO8tBUwqgLqULTKWuTBU2UC0Tl2pLsxRZwk+FPjmEW3mndyBpV4g/P8u8rULGe7WQ==
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=vHKo5uZpAL4/oCzvPSkmYngRrXhTUmJ4Z/myJBMtB6Q=; b=Xn75EETsWaprp9Ab8f4OnoS7wdqd7kQIFEH+k946/HP33VZ+0NgatkE7gWRdjD9HKzfZLN/id31bahY2uWnbfdQFwbMOhBtfIHi1Td1CqRUXUavY2zX/ui3TnSbce023PLmIYHNQjjf2GgbPsxOSor7NoYfhIOcGfqk//AZNNU8fkCNnkgzb2pqmBLRlF8DI44h23dK+ck0aIlj0fu3ZUYN2mf7QmL6hbH05aKEPLxpp+GswI2fJIcZ75iQLV1jpY3ltN82GhPiWxaxV92hWDVn1OdFgXsWF1V+nD8cSkf3btBjhiwyS4hlaIrAQjP03dNWcHUXg6Lnk4P7fMkFrkA==
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=vHKo5uZpAL4/oCzvPSkmYngRrXhTUmJ4Z/myJBMtB6Q=; b=uvhpMnveIXUOE6Gjnhb89cs8JWwj6qqCyMXpTZCFAe4LvDysgltRIwnbe8tsixWFjzfJqKbDBtF5SviKIR1F5TZPZQAXpH5EJ0Hvbbbw+IJfalZnJk6hS5RRXoETmB/VphHP82E77pSphP0vaq6LqnN8mL22/x0U+9l3izs5f+0=
Received: from AM6PR07MB5944.eurprd07.prod.outlook.com (20.178.91.205) by AM6PR07MB4085.eurprd07.prod.outlook.com (52.134.116.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.14; Thu, 26 Sep 2019 16:14:45 +0000
Received: from AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142]) by AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142%7]) with mapi id 15.20.2327.004; Thu, 26 Sep 2019 16:14:45 +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?XSAg562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGltcGxlbWVudGF0?= =?utf-8?B?aW9uIGFib3V0IOKAmHdoZW7igJk=?=
Thread-Index: AQHVdIWCScnacP0QVkaiE+VCF3oTXA==
Date: Thu, 26 Sep 2019 16:14:45 +0000
Message-ID: <01c701d57485$400d8d40$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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0117.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::33) To AM6PR07MB5944.eurprd07.prod.outlook.com (2603:10a6:20b:90::13)
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: 9620cea1-0314-43fe-119c-08d7429ca557
x-ms-traffictypediagnostic: AM6PR07MB4085:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM6PR07MB40859705427F70FB5C7B9EC3A0860@AM6PR07MB4085.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0172F0EF77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(396003)(346002)(376002)(13464003)(199004)(189003)(1556002)(25786009)(44736005)(50226002)(8936002)(6436002)(6486002)(81166006)(316002)(81156014)(71200400001)(71190400001)(256004)(14444005)(446003)(66066001)(486006)(14454004)(2906002)(224303003)(476003)(3846002)(6116002)(61296003)(81816011)(6916009)(5660300002)(6512007)(9686003)(4326008)(52116002)(64756008)(66556008)(66476007)(66446008)(6306002)(6506007)(386003)(62236002)(14496001)(44716002)(53546011)(66946007)(4720700003)(966005)(81686011)(478600001)(99286004)(86362001)(305945005)(186003)(7736002)(102836004)(26005)(76176011)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB4085; H:AM6PR07MB5944.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
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: z72e6C0ZrTP1HQuLGGM2QScxWp1/h5gIqCMfmWfp/ASEtXyWrr6+6DrsMaeexP5AKzQtAukKOnQccsCWNCBCctgHrSuT0UfqfAXbn3VFb75orRoCdoZrOSqliQ33l1F6cj61AD6N/ll9kw2yAes51Kr7p/6Osg0o0ll48YmDR9gwR6dY3NDCZuFN65fFtZOo3acElRU2yynRQenqfyc7zT1Taj+POna/A/nhY0AQ3ggoxXsyXdaMpkktE+R7uZQ5ivRca5zplXINk3hRGIb7zYxW+xCscgIEVzWzsScIb9Nw2P+oLTrUGZS3qdtTDS6Gh2zOvrV0SFHhSVN1ioDPRNceqAHBBwXLts175UofgVCEMbfUW3AnFuO2mqlxVCs6q73PuztHbbV0wZA0Bgpex+oWty+Rx8xuId0mqR+4pJvm5o6vZK1rhT5y/iEmNyujeRwDslUEh8zVkPNjI7mGDw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <767FB26D3A0BA14AA6266B88EF9D7DBB@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9620cea1-0314-43fe-119c-08d7429ca557
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 16:14:45.4651 (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: 3FXe9kOK9p1nkj5PVm9LPZC2dxV3d6L+pCbcN7E2Vj0lLPgpyIJWZZtkFH2rHf3k3ZQj0pJfGOmRqIPD/YCd+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4085
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EV8JnrYggNjsczs1YQ2oeDoa6WI>
Subject: [netmod] =?utf-8?q?What=27s_the_problem_with_NMDA=3F_was_Re=3A__?= =?utf-8?b?IOetlOWkjTog562U5aSNOiBQbGVhc2UgY2xhcmlmeSBpbXBsZW1lbnRhdGlv?= =?utf-8?b?biBhYm91dCDigJh3aGVu4oCZ?=
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: Thu, 26 Sep 2019 16:14:52 -0000

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.


Tom Petch

Thanks,
> Rob
>
>

Andy


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