Re: [NGO] external module properties

Andy Bierman <> Thu, 01 May 2008 22:44 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 72DD928C1D8; Thu, 1 May 2008 15:44:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCB1228C1D8 for <>; Thu, 1 May 2008 15:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.183
X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2DcgrvqMG-VP for <>; Thu, 1 May 2008 15:44:44 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 1BE4F28C1D4 for <>; Thu, 1 May 2008 15:44:44 -0700 (PDT)
Received: (qmail 36313 invoked from network); 1 May 2008 22:44:46 -0000
Received: from unknown (HELO ? ( with plain) by with SMTP; 1 May 2008 22:44:45 -0000
X-YMail-OSG: RGbn.CIVM1kByO.vomCnGkuQ_ciC8ueW4fTna4yLVEVLNxAvfNp.Ur4K.C6P5ZXiR1O7XE7qytMcmJwKQWZD.SjZCsJGxfYuDYri2J1Gos2pUzcmL5iMAEM1KjhI7jKVkwU-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Thu, 01 May 2008 15:44:42 -0700
From: Andy Bierman <>
User-Agent: Thunderbird (Windows/20080213)
MIME-Version: 1.0
To: Ladislav Lhotka <>
References: <> <> <> <> <1209495880.15947.5.camel@missotis> <> <1209499369.15947.22.camel@missotis>
In-Reply-To: <1209499369.15947.22.camel@missotis>
Cc: NETCONF goes on <>
Subject: Re: [NGO] external module properties
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Ladislav Lhotka wrote:
> Andy Bierman píše v Út 29. 04. 2008 v 12:16 -0700:
>> Excellent point.
>> I am envisioning a system which includes a mandatory standard
>> 'schema-discovery' mechanism.  The <hello> exchange is a bad
>> place for all this versioned module to namespace mapping info
>> (even though that's exactly what I have implemented now ;-)
> Why is it so bad? The big advantage I see is that it works with the
> existing NETCONF framework.
>> The namespace URI should be stable.  It is assigned in
>> the first version of the module.  It can never change.
>> If the module is obsolete, the namespace is still 'used up',
>> and can never be reused in another module.
>> In XSD, the <schema> 'version' attribute should be used in addition
>> to the targetNamespace, to determine the exact schema content.
>> In YANG, each new version of a module (std:MUST/vendor:SHOULD)
>> include a new revision-stmt, which has a date string which becomes
>> the new version identifier.
> RELAX NG has no such attribute and nobody seems to be complaining.
> Version numbers are indeed encoded in namespace URIs. In my view, the
> revision statement could be interpreted as an auxiliary version marker
> intended for human readers - the only authoritative identifier of a YANG
> module content would be the URI.

The problem with this approach is that is it very API-unfriendly
for NM devices.  Consider dozens of NETCONF applications
that are all using FOO-MIB with namespace "foo-mib-1".
If an agent implementing a new version changes the namespace
to "foo-mib-2", all the applications that are currently
using "foo-mib-1" will break, when talking to that agent.

Since NM modules are only allowed to change in backward-compatible
ways, and since breaking existing applications to deploy new ones
is not acceptable, it is actually harmful to change the namespace URI.

If the FOO-MIB needs to be changed such that it breaks existing APIs,
then a new module must be defined instead, with a new name and
a new namespace.

> Lada


NGO mailing list