Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree?

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jul 2015 20:40:14 +0000

In my effort to submit an update for this draft before the cutoff on
Monday, I'm going to assume that silence equals consent on the solution
below, if no objects are raised before this end of day Friday.

Thanks,
Kent

On 6/25/15, 7:25 PM, "Kent Watsen" <[email-masked]> wrote:

>
>Regarding moving "idle-timeout" node to the "listen" tree, I'm still a fan
>of that, but what I think would be even better is to also have an
>idle-timeout in the call-home/periodic and the call-home/persistent
>sub-trees.   
>
>An idle-timeout is always useful, but its value needs to be different for
>the various cases.  How about this:
>
>                                          Default
>                                          -------
>   listen/idle-timeout                    1 hour
>   call-home/periodic/idle-timeout        5 min
>   call-home/persistent/idle-timeout      1 day
>
>
>What do you think?  - makes sense?
>
>
>Kent
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2015 14:04:23 -0700

> >What do you think?  - makes sense?

I guess I missed a meeting.
I remember deciding to remove idle-timeout for persistent connections.
Why do we need persistent connection timeouts?  I know a session
that has a notification subscription active never times out.

What kind of persistent session times out after 1 day?
Seems like call-home sessions should be the same timeout
as the idle-timeout (and persistent connections never time out).

> >Kent

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jul 2015 21:31:29 +0000

> I guess I missed a meeting.

There was none, just the email I sent before...

> Why do we need persistent connection timeouts?

Even a persistent connection should have some kind of timeout.  A day, a week, a month, whatever.  It just seems that, after some crazy long duration with no NC/RC-level message being sent by the client, something has gone wrong and the session should be reaped.

> as the idle-timeout (and persistent connections never time out).

Very different timeouts are desired.  Persistent connection timeouts are addressed above.   On the other end of the spectrum, we have periodic connections that, by design, should not be held open for an extended amount of time.  Again, be it 5 minutes, 30 minutes, or an hour, at some point it becomes clear that something has gone wrong and the session should be reaped.

The net-net is that I'm thinking that there should always be some kind of idle-timeout, but its default value varies greatly by use-case.    Makes sense?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2015 14:36:59 -0700

On Wed, Jul 1, 2015 at 2:31 PM, Kent Watsen <[email-masked]> wrote:

>  Even a persistent connection should have some kind of timeout.  A day, a
> week, a month, whatever.  It just seems that, after some crazy long
> duration with no NC/RC-level message being sent by the client, something
> has gone wrong and the session should be reaped.
>
>

A client that starts a session for NETCONF notifications
or even RESTCONF SSE may only send 1 request and never send anything again.
It will only listen for notifications.  Our server never times out these
sessions.

>    Very different timeouts are desired.  Persistent connection timeouts
> are addressed above.   On the other end of the spectrum, we have periodic
> connections that, by design, should not be held open for an extended amount
> of time.  Again, be it 5 minutes, 30 minutes, or an hour, at some point it
> becomes clear that something has gone wrong and the session should be
> reaped.
>
>
>  The net-net is that I'm thinking that there should always be some kind
> of idle-timeout, but its default value varies greatly by use-case.    Makes
> sense?
>
>  Kent
>
>

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jul 2015 22:04:35 +0000

> It will only listen for notifications.  Our server never times out these sessions.

Yes indeed, the current idle-timeout description says "Sessions that have a notification subscription active are never dropped." - we'd keep this language.    This said, do you agree that having a different idle-timeout value for the various use-cases makes sense?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2015 15:08:57 -0700

On Wed, Jul 1, 2015 at 3:04 PM, Kent Watsen <[email-masked]> wrote:

>  Yes indeed, the current idle-timeout description says "Sessions that
> have a notification subscription active are never dropped." - we'd keep
> this language.    This said, do you agree that having a different
> idle-timeout value for the various use-cases makes sense?
>
>

OK -- sorry I forgot that notification text was already in there.

I agree with your proposal to have 3 different defaults

Andy