Re: [YANG] keyref
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 22 January 2008 22:15 UTC
Return-path: <yang-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1JHROZ-0001Mb-Cg; Tue, 22 Jan 2008 17:15:03 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43)
id 1JHROY-0001ML-BI
for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 17:15:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1JHROX-0001KN-Q5
for yang@ietf.org; Tue, 22 Jan 2008 17:15:02 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23])
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHROX-00055u-6v
for yang@ietf.org; Tue, 22 Jan 2008 17:15:01 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32])
by hermes.jacobs-university.de (Postfix) with ESMTP id BB3C88A24E;
Tue, 22 Jan 2008 23:15:00 +0100 (CET)
Received: from hermes.jacobs-university.de ([212.201.44.23])
by localhost (demetrius.jacobs-university.de [212.201.44.32])
(amavisd-new, port 10024)
with ESMTP id 02201-06; Tue, 22 Jan 2008 23:14:53 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
by hermes.jacobs-university.de (Postfix) with ESMTP id 1F9B88A24A;
Tue, 22 Jan 2008 23:14:53 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501)
id 9446D47909D; Tue, 22 Jan 2008 23:14:51 +0100 (CET)
Date: Tue, 22 Jan 2008 23:14:51 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Bert Wijnen <bertietf@bwijnen.net>
Subject: Re: [YANG] keyref
Message-ID: <20080122221451.GB6901@elstar.local>
Mail-Followup-To: Bert Wijnen <bertietf@bwijnen.net>,
Balazs Lengyel <balazs.lengyel@ericsson.com>,
Martin Bjorklund <mbj@tail-f.com>, yang@ietf.org
References: <4795F2C3.4080004@ericsson.com>
<NIEJLKBACMDODCGLGOCNCELGEFAA.bertietf@bwijnen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NIEJLKBACMDODCGLGOCNCELGEFAA.bertietf@bwijnen.net>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: yang@ietf.org
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: YANG modeling Language for NETCONF <yang.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/yang>,
<mailto:yang-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/yang>
List-Post: <mailto:yang@ietf.org>
List-Help: <mailto:yang-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/yang>,
<mailto:yang-request@ietf.org?subject=subscribe>
Errors-To: yang-bounces@ietf.org
On Tue, Jan 22, 2008 at 03:26:34PM +0100, Bert Wijnen wrote: > Let me remind everyone that the referential integrity (specifically > for ifIndex) was/is one of the big open issues in the MIB space. > > It would be good if we can solve it in the NETCONF DML space. > > Unfortunately, I have no solution to offer at this point. Sorry. Whether you want to have the config for your wlan card move with the wlan card or be statically bound to the slot you insert your wlan card into is a configuration decision to be taken by the owner of the device. We should not invent DML mechanisms to enforce a specific behaviour in the data model - this will be a failure. Instead, we have to ensure that people can write configurations that are flexible in terms of what is being used to refer to something. The IF-MIB says "here is ifIndex to refer to an interface" (and often the ifIndex is related to physical ports - but it does not have to be this way; it is just common on routers and switches). But we have heard many times that operators really like to refer to an interface name (which on some OSes is a logical interface mapping to a physical interface in some way) or an interface alias (which is something a human has configured to identify the interface connected to a certain customer, whatever physical port is used). I assume that a decent solution will carry some weight and bring us close to configuration templates or other advanced configuration language features (variables and such things) which I assume to be way too ambitious for the IETF to deliver anything useful within this decade. We should instead concentrate on doing basic YANG 1.0 in a timely manner; let early adoptors experiment with advanced features so we have good input based on real world experience for YANG 2.0 if that ever happens. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang
- [YANG] keyref Andy Bierman
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Balazs Lengyel
- Re: [YANG] keyref Balazs Lengyel
- RE: [YANG] keyref Bert Wijnen
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Balazs Lengyel
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Juergen Schoenwaelder
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Phil Shafer
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Randy Presuhn
- Re: [YANG] keyref Randy Presuhn
- Re: [YANG] keyref Phil Shafer
- Re: [YANG] keyref Andy Bierman
- Re: [YANG] keyref Martin Bjorklund
- Re: [YANG] keyref Balazs Lengyel
- Re: [YANG] keyref Andy Bierman