Document: draft-ietf-sipping-race-examples-05 Reviewer: Ben Campbell Review Date: 2008-05-27 IETF LC End Date: 2008-05-28 IESG Telechat date: (if known) Summary: This draft is almost ready for publication. I have some comments that I think should be considered first, as well as a question on whether this should really be a BCP verses just an informational RFC. Comments: General: --BCP vs Informational: I am confused as to why this is expected to be a BCP rather than just an informational RFC. What specific practices are being recommended over and above those already in the SIP standards? In general, I see two classes of practices that might be candidates: 1) Section 3.1.1 references a bug in RFC 3261, and describes the correct behavior. This would certainly count towards being a recommended practice. However, this bug is already being addressed as part of the SIP essential corrections process, in draft-sparks-sip- invfix. I assume that draft is to be a standards track update to RFC 3261, and will therefore be "authorative" on this matter. Given that the window of time between when this draft and that draft are published as RFCs will likely be small relative to the lifetime of RFCs, I'm not sure this draft should do much more than reference that one. 2) Most of the cases in this draft have a section described as a "hint" for how an implementation can avoid the race condition. However, it is generally not clear to me if this is intended as a recommended practice, or just offered up as something people could do if they wanted to. If the former, then they should probably be described in terms more strong than "hint". On the other hand, I realize that other documents which primarily offer examples of SIP message flows have been published as BCPs. While it is not clear to me why that is the case, I am open to answers of the form "Lets do this as a BCP to be consistent with the other call flow example documents." --Harmful vs harmless cases and "hints" : It would be helpful if, in each race condition, you mention whether what specific harm is caused by the case, or that it is harmless. In almost each case, you mention a "hint" on how an implementation could avoid a race condition by playing with the timing of certain actions. That might make sense in a harmful case depending on the extent of the harm. But it's probably not worth adding the complexity if the particular case is harmless. Also it would help to be extra clear on whether each section is recommending new behavior over and above RFC 3261, or if correct implementations can handle the case "as-is". Also, for each "hint" it would be worth adding a sentence or two discussing whether following the "hint" is likely to do other harm. For example, could delaying a re-invite a few seconds degrade the user's experience, since they might not get an immediate response to some action like putting a call on hold? Section 1.1, paragraph 2: You say that these use cases are not specific to the transport protocol. Should I infer from that that all of these cases are the same for TCP as for UDP? I am skeptical that this is true for cases that indicate a dropped packet. Section 2, first paragraph after Figure 1: "The caller MAY send a BYE in the Early state, even though this behavior is NOT RECOMMENDED." It's not clear to me whether this is a new recommendation made by this draft, or a description of a recommendation in RFC 3261. (I find this to be true of much of the normative language in this draft.) First paragraph after figure 2: "A CANCEL request does not cause a dialog state transition." I can see that being true for the UAC, but is it really true for the UAS? You go on to say that the "callee terminates the dialog"; how is that not a state transition? Definition of Moratorium State: It's not clear to me from the description what the "conceptual" meaning is for the moratorium state? Can you mention why you chose the term "moratorium"? 3.1.1, title. The titles would be more meaningful if they mentioned the actor. For example "Callee receives initial INVITE..." vs "Receiving initial INVITE..." Paragraph 2: "SIP bug": I'm not sure all readers will know what that means. I suggest something to the effect of "... error in the SIP specification". You reference bug #769 from bugs.sipit.net. Keeping in mind that RFCs last practically forever, I'm not sure a web site reference is a good choice, since web pages are relatively ephemeral. It would probably be better to at least reference draft-sparks-sip-invfix, although that is also a work in progress. "(UAs that do not deal with this bug still need to recognize..." That _sounds_ like a requirement. Should it be stated normatively? 3.1.2, 2nd paragraph: s/"... an INVITE failure"/"... the INVITE was actually canceled". (A canceled INVITE is not a failure). 3.1.4, 1st paragraph: It's easy to get confused over which device is in which state. I suggest language to the effect of " ... a UAS in the moratorium state receives a re-invite sent by a UAC in the Established state." 2nd paragraph: Please don't abbreviate the word "with" as "w/..." 3rd paragraph: "it is recommended that the UA return a 491 to the re-INVITE" Is that intended to be normative? "This example recommends that 200 be sent instead of 491 because it does not have an influence on the session. However, a 491 response can also lead to the same outcome, so either response can be used." I'm confused--the text just said 419 is recommended, now it says 200 is better, but then again it really doesn't matter? 4th paragraph: "The UA should not reject or drop the ACK on grounds of the CSeq number." Normative? 3.2.1, 2nd paragraph: "shall return 200" Are you saying that 3261 compliant UAs will do this, or suggesting a new requirement? Also what do you mean by "exchange reports about the session" with simultaneous BYE requests? 3.3.1, 3rd paragraph: I am confused whether this paragraph is talking about bona-fide request retransmissions (i.e. same CSeq, etc) vs merely trying an action again by sending a _new_ request after receiving the 491. Appendices (all) It's not clear to me why the information in the appendices is in scope for this draft. None of it seems to be about race conditions. They are, however, good discussions of interesting corner cases, and maybe worthy of drafts in themselves. This is certainly not a big deal; I just have a mild fear that relegating them to appendices of a draft on a different subject may not get them the reader attention they deserve.