Subject: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06

From: Larry Zhu <[email-masked]>
Date: Tue, 7 Oct 2008 01:21:43 -0700

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Overall the document is clear. I have the following comments:

1. The title of the document does not seem to reflect the content of the document. The document seems to describe implementation pitfalls in SIP, not racing conditions.

See http://en.wikipedia.org/wiki/Race_condition, a race condition is perceived as a flaw. Throughout the document I am not convinced the SIP protocol is flawed. Rather, the document seems to suggest that implementations flaws can be avoided if the asynchronous nature of the SIP message processing is taken into considerations. The body of the document at various places suggests this document contains just clarifications to RFC3261. I suspect that the word "clarifications" might be used to better describe what the document is about.

2. Section 1, paragraph 3, the word "UA". This should be expanded on the first use.

3. Section 1, paragraph 5, the word "SDP". This should be expanded on the first use.

4. Section 1, paragraph 4, last sentence. Consider s/standard/robust/. I suspect the later word is intended.

5. section 1.3, there is line with just "actors", I do not understand why the extra line is there.

6. Section 1.3, " (Which differs somewhat from the definition of the term in RFC 3261.)". This sentence is confusing and not substantiated. I am not sure why the session definition is "somewhat" different. This could be expanded or just removed since it adds confusions for the reader (as least for me).

7. Section 2, under figure 1, "Where (r) is not used as an indicator, "response" means receive, and "request" means send." I do not understand what this sentence because I could not find either the word "response" or the word "request" in the diagram.

8. Section 2, under figure 2. Ditto.

9. There are over 10 pages of text in the appendix portion of the document. If this document were titled as "clarifications to RFC3261", these appendices probably should be moved into the main body of the document.

--Larry

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

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

> See http://en.wikipedia.org/wiki/Race_condition, a race condition is perceived as a flaw. Throughout the document I am not convinced the SIP protocol is flawed. Rather, the document seems to sugges…

Point taken. I'm struggling to come up with something that is more 
appropriate and also works as a document title/name. And its hard.

Clarifications of race condition handling in the Session Initiation Protocol
draft-ietf-sipping-race-condition-clarifications.txt
draft-ietf-sipping-race-condition-handling.txt

Resolution of race conditions in the Session Initiation Protocol
draft-ietf-sipping-race-condition-resolution.txt

Neither seems perfect to me, but I guess either would do and be more 
meaningful than the current name. Of course if we change the file name 
we will be back to -00. :-(

	Thanks,
	Paul

> 8. Section 2, under figure 2. Ditto.

We will take care of all these.

> 9. There are over 10 pages of text in the appendix portion of the document. If this document were titled as "clarifications to RFC3261", these appendices probably should be moved into the main body…

This has been discussed elsewhere. Technically they aren't about race 
conditions, but they are similar sorts of things that people have had 
question about. There has been some suggestion to make them another 
document, but nobody can justify the extra work that would take. We've 
been hoping we could just get by the way it is.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Oct 2008 18:36:42 -0500

How about "Clarification of Time and State Interactions in the Session
Initiation Protocol"

--
Dean

---

From: Larry Zhu <[email-masked]>
Date: Tue, 14 Oct 2008 16:48:04 -0700

That sounds great!

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 4:37 PM
To: Paul Kyzivat
Cc: Larry Zhu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: SECDIR review of draft-ietf-sipping-race-examples-06

--
Dean

---

From: Miki HASEBE <[email-masked]>
Date: Thu, 16 Oct 2008 20:16:05 +0900

Hi,

I've summarized the comments which I think I have to reflect to the draft.

1.Change of title of the draft
 I'm not sure whether the title may be changed at the current step.
 Does sipping chairs agree to change to the following title?
  "Clarification of Time and State Interactions in the Session Initiation
   Protocol"
2.SIP-over-TCP
 I'll add the considertaion when using TCP as transport to each sequence.
3.BCP/Informational
 Who has the right to make a decision whether BCP or Informational?
 I assume BCP and update the draft to clarify recommendations as BCP and
 other descriptions.
4.Other Gen-ART and SECDIR comments will be reflected.

Is my understanding correct that we will discuss it again after I send the
revision reflecting the above comments?

Thank you,
Miki
---------------------------------------------------------
Miki HASEBE
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 1236
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------