Subject: [Gen-art] Gen-ART LC review of draft-ietf-sipping-race-examples-05

From: Ben Campbell <[email-masked]>
Date: Tue, 27 May 2008 17:34:43 -0500

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art