[Sip] Comments on draft-ietf-sip-gruu-11

[EKR <ekr at networkresonance.com>]

$Id$

This draft seems like a big improvement over -10. That said, I still
have some comments.

GENERAL
The opposition of "public" GRUUs versus "temporary" GRUUs seems
a bit weird. Aren't these orthogonal? I suggest names which
actually are opposites. E.g., "public" vs. "private" or 
"opaque" vs. "non-opaque" (nothing like a non to make things
opposites).


S 3.1.1.
   call attempts.  If the UA had made a call towards a GRUU (perhaps as

s/towards/to/?

S 3.1.2.
I think an example of such a GRUU would be appropriate here.


S 4.1:
Can you show an example of an appropriate REGISTER request (cribbing
from the extended example later is fine).

S 4.2.

   instance, respectively.  A UA MUST be prepared for a Contact header
   field to contain just a "pub-gruu", just a "temp-gruu", neither, or
   both.  The temporary GRUU will be valid for the duration of the
   registration, while the public GRUU persists across registrations.
   The UA will receive a new temporary GRUU in each successful REGISTER
   response, while the public GRUU will typically be the same.  However,

Is there a reason to not have GRUU delivery by the server be all-or-nothing?
I.e., you get a public GRUU and a temporary GRUU or no GRUUS at all?


   remains registered.  If a UA stores any temporary GRUUs for use
   during its registration, it needs to be certain that the registration
   does not accidentally lapse due to clock skew between the UA and
   registrar.  Consequently, the UA MUST refresh its registration well
   in advance of expiration.

This doesn't seem like a MUST to me. There are environments where the
clocks are well synched and I don't know what "well in advance of"
means anyway.


S 4.4.

   registrar.  Of course, when a UA wishes to construct an anonymous
   request as described in RFC 3323 [16], it SHOULD use a temporary

s/Of course//


S 4.5.

      as sending a request to the GRUU, it does not.  The caller
      preferences expressed in the Accept-Contact header field are just
      preferences.  Its efficacy depends on a UA constructing an Accept-

s/Its/Their/


S 4.6.
   resulting URI will be seemingly random.  Future work may provide
   improved mechanisms that would allow an automata to know that a URI
   is anonymized and thus should not be rendered.

Why isn't the rule "if gr has no parameters, it's anonymous"
fine here. Also, the singular of automata is automaton.


S 5.1.
   If the contact URI is equivalent (based on URI equivalence in RFC
   3261) to the AOR, the registrar MUST reject the request with a 403,
   since this would cause a routing loop.  If the contact URI is a GRUU
   for the AOR in the To header field of the REGISTER request, the
   registrar MUST reject the request with a 403, for the same reason.
   If the contact is not a SIP URI, the REGISTER request MUST be
   rejected with a 403.

Is this normal REGISTER behavior non-specific to GRUU?


S 5.1/5.2.
I see how the "generate a new temp GRUU" in 5.1 and then "send the
most recent temp GRUU" in 5.2 work together, but I think it would
be less confusing (and less error prone) to have "generate a new
temp GRUU and send it" in one place.


S 5.3.

   If, as a consequence of the expiration of the contact, a particular
   GRUU no longer has any registered contacts bound to it, and the GRUU
   is a temporary GRUU, the GRUU MUST be destroyed.  This means that all
   of the accumulated temporary GRUUs get destroyed once the last
   contact for a given instance ID expires.  A consequence of this
   destruction is that requests addressed to the GRUU will be rejected
   by the domain with a 404 from this point forward.

It's not clear what destroyed means if you have a cryptographically
generated stateless GRUU. The "as if" rule seems appropriate here.


S 5.4.
You should explain how it is you get two contacts for one GRUU.


S 10.2.
It's worth noting that you can use cryptographic techniques that
block this kind of substitution attack.

S A.2.
I note that you could use a nonce instead of a timestamp here..


-Ekr









_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip