Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting

Jeffrey Haas <jhaas@pfrc.org> Tue, 06 October 2015 14:06 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 DE90E1ACD15 for <i2rs-proto-dt@ietfa.amsl.com>; Tue, 6 Oct 2015 07:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jXy68qUOEEaM for <i2rs-proto-dt@ietfa.amsl.com>; Tue, 6 Oct 2015 07:06:42 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 11C881ACD09 for <i2rs-proto-dt@ietf.org>; Tue, 6 Oct 2015 07:06:42 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4EC501E4DD; Tue, 6 Oct 2015 10:10:37 -0400 (EDT)
Date: Tue, 06 Oct 2015 10:10:37 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Andy Bierman <andy@yumaworks.com>
Message-ID: <20151006141037.GD12583@pfrc.org>
References: <008701d0fd35$821bfa30$8653ee90$@ndzh.com> <20151005204631.GX5754@pfrc.org> <CABCOCHSMQ6WWHQCgFNzM34bJTDW1xvLzz2jAXNZGm1K4HCbuBg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABCOCHSMQ6WWHQCgFNzM34bJTDW1xvLzz2jAXNZGm1K4HCbuBg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/jKfmaZgboHipvDBxZ74vvbgJWek>
Cc: i2rs-proto-dt@ietf.org, Susan Hares <shares@ndzh.com>
Subject: Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting
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: Tue, 06 Oct 2015 14:06:43 -0000

On Mon, Oct 05, 2015 at 03:06:18PM -0700, Andy Bierman wrote:
> I am curious about bulk-read and bulk-write
> 
> IMO we just need 1 GET or 1 PUT type of method.
> Using YANG Patch with RESTCONF, multiple edits can be done at once.

That was my impression as well, but I had guessed that someone had brought
it up as a feature of some sort where I didn't have context.  

I suspect we can drop this section?

> It is important to decouple the produce (sensor) from the consumer (applied
> config)
> The sensor still puts out its operational value but the
> system (directed by I2RS edits) uses the injected value
> as the applied config instead of the sensor value.

I can grok your use of terminology, but it seems a bit skewed to how I'd
interpret things.

I'd like to suggest you put together the taxonomy section for the start of
the doc.  Or, if you think that the openconfig opstate draft covers it, we
can refer to that one.

> It is really just an implementation detail, but if N clients map
> to 1 priority (like the default priority if the client is not configured)
> then the client ID needs to be saved to decide first-1-wins in
> any future edit collisions.

Agreed.  I liked the idea mostly because it avoids having to adjudicate the
collisions.

> > I'm a bit confused by the writeable config false ephemeral true node.  Do
> > we
> > really want to support that?
> >
> 
> 
> That is the most controversial part.
> 
> Are there YANG objects that are config=false used to model
> the derived state?  Does that derived state ever need to
> be altered by I2RS?   An alternative would be to have new YANG objects
> that represent the I2RS-provided values.  But the config-stmt for
> these nodes needs some value.  Clearly it is not true, since NETCONF
> is not allowed to edit it.

My thoughts on this depend on the idea of datastores and schema.

Nodes are editable or not.  Whether the node has schema presence in
ephemeral or not is controlled by the ephemeral keyword in the yang.

It *may* be possible that a node is present in both config and in ephemeral
both. Examples are where we want to override things.

The question is how can we signal presence in both?  Do we want to simplify
and say that config datastore is always permitted when ephemeral is?

-- Jeff