Re: [NGO] external module properties

Ladislav Lhotka <lhotka@cesnet.cz> Tue, 29 April 2008 19:04 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 B371528C30E; Tue, 29 Apr 2008 12:04:58 -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 75EEA3A68D5 for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 12:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
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 9jnpP3UCgg0C for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 12:04:52 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 24C743A6DF3 for <ngo@ietf.org>; Tue, 29 Apr 2008 12:04:37 -0700 (PDT)
Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 439C8D800C1 for <ngo@ietf.org>; Tue, 29 Apr 2008 21:04:39 +0200 (CEST)
From: Ladislav Lhotka <lhotka@cesnet.cz>
To: ngo@ietf.org
In-Reply-To: <48176253.1070102@andybierman.com>
References: <481742EF.5030607@andybierman.com> <200804291611.m3TGBTHr088389@idle.juniper.net> <20080429.191023.153396365.mbj@tail-f.com> <48176253.1070102@andybierman.com>
Organization: CESNET
Date: Tue, 29 Apr 2008 21:04:40 +0200
Message-Id: <1209495880.15947.5.camel@missotis>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1
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

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.

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.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo