Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

"t.petch" <ietfc@btconnect.com> Wed, 20 September 2017 12:08 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 76B001342E1 for <netmod@ietfa.amsl.com>; Wed, 20 Sep 2017 05:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 ler4ypSvhrke for <netmod@ietfa.amsl.com>; Wed, 20 Sep 2017 05:08:18 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40123.outbound.protection.outlook.com [40.107.4.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E92133208 for <netmod@ietf.org>; Wed, 20 Sep 2017 05:08:17 -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=Glm/ovvDUNZwqluxBFhvT+0HiyGeUM7sLhYE0FNqQEs=; b=eZxOIAMtgoZ3CsfMX7nkEnZf3fkRSQM+YM/MhYuGkBbMXrF2wVgXja7gQ0kh33hoWTBm6VEwY/VlAzO4gswmiA2brVhxxmXVemtMcDlVgEcMmur8WjWOvUZ08D6mSV6SqwQPwKSHxtfNe2IYStatnfT1PBclejbrkRW5YfCOrQM=
Received: from pc6 (109.146.128.123) by AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 12:08:15 +0000
Message-ID: <045f01d33208$e8adae60$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Ladislav Lhotka" <lhotka@nic.cz>, "Martin Bjorklund" <mbj@tail-f.com>, "Robert Wilton" <rwilton@cisco.com>
Cc: <netmod@ietf.org>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <031801d331f9$e6b95640$4001a8c0@gateway.2wire.net> <6def5662-2b4f-b7f3-f709-4d133a91b033@cisco.com>
Date: Wed, 20 Sep 2017 13:06:30 +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: [109.146.128.123]
X-ClientProxiedBy: AM5P194CA0017.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::27) To AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18)
X-MS-Office365-Filtering-Correlation-Id: d847999e-9542-40cb-71a9-08d50020462e
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2996;
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:PLufzYX47qSTH+zsXGzXrZm0ppG8+2WZYoN6jvhv16NtATXM8MWgBXG43+sRBVddOxRzqldA7RyCWmWxIoZeqvyuYobN2rsIuAruISwYNye0oaRQ/gga4z1v0JwyWTNys7kB7Xa0bMBwHOfVkI/FG2jb9uRBJ3LGz8k2YDtDLi3bbyWgx6R12kp0grUvQpUG+3dMoDYxau7s0jHueQE0RNfjUVnot2/MiKBlsy4jd/fqh5ionFYNuR4rOPpeVDwH; 25:WZ7UBqBrzOOMu9bAKKvFdgRnejuG9rycAcaX4uBM6OtC/m+gxusg6pVnUJN5t09/WzzKOqMAuuBxcQxKUekZQVcP+5ew4C/FaitaaPp/q/NYDpSJtXIS7d2HsVx5ANzFsowBGxIzEBEygdvoGagzzVUpHJUcpobuSVW8EO/T+yapR/y5MH6eOMy7y84dweB3XbVhwmlIrb6Av4TASHTHbhQkZG9hvNU5KYG/DU0lATYmRp09QZXS98AZiGoUZUWPVUvMvUTUXsXJniV1WjesViQwHFI5XBzGUJArMaFj4bnI7SK0K4rDmkgIN1C0K2HUIeU8FIrNSbzAWffFOzceiw==; 31:jtu+eMHv70/wl879rFTqABFk3neN5lIf+bP3dECiC6NIV1eivlYcoCY/HfMSlUowIzzChjGnPAz6dYclF7c5B+pQ2Hd3YYuFrHPA91UIoLVlX8o04VNmF4lNQRoldd3klPzZnr34Fx44mydPQJoQTJ2Th/4i8trGelw8JppBCBy78TxyxXm7NKdBy2L7t0bC0tD3B3XKz/hxuJ+jx0D8AO/AiIuhtKJWhXZyW9YOv3U=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2996:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 20:RNqelyc1EWlCIYCKaPm1cvh65+0ZUYZtU/qjN/SKzqJbEcVJXgDbViY3flU9DdmCpmKd+2/7pbIsQ7mwJbBnQMhEtPXCVS106teqKiqopypiM9LfOoNHkHVzE/iqb5FIjXrpeaFKRpJc+LhjTPj95cbHxXEPuwAdOcOjm6TgL94Muf9i7Pew3jdnitz70K3kinmvpS6cx1kWgbR3rxo0D5eUJT8Bp+3vLNu0xMS2TqKlpNOJ2oECUGLMVxWv1ocDrlLxLdZeZ9D05IauooZCzwJDNwwyGSszZaTI/6cGwGibFyRXA+kXr28AZ2tu31useyRYUEfBJfndi7tLoLcNqg==; 4:ugKEdETE7PkFpusQut4gTwjl6rdfzMX8OUqMATKsnJ8TjeFtdcRSl+/stIP6C18bM1bPwm1gwQyuCdjHv3ekdSoySoS+lw5itYgNTxXXbJeAYF1am8NNhmL1RS671y3atN9U5OOpPLRN4DKZvZCC3Y76Uyk+X0zo54HOb+3hUkvnall80AftmgIAiSQCGEbEjNtM1zlSusEO4YSWREypUmCq/0ZHYg1IXhwVrAtfqFZXYVYPR7nyhibnYR70EXtAlpjApC38Zl3aJwvXEbXE2I4CKcHbmQ+ZT9JoIRgPDyU=
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Microsoft-Antispam-PRVS: <AM5PR0701MB29962E2125C9FD6DAE23602AA0610@AM5PR0701MB2996.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2996;
X-Forefront-PRVS: 04362AC73B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(24454002)(377454003)(13464003)(199003)(51444003)(53546010)(105586002)(2906002)(305945005)(106356001)(8676002)(1556002)(84392002)(86362001)(50226002)(81156014)(81166006)(16526017)(8936002)(316002)(478600001)(61296003)(14496001)(93886005)(116806002)(97736004)(110136005)(230783001)(7736002)(1456003)(33646002)(4326008)(81686999)(81816999)(76176999)(50986999)(50466002)(6666003)(561944003)(4720700003)(229853002)(101416001)(68736007)(9686003)(53936002)(6486002)(44736005)(6116002)(6246003)(3846002)(66066001)(230700001)(44716002)(25786009)(62236002)(5660300001)(189998001)(6496005)(23676002)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTY7MjM6MlBRdFM2U1dSZ0c3SkhTeXp1N09FaHEx?= =?utf-8?B?UndQOEhvM1FHYmRHUFhzMVFZZWh6aEY2cVpTN0dHMUJJQVpna0pUbTB0L1Rp?= =?utf-8?B?RVgraVhFdkx5ZXBpZjVMb0pySGpWZmpnMXJOaWg0Yll2SVRZanh2ZStCNGlj?= =?utf-8?B?NFl4UHBqUnN4Z3JPcThPQzhIZkVaalNYTWNVZ1NuL3lXdmcvMFlZTnFtTlNM?= =?utf-8?B?VW4ydytnOWNEWm5GZUJuTElSYjJkYm1naHp5a21YcTg2R0FTM3doSjV4bnFP?= =?utf-8?B?Yjk1ZUJ5SWRGS0NpRU9OMlZMQUcybkY1bThaSzk4UWdsS1hHbDlWNHJPM3VS?= =?utf-8?B?TUN3TTRVTjd4dmlDTE9iQUFUdjl3RktvWnU4dVBuWnpMY21pMFVzWmZwUjls?= =?utf-8?B?WlU5WW03QVNpbGI2eTVpamNiK2E2OUwzT3FZeDhBQ2hrVW1BTXBIL25nNUE1?= =?utf-8?B?SlU1U3YvWjZuVTZsUmxCZnFTNzFWUFlndTM3OG1zKzROYWJiMVpsMC9zNlpa?= =?utf-8?B?U3VMNkxjaEd1ODJ1d2MwbHhPY0ZJUlpmeXppZ2tLK1R6MmkvbFh6QlpnLzVt?= =?utf-8?B?bjM5Y1U5a2l5QjQwVk9ZYUVUNUtiNjdoWWdyakVmL3U2aGthZHFvelpNc3Y0?= =?utf-8?B?b0g1bllwUzQ4NUtWRTBSK1ozOHVUQjZLVDdRNXRmY3BPUlkvZjR4M0hDRytC?= =?utf-8?B?a1drOUJMVWdHdlY5WkQvVUVnRzVDRVJQeDRKWlRQUTNDYUpzZnZ1QTVyMmxE?= =?utf-8?B?SDJUZEZuSjQxWm4zekQwVjZFeTBadnN5TUFBRE9MQmRtN0hOSTROdnVOS1lT?= =?utf-8?B?Yk0rU1RWVXh1dnJxSEtEWDUzOStKYXcwNllZbEVmWUFZcWpNaUFqU0pYRjZL?= =?utf-8?B?aVBzQldyNE50b2pWU2kzdUhUZVlzb1ZacVdGZHBMSW9ZOGY2U0hscmZmQ2da?= =?utf-8?B?RTF4RVhSTUc5Wks0cGo4Q1ZwdzBHWHh3ZXpsMnk4ekJGVTF3TDE1TG1hUkJ2?= =?utf-8?B?eEdKK1c3Z0FHcVVTMDQvRkpwbEEybGJqQUhwbjBueEM2dUQ3L0k2MTZndWhq?= =?utf-8?B?a1F1K0NTeGZPYk1ZN1NZK041cEtJZlgwdE1pa3kvQnZKS2dQdU42bUJadEZa?= =?utf-8?B?SnJ4YVhVNjluY0hubUtOYTU1dHR0VURUN1JiSnF2aFh6RFhTU0RIWnp5MEtC?= =?utf-8?B?ZXpHbFlSTWpkMG9RYytnbVI1L2ZhZ2tneEQxdHJpa1dXbyt6M2hFelYwZEla?= =?utf-8?B?M2pEbjFwT3lPbXprc0MxZHQ4cmpQbWVDMHpEZDZrNE1va1dpUWdKV0haN1cz?= =?utf-8?B?dkcxQmtNNU1CVWJpaStkaW94TmxGUWZyYUo4REtRSm5tTnV4VXBYek9BWkZS?= =?utf-8?B?VDdzK0pJY1NFcmVTYTlzRlcyTVJOWDRESEs5UUV6NWFZMlRtc1ZKRHdKampx?= =?utf-8?B?QnNLMENrNjBIdmhISkdsa3Nnb1VpVDJ2N0lHSXZFZW4zMmJEVER3NmdlNTkr?= =?utf-8?B?TGh3WTFXdnZoemVCRk5BQXREVkZUcFFVOXhTWGZUUTZCQVlraWZBM0JxZVl1?= =?utf-8?B?anlOTGxPblV5bUM1c2tGRFRYQ0V5VTEvNUNLdis4THNQdC94NFR1bDdCVmJG?= =?utf-8?B?aldKUXRjY1ZXTHpJcmxZb3p3SlE3TnBKd3ptMUlCVVlKMzFBMVZ2Zk5jTVdE?= =?utf-8?B?TkZucktNTlhzTWs4SzlKczRJSFRQNVREaXR4eDlJQUEvZUJpb3p0THo3eGJo?= =?utf-8?B?Wmxwa3Qzc2o2M0VIOFc3T1E4eDRxWXVjWTFpTXFURC9xNUl3aElLSFV3UGFz?= =?utf-8?B?R09nV2RHeTgwSUtUNEwvbHZrcXluenVyWm5ldm5YMmljdnV6c0toQzRRekkv?= =?utf-8?B?aUwveXFvcW5oTjZNcEJtU2pIR0xveHc5UjJvaGRhL0NtUXJNQk5NVDlpcTAv?= =?utf-8?B?UDltSFhwR1l2NEEzaUxUZnpNMno0eFZjb1kzSUowSGt3ZGZ2MXdSUVdpaVI1?= =?utf-8?B?dk5zYjdFZ2ppRE9vNSt1cWFhbGt3KzBUYzZXeHh2SytXeng4VFVrMGZXVW5z?= =?utf-8?Q?M+Gi6z5xs8OFkYzmr3DDah7x7c0?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:ftHFL+g0KTz798bKPNd7RpAiG6r415rIpa+V+VZHkGGL50YYsgGy9J1Mp56FjSI6oHx6R05MV5DDcoqR8kavANZhoQ1bgNNl0XYXEZaUOtkc2t5mEvAM3diXSkw2qNO3IL6dotc/bKDoxlFp7t6kDjBUeSUEe3Qpg6/mp+fWwYhM8s8FkXtRAjwVngpoXamjafYJk3sC2e3sztuKFLt0Bp5EYin05tavxT/A3+zKqQxwKIlTSQZIz3else0eYjJ3SKiGtgljQ3bIX9cU3xlirhetWUuVpGbq6eEo8JheCa7V1G2bxjiMCPeF7ELft0b6xtcGXAeRReITnlwX3p5Oxg==; 5:Y5Hrp+bGTfIB4Pc8HRTT0dYQoWxw79GYJ5qQ7ePQyGmT2WtnlK89ZlNh92tjPbtakFvkfaTfBMYCHXjlqP5f+GHkI4y+AeMXSEnfcUEQBtSUtZCVZcZ1tyfI8/wb14LNdtIvSIkxFOP4lGJ9ritHQw==; 24:XO3T3KacOxEbzzC0nnZ8tAzpFmBh8U+u0wTO/b/8yF0NH5Ynzwb1jjLtVEDd/mN1lMq5mTxNTYggLbUoK/IMmAQRTAZcZyn9zIp7XWOvAqo=; 7:2zXsq+3IusjzcXsEGn4vn/ejDsaGqxtHgDfKw1afjSOIs8cmxAIoKpEVB6ambKI1eVbtA4Hv3PBIMYG+f+9uvtEwW7eBAGUSuflpN4RK8H3gqp1cyGXaqAS+evIWEI6nwi4jaPD9KCUWzDL05BrptV0m4FHIwA3JVXD3GA1qGyI3dZjdRWyhJqlMbANl2TuY5mfOU2zF9NJHygvIxJy5HHvfALeD7dalnIZ2xFZfTSQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 12:08:15.5758 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Bch3qG7GK6ghVyRXs_K7EjU6ZRM>
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
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: Wed, 20 Sep 2017 12:08:20 -0000

----- Original Message -----
From: "Robert Wilton" <rwilton@cisco.com>
Sent: Wednesday, September 20, 2017 12:04 PM

> On 20/09/2017 11:18, t.petch wrote:
> > ----- Original Message -----
> > From: "Ladislav Lhotka" <lhotka@nic.cz>
> > Sent: Tuesday, September 19, 2017 2:37 PM
> >
> >> Martin Bjorklund <mbj@tail-f.com> writes:
> >>
> >>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>>
> >>>> I support the adoption but I propose two conceptual changes:
> >>>>
> >>>> 1. Introduce a new module name and namespace so that it is not
> >>>> necessary to carry along the deprecated baggage. If readability
is
> >>>> the primary concern, this is IMO the way to go. Instead of
> >>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> >>>>
> >>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
> > continue
> >>>> to be used
> >>>> in areas where NMDA is an overkill, such as open source home
> >>>> routers.
> >>> Why wouldn't NMDA be appropriate in an open source home router?
> > Note
> >>> that the new model really just have a single tree instead of two
> >>> trees, so the data that needs to be instrumented is more or less
the
> >>> same.
> >> It is quite likely that some parts of the data models will be
> >> implemented only as configuration but not state data. In the "old
> > style"
> >> modules it is easy to add a deviation for the node(s) under -state
but
> >> in NMDA style this is not possible because we only have one node.
> >>
> >> There are subtle differences in the schemas for configuration and
> > state
> >> data that the NMDA concept doesn't address. If you want another
> > example,
> >> ietf-routing-2 has the "router-id" leaf that is conditional via the
> >> "router-id" feature. If this feature is not supported, router-id
> > cannot
> >> be explicitly configured (it is assigned by the system) but in
state
> > data
> >> "router-id" needs IMO be present in any case. But the if-feature
> >> isn't able to differentiate between configuration and state data if
> >> there is only one node for both.
> > So add a second node!  I think that the idea that NMDA eliminates
all
> > duplication of config and state is a myth; there will still be
> > duplication where the life cycle of the data diverges, ie it is not
> > really duplication! I think too that the twin trees approach, while
> > clumsy, was easy to create;
> Easy to create, but just as easy to get wrong. Alas, with the twin
> trees approach, the config and state trees can (and do) diverge.
> Different WGs within IETF were already starting to model the state
> information with different tree structures. Some WG models includes
the
> applied config value, others didn't. We seemed to be loosing
> consistency between the model. My opinion is that the end outcome of
> this would effectively require all clients to write custom code to
> correlate equivalent information between the config and its related
> state, which doesn't seem great.
>
> >   the NMDA approach is more subtle, more
> > complex, easier to get wrong.
> Yes, I agree the NMDA approach is a bit more subtle. And there are
> definitely some concepts that probably should be modeled slightly
> differently:
>
> A case in point might be "interface MTU" that can be automatically
> assigned (the default behaviour) or statically configured.
>
> (1) A pre-NMDA split config/state model might have:
> - a config true interfaces/mtu leaf that is either "auto" or a
specific
> value,
> - a config false interfaces-state/mtu leaf holding the actual
> operational value,
> - [potentially also a config false interfaces-state/cfgd-mtu leaf
> indicating the applied config value.]
>
> (2) One way of modelling this in NMDA would be to split whether mtu
was
> auto vs manually configured separately from the mtu value. So this
> could be modeled as:
> - one config true leaf that represents with MTU is automatic or
manually
> configured.
> --one config true leaf that represents the manually configured and
> operational MTU value. Allow with an appropriate constraint so that
> both leaves are not configured.
>
> (3) Alternatively, in both pre NMDA or post NMDA, the model could
assume
> "automatic" as the implicit default MTU behaviour. In this case you
> only need to have a single leaf in the NMDA model (or 2 leaves in the
> split model).
>   - one config true leaf that represents the operational MTU of the
> interface, which may be configured if a specific value is to be
enforced.
>
> For MTU, it is the third approach that I prefer.
>
> Another similar example is Ethernet auto-negotiation, where (2) looks
> like the best approach post NMDA with an explicit leaf to control
> whether the auto-negotiation protocol is enabled (rather than
attempting
> to merge it with the speed, duplex, and flow-control leaves). But in
> the end, (2) also has the added benefit that it actually more closely
> marries up to how the auto-negotiation protocol is defined, and what
> functionality is actually allowed.
>
> I think that building up a set of these examples (probably on an FAQ),
> of how particular abstract concepts can be effectively modeled may
make
> it a bit easier when folks are trying to figure out the best way of
> modeling something in the post NMDA world.

Yes, although I would make it an RFC,  guidelines on how to use NMDA.

The examples you give above are spot on, and we have had many such over
the past few years.

Tom Petch

> > I recall that in the initial stages of discussion of this issue
there
> > was a proposal for an object to have potentially eight different
> > characteristics so what NMDA gives us at present is limited and will
not
> > solve all the issues of needing more than one node.
> I think that I missed those early discussions. Perhaps that was a good
> thing :-)
>
> Thanks,
> Rob
>
> >
> > Tom Petch
> >
> >>> In fact, if we claim that the new architecture is not appropriate
> > for
> >>> some devices I think we have failed, especially if the conclusion
is
> >>> that we need to maintain two versions of all modules going
forward.
> >> I am not asking for this but, on the other hand, if NMDA versions
used
> > a new
> >> module name and namespace (my item #1, which is what ietf-routing-2
> >> does), then I don't see any pressing need for obsoleting the old
style
> >> modules.
> >>
> >> Lada
> >>
> >>> /martin

<snip>