Subject: [Gen-art] Gen-art LC review of draft-ietf-sipcore-reinvite-06.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Oct 2010 16:57:35 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sipcore-reinvite-06
Reviewer: Elwyn Davies
Review Date: 2010-10-19
IETF LC End Date: 2010-10-20
IESG Telechat date: (if known)

Summary:
This document is probably ready for publication as a provisional standard.  Caveat:  This document purports to clarify some fairly convoluted logic that had confused implementors.  It appears reasonably well presented but is *still* extremely complex and I make no guarantees that it is either correct or will really do the business of clarification for given implememtors - I assume that is has been run past a sample of implementors to check that it does indeed provide clarification and  that more SIP-wise persons believe that it is consistent with the documents that it updates and correct so far as can be ascertained.  In particular the last (and very long) para of section 3.3 is *very* complicated.  I was also not totally happy that I could immediately convince myself that the statements in the last para of section 3.5 indicating that the statements of section 3.4 covered the situation were really true, but then I am far from beimg a SIP expert.

Nits:
-The expansion of UAS is needed in para 2 of Section 1  whereas it is currently in para 4.
- Figures 3 and 4 have the same title - they are about the same basic situation but with response/timing differences - a differentiation in the titles would help.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 20 Oct 2010 15:25:48 +0300

Hi Elwyn,

thanks for your review. Yes, as you point out, this draft deals with a
complex issue. It would be great if we could re-write the relevant parts
of RFC 3261 without considering backwards compatibility. Unfortunately,
that is not an option when dealing with a widely-implemented RFC such as
3261. So, we have tried and provided solutions that take into account
backwards compatibility while fixing the issues found in RFC 3261.

This draft is the result of discussing these issues with all the SIP
experts within the SIPCORE WG. SIP developers provided very-valuable
input on the current behavior of their implementations.

I will take care of the nits you identified below in the next revision
of the draft.

Thanks,

Gonzalo