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.
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 <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.
[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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
