Subject: RE: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Jul 2006 15:29:42 +0100

(as chair)

Well I believe we got a grand total of TWO responses on this question.

That means we are going to have to institute a more formal review, probably on the lines of the review process Dean outlined in a previous mail.

We will be discussing the logistics for this process offline in Montreal, but we will be looking for critical reviewers to formally assess this from various sectors of the IETF community.

If you consider yourself or someone else a person who should be a critical reviewer let us (the WG chairs) know. Also if have knowledge of a sector that should be addressing the review (e.g. SIPIT, security, CableLabs...) then please let us know.

regards

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: 27 June 2006 15:03
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG?
> 
> 
> (As WG chair)
> 
> I'm afraid I am going to have to ask you to be much more 
> proactive on this question, as the IESG need something a 
> little more positive from the WG. So...
> 
> i)	If you have thoroughly reviewed this, and as a result 
> believe it is ready, and I know there are at least some of 
> you out there who have torn GRUU to pieces, throughly 
> digested it and put it back together again, then send Dean 
> and myself an email to that effect at [email-masked].
> 
> ii)	If you are intending to review this but want more time 
> before responding, then also please say.
> 
> Remember this document is still in the WGLC state. We trying 
> to get it into the next state of IESG review. That means WG 
> consensus that it is ready.
> 
> Please try to respond by my original deadline of 30th June 
> (although we may give a couple of extra days grace here).
> 
> regards
> 
> Keith
> 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: 23 June 2006 11:57
> > To: [email-masked]'
> > Cc: [email-masked]'
> > Subject: [Sip] draft-ietf-sip-gruu-09.txt ready for IESG?
> > 
> > 
> > (As WG chair)
> > 
> > The SIP WG chairs and the author all think this document is 
> > ready for sending to the IESG.
> > 
> > We have had WGLC announced 5th July 2004 to complete 17th 
> July 2004. 
> > We had a further last round of WG review requested 26th 
> > October 2005 to complete 6th November 2005.
> > We have had significant discussion on the lists since then of 
> > this draft, and discussion in SIP WG sessions, and all 
> > comments have been resolved.
> > 
> > If you believe this document IS NOT ready to send to IESG, 
> > can you please indicate this to the list and the WG chairs by 
> > 12:00 midday UK time (7:00 am US Eastern Time) on 30th June 
> > 2006, giving technical justification for your objection.
> > 
> > Please limit this thread to answering the question above. If 
> > you have other discussion relating to GRUU generally, then 
> > please use a different thread.
> > 
> > regards
> > 
> > Keith
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 22 June 2006 20:50
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-09.txt 
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > This draft is a work item of the Session Initiation Protocol 
> > Working Group of the IETF.
> > 
> > 	Title		: Obtaining and Using Globally Routable 
> > User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)
> > 	Author(s)	: J. Rosenberg
> > 	Filename	: draft-ietf-sip-gruu-09.txt
> > 	Pages		: 38
> > 	Date		: 2006-6-22
> > 	
> > Several applications of the Session Initiation Protocol 
> (SIP) require
> > a user agent (UA) to construct and distribute a URI that can be used
> > by anyone on the Internet to route a call to that specific UA
> > instance.  A URI that routes to a specific UA instance is called a
> > Globally Routable UA URI (GRUU).  This document describes an
> > extension to SIP for obtaining a GRUU from a server and for
> > communicating a GRUU to a peer within a dialog.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-09.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> > the body of the message.  
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-sip-gruu-09.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sip-gruu-09.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

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

---

From: [email-masked]
Date: Wed, 5 Jul 2006 21:55:55 -0400

I fear this is an issue that was disposed of before and I don't
realize it:

I think the I-D needs to make clearer that when sending a request with
a GRUU that the request must be sent via an outbound proxy for the
GRUU's domain.  This is needed to make the machinery work, but isn't
stated explicitly as a UA requirement, it's implied in a section of
the I-D that appears to be a proxy requirement.

There's also the question of how the UA discovers the correct outbound
proxy address.  Strictly speaking, without a standardized mechanism,
different vendors could have incompatible implementations.  I admit
that this isn't much worse than the UA configuration problem as it now
stands.  Perhaps a good dodge is to allow (absent other configuration)
the UA to use the proxy for GRUU's domain as an outgoing proxy for
requests using that GRUU as a Contact?

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2006 22:00:02 -0400

inline.

> the I-D that appears to be a proxy requirement.

Actually, GRUU works just fine if there is NO outbound proxy at all. 
Consider the case of a call between Alice and Bob. Alice sends the 
INVITE directly to Bob's proxy, which record-routes and forwards to Bob. 
Now, when Bob sends a mid-dialog request, the r-uri has the gruu and the 
Route points to the proxy in Bob's domain. The request goes to that 
proxy. From there, as there are no more route headers, the r-uri is 
looked up, which goes to the home proxy in Alice's domain. The gruu is 
translated by the home proxy to the registered contact and the request 
is routed there.

What doesn't work so well is if a user has multiple outbound proxies for 
multiple providers, and it ends up sending a request to provider X with 
a Contact whose GRUU is from provider Y. In this case we will end up 
with the nasty spiral that was in early versions of GRUU. It might still 
work, but there are issues. I consider this a pretty far fetched corner 
case. However, the assumptions here are worth mentioning.

I've added the following text in the section on using GRUU:

<t> In addition, if the UA is making use of an outbound proxy, the
GRUU that is placed into the Contact header field of a request MUST be
one that was obtained from the same domain as the outbound proxy. This
assumes that a user agent is aware of the domain associated with each
outbound proxy. This specification does not require the use of an
outbound proxy; it merely introduces a requirement in cases where one
is used.  </t>

> requests using that GRUU as a Contact?

Per above, you don't need an outbound proxy. There is still this issue 
of, if you use one, how did you discover it. Thats a recognized open 
issue right now with sip-outbound, and not one that I think we need to 
address in this specification.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com