Re: [Rtg-yang-coord] Operational State Modeling
"Thomas D. Nadeau" <tnadeau@lucidvision.com> Wed, 13 May 2015 13:13 UTC
Return-Path: <tnadeau@lucidvision.com>
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 7786F1A9170
for <rtg-yang-coord@ietfa.amsl.com>; Wed, 13 May 2015 06:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level:
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 i4YN1YtDDGWF for <rtg-yang-coord@ietfa.amsl.com>;
Wed, 13 May 2015 06:13:38 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178])
by ietfa.amsl.com (Postfix) with ESMTP id 453ED1A876E
for <Rtg-yang-coord@ietf.org>; Wed, 13 May 2015 06:13:38 -0700 (PDT)
Received: from [192.168.1.108] (unknown [50.255.148.181])
by lucidvision.com (Postfix) with ESMTP id B1D1534922D4;
Wed, 13 May 2015 09:13:37 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <20150513103509.GA59689@elstar.local>
Date: Wed, 13 May 2015 09:13:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D481ED34-84C4-455D-8CE5-36D01A5264CC@lucidvision.com>
References: <D177E7E1.1AC4C%acee@cisco.com>
<CAJK7ZqLp4_dOVMcSMXP3juZHHeQJ6iLGkryJ8t6gs2Mcn=Ez5Q@mail.gmail.com>
<20150513103509.GA59689@elstar.local>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/E1PciUQfvfWiItkd3qYeJaHZdDY>
Cc: "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>,
Xufeng Liu <xufeng.liu@ericsson.com>, "Acee Lindem \(acee\)" <acee@cisco.com>,
Anees Shaikh <aashaikh@google.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: Wed, 13 May 2015 13:13:39 -0000
Speaking as an individual, while what Juergen says is true, that does not mean that existing models can never be refactored. —Tom > On May 13, 2015:6:35 AM, at 6:35 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > On Wed, May 13, 2015 at 12:51:41AM -0700, Anees Shaikh wrote: >> >> Regarding compatibility with existing models, I really don't agree at all >> that the existing RFC models should constrain what we do when trying to >> meet the requirements of people trying to build real systems that use YANG >> models. With all respect to the authors of those few models (which we >> leverage considerably in our models), YANG models are software code, and >> should be treated as such IMO. We don't say that software is "done" and >> can't change -- it evolves and improves over time, sometimes in >> non-backward-compatible ways. And we don't issue a final version of >> software without considerable experience using and testing it in production. >> > > Standards and software are not the same. The value of standards is > that they provide a stable basis. In other words, the value of > standards is that they do not change every other day. Yes, you can > rewrite standardized data models but the cost of doing so is high and > hence the benefit of rewriting something must be high. I do not see > this here - not even remotely. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >
- [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling Russ White
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Acee Lindem (acee)
- Re: [Rtg-yang-coord] Operational State Modeling Anees Shaikh
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Thomas D. Nadeau
- Re: [Rtg-yang-coord] Operational State Modeling Andy Bierman
- Re: [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf
- Re: [Rtg-yang-coord] Operational State Modeling Anees Shaikh
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Christian Hopps
- Re: [Rtg-yang-coord] Operational State Modeling Ladislav Lhotka
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Acee Lindem (acee)
- Re: [Rtg-yang-coord] Operational State Modeling Nadeau Thomas
- Re: [Rtg-yang-coord] Operational State Modeling Andy Bierman
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Nadeau Thomas
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf