RE: [Sip] GRUU WGLC comments review

["Drage, Keith \(Keith\)" <drage at lucent.com>]

The notes of the call we had last week are as follows.

Regards

Keith

------------------------------------------

Notes of conference call held on 27th September 2006 to review GRUU WGLC
comments.

Participating:

Paul Kyzivat
Robert Sparks
Andrew Allen
Dale Worley
Jonathan Rosenberg (Editor)
Dean Willis (Moderator)
Eric Rescorla
Keith Drage (Scribe)

Review comment status as at this meeting:

https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.htm 

or

https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.doc

The following issues were addressed:

14) Bit about outbound proxies and what GRUU to use - comments that this
is confusing.
This was not a major issue, rather a need to phrase the requirements
better. The list would be asked to come up with better text.

15) applicability of record-routing languages in basic trapezoid case
(Cullen, tracker #112A)
There are two cases here, the triangular and the trapezoid. Is there a
way to turn off the record-routing in the trapezoid case. It was agreed
to pull text on this issue into a standalone appendix on network design,
which means that the normative text will remain very simple.

16) Alternative gruu construction algorithm from ekr (Tracker #124)
EKR has already sent text to Jonathan which will be adopted.

17)  SIP/SIPS text - should we say anything about SIPS? Consolidate SIPS
processing? (ekr and others, tracker #49)
Jonathan suggested punting text about SIPS and GRUU to a future document
that would fix SIPS generally, rather than including something in GRUU
that would have to change anyway. We need to consult with the Security
area to see if this is OK.

18)  tel URI handling (Andrew, tracker #91)
Identified that RFC 3261 specifies that the address of record has to be
a SIP URI. In normal use, the tel URI is an alias for the SIP URI that
is the address of record. It was regarded as reasonable to add a
sentence that states this, although it should be stated in terms that
can be applied to all URI types and e.g. sos URN, rather than being
specific to the tel URI.

19)  GRUU/AOR URI equivalence - an issue? (Dale tracker #41, Francois
tracker #76)
Dale attempted to clarify his comment, which was that the equivalence
matching rules in RFC 3261 do not apply in this case. For example when
the opaque parameter is stripped then we still need to match if it has
the same set of other parameters. It was agreed that we need a new URI
comparison rule that is not the RFC 3261 rule in this case.

20) Escaping allowed in GRUU contact header param? (Dale, tracker #116)
It was proposed that the GRUU parameter takes a quoted string and the
associated text says that it is a URI. Dale would send suggested text
and this issue was agreed to be resolved.

21)  Do we need client generated instance ID (Aki, tracker #7)
This was identified as an issue where some mechanisms already exist in
ETAGS that attempt to do some of what is performed in GRUU. However the
review team considered that the problems are sufficiently different to
merit different solutions., e.g. softstate or not. It was considered
that the proposal was insufficiently motivated to agree any change to
the current mechanism.

22) Related to whether GRUU is explicit: What do UACs do differently (if
anything) if a contact is a GRUU? (ekr, Dean tracker #6, others)
Discussed already in previous calls on other issues.

23) Do we need more clarification on the lifetime of GRUUs?This keep
coming up in non-registration-bound GRUU usages, like gateways. Can you
delete a GRUU? (Robert, tracker #75)
Dealt with on anonymity issue. There is one additional sublety in that
we need to emphasise that a request for a new (regular) GRUU will quite
likely give the same one as already in use.

24) Is the GRID functionality of UA-generated URI context something that
is more generally useful than just with GRUU? (ekr)
Dealt with on anonymity issue.

25) Is the GRID functionality of letting a contacted UA know that it was
reached via a GRUU both needful and best done with GRID, or would
another mechanism be more appropriate? (ekr)
Dealt with on anonymity issue.

Additionally the following two items were discussed:

A) As agreed on the call last week, the gruu URI parameter will be
renamed "gr". Jonathan had put a mail to the SIP WG list the previous
night indicating this.

B) Anonymity. It was identified that neither Cullen or Jeroen were on
the call, and these were key stakeholders in this discussion. It was
agreed that within the bounds of the current document, there was no need
for a level of privacy that was greater than that already provided by
RFC 3261. This does not preclude other documents in the future providing
a mechanism for a greater level of privacy.
The proposal is that on registration, two GRUUs will come back, the
regular GRUU and the pseudononymous GRUU. In general UEs will need both,
depending on the application they are trying to support. 
A related question, which impacts SIPPING, was as to whether both GRUUs
need to be revealed in the reg event package. It was agreed that
conveyance of both would need to be supported, but that we would need to
look at the text for authorization policy on the pseudononymous GRUU. 
It was agreed that informative text was needed to indicate that the UE
provides any recovery if the regular GRUU is mistakenly revealed, i.e.
by blocking calls made to that GRUU.
EKR agreed to produce text to make sure that the GRUU is secure and
disctinct when it is minted at different times.
The above was all agreed amongst the participants on the call. It was
understood that there may well be people on the list who do not agree
with the above and consensus will be determined on the list. 

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage at lucent.com] 
> Sent: 22 September 2006 10:41
> To: sip at ietf.org
> Subject: [Sip] GRUU WGLC comments review
> 
> We will be continuing the conference calls on resolving the 
> WGLC comments on GRUU.
> 
> Regards
> 
> Keith
> 
> 
> > The continuation call will be on:
> > 
> > Wednesday September 27th
> > ------------------------
> > 
> > 7:00 am - 9:00 am Pacific
> > 8:00 am - 10:00 am Mountain
> > 9:00 am - 11:00 am Central
> > 10:00 am - 12:00 midday Eastern
> > 3:00 pm - 5:00 pm UK
> > 
> > Bridge details
> > 
> > Access Phone Number:  8007718734
> > International Access Phone Number:  +1 6477233953 7-Digit 
> Access Code:
> 
> > 5776249
> > 
> > The compiled comments are at:
> > 
> > http://www.softarmor.com/sipwg/reviews/gruu/index.html
> > 
> > Other documents will also appear in this area, referenced 
> by this same
> 
> > index page.
> 
> Keith Drage
> Lucent Technologies
> drage at lucent.com
> tel: +44 1793 776249
> 
> _______________________________________________
> 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
> 

_______________________________________________
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