Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

Kent Watsen <kwatsen@juniper.net> Wed, 26 August 2015 14:51 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0211B3035; Wed, 26 Aug 2015 07:51:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 f-Kxt9HGkD6t; Wed, 26 Aug 2015 07:51:46 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE891B3016; Wed, 26 Aug 2015 07:51:45 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 26 Aug 2015 14:51:44 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Wed, 26 Aug 2015 14:51:44 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Andy Bierman <andy@yumaworks.com>, Nadeau Thomas <tnadeau@lucidvision.com>
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Thread-Topic: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Thread-Index: AQHQ2hI2vvHP2Jfp7UmC49Y77azqQ54Siz0AgACDKACAARvMgIAAXceAgAkYyICAAD9QgIAAMowAgAAMcwCAABNhgIAACXwAgAAQ4gCAAAcMgIAABYGA///M4AA=
Date: Wed, 26 Aug 2015 14:51:44 +0000
Message-ID: <D203469D.D339D%kwatsen@juniper.net>
References: <D203014F.2CA9C%acee@cisco.com> <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> <D203327E.2CAE1%acee@cisco.com> <ED14E3B4-450F-4E33-A786-8767E55C7002@lucidvision.com> <CABCOCHSxEwjuiU8PSJ9hyN_OxsdD1Xvu8-1BCL21G5rv=8NdtQ@mail.gmail.com>
In-Reply-To: <CABCOCHSxEwjuiU8PSJ9hyN_OxsdD1Xvu8-1BCL21G5rv=8NdtQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:Au0/pJ7utoBQ2VEdV3acNbJFWAA3AxoxxBbWXJ2abWadI8EP2edQOA9xcjXMC9JLCwaoPagwiPCIQmKkrgEAYn6/cphdV4F1pJ+ol+vo/G2P6jZQ7f1pTTZd1F/JYasXa6d9VN40YJcPfYSpTSEe8A==; 24:Tqa1NMrmVUiE5Ehyqd2xyAae6jT2WfAJuk94g4zJL/Qf75OWB0Q+as3qNZPtXrBDc8/a8sr0kGUEDog4AJ6LZ/e3B0Bj5hlaaAEIOIJI7/0=; 20:kUyXQVAXnFBkvJInenBPNNUiwDF5FHIkhCIA5aTLVFBGUzphaVJgVz70MS57z2tOFO19kTwiF9Np79/T1VwuzQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: <CO1PR05MB4589A9D70D4D55E490C876DA5600@CO1PR05MB458.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458;
x-forefront-prvs: 0680FADD48
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(105586002)(16236675004)(106356001)(102836002)(10400500002)(99286002)(106116001)(36756003)(54356999)(76176999)(4001540100001)(50986999)(46102003)(68736005)(93886004)(81156007)(4001350100001)(230783001)(87936001)(2656002)(5004730100002)(77156002)(40100003)(2900100001)(5001920100001)(62966003)(2950100001)(92566002)(86362001)(5001960100002)(83506001)(189998001)(5002640100001)(5007970100001)(101416001)(5001860100001)(66066001)(5001830100001)(5001770100001)(97736004)(122556002)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D203469DD339Dkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2015 14:51:44.2198 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/FGPv9B_6mcmR5VLiFJxuJ_aDUJw>
X-Mailman-Approved-At: Wed, 26 Aug 2015 11:20:04 -0700
Cc: "netmod@ietf.org" <netmod@ietf.org>, "draft-rtgyangdt-rtgwg-device-model@ietf.org" <draft-rtgyangdt-rtgwg-device-model@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2015 14:51:47 -0000


> Another approach is to not rely so heavily on one giant uber-tree
> that MUST be correct on the first try and never change.

I agree that an uber tree stands to make things worse.   Distinct modules have distinct namespaces and no collisions concerns.   But even better than that, distinct modules promote competition.  I have no issues with there existing modules with overlapping concerns, even when implemented simultaneously by the same server.  I'm projecting, but it seems that the uber tree approach would put a freeze to such experimentation, which is fine for a specific project to hoist onto itself, but seems inappropriate for a standards organization.  Again, I like the idea of relocatable modules, as it seems to allow coexistence of both options.

Kent // as a contributor