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

From: "Susan Hares" <[email-masked]>
Date: Mon, 19 Oct 2015 14:34:18 -0400

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 19 Oct 2015 20:02:19 +0000

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?

Section 4.2
Why is referential validation a "must not" instead of 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 by family reboot the thermostat to eventually gain write ownership?
'first-write-wins' is less common that 'last-write-wins' for reasons like this.

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.

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?

Thanks,
Eric

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, October 19, 2015 2:34 PM
To: [email-masked]
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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 20 Oct 2015 12:34:07 -0400

Eric: 

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

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of
Eric Voit (evoit)
Sent: Monday, October 19, 2015 4:02 PM
To: Susan Hares
Cc: 'Kent Watsen'; [email-masked]; '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….

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

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

>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. 

> 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:[email-masked]] On Behalf Of
Susan Hares
Sent: Monday, October 19, 2015 2:34 PM
To: [email-masked]
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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 Oct 2015 14:57:41 -0400

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

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 21 Oct 2015 02:52:18 +0000

Hi Sue,

A couple of comments on this draft:

1.       Section 2 says:

"The [I-D.openconfig-netmod-opstate] denotes the actual configuration as derived state."

While draft-openconfig-opstate says: The applied configuration and derived state can be considered as the overall 'operational' state of the NE."
Thus the applied(actual) configuration belongs to the operational state, but does not belong to derived state.

Section 2 also says: ""Recently the [I-D.openconfig-netmod-opstate] has proposed that intended configuration, actual configuration, and the traditional type of operational data be included as operational state."

Maybe there is a typo here, the intended configuration should belong to configuration.

2. Since Ephemeral is about data not persisting over a reboot, maybe a requirement for ephemeral states is that they MUST never be copied to the startup configuration datastore?

Best regards,
Jie

Sent: Tuesday, October 20, 2015 2:34 AM

HI all:

Sue

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 21 Oct 2015 05:59:01 -0400

Jie: 

Thank you for sending in comments.  You are correct that 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of
Dongjie (Jimmy)
Sent: Tuesday, October 20, 2015 10:52 PM
To: Susan Hares; [email-masked]
Cc: 'Kent Watsen'; 'Andy Bierman'
Subject: Re: [I2rs-proto-dt] I2RS Protocol Document - Please review on
Tuesday (10/20/2015)

Hi Sue, 

1.       Section 2 says:

"The [I-D.openconfig-netmod-opstate] denotes the actual configuration as
derived state."

While draft-openconfig-opstate says: The applied configuration and derived
state can be considered as the overall 'operational' state of the NE."

Thus the applied(actual) configuration belongs to the operational state, but
does not belong to derived state.

[Sue]: You are correct.  Good catch.  Jeff mentioned the same in his review.

Section 2 also says: ""Recently the [I-D.openconfig-netmod-opstate] has
proposed that intended configuration, actual configuration, and the
traditional type of operational data be included as operational state."

Maybe there is a typo here, the intended configuration should belong to
configuration.

[Sue]: You are correct - there is an error here.  Intended configuration
belongs to configuration. 

2. Since Ephemeral is about data not persisting over a reboot, maybe a
requirement for ephemeral states is that they MUST never be copied to the
startup configuration datastore? 

[Sue]: I will add this to the ephemeral state. 

Best regards,

Jie

HI all: 

Sue