Subject: [I2rs-proto-dt] I2RS meeting

From: Andy Bierman <[email-masked]>
Date: Sun, 1 Nov 2015 12:35:32 -0800

Hi,

I plan to listen in to the I2RS meeting.
It's probably too late for a conf-call before the meeting,
but I am available.

I think it is OK to say the YANG constraints apply to
the derived "intended config" and also apply
to the running datastore as defined in YANG.

That means if the max-entries is 5, then 5 can exist in
the running config, and new entries added to ephemeral
must override entries in running.  Retrieving the intended config
actually used (e.g., which config entry is disabled) is
a different issue.  The intended config can only have 5 entries
in it.  It falls out that the ephemeral datastore can only
have 5 entries in it as well.

Not all YANG constraints are as easy as min-elements,
and max-elements.

mandatory, must, when, and unique need more careful thought

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 1 Nov 2015 16:04:26 -0500

Andy:  

I really appreciate this email.   Please comment remotely or skype me (Susan.Hares) or send a note to the jabber scribe. 

How is your dog? 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Sunday, November 01, 2015 3:36 PM
To: Susan Hares; [email-masked]
Subject: [I2rs-proto-dt] I2RS meeting

Hi,

but I am available.

and max-elements.

 

Andy

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 2 Nov 2015 06:32:12 +0900

I support Andy's comments

> On Nov 2, 2015, at 06:04, Susan Hares <[email-masked]> wrote:
> 
> Andy: 
>  
> _______________________________________________
> I2rs-proto-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt

---

From: Andy Bierman <[email-masked]>
Date: Sun, 1 Nov 2015 15:12:30 -0800

On Sun, Nov 1, 2015 at 1:04 PM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> I really appreciate this email.   Please comment remotely or skype me
> (Susan.Hares) or send a note to the jabber scribe.
>
>
>

I will try to figure out jabber and meetecho in time for the meeting
I think we are close to being able to express what we want in proper YANG
terminology.

How is your dog?

He passed away, sorry to say.  I'm glad I was here to deal with it instead
of 15 time zones away from home.

Andy

>
>
> *From:* I2rs-proto-dt [mailto:[email-masked]] *On Behalf
> Of *Andy Bierman
> *Sent:* Sunday, November 01, 2015 3:36 PM
> *To:* Susan Hares; [email-masked]
> *Subject:* [I2rs-proto-dt] I2RS meeting
>
>
>
> Hi,
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Nov 2015 19:30:15 -0800

Hi,

I have some new questions about I2RS.

1) save client-id or client-id and priority?
Jan was concerned about saving state for every node.
If there is only 1 client and 1 priority then there is nothing to save.
For multi-head agents they will need to save the client-id.
The priority is configured for the client. It if changes the
priority of all the client's data automatically changes.
If this is not acceptable, then the priority and the client have to
be saved per node.

2) edit boundaries are not remembered
Each edit by each client will just go into the ephemeral datastore.
Identification of individual edits is not remembered.
Therefore the data that gets bumped by a high-priority overlap
is deleted based only on the overlap, not the original edit.

3) because of (2) there might be client interactions that break things.
e.g...
   client-worst sets entire /foo/bar subtree and it is accepted and
activated
   client-best later sets some subtree inside /foo/bar and the old subtree
is deleted
   and replaced with the data from client-best.  At this point the overall
   config may be invalid. The agent needs to do lots of expensive validation
   and may need to remove even more data from client-worst.
   Whether arbitrary pruning is done or not, the config may be operationally
   invalid at this point. Maybe this is no different than clashing clients
in persistent config,
  and can be considered out of scope.

Andy

On Sun, Nov 1, 2015 at 1:32 PM, Dean Bogdanovic <[email-masked]> wrote:

> *From:* I2rs-proto-dt [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Andy Bierman

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Nov 2015 11:56:11 -0800

Hi,

I have more questions ;-)
I want to help Susan get a good draft out soon.

Maybe the I2RS priority model is easy to describe using the thermostat.

Susan's daughter sets the "hold" button to 82 degrees F.

Susan's smartphone app is monitoring the /thermostat resource and gets
and update that the hold-button is now set to 82.

Susan's phone now sets the hold-button to 72.  Since Susan has the
highest priority, her edit is accepted by the I2RS agent.

Her daughter's smartphone app is monitoring the /thermostat resource and
gets
and update that the hold-button is now set to 72.

She tries to set it to 82 again and gets an error.
The /thermostat resource is not altered.

Susan eventually deletes the "hold 72" data.
The thermostat goes back to normal program (running config).
The previous client setting of 82 is long forgotten.

Is this the correct model? Seems OK to me. No caching is done.

Is it completely up to the client to subscribe to the /thermostat resource
or is the
I2RS agent expected to automatically subscribe the client to the target
resource?

Andy