Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Martin Bjorklund <mbj@tail-f.com> Thu, 09 March 2017 13:31 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2A129591 for <netmod@ietfa.amsl.com>; Thu, 9 Mar 2017 05:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObA-9l7xYd8h for <netmod@ietfa.amsl.com>; Thu, 9 Mar 2017 05:31:40 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5412945F for <netmod@ietf.org>; Thu, 9 Mar 2017 05:31:39 -0800 (PST)
Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 841071AE02A7; Thu, 9 Mar 2017 14:31:36 +0100 (CET)
Date: Thu, 09 Mar 2017 14:31:35 +0100 (CET)
Message-Id: <20170309.143135.262966763364971166.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <AM2PR07MB0627DAA0B0816C94B5E275E894210@AM2PR07MB0627.eurprd07.prod.outlook.com>
References: <20170308145133.GC9814@elstar.local> <20170308.162542.2034349701486649544.mbj@tail-f.com> <AM2PR07MB0627DAA0B0816C94B5E275E894210@AM2PR07MB0627.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0>
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 13:31:41 -0000

"Bogaert, Bart (Nokia - BE)" <bart.bogaert@nokia.com> wrote:
> So; to make this work the YANG property of the parent leaf in the config
> data tree should be set to false to allow a reference to hardware-state,
> correct?

It would be:

      leaf parent {
        type leafref {
          path "/hardware-state/component/name";
          require-instance false;
        }


/martin


> 
> Regards, Bart
>  
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Wed, Mar 08, 2017 at 02:48:15PM +0000, Bogaert, Bart (Nokia - BE)
> wrote:
> > > Hi,
> > > 
> > > > If we pick the former, it will not be possible to configure a 
> > > > component with a system controlled parent (unless you also add the 
> > > > system controlled parent to the configuration).
> > > > [Bart Bogaert] Is there a reason to only have this parent in the 
> > > > state tree and not in the config tree?
> > > 
> > > I am not sure I understand the question.  Suppose the config tree is 
> > > empty, and the system boots and populates the state tree with all 
> > > detected harwdare.  Next, a client would like to pre-provision a 
> > > module in a chassis that exists in state.  If the leafref is to the 
> > > config tree, the client would have to create both the chassis and 
> > > the module in the config tree, since the leafef would otherwise fail to
> validate.
> > > 
> > > [Bart Bogaert] Ok, so you are looking for a solution that refers to 
> > > an entry in the state tree.  I always thought that one could not 
> > > refer from config to state but it seems I misunderstood this since 
> > > this is exactly what you are proposing.
> > > 
> > > > If we pick the latter you will not get any validation (since it 
> > > > has to be require-instance false).
> > > >
> > > > It is fine w/ me to change the type string to a leafref of the 
> > > > former
> > > type.
> > > 
> > > Correction: I am fine with changing the string to a leafref to state.
> > > 
> > > > [Bart Bogaert] If we leave it as a string it would mean that an 
> > > > external application would have to check whether the value of the 
> > > > string actually corresponds to a component that should exist (in 
> > > > the case of a non-system-controlled parent)?
> > > 
> > > So are you ok with a leafref to state?
> > > 
> > > [Bart Bogaert] Since that seems possible this would solve the 
> > > problem.  I'm checking this with our people.
> > 
> > Are you discussing leafref to a config false node with require 
> > instance false?
> 
> Yes.
> 
> > I am not sure this is valid YANG.
> 
> It is valid,  section 9.9 on leafref says:
> 
>    If the referring node represents configuration data and the
>    "require-instance" property (Section 9.9.3) is "true", the referred
>    node MUST also represent configuration.
> 
> 
> 
> /martin