Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)
Note: This ballot was opened for revision 06 and is now closed.
(Lisa Dusseault) Yes
(Jon Peterson) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
Comment (2008-09-23 for -)
INTRODUCTION, paragraph 13: > This document gives examples call flows of race conditions in the > Session Initiation Protocol (SIP). Race conditions are inherently > confusing and difficult to thwart; this document shows the best > practices to handle them. After reading the title, I was wondering why examples of race conditions are a BCP. I'd suggest to highlight in the title that the document also recommends practices to handle them. Section 1.1., paragraph 2: > These flows do not assume specific underlying transport protocols > such as TCP, TLS, and UDP. See the discussion in RFC 3261  for > details of the transport issues for SIP. I believe this statement oversimplifies things. For example, the scenario in Section 3.1.1 shows the "180 F2" being lost and the following "200 F3" getting through. If SIP runs over TCP instead of UDP, this scenario is extremely unlikely, because an implementation is recommended to reuse the same TCP connection for subsequent SIP messages, which means that TCP will retransmit the "180 F2" until it is delivered, before it transmits the "200 F3". What I'm getting at is that the choice of transport will affect the likelihood of these race conditions. If some race conditions would be a less likely with SIP-over-TCP, it may be a good idea if this BCP document recommended SIP-over-TCP rather than SIP-over-UDP. Section 200, paragraph 8: > /* F4 is a retransmission of F1. They are exactly the same INVITE > request. For UAs that have not dealt with bug report #769 Where can the reader find bug report #769 and others? Please add a reference.
(Pasi Eronen) (was Discuss) No Objection
(Russ Housley) No Objection
The document title is could be more clear. The document describes implementation pitfalls in SIP, not racing conditions. The document suggests that implementation flaws can be avoided by paying attention to the asynchronous nature of the SIP message processing. It seems that this document is similar to RFC 4718, IKEv2 Clarifications and Implementation Guidelines. I suspect that a similar title that uses "clarifications" would be a better document title. Ben Campbell did a Gen-ART review of -05 and -06. Some of his comments on -05 were addressed in -06, but some were not. The 2nd review can be found at: http://www.softarmor.com/rai/temp-gen-art/ draft-ietf-sipping-race-examples-06-campbell.txt
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) No Objection
Comment (2008-09-25 for -)
Section 3.1.4, para 3 seems to include conflicting recommendations. In the first sentence, "it is recommended that the UA return a 491..." but the next to last sentence states "This example recommends that 200 be sent instead of 491..." Perhaps the first recommendation was from some other document?
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
(Magnus Westerlund) No Objection
I have to support Lars's comment about the transport dependencies in some of these race condition. I would be happier if that was more explicitly pointed out.