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