Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

From: "Burger, Eric" <[email-masked]>
Date: Tue, 13 Jun 2006 05:00:52 -0400

Also don't forget that under any circumstance, the server could decide
'later' that it cannot honor a request.  This is independent of whether
we have the server say, "I might have so many sessions available for
you" when asked or if the server doesn't say anything about how many
sessions are (could be) available.  Once you have to write the code for
the client to handle that situation, it turns out there is no value to
the server giving an indication as to how many sessions are available
for you.  Thus we took out reporting on the number of available server
sessions from the specification.

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Sunday, June 11, 2006 3:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-07.txt

[email-masked] wrote:

>Thank You for the update Alexey,
>I have a few comments:
> - "   state is deleted.  While there is no required minimum expiration
>   timeout, server implementations are encouraged to support as long a
>   time as possible, subject to denial-of-service and related
concerns." This is something I have commented before. I do not know if
the idea has been discussed. It would be very beneficial for the client
to know how long the server keeps the sessions, even better if the
client could negotiate this setting. Has this been discussed during the
interim?
No it hasn't.
I've read both your message and Randy's reply to it. I think Randy 
argued against the need for the server to advertise/be able to change 
any limit. If you disagree, can you please reply to Randy's message and 
we will continue the discussion.

>Was there any conclusion?
> - "   previous, active resumable session is available.  If an active
>   session is already available and a new one can be created, the" What
happens when a new session cannot be created?
The server would reply NO and the current active session remains active.

I guess this can be spelled out in the document.

>Who says it cannot be created and why?
>
Server can have a policy limiting number of available sessions per user,

per IP or other factors. This can be done in order to limit DoS attacks.
Server can have a global limit on number of sessions it can serve.

At the end this is dictated by available resources.

>What is the server/client behaviour if it could not be created?
>  
>
Client needs to fallback to using regular IMAP, as if the quick 
reconnect extension is not available.

In theory the client can do something differently if it expects, say, 3 
resumable sessions and only got 2.

> - "   In order to limit Denial of Service attacks a server
implementation
>   SHOULD have a per-user limit on maximum number of resumable
sessions." If the server imposes such limit, what is the way to
communicate the number of current sessions and the limit to the client?
There is currently no way to communicate the number of sessions 
available to a user.
This was discussed during the recent interim and Eric convinced me that
a). specifying any limit in the document wouldn't help, as multiple 
clients acting on behalf of a single user would be able to exceed any
limit.
b). advertising any limit (or remaining number of sessions) would not 
help, as there is a race condition between the moment when the server 
advertises the remaining number and the moment when the client can 
create a new session. So the client would have to be able to deal with 
server saying "I can't create any more sessions" anyway.

> - "   server then checks the last known modification sequence."
MODSEQ?
Yes.

> - "   [[anchor8: This section clearly assumes voluntarily
disconnect]]" should it be described instead having it as an anchor? It
is already described  - except the voluntary part - so it could simply
be removed.
Yes, this will be deleted.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Tue, 13 Jun 2006 15:12:21 -0700

>  sessions from the specification.

If we expect clients to maintain multiple active sessions, then there 
may be some benefit in providing guidance (not a requirement) as to 
how many sessions a server should permit and a client can expect. 
Guidance as to what is reasonable.  Informative, not normative.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We adore chaos because we love to produce order.
                                  --M. C. Escher