Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Fri, 03 February 2017 15:32 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E67129C0E; Fri, 3 Feb 2017 07:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 Y5vg6hs_a4UN; Fri, 3 Feb 2017 07:32:22 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD91C129BC9; Fri, 3 Feb 2017 07:32:22 -0800 (PST)
Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id B92711AE012C; Fri, 3 Feb 2017 16:32:16 +0100 (CET)
Date: Fri, 03 Feb 2017 16:32:16 +0100
Message-Id: <20170203.163216.1400419881696462638.mbj@tail-f.com>
To: Xufeng_Liu@jabil.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BN3PR02MB1141BE8B907D10AAFAA6BDA7F14F0@BN3PR02MB1141.namprd02.prod.outlook.com>
References: <BN3PR02MB11415971D591FE5181D53409F14C0@BN3PR02MB1141.namprd02.prod.outlook.com> <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> <BN3PR02MB1141BE8B907D10AAFAA6BDA7F14F0@BN3PR02MB1141.namprd02.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / 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/i2rs/wPonUotoW4ZhMQihm7rBRWVW8k8>
Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, kwatsen@juniper.net
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 15:32:24 -0000

Hi,


Xufeng Liu <Xufeng_Liu@jabil.com> wrote:
> Hi Kent,
> 
> > -----Original Message-----
> > From: Kent Watsen [mailto:kwatsen@juniper.net]
> > Sent: Thursday, February 2, 2017 8:39 PM
> > To: Xufeng Liu <Xufeng_Liu@jabil.com>
> > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > draft-ietf-i2rs-yang-l3-
> > topology-08: (with COMMENT)
> > 
> > [reducing distribution]
> > 
> > 
> > Hi Xufeng,
> > 
> > > Assume the following model:
> > >
> > > +--rw nodes
> > >   +--rw node [id]
> > >      +--rw id   string
> > >      +--rw under-lay-attribute-a ???
> > > +---ro nodes-state
> > >   +--ro node [id]
> > >      +--ro id   string
> > >      +--ro attribute-a string
> > >
> > > I cannot define the under-lay-attribute-a to reference attribute-a as:
> > >               type leafref {
> > >                 path "../node/attribute-a"'
> > >               }
> > 
> > 
> > True, but maybe it could be:
> > 
> >    type leafref {
> >       path "../node/attribute-a"
> >       require-instance false;
> >       description
> >         "In the case when the referenced instance is not a configured
> >          object, the system may resolve it by looking for it under the
> >          /nodes-state node.  As the referenced operational state data
> >          may have a lifecycle independent of configuration, this results
> >          in an effect much like pre-provisioning interfaces in RFC 7223.";
> >    }
> [Xufeng] I think that "require-instance false" does not help here. The
> validation for path "../node/attribute-a" still fails because
> "attribute-a" does not exist under /nodes/node/.

No, "require-instance false" essentially turns off validation.  Section
9.9.3 in RFC 7950 says:

   If "require-instance" is "false", it means that the instance being
   referred to MAY exist in valid data.


/martin