Subject: [i2rs] I2RS second meeting on 4/7/2016 at 16:20 - 17:20 pm toady

From: "Susan Hares" <[email-masked]>
Date: Thu, 7 Apr 2016 11:02:52 -0400

I2RS:

I2RS will hold its second meeting from 16:20 - 17:20pm.   This meeting is
after the NETCONF meeting.  We will talk about protocol-strawman with any
NETCONF participants.  

We have one issue to decide upon:  How much validation will I2RS provide for
the writes?

Should we allow clients to have "No validation",  "some validation", and
full (NETCONF) validation. 

Please send comments to the list. 

Sue 

 

From: Susan Hares [mailto:[email-masked]] 
Sent: Thursday, April 07, 2016 7:48 AM
To: [email-masked]'
Cc: 'Joel M. Halpern'; 'Kent Watsen'; [email-masked]'; 'Alia Atlas'
Subject: Revision of slides for the I2RS meeting this afternoon 

I2RS people: 

We have a session to after netconf (16:00 - 17:00). Please plan on joining
us so that the NETCONF/I2RS people can both discuss with I2RS the data flow
requirements and protocol specification. 

Based on the feedback from Monday's meeting new slides have been upload.
We'll also talk about hackathon at IETF 96. 

Sue

---

From: Joe Clarke <[email-masked]>
Date: Thu, 7 Apr 2016 16:42:15 -0400

On 4/7/16 11:02, Susan Hares wrote:
> I2RS:
>
> I2RS will hold its second meeting from 16:20 – 17:20pm.   This meeting
> is after the NETCONF meeting.  We will talk about protocol-strawman with
> any NETCONF participants.
>

Sue, at the meeting today you started an example talking about running 
config with a priority of 1 and an I2RS Client with a priority of 10 (or 
reverse, I don't remember).  Then you said that the I2RS Client's write 
would win.  Agreed.

But you didn't mention anything about the "shattering" pane of glass. 
The fact that running has a priority implies that any write to running 
would still sit under the Client's pane of glass.  I'm not sure if 
that's what you intended to convey, but I like it.  This makes sense to me.

What I anticipate in the case of a last-write-to-running winning is 
config churn.  Let me use your thermostat example.

I like it cooler in the room.  When I visit relatives (that typically 
like it warmer) I will set the thermostat to 16 C or so.  I expect this 
to stay until I leave.  So I'm the high priority I2RS client overlaying 
the config that will remain.  If my relative makes a change to the 
underlying "config" of the thermostat, thus destroying my intended, 
ephemeral config, I will just go back and re-add my ephemeral config.

In the networking world, this will be churn that is likely not needed.

Joe