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

Andy Bierman <andy@yumaworks.com> Fri, 23 October 2015 21:04 UTC

Return-Path: <andy@yumaworks.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 9BC561A9139 for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 23 Oct 2015 14:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] 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 0NyNQHLRSpOM for <i2rs-proto-dt@ietfa.amsl.com>; Fri, 23 Oct 2015 14:04:57 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479091A906A for <i2rs-proto-dt@ietf.org>; Fri, 23 Oct 2015 14:04:50 -0700 (PDT)
Received: by lffz202 with SMTP id z202so96912697lff.3 for <i2rs-proto-dt@ietf.org>; Fri, 23 Oct 2015 14:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TT4GH0vm6qMjqZW9G9Vw8gxmJk1F5Spc3R//ESFqfuw=; b=0hPmpKAJEnfL8jVVf4tlWf6M4SMiieFZlgtALY0Sn5AgKCrH155lgePwLpjNLW+FmJ 0ZGFCB1Zdv1glj3gvBupTD/3Zb4+nYd0JEuINwgO8dc/EysbzK27tLOipobV2+Ou190j +b8a9Xf2JXGnUtTINK4Z5UTSVLdjI5GSSHmLy0jMZjmWJgZafdXI6uFi9JN86FbUNWdg lC+TH0sqF3VCN6xRhPwreTBo1OCAmCa2uGmUZD1X1uM23/dzEAsarhrQHI6qjy6iMVRz tQHVMwMKhuBoB6K0gMOM9jGK287MeN24UxLmFGyeByJuQ4IYbLppUMZl0Us8pOwR1NWQ uerg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TT4GH0vm6qMjqZW9G9Vw8gxmJk1F5Spc3R//ESFqfuw=; b=FlYHY9AECH/6axKst3vlyRrGnS/9IHkAMkRl8kWKbpT9oa0iZ64sl+maSXHunldNnk JKZpxMwXVZMhHtuXOoA9ChBiOZqCBTmV7+XAaAzbf6OGT2vtKwm/cXpox4EnBNMv2WIC DUochPlI6kwxvtIx6PeOLJUCxhAEnM80QCJRvb3rjQboRUYetYvR3dH80Oe78saZBTKn ba1/weS6aexFrjNdTgvD7sH1khPWPvY7FpVcd5dx9IZSB3Ue50A4b5MmIJDnYWeDEGet Wrr9nmDIyg9pwFcIlqxCMAtgHyPhS/Mtf27+BfdIHGQ5th1i8YOyqRf9brsp0lwjhzza gIDw==
X-Gm-Message-State: ALoCoQnK+hV/dh1AcNTl+OIgQfyCHehIpQD6yUKLlzipo0NN7g33bV1jenRpjp3m8Obu5V+Nd2L6
MIME-Version: 1.0
X-Received: by 10.112.135.136 with SMTP id ps8mr11988047lbb.38.1445634288544; Fri, 23 Oct 2015 14:04:48 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Fri, 23 Oct 2015 14:04:48 -0700 (PDT)
In-Reply-To: <033801d10dd3$32542190$96fc64b0$@ndzh.com>
References: <CABCOCHRRDZZZF1uj6UVDezmZzM3g8bEQiWTkyZKUPk6HL40fcg@mail.gmail.com> <20151023151756.GF26793@pfrc.org> <033801d10dd3$32542190$96fc64b0$@ndzh.com>
Date: Fri, 23 Oct 2015 14:04:48 -0700
Message-ID: <CABCOCHTBQXkZ7X5A02yoTOC4GaBv5TFqSWU8Joj50BRheJ3dqg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=089e011607123e92cd0522cbf68c
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/yeqY417BOQISkpeCgQ50B9VTfkA>
Cc: Jeffrey Haas <jhaas@pfrc.org>, 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 21:04:58 -0000

On Fri, Oct 23, 2015 at 1:41 PM, Susan Hares <shares@ndzh.com>; wrote:

> 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.
>
>

No -- currently there is no way to tell that the constraints apply to I2RS.

So the YANG constraints apply to the running datastore.
The config=true nodes make up the running datastore.
The ephemeral datastore contents and the ephemeral-stmt
values are ignored for this validation.

There is no YANG constraint enforcement in the ephemeral datastore at all.
Only the YANG "type" statement is enforced, and even then,
leafrefs with "require-instance true" are treated as if they were
"require-instance false".

All servers should do validation the same way or the client will not know
what to expect.




> 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.
>
>


But the YANG statements only apply to the running datastore.
What does "same constraints" mean here?


Andy



> -----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
>
>