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

Nadeau Thomas <> Wed, 26 August 2015 13:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 43D7A1A1BED; Wed, 26 Aug 2015 06:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.012
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ff0nSJWkivsw; Wed, 26 Aug 2015 06:18:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2DBC1A1EF4; Wed, 26 Aug 2015 06:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=;
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 <>
In-Reply-To: <>
Date: Wed, 26 Aug 2015 09:17:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20150826064030.GB84416@elstar.local> <> <> <>
To: Martin Bjorklund <>
X-Mailer: Apple Mail (2.2104)
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=9 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=
X-IP-stats: Notspam Incoming Last 0, First 103, in=1150, out=0, spam=0 Known=true ip=
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>; wrote:
> Nadeau Thomas <>; 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.