Subject: FW: [Sipping] -04 version of draft-ietf-sipping-v6-transition

From: "Mary Barnes" <[email-masked]>
Date: Fri, 15 Sep 2006 14:34:45 -0500

Folks,

This document has been in the repository since the 10th and the diff is
available on the tools page:
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-v6-transition/draft-
ietf-sipping-v6-transition-04-from-03.diff.html

I've reviewed the updated document and believe it is ready to go.  

If anyone has any concerns about progressing this document, please
respond by COB on 
19 September 2006.

Thanks,
Mary

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Friday, September 08, 2006 11:21 AM
To: SIPPING LIST
Subject: [Sipping] -04 version of draft-ietf-sipping-v6-transition

Folks: I have just submitted the -04 version of
draft-ietf-sipping-v6-transition.

Until it is available in the IETF archives, you can get a copy from:

http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/sipping-v6-transition/
draft-ietf-sipping-v6-transition-04.html
http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/sipping-v6-transition/
draft-ietf-sipping-v6-transition-04.txt

This version includes the review process comments from Keith Drage,
Mary Barnes, Dale Worley, and Francois Audet, as well as other
comments on the WG mailing list (thanks!)

All the comments during the WGLC review process have been addressed.
The changes resulting from the review were:

   1/ Incorporated nits and typos found by reviewers.
   2/ The interaction of RFC3263 and RFC3484 was ambiguous in the
      -03 version.  In the -04 version it is much more fleshed out,
      and occupies its own section (Section 5).
   3/ Common behavior of a UAC and a proxy has now been folded into
      one exposition (Section 5).

Could the WGLC reviewers kindly ensure that their comments have been
addressed adequately.  Please send any inadverdent omissions or
corrections to the list.

The draft is now ready to proceed further.

Thank you.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Sep 2006 16:05:44 -0500

I withdraw my WGLC comments on from a while ago regarding the usage of
double record-route. I have seen the light, and it now seems to me that
it is 
consistent with RFC 3608 and other drafts. 

I'm happy with the draft.

Nits:
-----

- Section 3.1.1, 4th paragraph: Replace  "...then it must insert..."
with
  "then it MUST insert".

- Section 3.1.1: It may be useful to explain why the double record-route
  is used instead of the "muck-around-with-response" approach described
in
  RFC 3261. This could be done by referencing the precedent of RFC 3608

  Here is an extract from draft-audet-sips-guidelines where I explain it
(in
  the context of sip/sips, but the same is applicable here and could be 
  adapted). That extract is inspired from RFC 3608:

   [RFC3261] sections 16.6 and 16.7 describe how this can
   be done by having the proxy modifying the Record-Route in the
   response.  However, as described in [RFC3608], this is problematic.
   This specification therefore adopts the procedure of [RFC3608], and
   instead of following the procedure in [RFC3261], proxies that are
   inserting Record-Route or Path header field URIs MUST record not
   one but two route URIs when processing the request.  The first value
   recorded indicates the receiving interface, and the second indicates
   the sending interface.  When processing the response, no modification
   of the recorded route is required.  This optimization provides for
   fully invertible routes that can be effectively used in construction
   of service routes. 

> From: Barnes, Mary (RICH2:B601) 
> Sent: Friday, September 15, 2006 12:35 PM
> To: [email-masked]
> Subject: FW: [Sipping] -04 version of draft-ietf-sipping-v6-transition
> 
> Folks,
> 
> This document has been in the repository since the 10th and 
> the diff is available on the tools page:
> If anyone has any concerns about progressing this document, 
> please respond by COB on
> 19 September 2006.
> 
> Thanks,
> Mary
> 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 24 Sep 2006 10:25:48 -0500

Francois: Thanks for eyeballing -04 and your comments below.  I
will incorporate them in auth48.

Francois Audet wrote:
> with "then it MUST insert".
> 
> in RFC 3261. 
[...]

Thanks,

- vijay