Re: [I2rs-proto-dt] couple YANG details

"Susan Hares" <shares@ndzh.com> Fri, 23 October 2015 20:41 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs-proto-dt@ietfa.amsl.com
Delivered-To: i2rs-proto-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6111A907F for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 23 Oct 2015 13:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 OarDidLq6aJe for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 23 Oct 2015 13:41:28 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A381A907C for <i2rs-proto-dt@ietf.org>; Fri, 23 Oct 2015 13:41:28 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.177;
From: "Susan Hares" <shares@ndzh.com>
To: "'Jeffrey Haas'" <jhaas@pfrc.org>, "'Andy Bierman'" <andy@yumaworks.com>
References: <CABCOCHRRDZZZF1uj6UVDezmZzM3g8bEQiWTkyZKUPk6HL40fcg@mail.gmail.com> <20151023151756.GF26793@pfrc.org>
In-Reply-To: <20151023151756.GF26793@pfrc.org>
Date: Fri, 23 Oct 2015 16:41:29 -0400
Message-ID: <033801d10dd3$32542190$96fc64b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKMEsdjPzkqeQIW8vtZ5c+9e7UOnAGkpZ8knPZac+A=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/W3bEyWxZF6o5zUPn6I8dC4N27vQ>
Cc: i2rs-proto-dt@ietf.org
Subject: Re: [I2rs-proto-dt] couple YANG details
X-BeenThere: i2rs-proto-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <i2rs-proto-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs-proto-dt/>
List-Post: <mailto:i2rs-proto-dt@ietf.org>
List-Help: <mailto:i2rs-proto-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2015 20:41:29 -0000

Jeff and Andy: 

I agree with Jeff.  I2RS should not create new constraints for anything
under a configuration data tree.   (Jeff see the BGP suggestions below). 

What about the I2RS protocol data modules?  I think these data modules have
their own constraints.  Is this true. 

Sue 

Examples from BGP: 

1) if you create an ephemeral BGP peer, then it should have the same
constraints and other peers. 
b) If you create a BGP cost community, then it should have the same
constraints as other cost communities. 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org] 
Sent: Friday, October 23, 2015 11:18 AM
To: Andy Bierman
Cc: Susan Hares; i2rs-proto-dt@ietf.org
Subject: Re: [I2rs-proto-dt] couple YANG details

On Wed, Oct 21, 2015 at 02:45:56PM -0700, Andy Bierman wrote:
> 1) module-level "ephemeral" flag
> Since the data node flag applies to the entire subtree, it should be 
> simple enough to just require each top-level data node to declare 
> 'ephemeral true' if needed.
> There are usually 1 - 2 top-level data nodes per module so this is not 
> a burden.  Checking 2 places is too complicated and they can conflict.

As long as we permit ephemeral true in nodes other than the top one, I think
that's good.  We want to permit data models to be published that have
non-ephemeral components with some ephemeral without requiring an ephemeral
augmentation module just for the ephemeral properties.

> 2) groupings wrt/ edit overlap
> 
> YANG already has a way to say what sub-nodes must be present 
> (mandatory=true, min-elements>0).
> Is this good enough for I2RS?  Can the requirements for the ephemeral 
> version be different than the persistent version, wrt/ mandatory & 
> min-elements?

If I'm parsing this correctly, I think that's fine.  We want to avoid
introducing additional constraints in ephemeral modules, but shouldn't
perturb the requirements for persistent config state.  Since ephemeral state
can only go underneath the persistent stuff when they mix, min-elements
should be tied to requirements for the persistent nodes; the ephemeral nodes
may contribute, but shouldn't count against the min, ideally.

-- Jeff