Re: [NGO] external module properties
Andy Bierman <ietf@andybierman.com> Tue, 29 April 2008 19:18 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 049AB28C25A; Tue, 29 Apr 2008 12:18:14 -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 CF7AB28C313 for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 12:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.188
X-Spam-Level:
X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Y3jFsahEXGLI for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 12:17:59 -0700 (PDT)
Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 61F8228C332 for <ngo@ietf.org>; Tue, 29 Apr 2008 12:16:28 -0700 (PDT)
Received: (qmail 54880 invoked from network); 29 Apr 2008 19:16:31 -0000
Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.241.42 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 29 Apr 2008 19:16:30 -0000
X-YMail-OSG: xBMOUx0VM1kYLrJQMD6yNH_TpqQZRo4w7GivowkIJkA2atzvvW7YkoJrqtqL7mAhjtg2eNJC2PgBEDVf13rzMB_HQDykOPCX44pfWr6o_g--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4817740D.5080803@andybierman.com>
Date: Tue, 29 Apr 2008 12:16:29 -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>
In-Reply-To: <1209495880.15947.5.camel@missotis>
Cc: 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 11:00 -0700: > >> We should do what we can within the XML sandbox. >> I agree with your comment about using the namespace URI instead >> of a long string for the module name. There are enough static >> mappings to deal with already. However, these URIs will >> not be very easy to memorize, unlike module names. > > Given the way how NETCONF works, the capability URIs are supposed to be > the identifiers that are communicated between the parties. Then each > party can have its own catalog that maps this URI to a local file name > (that even needn't be globally unique) or an URL in general. This way, > the file name of the module is a non-issue and search path can be > handled as well. > 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 ;-) > I would also prefer to encode version numbers (if there are any) to the > URI rather than invent yet another meta-parameter of YANG models. > We wrapped around the axle once before on this topic. IMO: 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. > 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