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

Nadeau Thomas <tnadeau@lucidvision.com> Wed, 26 August 2015 15:19 UTC

Return-Path: <tnadeau@lucidvision.com>
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 AB2401B2C96; Wed, 26 Aug 2015 08:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 auc50Bq8Pap8; Wed, 26 Aug 2015 08:19:38 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531D51B2BA0; Wed, 26 Aug 2015 08:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440602314; bh=uFDFLwYLJyKHr5IC51DyEbrDo/WDTGJArBnNkSjOrLA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=0mPb8GjhXfpKiQ8bUzRtlqjTKYQf5m2pbfXFgCz1RfawssfSPVXo1JXFDnjRfViwn N+5j4HA2lVSb7Iji63YTYigAG40kjHN4yMnflSVqbUvs6dkT74ckIzr/lSGJnCd8oF apG1PsKRrE1I19UsUie9A6xgT7SUlJHjhVuCsBxY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181;
Content-Type: multipart/alternative; boundary="Apple-Mail=_4ABF2180-4772-47BC-AE24-183B374258F4"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Nadeau Thomas <tnadeau@lucidvision.com>
In-Reply-To: <D203469D.D339D%kwatsen@juniper.net>
Date: Wed, 26 Aug 2015 11:19:34 -0400
Message-Id: <6FBD632F-7F12-4324-8723-B802DC108DC9@lucidvision.com>
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> <D203469D.D339D%kwatsen@juniper.net>
To: Kent Watsen <kwatsen@juniper.net>
X-Mailer: Apple Mail (2.2104)
X-Authenticated-User: tnadeau@lucidvision.com
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-ShareWhite: 50.255.148.181
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=16 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 103, in=1157, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/Iz00b9XxG_CDWFZ7dE3xt75XL2Q>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Andy Bierman <andy@yumaworks.com>, "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 15:19:39 -0000

> On Aug 26, 2015:10:51 AM, at 10:51 AM, Kent Watsen <kwatsen@juniper.net> wrote:
> 
> 
> 
> > 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.  

	This seems to be the case the more we think through this.

> Distinct modules have distinct namespaces and no collisions concerns.   But even better than that, distinct modules promote competition.  

	Or simply multiple versions of the same modules at the same time. ODL lets you do this, for example, and happily works.  But the other more IETF-related situation is as you say, if there are two draft models for the same features.  One could and should 
be able to run them together, for at least experimental purposes. 

> 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.

	I agree.

	Tom  (as individual).

> 
> Kent // as a contributor
> 
> 
>