Re: [netmod] handling module incompatibility

Qin Wu <> Fri, 13 October 2017 01:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85F98134580; Thu, 12 Oct 2017 18:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HsSzD0i66Bxe; Thu, 12 Oct 2017 18:30:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E93531344C5; Thu, 12 Oct 2017 18:30:30 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DXP03103; Fri, 13 Oct 2017 01:30:29 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Oct 2017 02:30:28 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 13 Oct 2017 09:30:23 +0800
From: Qin Wu <>
To: Juergen Schoenwaelder <>, Robert Wilton <>
CC: Lou Berger <>, NetMod WG <>, "" <>, "" <>
Thread-Topic: [netmod] handling module incompatibility
Thread-Index: AQHTPqafiD0PunpOs0S5Nqqj+UPebKLWYU8AgAAinACACoL7wA==
Date: Fri, 13 Oct 2017 01:30:24 +0000
Message-ID: <>
References: <> <> <20171006165342.syfqsjsdmr2tzgqg@elstar.local>
In-Reply-To: <20171006165342.syfqsjsdmr2tzgqg@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59E01735.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bd91f92fe245fa5929827f007e35e729
Archived-At: <>
Subject: Re: [netmod] handling module incompatibility
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Oct 2017 01:30:33 -0000

Thank Lou to help bring up this issue, thank Robert, Juergen, Tom, Kent to share your valuable thoughts.
Jurgen, we will address your concern in v-(07) based on your input and others' feedback.
Many thanks.

发件人: Juergen Schoenwaelder [] 
发送时间: 2017年10月7日 0:54
收件人: Robert Wilton
抄送: Lou Berger; NetMod WG;;
主题: Re: [netmod] handling module incompatibility

On Fri, Oct 06, 2017 at 03:49:50PM +0100, Robert Wilton wrote:
> Hi,
> On 06/10/2017 14:25, Lou Berger wrote:
> > Hi,
> > 
> >      As part of the my Routing Directorate review of 
> > draft-wu-l3sm-rfc8049bis I noted that there were several 
> > incompatible changes being made to the ietf-l3vpn-svc module without 
> > changing the name.  I raised this with the YANG doctors and others 
> > involved with the draft and it surfaced some topics which really 
> > should be discussed here in NetMod.
> > 
> > The background (as explained off-list by others, so I hope I have it
> > right)  is that one of the YANG Doctors noted that RFC8049 was 
> > broken and could not be implemented as defined, and therefore a fix 
> > was needed.  L3SM has concluded so the fix is in the individual 
> > draft draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of 
> > ietf-l3vpn-svc module could not be implemented, the feeling by the 
> > YANG Dr was that even though the new module is incompatible with the 
> > original definition the module the rule defined in Section 11 of 
> > YANG 1.1 (or section 10 of RFC 6020) didn't have to be followed and the same name could be used.
> I think that this is the view that I support as well.  If something is 
> clearly broken then it should be possible to fix it without requiring 
> a new module name, just an updated revision.

The hidden question is what is 'broken' or 'clearly broken' and when are definitions in a module broken and when is the damage so big that the whole module is broken. Does a broken xpath statement cause the whole module to be fundamentally flawed such that an implementation of the rest is impossible?

It is not uncommon to find errors in data models and it is then often a matter of a new revision or errata to address those. The question here is when is an entire module broken up to the point that nobody ever will have implemented it or parts of it.

I do not know the answer but I see a certain risk that minor bugs will be used to argue none of the YANG update rules apply.


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>