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

Martin Bjorklund <> Wed, 26 August 2015 11:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF9E71A8960; Wed, 26 Aug 2015 04:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3PzSqFJhrHNm; Wed, 26 Aug 2015 04:58:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CBD071A8870; Wed, 26 Aug 2015 04:58:30 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id ECAEA1AE049C; Wed, 26 Aug 2015 13:58:25 +0200 (CEST)
Date: Wed, 26 Aug 2015 13:58:23 +0200 (CEST)
Message-Id: <>
Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
From: Martin Bjorklund <>
In-Reply-To: <>
References: <20150826064030.GB84416@elstar.local> <> <>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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 11:58:32 -0000

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.