Re: [NGO] external module properties
Andy Bierman <ietf@andybierman.com> Thu, 01 May 2008 22:44 UTC
Return-Path: <ngo-bounces@ietf.org>
X-Original-To: ngo-archive@optimus.ietf.org
Delivered-To: ietfarch-ngo-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DD928C1D8; Thu, 1 May 2008 15:44:45 -0700 (PDT)
X-Original-To: ngo@core3.amsl.com
Delivered-To: ngo@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB1228C1D8 for <ngo@core3.amsl.com>; Thu, 1 May 2008 15:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.183
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DcgrvqMG-VP for <ngo@core3.amsl.com>; Thu, 1 May 2008 15:44:44 -0700 (PDT)
Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 1BE4F28C1D4 for <ngo@ietf.org>; 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 ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp119.sbc.mail.sp1.yahoo.com 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: <481A47DA.8090708@andybierman.com>
Date: Thu, 01 May 2008 15:44:42 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@cesnet.cz>
References: <481742EF.5030607@andybierman.com> <200804291611.m3TGBTHr088389@idle.juniper.net> <20080429.191023.153396365.mbj@tail-f.com> <48176253.1070102@andybierman.com> <1209495880.15947.5.camel@missotis> <4817740D.5080803@andybierman.com> <1209499369.15947.22.camel@missotis>
In-Reply-To: <1209499369.15947.22.camel@missotis>
Cc: NETCONF goes on <ngo@ietf.org>
Subject: Re: [NGO] external module properties
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ngo-bounces@ietf.org
Errors-To: ngo-bounces@ietf.org
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 > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www.ietf.org/mailman/listinfo/ngo
- [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Jon Saperia
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Balazs Lengyel
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Ladislav Lhotka
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties David Harrington
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Juergen Schoenwaelder
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Wes Hardaker
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Randy Presuhn
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Andy Bierman
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Phil Shafer
- Re: [NGO] external module properties Martin Bjorklund
- Re: [NGO] external module properties Martin Bjorklund