Subject: RE: [SIP] First cut review of Session Timer draft

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Apr 2001 22:43:15 -0500

Hi all,

I also have a few first cut comments on the draft for the last-call(for
which Rakesh has just made the WG announcement). I've followed Ben's
formatting convention and also use " " to indicate exact text
references/proposals:

3:4 - In the middle of the paragraph, there is a statement: 
" To make  sure the UAC is aware it must
actually do them, the UAS MUST add a Require header to the 200 class
response, with the tag "timer", when the request contains a Require
header with tag "timer". "
--> The last clause of the sentence should be...
" when the request contains a Supported header with tag "timer". "

9:1 (Section 5) Propose that the statement "In general, proxies which ask
for session timers will record-route, since they won't receive refresheds if
they don't." be changed to something a bit stronger (i.e. a bold
RECOMMENDATION) such as: 
"It is RECOMMENDED that the proxy include the record-route header if it
wants to receive the refreshes."

12:Table 3 - (minor formatting) Propose line spacing between table entries.
It can be a bit difficult to read since the Behavior spans multiple lines.
Another suggestion would be to have the entries in the same order in which
the scenarios were discussed in the preceeding paragraphs.  

In addition I have a couple more general recommendations on the Session
Timer one of which is in line with Ben's recommendation about a strong
statement on NOT to use Session Timer for billing. 

- Per the recent thread on the use of Session Timer for Pre-paid (you can
view this as a billing variant, but I see it more as a Service or
Application requiring a general purpose timing mechanism), I would suggest
adding a statement along the lines as follows just before the NAT/firewall
control paragraph on page 2:
"The Session Timer SHOULD NOT be used for service implementations (e.g.
Billing, Pre-paid, etc.).  Session Timer is not a general purpose network
timing mechanism, but is more specific to being able to free up resources
for some pathological scenarios.  Indeed, the Session Timer could be viewed
as much more of a network "maintenance" mechanism than a general purpose
network timer primitive mechanism." 

- 2:5 In addition, I would suggest at a minimum to "soften" the endorsement
of session timer for NAT/Firewall control.  One suggestion would be
rewording the paragraph to be:
"Another possible application of the session timer may be in NAT and
firewall control."  
In line with this suggestion, I would think since the referenced draft is
still an ongoing project of the WG that it may not be prudent to include
this reference in this document going forward.  
A more radical suggestion would be to remove the NAT and firewall paragraph
altogether.  The NAT/firewall draft references Session Timer and I think
that would be sufficient (i.e the circular references are unnecessary). In
additon, my view would be that if any potential application of the Session
Timer were discussed further in this draft, it would be the use for the
recovery mechanism to accomplish soft stated SIP sessions (referenced page
2, paragraph 3),  Particularly since this is the substantiation given for
using INVITES rather than a lighter weight mechansim such as the INFO ping
(which reduces end to end messaging and simplifies the processing for the
mechanism).   

Regards,
Mary H. Barnes
[email-masked]
IMS Solutions Standards Strategy
972-684-5432

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, April 24, 2001 11:57 AM
To: Steve Donovan; Jonathan Rosenberg
Cc: Rakesh Shah; [email-masked]'
Subject: [SIP] First cut review of Session Timer draft.

Here are my first cut comments on session-timer for the upcoming last-call.
Most of these are minor comments. Please forgive me if I am re-opening old
discussions, as I did not follow the original session-timer work. 

Comments referring to specific parts of the document are prefixed with
(page:paragraph)

Global - We might need language (perhaps in security considerations) that
recommends against using session-timer for billing purposes with out
additional corroboration. I can imagine a theft-of-service attack where the
UAs collude in letting the session expire, but maintain the RTP session. Any
proxy in the middle would assume the call was over. This will not work if
the timer controls a firewall, but it could if the timer was only used to
establish end-of-call for billing purposes.

Global - (nit) there are several sections where the normative language is
not clear. For example, it often says "X does Y" instead of "X MUST|MAY|etc
do Y." Most of these are in the early descriptions, so perhaps the intent is
to reserve normative language for the specific behavior descriptions later
in the draft. If that is so, then it is not consistent.

3:2-A proxy can lower but not increase the expiration time. Jonathan brought
up the issue of a DoS attack using insanely small expirations. If a proxy
cannot increase the expiration, it at least needs the option of rejecting
requests with expiration values below a threshold.

3:4 - (Typo) Sentence "They UAS MAY..." should read "The UAS MAY..."

3:4 - (Minor) I am not sure I see the value in pushing responsibility back
to a supporting UAC, if the UAC did not request the timer in the first
place. Why not just let the UAS deal with it, if the UAS is the element that
wishes to use a timer? At least it might make sense to say that the UAS must
insert the Required header IF it wishes the UAC to handle the re-invites.

4:5  What happens if the UAC does _NOT_ include a Session-Expires header on
the re-invite? I assume everyone resets their timers with the original
values? Or does timer processing cease?

5:2 - Doesn't option of absolute time imply an assumption that all elements
have their clocks reasonably synchronized?

5:3 - Again, we need to allow elements to reject expirations below a
configured threshold.

10:2 - How can a proxy know that it is the closes proxy to the UAC that
cares about the timer? Except in the trivial case where the proxy is the
closest to the UAC period, this seems problematic.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.