Draft: draft-ietf-sipping-dialogusage-03
Reviewer:  Vijay K. Gurbani <vkg@lucent.com>
Review Date: Sept. 29, 2006
Review Deadline:  Oct. 2, 2006
Status: WGLC

Summary:
This draft is basically ready for publication, but has nits that should
be fixed before publication.

Detailed review:
This document posits that multiple dialog usage should be avoided simply
because its use was never envisioned in the protocol (SIP).  As a
result, the use of multiple dialogs today is rife with error cases that
are not canonicalized anywhere (and this draft attempts to document some
of these), nor does the working group has any substantive experience in
other cases where multiple dialog usage may be employed (e.g., use of
multiple dialogs with rfc3891, the "Replaces" header.)

As such, protocol designers are urged not to design extensions that
depend on, or employ multiple dialog usage semantics, and implementors
are urged not to support such usage in new code.

IMHO, this document needs to be more forceful in pointing the
conclusions in the above paragraph out -- this is what I surmised after
reading the document, especially S5.  The first two paragraphs of S5
should be put in the Abstract and then repeated again in the
Introduction, just to be safe.

One aspect that the draft points out on multiple occasions is that
so far (thankfully) we do not have implementations that share REGISTER-
created dialog usages.  It should then point out in a forceful manner
that protocol designers should not even contemplate on doing this, nor
should implementors assume that REGISTER establishes a dialog usage that
can be shared.  It attempts to softly caution implementors and protocol
designers at a couple of places -- one being the end of the first
paragraph in S4.3,and the other being the last paragraph of S1 -- but
the draft should take a position that no one has done it yet and it is
expected that no one will do so in the future either.

S5 states that the working group is not comfortable with recommending
that GRUUs be used as part of a solution, yet one of the two ways to
avoid multiple usages shown in the document utilizes a GRUU.  I think
that section needs to simply be re-organized such that it presents
two ways to avoid multiple usages: one - use Join and Replaces, and
two - use Join and Replaces with GRUU.

Provide a reference for the specification defining the Target-
Dialog header (rfc4538), and possibly rephrase the sentence
as follows:

   OLD:
   A new header, Target-Dialog: perhaps, would be included
   in the REFER listing the dialog this REFER is associated with.

   NEW:
   The Target-Dialog header [RFC4538] would be included in the
   REFER, listing the dialog that the REFER request is associated
   with.


I will also second Paul's idea of using some sort of a table for Section 4.

Nits:
* S2.1, paragraph 1: we need a better word than "springs" -- maybe
  "comes"?

* S2.1, Figure 1: I think you mean "Dialog 1 Usage 1 Proceeds" towards
  the end of the figure.

* S2.2: s/He decides skip/He decides to skip/

* S4: s/explores the problem spots/explores the problem areas/

* S4.1, discussion on 480: It says "Clarifications will be made to
  show..." by who?  you probably mean later versions of rfc3261?  If so,
  maybe reword it as "Later revisions of the SIP specification are
  expected to include clarifications that show..."

* S4.1, discussion on 503: towards the end, you are missing a closing
  parenthesis.

* S4.1, discussion on 604: s/is being 604ed/ is being responsed to by a
  604/

* S5: s/by two primary pressures/by three primary pressures

* S5, list item 1: replace the subjective personal pronoun "we" in the
  last sentence with more neutral phrasing.  Something like:
     Sending the REFER on an existing dialog at the very least
     ensured that it got to the same endpoint with which the
     existing dialog had already been established.

* In Figure 3, flow F1, s/call-id-one/call-id one/
                                      (i.e., no '-')