Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20

Andy Bierman <andy@yumaworks.com> Sun, 11 October 2015 18:10 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 945321B2C35 for <i2rs-proto-dt@ietfa.amsl.com>; Sun, 11 Oct 2015 11:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 BDdxTBR5io74 for <i2rs-proto-dt@ietfa.amsl.com>; Sun, 11 Oct 2015 11:10:18 -0700 (PDT)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 4B5B81B2C31 for <i2rs-proto-dt@ietf.org>; Sun, 11 Oct 2015 11:10:18 -0700 (PDT)
Received: by lbbk10 with SMTP id k10so11756886lbb.0 for <i2rs-proto-dt@ietf.org>; Sun, 11 Oct 2015 11:10:16 -0700 (PDT)
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:content-type; bh=x+nhkfT7ewFcgye3nMhskvY1JUNRuujJ/YXED0z3KLo=; b=iFthCyb/7amG1Bi5UED6lfgwmBOAgNZ9m6zha6v4dydKCq2HahnN20UrbZDQrmi+do PqeJMIJIHrMwr8ZOw7jTZxwiZrrs0F2oXeqRCeMRgy5R0rPVbL9hV0J4RN53ehA7+HL8 WxSCK76iXQ8JF3XJLnEfb8bCEF7Lu2CKm/bu2AQ3Gn8teM6SkGi5Xg5MFlz6OoGO46V/ dSZKUcwckao/S4K2+ZRFbfyPQVMI9dvxbaIobE5dAqHqpflLdTTJgsz35Jzc0KM026LM 1NM/jJS4FiL4LLhNP98ksI8eaBokmUScY1VhcfBZWwgwADyBwx0FJZ0SHwGtfJsNTsNv FoQA==
X-Gm-Message-State: ALoCoQmn5Hkm7qQ27TIFJInhpny2ps2sf3gX8iCNhz2LvBkxTEFmx0BCJv9hlYwsN5fyAweLmwIo
MIME-Version: 1.0
X-Received: by 10.112.199.170 with SMTP id jl10mr5224961lbc.88.1444587016346; Sun, 11 Oct 2015 11:10:16 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Sun, 11 Oct 2015 11:10:16 -0700 (PDT)
In-Reply-To: <20151011175123.GA62046@elstar.local>
References: <05c801d102ce$eb398930$c1ac9b90$@ndzh.com> <20151011161106.GA61856@elstar.local> <CABCOCHTb6VxuV1YxP+zVd8qo171+OUFoH2qeZxAiFqi2RrdrXA@mail.gmail.com> <20151011175123.GA62046@elstar.local>
Date: Sun, 11 Oct 2015 11:10:16 -0700
Message-ID: <CABCOCHQa1Dv-vkt-xhGDzOw4rt4UWnGPjEsxHj5vrVNFGjk-xQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>, i2rs-proto-dt@ietf.org
Content-Type: multipart/alternative; boundary="001a11c38a7af504210521d81f9b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/CgD1o8QAODWd_WPGCNYz3VKgInw>
Subject: Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20
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: Sun, 11 Oct 2015 18:10:20 -0000

On Sun, Oct 11, 2015 at 10:51 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sun, Oct 11, 2015 at 09:55:31AM -0700, Andy Bierman wrote:
> > On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote:
> > > > The 10/7/2015 interim discussed the ephemeral portion of the protocol
> > > >
> > > >
> > > >
> > > > 1)      Ephemeral state is not unique to zI2RS
> > > >
> > > > 2)      The ephemeral datastore is a datastore holds
> > > >
> > > > configuration that is intended to not survive a reboot.
> > > >
> > >
> > > Configuration as YANG config true or a subset thereof?
> > >
> >
> >
> > config=true nodes only.
>
> good
>
> > Some way is needed to specify I2RS conformance for
> > a given YANG module, unless every persistent config leaf
> > is expected to also be supported as ephemeral data.
> >
> > If not, a YANG "ephemeral-stmt" is probably needed, since
> > config=true is insufficient to support I2RS conformance.
>
> One question is whether this needs to be inline in the data model or
> not. If conformance is the goal, then you know what having things
> defined inline has limits. If we would address conformance in more
> general terms, perhaps I2RS conformance falls out as a special case.
>
> > One ephemeral datastore.
> > No client panes.  That was to support caching, but
> > the architecture forbids caching, so that was taken out.
> >
> > One ephemeral pane that overrides the running datastore
>
> good
>
> > > Identities? I assume you mean schema nodes, do you?  Adding by
> > > defining an YANG extension such as i2rs:ephemeral true? How does such
> > > an i2rs:ephemeral true interplay with config true/false? What about
> > > contexts for must/when expressions? Or is the idea to settle on
> > > RESTCONF and to work with YANG patch?
> > >
> >
> > I think a real keyword is needed not an extension.
> > Otherwise YANG groupings cannot be utilized w/ statements
> > that are refined in the uses-stmt to set the ephemeral flag.
>
> I fail to understand the groupings argument.
>


The refine-stmt is defined to work on YANG statements, not external
statements.

A YANG extension is (by definition) something external to the YANG language.
The WG needs to decide if the ephemeral property should be specific to
an I2RS YANG module or should be basic property of the YANG data modeling
language.  YANG keywords must be supported and they do not need
to be imported from a YANG module to be used.



> > NETCONF has no edit ordering or ability to return a partial
> > error. IMO only RESTCONF is needed.  Proposals to
> > improve NETCONF editing to support YANG Patch have
> > already been made, and the WG had higher priorities.
> > I don't see why 2 protocols are needed instead of 1.
>
> Perhaps the WG should discuss and decide. If all the WG wants is
> RESTCONF, then we can simplify the discussion.



>
>
/js
>
>

Andy



> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>