Subject: [Sip] Notes of GRUU conference calls 11th September and 19th September

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 22 Sep 2006 16:37:22 +0200

Attached find the notes of the two conference calls held so far on
resolution of GRUU comments.

Any corrections / clarifications welcome.

Please open any technical issues on GRUU itself as a new thread.

Regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

--------------------------------
Notes of conference call held on 11th September 2006 to review GRUU WGLC

comments.

Participating:

Paul Kyzivat
Alan Hawrylyshen
Robert Sparks
Andrew Allen
Dale Worley
Cullen Jennings
Jonathan Rosenberg (Editor)
Dean Willis (Moderator)
Eric Rescorla
David Hancock
Keith Drage (Scribe)

Review comment status as at this meeting:

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

or

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

Agenda discussion on what to discuss in what order. Settled on the
following list:

*	Its too complicated (Dean, Ekr)
	>	remove properties discussion?
	>	remove figure 3?
	>	remove some use cases?
	>	rewrite overview?
>	total flush, rewrite, and kill the editor
*	do we discuss UA treatment of a contact if it doesnt have gruu
flag (Paul)
*	do we need more clarification on lifetime of gruus - gruus not
assigned by 
registration
*	Lack of generality in grid/opaque design. Way for a more generic
demux? (ekr)
*	retargeting, forwarding services applied to gruu? Is this policy
or protocol 
requirements? 
*	All of Robert's issue mails:
	>	GRUU as a header and a URI param
	>	statefulness required?
	>	in vs. out of dialog retargeting
*	When to apply GRUU - is at always? Roberts comment.
*	Determining whether a request is mid-dialog or not, to apply
service treatment 
(and other things) - how to do that? (Robert)
*	Deans comments on whether gruu needs to be explicitly flagged or
not
*	Xavier's alternative proposal on To modification home/edge proxy
terminolgy - 
where to define, how to define
*	bit about outbound proxies and what GRUU to use - comments that
this is 
confusing
*	applicability of record-routing languages in basic trapezoid
case
*	anonymity of gruus
*	Altenative gruu construction algorithm from ekr
*	SIP/SIPS text - should we say anything about SIPS? COnsolidate
SIPS processing?
*	tel URI handling (Andrew)
*	GRUU/AOR URI equivalence - an issue? (Dale)
*	Escaping allowed in GRUU contact header param? (Dale)
*	do we need client generated insteance ID (Aki)

Its too complicated (Dean, Ekr) - Comment #008 and others:
Ekr regarded his comment as primarily editorial, however Dean says it is
technically 
too complex. Ekr indicated that it was difficult to tell normative from
informative. 
Agreed that we need to extract the explanatory information into a later
part. Restate 
normative part as differences from RFC 3261 and do not restate RFC 3261.
The 
primary idea of GRUU is simple but it is the secondary issues that make
it more 
complex - need to get primary idea across to the audience as quickly as
possible.
There was consensus on the need for reorganisation, with the emphasis on

reorganisation rather than rewriting. Specifically: Figure 3: new
simpler figure plus 
text. Use cases: REFER use case in introduction and move other use cases
to an 
additional material area. Rewrite and simplify overview: Ekr agreed to
provide the 
basis for this.

Anonymity: Cullen comment
Currently can always find the AoR. Lifetimes are infinite - why?
Justification is for 
debugging and callback. This branches into the lifetime discussion.
Possible enhancements to provide flag in register which indicates please
mint new 
GRUU - however the old one will remain valid. Dean says this is the
start of his 
technically too complicated argument - GRUU should be an ephemeral
anonymous 
identifier. 
Agreed to take the open issue to the list for discussion and resolution.
Jonathan to 
draft the issue statement to the list.

Agreed we need another call. Keith Drage to arrange.

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

Notes of conference call held on 11th September 2006 to review GRUU WGLC

comments.

Participating:

Paul Kyzivat
Alan Hawrylyshen
Robert Sparks
Andrew Allen
Dale Worley
Cullen Jennings
Jonathan Rosenberg (Editor)
Dean Willis (Moderator)
Eric Rescorla
David Hancock
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

1) anonymity of gruus (note we started this on previous call but reached
no conclusion 
-- I suspect list discussion has suggested that "yes, some change to the
doc is needed" 
is the answer. Tracker #124A and others)
Noted: Come back to this one later in the call

2) When to apply GRUU - is it always? (Robert, tracker #4). 
Noted that JDR had followed up on list.
Clarified that the issue is when to use GRUU in Contact rather than when
to create the 
GRUU.
Robert to send text, which will include 'Not the intent of this draft to
preclude end-to-
end signalling".
One should always provide a contact with GRUU properties, either using
registration-
minting or construction from configuration.

3) Lifetime of GRUU (Robert, tracker #11)
For anonymity to work, one can't require immortal GRUU. However
cancellability 
requires state and Robert has requirement not to support state. 
Also need to discuss 404 vs 480 responses, such that the use of 404
responses does 
not imply state.
Do we think that GRUU must be perpetual? No, we need to specify
mortality as an 
option.
Noted that we must NOT specify a mechanism that returns 480 to a GRUU
that has 
never been minted.

4) Explicit mechanism for cancelling a GRUU? Do we need one?
Does removing the contact binding satisfy the requirement? Apparently
not. It seems 
that the only solution is an automatic anonymizer service engaged by a
privacy header. 
The contact minted by the anonymity server may need to be flagged as a
GRUU.

5)  Lack of generality in grid/opaque design. Way for a more generic
demux? (ekr, 
many tracker items)
This led to a discussion of of request-URI processing and rewrites on
contact routing 
that would allow e2e parameter transparency. Need to ensure that the
Request URI is 
not rewritten, and will need to be a property per contact.
Proposed that we delete GRID from GRUU, move it to a separate spec that
fixes 
parameter passage in general. This will be a UA loose route technique
and will be 
done without additional flags. Robert volunteers to help on this draft.

6) retargeting, forwarding services applied to gruu? Is this policy or
protocol 
requirements?
Part of this is debate about whether GRUU is an alias for the Contact or
for the AoR.
Noted that the GRUU doc needs to include a statement about intent.

7) GRUU as a header and a URI param (Robert, tracker #5)
Jonathan proposed a solution on email (rename to gr) that all seem happy
with.

8) Statefulness required? (Robert, tracker #11 and others)
Already done, tied into cancellation and anonymity

9) in vs. out of dialog retargeting (Robert, tracker #12)
Robert finds asking a proxy to act differently in or out of dialog as
added complexity. 
However, if we require this, the current text (test for route header)
for "in or out" fails 
due to the possibility of preloaded routes. 
Do we really need to be able to detect this? It seems only
service-treatment depends 
on it. Noted that 3261 is vague on handling a request with route
headers.
Proposed that we can deal with this at the level of correctly describing
proxy behavior 
for request with route headers, and not mandate different behavior on
in/out of dialog.
The Route header processing may need further clarification generally.

10) Determining whether a request is mid-dialog or not, to apply service
treatment 
(and other things) - how to do that? (Robert)
Mooted, see above.

11) Whether gruu needs to be explicitly flagged (This is a GRUU!) or not
(Dean, 
tracker #6)
Reason is that there is such widespread violation of RFC 3261
requirements that 
Contact is globally routeable anyway that we need to do something.
Consensus: yes, it must be. No change to doc. If anywhere, this belongs
in transfer 
spec.

12) Xavier's alternative proposal on To modification (Tracker #1)
Doing this makes GRUU less compatible with RFC 3261.
Consensus on "no" from this review team.

13) Home/edge proxy terminology - where to define, how to define
Suggested that this might belong in Outbound. Author will make a change
to GRUU, 
referencing the outbound spec for the def. Cullen actioned to follow up
in outbound.

deferred remaining points to next call.

_______________________________________________
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