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

[Jeffrey Haas <[e-mail]>]

In the section on referential validation, there's a tricky implication: If
you have ephemeral nodes underneath non-ephemeral config=true, and those
config=true have referential checks, do they get ignored because an
ephemeral node is intantiated under the non-ephemeral?

I think no, we continue to do the validation.  Yes, it will impact the
speed.

If you need the speed, you don't have ephemeral state instantiated that may
need to be free of such checks.


-- Jeff

On Tue, Oct 20, 2015 at 12:34:07PM -0400, Susan Hares wrote:
> 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 
> 

> _______________________________________________
> I2rs-proto-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt