Subject: [Sip] YAGR (yet another GRUU Review) draft-ietf-sip-gruu-10

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Aug 2006 14:53:28 -0500

Jonathan/Chairs: I realize that the deadline was yesterday, but
I am submitting this review in the hope that it may still
be useful.

I had followed earlier versions (-00, -01) of the draft, but
then other work took over, until now.  -10 has changed much
since I last remember GRUUs; so as I read it now, I am doing
so with very little context (which may be good ... or bad).

Summary: RFC3261 mandates that the Contact URI be global and
persist beyond the lifetime of a dialog.  In practice, this
requirement has been hard to meet.  This document proposes
the notion of a GRUU to mitigate the rfc3261 requirement on
the Contact URI.  A GRUU persists beyond the lifetime of a
dialog, and in addition it is globally routable, even if the
UA itself has a private address.

Details:

Section 4 does a very good job of explaining the use cases
that motivate the need for a GRUU.

I had a bit of a rough time hunting the information in the
document as I had to skip ahed to the examples section when
reading sections 5, 7, and 8.  Not sure what can be done
to alleviate this non-linear reading, though.

A major question around the design of the grid parameter I
have is this: to indicate to the UAS that the request was
sent to a GRUU, the the proxy is required to put a (possibly
empty) "grid" parameter when it sends a request to a UAS
(cf. towards the end of Section 5 and top of page
20, Section 8.2.1).  The proxy is required to remove the
"gruu" parameter from this incoming GRUU R-URI before
sending it to the UAS, and putting a "grid" parameter.
Why not just maintain the "gruu" parameter?  Why overload
the meaning of "grid" in this manner?  It makes it more
complex, IMHO (unless there is a reason that I cannot forsee).

A couple of places in the text it is maintained that an
out-of-dialog request would be indicated by the absence of
Route headers.  This is not entirely true if there is a pre-
loaded Route set, is it?  Would the lack of a To-tag not be a
better indication of an out-of-dialog request?  Once a dialog
has been established, To header will have a tag, which
will be used in subsequent re-INVs and SUBS.

I had trouble following the proxy handling section 8.2.1.
The second paragraph lays out what a proxy should do if
the R-URI is a GRUU.  However, what if the R-URI is not
a GRUU?  The third paragraph simply assumes that the R-URI
is a GRUU ("Otherwise, handling of the GRUU...").  Did you
mean "handling of the R-URI instead?

I also tried to correlate this section with the example in
Section 12 and ran into problems.  I will try to list these --
please see if they make sense.  WRT Figure 5, an INVITE
arrives at the proxy in (3).  Since the UAC had no idea
that the UAS is reachable using GRUU, it would probably have
inserted a R-URI as follows:

   INVITE sip:[email-masked] SIP/2.0

Now, given this R-URI, I attempted to follow Section 8.2.1 since
the request is an out-of-dialog request.  The R-URI does not
contain a "gruu" parameter, so none of the text in the second
paragraph of Section 8.2.1 applies.  So I go to the next
paragraph.  Disregarding the fact that the text uses the word
GRUU for the URI (sip:[email-masked]) which is most
definately not a GRUU, the proxy does a location server lookup
on the URI.

What is the expected behavior now?  I can see two outcomes:

   1) The proxy rejects the request with a 480; or
   2) What really happens during the REGISTER processing is
   that the AoR gets bound to *three* contacts:

   sip:[email-masked] ----is bound to--->
      1/ sip:[email-masked]
      2/ sip:[email-masked];gruu;
          opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
          +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
      3/ sips:[email-masked];gruu;
          opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
          +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

   So, now if the proxy gets a R-URI of "sip:[email-masked]",
   it will be mapped to "sip:[email-masked]" and if the
   proxy gets a GRUU R-URI of
   sip:[email-masked];gruu;
     opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
   then this will be mapped to:
   sip:[email-masked];grid

I suspect that (2) is the right outcome.  Yes?  Reading between
the lines in Section 7.1.2.1 appears to point in that direction
as well; especially the fourth paragraph: "...If, after that
processing, that contact is bound to the AOR, it also becomes
bound to the GRU associated with that instance ID/AOR pair."

Is this correct?  If so, I would strongly urge that this be
highlighted when you talk about the 200 OK response to the
REGISTER in the Examples section.  Maybe this is obvious
to the people who have been involved in GRUU for a long
time, but it certainly was not to me.

Also in Section 12, I think it will be very helpful to fill
in the missing details of the following messages: (4), (7),
and (8).  Clearly, the proxy R-Rs, following text of Section
8.2.2, and that is why the ACK goes to it.  But since the
example does not fill in the missing pieces, it is very hard
to understand what is going on.

Section 8.1.3 says that "If the user agent had previously handed
out its GRUU with a "grid" parameter, the incoming Request-URI
may contain that parameter."
^^^^ I thought that somewhere it said that the "grid" parameter
MUST be reflected in the GRUU by the UAC.  If the UAC drops
the "grid" parameter, why bother with it at all?

In Section 12, you demonstrate the UAC crashing and rebooting.
Upon reboot, it gets the same GRUU.  Upon getting the 200 OK,
the newly rebooted UAC knows that it has a pending, and now
stale, registration.  Should it not send a REGISTER expiring
the GRUU corresponding to the contact sip:[email-masked]?

Nits:
* Section 1, fourth paragraph:
   s/to which the user is/to which the host identified by the IP
   address is

* Section 1, last paragraph:
   s/the GRUU properties/the GRUU properties (defined in Section 3)

* Section 3, towards the end, second to last paragraph:
   s/of the domain which mints/of the domain that mints

* Section 8.1.1 - you may want to consider moving the paragraph
   "When using a GRUU ... at the "grid" parameter" towards the
   end; i.e., make it the last paragraph.  The reason is that
   as it is situated right now, it breaks the flow of thinking
   between the paragraphs bounding it.  These talk about GRUUs
   requiring a visit through intermediaries, whereas the
   paragraph I point out talks mostly about the "grid" parameter.

* Section 8.2.1:
   s/This produces zero or one contacts/This produces zero or
   one contact

Thanks.

- 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)

_______________________________________________
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