IETF Logo Mail Archive

Re: [Rtg-yang-coord] Operational State Modeling

Christian Hopps <chopps@chopps.org> Fri, 15 May 2015 13:35 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033521A8991 for <rtg-yang-coord@ietfa.amsl.com>; Fri, 15 May 2015 06:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y_JXz0fZxCam for <rtg-yang-coord@ietfa.amsl.com>; Fri, 15 May 2015 06:35:29 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4C1A893B for <Rtg-yang-coord@ietf.org>; Fri, 15 May 2015 06:34:12 -0700 (PDT)
Received: from dex.local.chopps.org (c-68-61-203-90.hsd1.mi.comcast.net [68.61.203.90]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 62BA66003C; Fri, 15 May 2015 13:34:11 +0000 (UTC)
References: <D177E7E1.1AC4C%acee@cisco.com> <CAJK7ZqLp4_dOVMcSMXP3juZHHeQJ6iLGkryJ8t6gs2Mcn=Ez5Q@mail.gmail.com> <20150513103509.GA59689@elstar.local> <D481ED34-84C4-455D-8CE5-36D01A5264CC@lucidvision.com> <20150515085228.GA4024@elstar.local>
From: Christian Hopps <chopps@chopps.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-reply-to: <20150515085228.GA4024@elstar.local>
Date: Fri, 15 May 2015 09:34:10 -0400
Message-ID: <87h9revub1.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/eUSCqnlg8Tyhpjguf75I4WVNx0o>
Cc: "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, "Thomas D. Nadeau" <tnadeau@lucidvision.com>, Anees Shaikh <aashaikh@google.com>, "Acee Lindem \(acee\)" <acee@cisco.com>, Xufeng Liu <xufeng.liu@ericsson.com>
Subject: Re: [Rtg-yang-coord] Operational State Modeling
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2015 13:35:31 -0000

Juergen Schoenwaelder writes:

> On Wed, May 13, 2015 at 09:13:37AM -0400, Thomas D. Nadeau wrote:
>> 
>> 	Speaking as an individual, while what Juergen says is true, that does not mean that existing models can never be refactored. 
>>
>
> Refactoring for the sake of 'it looks nicer' (for some definition of
> nice) likely does not meet the bar. We are talking about APIs here
> with multiple independent implementations and applications sitting on
> top of these APIs.


Isn't the idea to create a common standard way to access state and
config? If so I don't think that qualifies as "it looks nicer", rather
it allows for creating generic code one time that works on any model
including as yet unwritten ones vs. custom code for each model.

Thanks,
Chris.


>
> /js

v2.8.7 | Report a Bug | By Email