Re: [YANG] keyref
Balazs Lengyel <balazs.lengyel@ericsson.com> Tue, 22 January 2008 15:32 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 1JHL6Y-0005M2-Dz; Tue, 22 Jan 2008 10:32:02 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43)
id 1JHL6W-0005Er-To
for yang-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 10:32:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1JHL6W-0005Cg-HF
for yang@ietf.org; Tue, 22 Jan 2008 10:32:00 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHL6W-000665-36
for yang@ietf.org; Tue, 22 Jan 2008 10:32:00 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
8D22320569; Tue, 22 Jan 2008 16:31:59 +0100 (CET)
X-AuditID: c1b4fb3e-ab5e9bb0000007e1-00-47960c6fb251
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
6D86A20455; Tue, 22 Jan 2008 16:31:59 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 22 Jan 2008 16:31:59 +0100
Received: from [159.107.197.224] ([159.107.197.224]) by
esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 22 Jan 2008 16:31:58 +0100
Message-ID: <47960C6E.5060804@ericsson.com>
Date: Tue, 22 Jan 2008 16:31:58 +0100
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Andy Bierman <ietf@andybierman.com>
Subject: Re: [YANG] keyref
References: <47954F24.905@andybierman.com> <20080122.091246.105352306.mbj@tail-f.com> <20080122081821.GA5210@elstar.local> <20080122.094430.48542159.mbj@tail-f.com> <20080122085918.GC5210@elstar.local>
<4795FECC.4090803@andybierman.com>
In-Reply-To: <4795FECC.4090803@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2008 15:31:59.0020 (UTC)
FILETIME=[ED78CEC0:01C85D0B]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: yang@ietf.org
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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
Hello,
We are trying to define a formal way to specify relationships between config database nodes.
The this problem has many facets
- reference to multi-keyed items
- reference to leafs versus keys
- constraining references to certain items or having free pointers
- reference integrity
The problem we try to solve is how to define these relations in a way that allows automatic
checking. We need some solution, even if we do not solve the complete problem. E.g. I think
referential integrity is a too high goal.
Balazs
Andy Bierman wrote:
> IMO, it is not clear what problem is being solved by keyref.
> There seems to be some assumption that the purpose of all this
> complexity is justified because of all the value it provides.
>
> The InterfaceIndex approach is well-established and simple.
>
> leaf mgmt-interface {
> type keyref {
> path "/if:interfaces/if:interface/if:ifIndex";
> }
> }
>
> leaf mgmt-interface {
> type if:InterfaceIndex;
> }
>
> Not only is the TC approach simpler, but keyref does not support
> the ability to hold a 'not-set' value, such as InterfaceIndexOrZero.
_______________________________________________
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