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 resolve these comments along with any other Last Call comments
you may receive.
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
