Re: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday (10/20/2015)

["Susan Hares" <[e-mail]>]

Eric: 

 

See comments below.  Great feedback.  I will update the document and send it
to the list today. 

 

Sue 

 

From: I2rs-proto-dt [mailto:[e-mail]] On Behalf Of
Eric Voit (evoit)
Sent: Monday, October 19, 2015 4:02 PM
To: Susan Hares
Cc: 'Kent Watsen'; [e-mail]; 'Andy Bierman'
Subject: Re: [I2rs-proto-dt] I2RS Protocol Document - Please review on
Tuesday (10/20/2015)

 

There is good stuff here.  Some thoughts are in the change-marked document
enclosed.  I have extracted and highlighted a few of these below….

 

>Section 3

>Why is the caching question explicitly disallowed?   Why not just say
implications are out-of->scope?  

[Sue]: I will change to out of scope.

 

>Section 4.2

>Why is referential validation a “must not” instead of a “may not”?

[Sue]: Good point. I will change to a may not. 

 

Section 4.4

Priority preemption needs more thought.  When may the ephemeral value placed
by a higher priority client write no longer visible or relevant?  

·         Can my son and I fight over the thermostat on our iPads
immediately?   (Hopefully my client has priority so he can’t override him)

·         Must I maintain a logged in session to the thermostat to maintain
my priority? How long does the ephemeral data maintain the linkage to the
originator?  What if that linkage is deleted, can anyone be locked out? 

·         If I forget about the thermostat and go on vacation, must my
family reboot the thermostat to eventually gain write ownership?

‘first-write-wins’ is less common that ‘last-write-wins’ for reasons like
this.

[Sue]: The idea is the I2RS client – I2RS agent establishes a relationship
that persists beyond a single transport session.   The difficultly in having
a relationship beyond a transport session is that I2RS Agent must have an
ability to query clients to determine if the client has gone away, and to
time-out non-responsive clients.   

Ø  You and your son fight over the thermostat on your iPads immediately if
you have a higher priority.  However, after you win (higher priority locks
out lower) the fight will stop. 

Ø  You need to retain a relationship between your client and the I2RS agent.
This is not a transport session, but a linkage between the two devices.  It
is clearly something we need to address in the protocol on how to get a
“heart-beat” going between the I2RS agent and the I2RS client so that some
type of timeout  can be done automatically by the I2RS agent. 

Ø  If you forget about the thermostat and your home computer with the I2RS
client is still responding to heart beats, your family must reboot the
thermostat.   If your computer application is not responding to heart beats,
then the relationship stops. 

 

Figure 5

It would be good to have more details on how the linkage to the higher
priority client is encoded, maintained, and made visible.

[Sue]: I will provide more details. 

 

> Section 9.1 & 9.2

> Notification of write conflicts is a complex topic which means much info
must be stored about > every ephemeral object.   And since mechanisms for
delivery of notifications might not exist if > a NETCONF session goes down,
should the Ephemeral data persist the loss of its originator?

 

[Sue]: The ephemeral data persists the loss of a transport session, but not
the loss of a end-to-end session (see above).  

 

 

Thanks,

Eric

 

 

From: I2rs-proto-dt [mailto:[e-mail]] On Behalf Of
Susan Hares
Sent: Monday, October 19, 2015 2:34 PM
To: [e-mail]
Cc: 'Kent Watsen'; 'Andy Bierman'
Subject: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday
(10/20/2015)

 

HI all: 

 

Here’s the I2RS protocol design document.  Would you review this on Tuesday
and send me comments?  If it is helpful, we could meet as a design team at
10:00-11:30am. 

 

I would like to get comments and feedback before Wednesday’s 10/21/2015
interim meeting. 

 

Sue