Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-sipping-race-examples-06

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Oct 2008 16:48:55 -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 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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Oct 2008 18:25:21 -0400

Ben,

Miki is hunting up something that I guess accidentally didn't get sent 
to you.

Meanwhle:

>> that indicate a dropped packet.

Certainly *reordered* messages can occur with TCP if there are any 
intermediate nodes.

I think perhaps a single message could also be *lost* with TCP on every 
hop and an intermediate proxy if the proxy crashed and restarted.

Certainly a message can be lost if the UAs have TCP connections to 
proxies, and there is at least one UDP connection between the proxies.

Of course proxies are typically not shown, so that is hard to show in 
detail, and would needlessly complicate things.

But I certainly agree that there might be a better way to to explain 
this. Would it be sufficient to beef up the above paragraph to explain 
that we don't show proxies, but assume they might be present, and that 
in the presence of proxies there is always the possibility of 
rearranging or losing messages for the above reason? Maybe that general 
principle is a good one to point out, since its another one of those 
things that is periodically brought up again.

	Thanks,
	Paul

---

From: Miki HASEBE <[email-masked]>
Date: Fri, 10 Oct 2008 17:57:26 +0900

Hi Ben,

Details seem not to get through to you because there was no address of you
 ([email-masked]) in the e-mail of the answer to Gen-ART. I have answered
again. 

The answer is inline.

> 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.

> > that indicate a dropped packet.

Dropped packets need to be considered even if the UA uses TCP, because
intermediate element may use UDP as a transport protocol.

> not clear to me if this draft is introducing the MAY or simply  

It is "simply reporting". Reason for recommendation is written in the
draft.

> > is that not a state transition?

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.)

> > meaning is for the moratorium state? Can you mention why you chose  

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.

> is _addresses_ by an essential correction.

OK, I will fix it.

> section to determine what is being referenced. Failing that, mnemonic  

I have no preference. I will insert <document name> to next revision.

> either making a stronger recommendation, or removing the  

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.

> > "The UA should not reject or drop the ACK on grounds of the CSeq

This is not stating anything beyond what is stated unambiguously in 3261.
Its just reiteration.

> > this, or suggesting a new requirement?

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.

> 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.

> > a draft on a different subject may not get them the reader attention  

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2008 14:08:28 -0500

On Oct 9, 2008, at 5:25 PM, Paul Kyzivat wrote:

> Ben,
>
> Miki is hunting up something that I guess accidentally didn't get  
> sent to you.
>
> Meanwhle:
>
> Ben Campbell wrote:
>
>>> same for TCP as for UDP? I am skeptical that this is true for  
>>> cases that indicate a dropped packet.
>
> I think perhaps a single message could also be *lost* with TCP on  
> every hop and an intermediate proxy if the proxy crashed and  
> restarted.
>
> Of course proxies are typically not shown, so that is hard to show  
> in detail, and would needlessly complicate things.
>
> this. Would it be sufficient to beef up the above paragraph to  
> explain that we don't show proxies, but assume they might be  
> present, and that in the presence of proxies there is always the  
> possibility of rearranging or losing messages for the above reason?  
> Maybe that general principle is a good one to point out, since its  
> another one of those things that is periodically brought up again.

I agree that this would help, and would address my comment.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2008 15:06:45 -0500

Thanks for the response--comments inline. I removed sections that I  
think we are in agreement on.

On Oct 10, 2008, at 3:57 AM, Miki HASEBE wrote:
[...]

> I'll follow AD's judgment.

Okay, that is reasonable. While the ADs certainly have the final say  
in the matter, I would suggest that if the purpose is to describe race  
conditions that can occur, this would be an informational. On the  
other hand, if the purpose is to suggest that implementors take  
specific actions to avoid or mitigate the conditions, then it might be  
a BCP.

> intermediate element may use UDP as a transport protocol.

Understood--see my comment to Paul's email on the subject.

> It is "simply reporting". Reason for recommendation is written in the

Okay. It would be less ambiguous if it said something to the effect  
of  "...not recommended by RFC 3261".

By the way, this is really bound up with the question about whether  
this is a BCP or an informational RFC. If it's just an informational,  
then I tend to assume statements like this are merely describing  
statements in the relevant specs. If it's a BCP, then I assume the RFC  
makes recommendations above and beyond those in the protocol specs, so  
it becomes more important to be unambiguous.

> (Refer to Section 9.6 in RFC3261.)

Okay.

> with BYE though this state is in the Confirmed state.

I'm sorry, but I am having trouble understanding that sentence.

The dictionary definition of "moratorium" is a temporary prohibition  
of an activity. I understand that in this case, the state is  
temporary--but what activity is being prohibited? It would be helpful  
to have explicit text on that in the definition in section 2.

> on whether the sending of the 491 or the 200.

Ah, that makes sense. It would be clearer to say something to the  
effect of "However, since a 491 response can also lead to the same  
outcome, an implementation should be prepared to accept either  
response."

> This is not stating anything beyond what is stated unambiguously in  

I think for a reader not intimately familiar with CSeq handling for  
ACK may read more into that sentence than you intend. I propose  
changing the word "should" to "will". On reflection, I think you could  
drop the sentence completely, since the previous sentence already  
points out that the CSeq is _supposed_ to match that of the INVITE.

> that session has been successfully terminated.

I think the current language is very confusing.

Does the following capture the intent?

"A UA in the Mortal state will return an error response to any request  
that normally operates within a dialog, such as re-INVITE, UPDATE, or  
REFER. But in this example, the UA returns a 200 OK when it receives  
the BYE request while in the Mortal state. This communicates to the  
sender that a dialog has been properly terminated. If, for example,  
the UA returned a 481 response, the sender would not be able to tell  
whether the dialog had been terminated properly, or whether the BYE  
was incorrectly sent for a non-existent dialog.

While the 200 OK response is more useful in this scenario, the sender  
of the BYE request must be prepared to receive other responses."

> Can we just let it slide?

On reflection, it is probably not worth the effort to change this at  
this point in the process.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2008 16:25:52 -0400

Ben,

More inline. And I have pruned out more settled stuff.

	Thanks,
	Paul

Ben Campbell wrote:
> Okay, that is reasonable. While the ADs certainly have the final say in 
> the matter, I would suggest that if the purpose is to describe race 
> conditions that can occur, this would be an informational. On the other 
> hand, if the purpose is to suggest that implementors take specific 
> actions to avoid or mitigate the conditions, then it might be a BCP.

I can still go either way on this, but would like to get it nailed down, 
because it influences the language we need to use.

I think I lean toward BCP so that we *can* make real recommendations 
between legal alternatives. Even then there are those "hints" where IMO 
there is disagreement over what is best. So in those cases there may 
continue to be just discussion, without recommendation.

> Okay. It would be less ambiguous if it said something to the effect of  
> "...not recommended by RFC 3261".
> 
> By the way, this is really bound up with the question about whether this 
> is a BCP or an informational RFC. If it's just an informational, then I 
> tend to assume statements like this are merely describing statements in 
> the relevant specs. If it's a BCP, then I assume the RFC makes 
> recommendations above and beyond those in the protocol specs, so it 
> becomes more important to be unambiguous.

See my comment above on this.

> The dictionary definition of "moratorium" is a temporary prohibition of 
> an activity. I understand that in this case, the state is temporary--but 
> what activity is being prohibited? It would be helpful to have explicit 
> text on that in the definition in section 2.

I'm not taking a position on this. To me these are just labels. The 
connotation has *some* value, but its of necessity limited. If there is 
a better alternative then I would be ok with changing it. But I don't 
have a better alternative in mind.

> Ah, that makes sense. It would be clearer to say something to the effect 
> of "However, since a 491 response can also lead to the same outcome, an 
> implementation should be prepared to accept either response."
> 
>>
>>
>>
>>>>
>>>> [3.1.4] 4th paragraph:
>>>>
> I think for a reader not intimately familiar with CSeq handling for ACK 
> may read more into that sentence than you intend. I propose changing the 
> word "should" to "will". On reflection, I think you could drop the 
> sentence completely, since the previous sentence already points out that 
> the CSeq is _supposed_ to match that of the INVITE.

I had to go back to the book on this one and I'm still not sure. The 
CSeq must match if there's no branch, so at best this only applies when 
there is a branch. In that case the matching rule doesn't call for 
matching on the CSeq, but any case when they didn't match would be 
illegal usage by the UAC.

So I think maybe I agree its ok not to mention this.

> REFER. But in this example, the UA returns a 200 OK when it receives the 
> BYE request while in the Mortal state. This communicates to the sender 
> that a dialog has been properly terminated. If, for example, the UA 
> returned a 481 response, the sender would not be able to tell whether 
> the dialog had been terminated properly, or whether the BYE was 
> incorrectly sent for a non-existent dialog.
> 
> While the 200 OK response is more useful in this scenario, the sender of 
> the BYE request must be prepared to receive other responses."

I like that. I had already proposed another alternative to Miki:

"UAs in the Mortal state return error responses to the requests that 
operate with a dialog or session, such as re-INVITE, UPDATE, and REFER. 
However, the recommended best practice is to return a 200 in response to 
a BYE received in Mortal state. This regularizes the common case where 
caller and callee exchange BYE messages when a session is being 
terminated. It is valid because RFC 3261 doesn't state whether a session 
ends then a BYE is sent or when the response to it is received. However 
the UA sending a BYE must also be prepared to receive a 481 response, 
and should not consider that abnormal."

But I think I like yours better.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Oct 2008 15:44:53 -0500

more pruning...

On Oct 10, 2008, at 3:25 PM, Paul Kyzivat wrote:

>> Okay, that is reasonable. While the ADs certainly have the final  
>> say in the matter, I would suggest that if the purpose is to  
>> describe race conditions that can occur, this would be an  
>> informational. On the other hand, if the purpose is to suggest that  
>> implementors take specific actions to avoid or mitigate the  
>> conditions, then it might be a BCP.
>
> I can still go either way on this, but would like to get it nailed  
> down, because it influences the language we need to use.
>
> between legal alternatives. Even then there are those "hints" where  
> IMO there is disagreement over what is best. So in those cases there  
> may continue to be just discussion, without recommendation.

Don't get me wrong, I don't hate the idea of this being a BCP. My  
issue was that it didn't seem like it made many real recommendations,  
with the possible exception of BYE glare conditions scenario. Given  
that the majority of this is descriptive text, if it does stay a BCP  
then it would be good to explicitly distinguish concrete  
recommendations between said legal alternatives.

For example, would you characterize the tweaks to the state machine as  
recommendation or description?

>> this is a BCP or an informational RFC. If it's just an  
>> informational, then I tend to assume statements like this are  
>> merely describing statements in the relevant specs. If it's a BCP,  
>> then I assume the RFC makes recommendations above and beyond those  
>> in the protocol specs, so it becomes more important to be  
>> unambiguous.
>

Same here :-)

>> The dictionary definition of "moratorium" is a temporary  
>> prohibition of an activity. I understand that in this case, the  
>> state is temporary--but what activity is being prohibited? It would  
>> be helpful to have explicit text on that in the definition in  
>> section 2.
>
> connotation has *some* value, but its of necessity limited. If there  
> is a better alternative then I would be ok with changing it. But I  
> don't have a better alternative in mind.
>

I'm not really asking for the label to be changed--merely that the  
reasoning behind the choice be given in the definition of the term,  
since I did not find it obvious.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Oct 2008 17:32:00 -0400

more...

Ben Campbell wrote:
>>> in the matter, I would suggest that if the purpose is to describe 
>>> race conditions that can occur, this would be an informational. On 
>>> the other hand, if the purpose is to suggest that implementors take 
>>> specific actions to avoid or mitigate the conditions, then it might 
>>> be a BCP.
>>
> Don't get me wrong, I don't hate the idea of this being a BCP. My issue 
> was that it didn't seem like it made many real recommendations, with the 
> possible exception of BYE glare conditions scenario. Given that the 
> majority of this is descriptive text, if it does stay a BCP then it 
> would be good to explicitly distinguish concrete recommendations between 
> said legal alternatives.

Good point. I think the exercise is to go through and tag (with some 
sort of language) each roughly normative statement as either a 
recommended best practice or a reiteration/inference from a spec.

If there are a meaningful number of best practices then its good for it 
to be a BCP.

> recommendation or description?

Well, I think some of the added detail reflects description of unclear 
but unambiguous inferences, and so is just description. But perhaps some 
of it reflects choices among legal alternatives and so is 
recommendation. But it may require some tweaking to make that clear.