IETF Logo Mail Archive

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

Nadeau Thomas <tnadeau@lucidvision.com> Wed, 26 August 2015 13:18 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 43D7A1A1BED; Wed, 26 Aug 2015 06:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level:
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Ff0nSJWkivsw; Wed, 26 Aug 2015 06:18:05 -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 C2DBC1A1EF4; Wed, 26 Aug 2015 06:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440595012; bh=DhoNZHdawI2vMqYTrpQHSJbJEknbEnmQsyGHJyohnGs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Sy87ieNQZNHx/+M7pyzjGHByotoQyEz247ErWc1KqxwqL+uAv2psozPu2cbZxiqcW yLnWqcC9JMd7C1J6RSi5CekZHvZ399IkPuFu5ImMR6WckSTKZIyAK5oP8mTG8mhXsx yTpph+ssdMzyGt3SX42jOFuUFOtsDKTwTGrmq260=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181;
Content-Type: text/plain; charset="utf-8"
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: <20150826.135823.2123307386758409523.mbj@tail-f.com>
Date: Wed, 26 Aug 2015 09:17:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com>
References: <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> <20150826.135823.2123307386758409523.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
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=9 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=1150, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/N64kxtoVZzaaxm9u9krRStLgTvw>
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@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 13:18:09 -0000

> On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Nadeau Thomas <tnadeau@lucidvision.com> wrote:
>> 	[Speaking for myself]
>> 
>> 	Is the resistance to this proposal because of the actual changes to
>> 	structure, or is it a resistance to churn/change?
> 
> The former.  IMO this is technically not a good proposal, as I have
> tried to explain several times.
> 
>>      And if we solved the
>> 	latter by say relaxing the rules around how we progress models to PS,
>> 	would this alleviate the concerns for the former?  The meta question I
>> 	will ask is: is the existing RFC process adequate/sufficient for us to
>> 	move forward on such a large scale with Yang models at the IETF?
>> 	Other organizations currently iterate on models using certain revision
>> 	conventions (that are consistent with the rules we put out here) yet
>> 	produce multiple versions of the same model within the same year.  As
>> 	a matter of fact, multiple versions are allowed to coexist within a
>> 	single implementation.  In stark contrast, the M.O. at the IETF has
>> 	been to treat Yang models much like we did SNMP MIBs (or any other
>> 	document here) thereby assuming that once it becomes an RFC, that it
>> 	is largely set in concrete for many years to come.
> 
> In this specific case the change is cosmetic but has disastrous
> effects on other standard modules, other vendor-specific modules,
> existing server code and existing client code.  I think people expect
> IETF standards to be a bit more stable than that.
> 
> 
> /martin

	Therein lies the salient part of question I am asking: is this really 
the case these days?  The operators seem to be providing an answer that contradicts
this age-old assumption. Other projects like ODL are too.  Both have real
deployments too - these reference points are not science projects. I think its
fair to bring this specific issue out in the open here to discuss because its
a real issue we need to solve not just here in NETMOD, but at the IETF 
in general.

	—Tom

v2.23.0 | Report a Bug | By Email