Document: draft-sparks-sip-nit-actions-03.txt
(reviewed in parallel with draft-sparks-sip-nit-problems-02.txt which identified 
the problems which this document proposes to solve).

Trigger: IETF last call, 10 March 2005
Reviewer: Elwyn Davies
AD: Allison Mankin
Review Date: 17 March 2005
Intended status: Proposed Standard (update of SIP, RFC3261)

Summary:
[I note that this appears to have been on track to be a WG draft before the WG 
shut down (as was the problems draft) – I am therefore assuming that the 
problems and solutions are acknowledged by the community as is evidenced by 
names of contributors which include ex-WG chairs].

The draft appears to be close to readiness as an update to RFC3261.  It is 
certainly closely matched to the problems draft (with the exception of the more 
general issue of mismatched T1 timer configuration values, which is really 
outside the scope of the drafts).  Also the security issues are better addressed 
in this draft.

I think that there are a couple of points where the wording needs clarifying.  
One particular point is to ensure that the revised SIP specification remains 
backwards compatible with the old specification.  I believe the changes set out 
in s4 *are* backwards compatible (for the most part server side changes), but 
the wording of the commentary in section 2.1 and the first bullet point of 2.2 
could be misinterpreted to imply non-backwards compatible changes to clients.

It should also be noted that predicting when Timer E in the client will expire 
is essentially impossible, so that changes suggested by the 2nd and 3rd bullet 
points in s2.1 will help but are not guaranteed to solve the problem.

Review:
The draft appears to be close to ready as a Proposed Standard.  There are a 
number of items which ought to be clarified, in line with comments to the 
'problems' draft, and to make it clear that the changes are backwards compatible 
so that an updated server will work with old clients (the client side is (or 
should be unchanged, I believe).

General: As per the problem draft, terminology definitions have been imported 
from RFc3261 and it should say so.  Copying the definition of T1 and Timer E 
would help and the '408' magic number should be turned into English at least 
once.

Header: Specify updates RFC3261

S1/S2: [See comments on 'problems' draft.] The phrases 'losing the race' and 
'408 responses are useless' are not very helpful.  Alternatives are suggested in 
the problems review.

S2: I note that 'reducing the probability of losing the race' to a negligible 
value is a desirable goal but is actually not really addressed by these actions 
and if expressed differently (as suggested above) will be seen for the 
impossibility it is.  All that can be achieved is to reduce the number of 
messages that are pretty much guaranteed to be sent at a time when they will 
'lose the race' such as the 408 errors which would always be sent at the end of 
the server timeout period.  A slow server can still send a success response 
towards the end of the timeout period and have it arrive too late for the 
client.

S2: s/useless/superfluous/

S2.1 and S2.2 Bullet point #1: It should be made clear that these actions relate 
only to servers.  'Disallowing' messages could be interpreted as requiring 
clients to be upgraded to explicitly reject such messages.  This would obviously 
not be backwards compatible.  Actually the detailed specifications later more or 
less make it clear that only servers are affected so this is just a matter of 
making it crystal clear that clients should continue to behave as at present.  
On second thoughts, presumably a client could perhaps silently ignore non-100 
provisionals?

S2.1: The effectiveness of this solution depends on the value of the Timer E 
timeout(s) being known or predictable in the server.  This relies on all nodes 
being configured similarly since the timeouts values are not 
transmitted/negotiated on the wire.  As mentioned elsewhere in the drafts the 
effects of this rule will be unpredictable if not. (E.g.) if the server timeouts 
are significantly shorter, the server may think Timer E has expired before the 
client and send the 100-Trying message too early before the Timer E timeout has 
reached T2 in the client.

S2.2: The term 'stray' is a technical term used in RFC3261... this should be 
made clear.

S4: It would be helpful to specify the sections of RFC3261 that these changes 
affect.

S4.1 (4th para): s/responed/responded/