Document: draft-ietf-sipping-race-examples-06 Reviewer: Ben Campbell Review Date: 06 Oct 2008 IESG Telechat date: 09 Oct 2008 Summary: This draft is almost ready for publication. I still have some comments that I think should be considered first. Comments: I reviewed version 05 at last call. Some, but not all of my comments have been addressed in this version. I will quote any comments I feel have not been addressed below, along with any additional commentary. Anything I don't mention from my previous review has been addressed to my satisfaction. --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." This version backs away from "recommending" the "hints" I reference in item 2 above, and now correctly references the essential correction draft in item 1. It seems to me that this version steps further back from recommending specific practices than the previous version--thus I still wonder why it is a BCP rather than an informational. > 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. No change or response. > 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.) The NOT RECOMMENDED part is now changed to lower case, but it is still not clear to me if this draft is introducing the MAY or simply reporting on it. > > > 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? No change or response > 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"? No change or response > [3.1.1] 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. Fixed, but I think there is a bug in the fix. You now refer to the scenario as an essential correction. I think you mean to say that this is _addresses_ by an essential correction. [New Comment] 3.1.2, first paragraph: Please say "corrected in [7]", rather than "corrected in [7]." The second form forces the reader to flip to the reference section to determine what is being referenced. Failing that, mnemonic references help. > [3.1.4, 3rd paragraph (formerly 4th)] > > "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? The conflict with preceding paragraph is fixed (that paragraph was removed), but I'm still not sure I understand why you recommend 200, but then go on to say that either response can be used. I'd suggest either making a stronger recommendation, or removing the recommendation entirely. > > [3.1.4] 4th paragraph: > > "The UA should not reject or drop the ACK on grounds of the CSeq > number." > > Normative? No change or response > > > 3.2.1, 2nd paragraph: > > "shall return 200" Are you saying that 3261 compliant UAs will do > this, or suggesting a new requirement? No change or response > Also what do you mean by "exchange reports about the session" with > simultaneous BYE requests? Wording is changed, but it is still not clear to me what you mean by a exchanging reports about a session when it is terminated. > 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. No change or response