Session Timers in the Session Initiation Protocol (SIP)
draft-ietf-sip-session-timer-15

[Ballot discuss]
In general, having a sip session timer seems like a good idea, and the draft has done a reasonable
job at describing the proposed mechanism.  I'm concerned, though, that it is built around an
assumption that may not be correct.  According to section 4:

  The default value of the Session-Expires header field, when not
  present, is infinity. This means that absence of the Session-Expires
  header field implies no expiration.

This seems to be based on the idea that since proxies have no deterministic way of establishing
session end today, they are implicitly supporting "infinity" for all sessions now.
Based on this assumption (everyone's signed up for infinity), the design choices to ensure
that minima are correct look sufficient. 

I'm concerned, however, that this assumption may not hold for all applications which might
be using SIP sessions (either now or in the future), and that some networks may be counting on
configured or heuristic limits to avoid proxy overload (since maintaining state "forever"
is obviously a significant load).  This mechanism has no way to establish or signal maxima.
There are obvious cases where a proxy knows it cannot maintain state for the full length of
time which a session might set for expiry (e.g. a planned maintenance window ) and others
where conditions may impose limits.  Describing what the proxy should do in those cases
seems like it would help this specification.

I'd also like to suggest changing the spec so that the absence of Session-Expires
does not mean "infinity", as I think that overloads a lack in an unfortunate way.
Having that mean "undefined expiry" makes sense (especially since you could infer
from that that heuristics might be applied at a proxy to close a session).  When
an element needs to signal an "infinite" expiration time, it can do so explicitly
by setting the expiration very far in the future.  If that is not possible, I think the
document needs a very strong recommendation in the text that implementations
supporting this should not leave this blank (so that this ambiguity in interpretation is limited
to legacy systems).

As a smaller matter, I think section 7.2 needs some justification for why the refresh
should be sent at the half interval.  There seem to be cases for long session expirations
where something more like Section 10's method for sending the BYE (which gives both
an absolute and a fraction, and has the implementation send the minimum) would make
sense.  A justification would be useful to describe the logic there.

[Ballot discuss]
In general, having a sip session timer seems like a good idea, and the draft has done a reasonable
job at describing the proposed mechanism.  I'm concerned, though, that it is built around an
assumption that may not be correct.  According to section 4:

  The default value of the Session-Expires header field, when not
  present, is infinity. This means that absence of the Session-Expires
  header field implies no expiration.

This seems to be based on the idea that since proxies have no deterministic way of establishing
session end today, they are implicitly supporting "infinity" for all sessions now.
Based on this assumption (everyone's signed up for infinity), the design choices to ensure
that minima are correct and look sufficient. 

I'm concerned, however, that this assumption may not hold for all applications which might
be using SIP sessions (either now or in the future), and that some networks may be counting on
configured or heuristic limits to avoid proxy overload (since maintaining state "forever"
is obviously a significant load).  This mechanism has no way to establish or signal maxima.
There are obvious cases where a proxy knows it cannot maintain state for the full length of
time which a session might set for expiry (e.g. a planned maintenance window ) and others
where conditions may impose limits.  Describing what the proxy should do in those cases
seems like it would help this specification.

I'd also like to suggest changing the spec so that the absence of Session-Expires
does not mean "infinity", as I think that overloads a lack in an unfortunate way.
Having that mean "undefined expiry" makes sense (especially since you could infer
from that that heuristics might be applied at a proxy to close a session).  When
an element needs to signal an "infinite" expiration time, it can do so explicitly
by setting the expiration very far in the future.  If that is not possible, I think the
document needs a very strong recommendation in the text that implementations
supporting this should not leave this blank (so that this ambiguity in interpretation is limited
to legacy systems).

As a smaller matter, I think section 7.2 needs some justification for why the refresh
should be sent at the half interval.  There seem to be cases for long session expirations
where something more like Section 10's method for sending the BYE (which gives both
an absolute and a fraction, and has the implementation send the minimum) would make
sense.  A justification would be useful to describe the logic there.

Two AD review comments, the second one needing the document to be rev'd:

1.
Section 8

Session timers are mostly of interest to call stateful proxy  servers. However, a stateful proxy server MAY also follow the rules described here.

"a stateless proxy server MAY also follow" ?  This seems to be the intention from the writing.  But on the other hand, does the revised sentence make any sense?  It conflicts with the indented sentence at the end of the section.

2.
Security Considerations

We don't have standards for IPSec for SIP - s/IPSec or TLS/
and  /TLS or IPSec/  /TLS (RFC 3261)./

Example flows in Section 13 must reflect RECOMMENDED strength of the security considerations and show TLS and sips (they currently have sip: and UDP).

Responsible: Author
Waiting for update to reflect RFC 3261.
Not high priority SIP task.  Will now need new review
and Last Call after all this time.

State Changes to New Version Needed (WG/Author)                    from Wait for Writeup                                  by Allison Mankin