Hi Ben, Details seem not to get through to you because there was no address of you ([EMAIL PROTECTED]) in the e-mail of the answer to Gen-ART. I have answered again.
The answer is inline. Ben Campbell <[EMAIL PROTECTED]> wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > 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. I've kept the draft's intended track as it is and related text unchanged, because it's still undecided whether it is going to be BCP or Informational. I'll follow AD's judgment. > > 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. Dropped packets need to be considered even if the UA uses TCP, because intermediate element may use UDP as a transport protocol. > > 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. It is "simply reporting". Reason for recommendation is written in the 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? > > No change or response Yes, it is true for the UAS. A CANCEL doesn't directly influence the dialog state of UAS and it only influences the INVITE transaction. The trigger that changes the dialog state of UAS is a 487 response to the INVITE. (Refer to Section 9.6 in RFC3261.) > > 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 The reason to select the name of Moratorium is a temporary period to the arrival at the perfect condition because of cutting with BYE though this state is in the Confirmed state. > > [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. OK, I will fix it. > [New Comment] 3.1.2, first paragraph: > > Please say "corrected in <document name> [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. I have no preference. I will insert <document name> to next revision. > > [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. The reason to recommend 200 is that there is no pending offer in this case. However, UA should be prepared to see a 491 response because 3261 isn't clear on whether the sending of the 491 or the 200. > > > > [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 This is not stating anything beyond what is stated unambiguously in 3261. Its just reiteration. > > > > > > 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 There is no new requirement. The problem is that 3261 isn't clear on whether the sending of the BYE or the receiving of the response to the BYE terminates the dialog. I think that RFC3261 allows both a 200 and an error (ex. 481) to the BYE request. As a BCP I think this is a best practice but one must be prepared to see a 481 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. I mean in this sentence that UAs will exchange the information that the BYE request has been processed properly and that session has been successfully 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 > I guess the other appendices could be deferred to a separate draft. But are they worthy of the effort needed to progress a separate draft? I think it would be better to keep these things together. Can we just let it slide? Thank you, Miki _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
