Re: [netmod] Y34 - root node

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

Return-Path: <tnadeau@lucidvision.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DAB1ACD77 for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2015 04:17:26 -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 S3MZ-4_U9VWB for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2015 04:17:24 -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 CDB4C1A8F3E for <netmod@ietf.org>; Wed, 26 Aug 2015 04:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440587781; bh=+hSoSJQq90mnK1AYImF0Da+yU8wsNEGE9sknwDjCe2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QrgQLOaqfT1VnrEfS2RkjLqgV65LNRg0O51kserC1lQB/MeZeyP24bxTBTjBfm/Ar 1BlaNAdq9yI2ve2/6/HDjCifQu5UHk16JeqeglOMKuwWkARUPYpjbge4RwIW9msrr1 FtXj0OOispOizhlFd31Z7ARAlaAI4saoTi3r8V9E=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181;
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5729ADB-CEF2-41A8-AE15-717A9F1F50A5"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Nadeau Thomas <tnadeau@lucidvision.com>
In-Reply-To: <D200EAAF.D22CE%kwatsen@juniper.net>
Date: Wed, 26 Aug 2015 07:17:22 -0400
Message-Id: <F20A48FA-8FE1-4696-9D92-56A5C81FD948@lucidvision.com>
References: <CABCOCHRgAHah6_f1qZkPs0_v8Cj6NA5TKokb_RtUv+XWNOocFA@mail.gmail.com> <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> <CABCOCHQhNp99RNvfTJqgDn48+waTjOgjbwS=TcFe4HMXct8J1Q@mail.gmail.com> <D200EAAF.D22CE%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=Unknown ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 1, First 103, in=1141, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/eg0zMPIP1bjFL02o0whbAJe06WI>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Aug 2015 11:17:26 -0000

	
> On Aug 25, 2015:1:25 PM, at 1:25 PM, Kent Watsen <kwatsen@juniper.net> wrote:
> 
> 
> I like the idea of relocatable modules.  It is almost to say everything defined by the IETF should be a grouping, allowing others to assemble the pieces as they see fit.  I do not think it makes sense for IETF to define an uber structure, especially using a language mandating forever backwards compatibility… 
	
	I personally think this is an important point not just for a list of the most recent incarnations of modules, but also as we (perhaps rapidly) iterate and rev modules going forward.  In particular, think about this within the context of the RFC model and what that implies going forward for model iteration.   Assembling pieces, including different revisions of models, is something we should think about.

	—tom


> 
> How to support logical/virtual systems is a bigger discussion.   Certainly there is a huge data model overlap between the host system and the logical systems, but some data may only exist in the host system and some data may only exist in a logical system.  Making things more interesting, some data in the host system (e.g., an interface) can be exported to a logical system as a read-only value.   The way I solved this in another life was using conditional enablement [1] on a shared data model to indicate the applicability of nodes in a context.
> 
> [1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
> 
> Kent, as a contributor
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod