Subject: [Sip] draft-ietf-sip-gruu-00

From: "Orit Levin" <[email-masked]>
Date: Tue, 3 Feb 2004 14:58:25 -0800

I have the following remarks regarding the GRUU draft:

1. The draft states that one of the GRUU properties is  
"   o It MUST NOT be possible, based on inspection of the URI, to
determine the associated Contact URI or Address of Record."

It MUST be possible to achieve such a property for a GRUU (if the
Registrar wants to enforce such a policy for its domain), but it is not
part of the requirements for the GRUU concept to always enforce such a
policy.

2. It is expressed throughout the draft that 
"This extension allows a UA to obtain a GRUU, and to use a GRUU. These
two mechanisms are separate, in that a UA can obtain a GRUU in any way
it likes, and use the mechanisms in this specification to use them.
Similarly, a UA can obtain a GRUU but never use it."

For consistency, I suggest in section "6.2 Using the GRUU" change the
first sentence from

   "A UA first obtains a GRUU using the procedures of Section 6.1."
to 
   "A UA first obtains a GRUU using the procedures of Section 6.1 or by
other means".

Thanks,
Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, February 02, 2004 10:54 PM
To: Christian Jansson
Cc: Paul Kyzivat; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and
target refresh request

Christian Jansson wrote:

> Perhaps a little late, and hopefully not off topic. Comments inline.

Not too late, not off topic.

> 
> 
>>Jonathan R. wrote
>>This, however, leads me into thinking a bit on the lifecycle
>>management for GRUUs. Currently, GRUU is bound to a single 
>>registration, where the registration is defined by the Contact URI. If
> 
> 
>>the UA should "move", in the sense that it acquires a new IP address, 
>>this will be a new Contact URI, and therefore, a new GRUU. It would be
>>nice if, instead, the GRUU were truly bound to the UA instance, and 
>>that even if the UA instance changed IP addresses, the GRUU could 
>>remain unchanged. In such a case, if the UA moves, there is actually 
>>no need to issue any target refresh requests. The UA would simply 
>>re-register, update the binding of its GRUU to its new IP 
>>address, and 
>>existing calls would be correctly routed.
> 
> 
> But if the ip actually changes, it would be necessary to send an
updated
> SDP with the new ip in the c= line.

Yes, that is true. If media relays are used (i.e., TURN), it might be 
possible to avoid even this, but lets leave that aside for now.

> So your idea won't save you from
> having to send a SIP request to the other end every time the ip
changes
> in an INVITE session. 

Right. However, it does solve the problem that, previously, if both 
endpoints moved at the same time, the call would fail - neither side 
could signal the other.

> For a non-INVITE session though the idea would
> save a lot of request from being sent if the session only contains
> signaling.

Right, in particular, a long lived presence subscription, for example.

-Jonathan R.

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

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 03 Feb 2004 17:58:47 -0600

> part of the requirements for the GRUU concept to always enforce such a

I have to admit I concur with this position. There might be very useful 
situations where the anonymity aspect of the GRUU would be undesirable.

I can even envision models where the GRUU is cryptographically 
validatable as representing an instance associated with a specific AOR, 
including variations where the validation can or cannot be done without 
prior knowledge of the associated AOR.

As far as I can tell, reversibility does not impact the given rationale 
for the requirements, that:

    With these rules, it is possible, though not required, to construct a
    GRUU without requiring the maintenance of any additional state. To do
    that, the URI would be constructed in the following fashion:

So I believe I would support making this a SHOULD strength requirement. 
Conceivably some discussion of the security implications of NOT meeting 
this requirement would be appropriate.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Feb 2004 01:03:16 -0500

inline.

Dean Willis wrote:

>> 1. The draft states that one of the GRUU properties is  "   o It MUST 
>> NOT be possible, based on inspection of the URI, to

I am ok to lessen the requirement.

The question becomes, do we want a way to allow the client to signal 
that a randomized gruu is desired, or is it up to the server? I would 
much prefer to leave it up to the server, in which case the only thing 
that we need to change is the requirement, above. I changed the text to 
read:

<t>In many cases, it will be desirable to construct the GRUU in such a
way that it will not be possible, based on inspection of the URI, to
determine the associated Contact URI or Address of Record. Whether or
not a GRUU should be constructed with this property is a local policy
decision of the administrator.
</t>

>    "A UA first obtains a GRUU using the procedures of Section 6.1 or by

OK, with the addition of "outside the scope of this specification.".

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Wed, 04 Feb 2004 13:25:01 -0600

> decision of the administrator.

This works for me. You might even strike " of the administrator" from 
the  end.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Feb 2004 02:38:27 -0500

> This works for me. You might even strike " of the administrator" from 

Done.

-Jonathan R.