Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton

"t.petch" <ietfc@btconnect.com> Thu, 14 September 2017 16:39 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 3B54C132924; Thu, 14 Sep 2017 09:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 MG308JTkemjU; Thu, 14 Sep 2017 09:39:17 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754DA13305A; Thu, 14 Sep 2017 09:39:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Izoydb1LHpFHgHpjzc6DK0PicFIczr47s0fUchK8VTo=; b=RC5zTLb9c9yZeIExsljuXnUPwsJZfYhbUhE+z6NkAkSr4D4WXBMyZ3TcOQvEy72WXLi/OT2O1WZCJJlrwZITW+wWIDY3h5G6BCDMuyqlikbViVxMiPQZdHLWfgJSYNdcEy81zh5xevO4OiBCZZnrKEDQPWBeqBsVhza37Ji45Wc=
Received: from pc6 (86.185.245.5) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 16:39:13 +0000
Message-ID: <011e01d32d77$c980dca0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: netmod WG <netmod@ietf.org>, Lou Berger <lberger@labn.net>
Cc: netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net> <92a410a9-e479-2321-7420-4bd2d9dbed38@labn.net>
Date: Thu, 14 Sep 2017 17:37:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.185.245.5]
X-ClientProxiedBy: DB6PR07CA0180.eurprd07.prod.outlook.com (2603:10a6:6:43::34) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4ed8d627-7fec-4e1c-e5f2-08d4fb8f224f
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3007;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:/Zsuo048TJPoEkrz0B6pdUrLIAtjt4UbmBwYklh3kW9njzLmDlSQBiIhxqwQFwwOBNN/SW3F/twqz44ML/Bo7mvuV8f3jJnM6KNctzojz8ccs69bDxnd3+9Bwa+22pJxKAo9Zdl228/6eCA3/36/KAzX4cmNnXy9ODdkxoN857JsvoXpcLcudURAzvajt+BhdHI7Myh2rjLYEUqH5LLgh+jUS7T+9i36eac0RWZ6K7Qy7cBKaDgy6iGkpraGTTvR; 25:I/hhdWATVVEUasLFJJZAZ6dc2b8QdNMBa0JZ5AJAyNGUOwV2sJOBoTk6WBbnFxdgFUYTPdpkTePxC6LDxuF8fRi5p429pCmts+rVn5rw/V7qE4tM095WiofftuUTzET+CkIgGfcz+MHn7GHEcVl4dXrKwFHgCE0H/G4/94kUN8I3AGTElcsDe78XhRkzk5fFg8uk7t/ssZkdaBqRgyV5dL9bmJxxFm2rHpPnG9InW2ltrWaiML11SfeoXVQyS43eCx6cogVH4BpAyn/axsyGXgPdaTv+KBze8hIWRpwthUg2S2JIlpwZVojbk6rzj7xUHvoBjVHwYInU+4vbV56CmA==; 31:FcZltyFClVYvhX4I2rC3nbH/gPP+qbd6qtgPlI7ImKA6KR3jDwgRE8YDNftn/pz75CQcO6QCstdQMkzv6F3/eZYu5MtWa+8AgG2OP0eZG5qjaqdfoDs8ZBs5DlQVCBrKbd5RQ8w39q7vEJA/cbY4dcwLU9DZ6rDvpTMjYdsXR/mLR5pd7taChMWcyUkS0kT9wqOBIVz0r36FYG/rcn/9u0/EfuA0/yhHjYeOtyB1+Fg=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 20:mTAOXf/gqSOTfY2baEVOunt7BajLshUMzsMUEHxn2NMj95I2h2UIIxMFnT1zJ0D9pHWcX2rI7vvwJp5wVehBQoYWOv4Ng0zFUyGVQ409Dbp3NAPC66JMWw9fHW51uTZbuHBg6G1QfQvya0d82wzdaf1qcjvChZ8S4OGg7vYY/G4UFJlvTqzASaMia5uyIgPBAmSknGhHmaSwSZwntjtdyQras6CerxPT9oB5irwHu5xghehMVk/LoKUoEIAW36my; 4:q+XKPOUnEfYt4DHBx/L7lehDsGb/3V6v+nA3Z+x/4oPtj8KUmKoFTgpgX9JUmcmUg5TvcGALPMvkA9LU2szraWn1bX/N5SeW84ke+rRtpEvt9KdyACijMmw9bY/gUpCCvfZQN9of7EZc80X07Z0dBKJ8K3pBFDBfohazapC3LffiX/bjyIpgLoJO8ECvryo+rrNFeIujDwDjBY5e3shUpu1xpcgWOYqXIKq7OF+k2V5d6PSQuH1u1lIP7hfA1TPki9P5QzxcoIQs4HPZ7/kDzNPwbGXJ9ILFmlHqBYLE/UY=
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574);
X-Microsoft-Antispam-PRVS: <VI1PR0701MB30071BE9F5024F5306D42263A06F0@VI1PR0701MB3007.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007;
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(376002)(346002)(13464003)(24454002)(51444003)(377454003)(199003)(189002)(44716002)(62236002)(478600001)(101416001)(305945005)(7736002)(105586002)(106356001)(53546010)(47776003)(61296003)(6496005)(7350300001)(33646002)(4326008)(6246003)(14496001)(66066001)(50226002)(6486002)(54906002)(9686003)(44736005)(6306002)(25786009)(189998001)(229853002)(4720700003)(6666003)(68736007)(116806002)(230783001)(23676002)(50466002)(966005)(8676002)(53936002)(2906002)(5660300001)(3846002)(81156014)(6116002)(81166006)(230700001)(316002)(1456003)(1556002)(76176999)(50986999)(345774005)(86362001)(81686999)(97736004)(84392002)(81816999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB3007;23:X8cMW3CXw6i8CCXlIPdehaXWiotK9OSVOFY2CH2eG3VkfjfVPD8rqPyc1qR4t4afuJ37wFQpUqvm38JHpquZEGvY/R9K0cqfnwqi/5dCAvtaiKeveNScTNQlcoPRkBZxaP71FIzTGewBX9lMpkHWWZO7r8X61jfd1e/Vusxu53yY+Gkixd8sm5/g3TbDYeziLWPeNVZ1uLtn04JxQDIToIEISBHE2IG00lHgiGo89bakSrraEQB24EZag4Djd6ZJJhmnPyRH7lEFP8YW2i1GzfH+nanAXSBlIlpsKsBSQNF4rc2/tQOQ1xm+IiN5rZqEgW267gk8Xjhzcy/xH6TwBuGVMaiitKS9fpx6Jphwjblrl9AmbHAEQ9TMIejHL66qbJFwsuam8eK0bmvYqAd95wOVLpp9lc1+i0+bP/r3HQNFwK09ELfucTjBnuL+Ou9gLe7bZrWlgvCOILu1nhHcqwLugrPSGti/dP4ZUfraHUjQccgs1lhVze3UPHrhU3ByxgnopJkgfCbOjp2oxDDPTqM48KpZ0aQX+aE0nGmFsJjLrnLwuSeHQJUuWI+u1VQm3o4N5uZm6HNTqUE8wSv+L8ssTUbDJBHOhmnwiO2XmRKrLH369pFDNe9QbCtajcvbCjtEd/lFLv8afD0pbzWRnaBKab+b0eZEqcWJLHQVrMIMBvTfpQ2ViSnV+VuDUnz8aWZfDeImeY4dob0Vvq3d5xH+JpkzJNgs19UFT9nKZhT1Qv7L2EfKvCdwT8uQDP1S3E8AN4QfoY6ByggyeImannhLI7bNHSd4waYMjs4oRYHZ49jjD3ZwrXrFFsXXdnlH11EHCFU+ii9RtIh3StpkAqicoGawv02FRATHnbywaiokmVCbsh/1xGYCW8Iz5YyRGzTuD2CIMDxSlRO+bV3DRpvYusYQEns4oPTkAETYNw9d2hcqaACZ6iaNdk2b06dIOUGL24tlo60nfNGqThC0BW7isrsYhBz5pnuZw+ab8v2YgOofYbG4Y0c8jtLxmmPQ3BeWXJSPBYx5Na6GJOO4jTQojhfisZEjIAI5Ug/kDJKlt9nPZw2pLmzTOmx8Ui1JMGeu/n9o73GYaswC20+KEfcHFBkU9qwoOCB+C7Kvk9NadYcbMWK/CvIxe2NgZ4lPM1de4F344nheF4N8Yrxa+xreeJsErCG5cFdMXdad6HBwX49T/ni7IVVF1MXY2PHqgPo18K7u6nDrJbekiog6izYG4VfNQDNWrNgV1lXLPCpC21DiqbsXkX9CmtiefnjYZDiHt353SrLvbiZak+HeMU+Diif3Lrv4Ol24hbm5YsFTgLfx3vQ6gBkbEArdDTil633poL2zqEJy8Zc6DgpCjnCX0wo5hQrngEj/U//X8lv47Xq8aHFz+Z13nAG0VOJlVgN7Ct7vju873ddyqoOmWm8hV3v0YuBwZk9sAvFvNSNm7VphM/OsZzHwi8loLL5we1O8k66FxqbeplN6fFwyFgvM+ILFCFmxmzsUEnUFB3jobdLx4cX9xvzBS8iZsL6PcQnnuYNdjvrjoCOO1/taaTpwlkdqYbONuAC0YMPip4+Qn8+Po5FIw+C+txZ4H2Af
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:YJYpQC2OilQkYYl1WLHbvC6+YSKwKewcG7ezotYRgtJVInDar3J+h9gXUkQte7fM5mU4MMn2K1oZUCNbEkkL+yAlLCnBK0HJRK7h7RH8aGIyTjs537FRQK23TgLSC+cw2FHGqVn6BJOM+OcHPYRLyIs7idT4sc+qXJIXq/hNneM9eoRrEQnKfsiXJw65KWxmSEaxBiNvhAekCseKZT+U2jXTzf7ybKminR0uhP7JL6L5D4iW83hrw6Yp03uq0fHW8JcO3Q1ZrtMuT4ohVxLy+vb/hUzjLoaH+G7Tgx00LHgHXSpm+L4asuok55fEdD4LfLNWIUs139HYORSjfFR92A==; 5:kfYgSkx24LjCTwZePT8vmUkXKgSCJeyqtWzBdwI2UIkXgZQTNaN2eenPdTDR8Io+8FGDZKP3AtvcWn8getZ5ZZx+enGYasX/xdLCOtIIQM8ywecmmKZ1mBeC7LejyaRi9iSnMeVp5lFdksgRy+w7dg==; 24:i3bqjjRbjv5gsRpYu+tXqTin/l8zIwHAcUlhYViM3c3GvztZQRQUqXIZBhhbQ6Ghf0/c1EkEfBgJERNFmeR6rvZ+MPNYb+G/IwuHeEWyO3g=; 7:ARtmClvqgw8pPGSlJmPslDg23yJfIvb/q13qaeXK0fhvUfIr2gmjeyGpsnPioH/izN1Kjq5bjV0icr4YmeaJv2Uo1MSaKeVA4tZ5yYFYihPHvllTE6NyC7lAP9PIfrNSDr3h7DiLjOIcuqBZ7UvD1JlyweZjArceJ+v47uuAlcJpm8U4HkgVYHIBeB6j9km4jKBmnJGlPF+R9Wdj4IXnP+H9CbPqnzHbf9qMfTOlxFg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 16:39:13.4545 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ux7yAtGCDai1jDlh8OQ8j3BW5aY>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
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, 14 Sep 2017 16:39:19 -0000

Lou

I am proposing that the text I included would go more or less as is into
the beginning of section 3.  I think that it makes sense even before we
get into the historic definitions of configuration etc.  I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores.  Thus start section 3
with

NEW

Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.

 The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.

This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems.  Having them in
 separate branches in the data model is operationally
complicated and impacts the readability of module
 definitions.  The relationship between
 the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.

With revised datastores,  the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.

 Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.

/NEW

I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material

Tom Petch

> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
ta
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >

Tom Petch

----- Original Message -----
From: "Lou Berger" <lberger@labn.net>
To: "t.petch" <ietfc@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-chairs@ietf.org>;
<draft-ietf-netmod-revised-datastores@ietf.org>
Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton


> > I believe that text such as this would make the I-D much easier to
> > follow.  As it stands, you have to read between the lines and
speculate.
> Tom,
>
> Thank you for the comments. Do you have a specific change in mind,
> or could your propose text, that would address this?
>
> Thanks,
> Lou
>
> On 9/13/2017 12:42 PM, t.petch wrote:
> > I think that in one respect, perhaps the key respect, this I-D fails
to
> > state the obvious (or at least what is likely obvious to those who
have
> > been at this for a while:-).
> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
> > I believe that text such as this would make the I-D much easier to
> > follow.  As it stands, you have to read between the lines and
speculate.
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Lou Berger" <lberger@labn.net>
> > To: "netmod WG" <netmod@ietf.org>
> > Cc: <netmod-chairs@ietf.org>;
> > <draft-ietf-netmod-revised-datastores@ietf.org>
> > Sent: Friday, September 01, 2017 10:02 PM
> >
> >> All,
> >>
> >> This starts a two week working group last call on
> >> draft-ietf-netmod-revised-datastores-04.
> >>
> >> The working group last call ends on September 17.
> >> Please send your comments to the netmod mailing list.
> >>
> >> Positive comments, e.g., "I've reviewed this document and
> >> believe it is ready for publication", are welcome!
> >> This is useful and important, even from authors.
> >>
> >> Thank you,
> >> Netmod Chairs
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
>