Subject: [Sip] Notes of second review call on resolution of location-conveyance comments

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 16 May 2007 18:26:33 +0200

(As WG chair)

The following represents the notes of the second conference call we held
to review comments.

Regards

Keith

Notes of review team call on WGLC comments on draft-ietf-sip-location-
conveyance-07 held on 1st May 2007

1)	Roll call

The following participated in the call.
Richard Barnes
Keith Drage (moderator and scribe)
James Polk (document editor)
Brian Rosen (document editor)
Henning Schulzrinne
Hannes Tschofenig

2)	Agenda bash

Proposed to go through the action items, followed by the remaining
agenda items 
from the previous meeting, following by any other issues from the
comments that 
the editor's considered needed input from the review team.

3)	Action points from previous review team discussion

Action 1/1: Keith to take above list to WG for consensus call, as
direction to 
the editors.

Done. Action complete on Thursday 3rd May.

List was:
-	location conveyance should support the delivery of multiple
locations;
-	the document will make no recommendations as to how the
recipient chooses 
which location to use. This is regarded as specific to the using
application, 
and therefore beyond the scope of the protocol extension;
-	the recipient should attempt to make use of all the locations
given, and 
should only respond with a 424 response if it is unable to use any of
those 
locations. This includes resolving all and any locations by reference;
-	as a result of the above, any 424 response is a collective
statement about 
all the locations given in the request rather than any specific location
in the 
request.

One of the comments made on the list was that draft-ietf-pdif-lo may
provide 
useful information to support this. It was therefore discussed whether
draft-
ietf-sip-location-conveyance should contain a normative reference to
this 
document. It was agreed that this document contained provides that were 
application specific rather than protocol specific, and therefore there
should 
not be a normative reference. 

Brian questioned whether there should be more than one reference in the
same 
provided-by. Proposal was that SHOULD NOT add multiple locations. Brian
agreed 
to draft text to send to people on his proposal.

Action 2/1: Brian to draft text on whether multiple locations should be
added by 
the same provided-by.

Action 1/2: Hannes to send text to editor's and review team covering
this issue

This issue being, it is known limitation that when a proxy inserts a
location by 
reference, that the UA user is not a rule maker (RFC 3693 specifies the 
rulemaker). There is some suitable text in the RELO document that covers
the 
same issue.

This issue was still to complete.

Action 1/3: Brian to provide text relating to the usage of TLS.

This issue was still to complete.

Action 1/4: Hannes to send text (can be just key points to be covered)
to 
editor's and review team covering this issue.

This issue concerned the adequacy of the security conditions.

This issue is still to complete.

Action 1/5: Keith to post to list stating that the agreement is to
remove and 
asking for WG consensus.

This action was done to complete on Thursday 3rd May.

Action 1/6: Keith to send mail to Cullen Jenning / Jason Fischl
regarding the 
need of draft-ietf-sip-certs to provide any documentation on this issue.

This action had been done. No reaction so far.

Action 1/7: Keith to send mail to list asking for WG consensus to
agreement to 
remove emergency call text from location-conveyance.

This action would complete on Thursday 5th. It was agreed that the
conclusion on 
this action would specifically address Ted's concerns and Keith would
ensure 
that he does agree with this conclusion.

Action 2/2: Keith to summarise emergency call decision to list, and also

correspond directly with Ted to ensure he is part of WG consensus.

With regard to the paragraph in section 1 it was agreed to keep the
paragraph, 
but to remove the word "frequently" and strike the last sentence.
Section 4.3 
had already gone as a result of other decisions. Section 6 would go in
total as 
a result of this action.

Action 1/8: Brian to post proposed procedures to list for covering the
above, 
and obtain WG consensus to this proposal.

This being:

-	location-conveyance in responses to give location of the UAS
would be 
specifically removed from the document. This should be done by a
subsequent 
request in the opposite direction.

-	that location in responses would relate to location of UAC for
test, but 
this would be a new procedure. This would need to be considered by the
WG in a 
list discussion.

This action was still to do. Needs to be decided (on list) if the echo
is all 
locations or just the one used.

Action 1/9: Henning to draft strawman proposal and initiate discussion
among 
review team in order to get the concepts correct, prior to SIP WG
discussion.

This action specifically related to the new procedures for error
handling.

Henning had drafted a proposal to the list on this. Keith would initiate
a 7 day 
call on this.

Action 2/3: Keith to initiate a 7 day call on Henning's error handling
proposal.

4)	Continuation of agenda from previous discussion

Previous agenda 11)	PIDF-LO usage

	Comments: 121, 153A
	Key questions:
	Point usage deprecated?
	Proxy usage - what can proxy say about this location - is this
in scope of 
this document or does GEOPRIV need to handle it?

This had been partly discussed in the previous call.

James proposed to keep Geo example and to keep the old 4.3 example
(location by 
reference). He would move the old civic example into a new appendix. 

In the geo example, point would be updated to position, and therefore
aligns 
with GML 3.1 This should incorporate all Martin's comments in this area.

Comment 153A had been partly covered by the action items. Proxy addition
has to 
be determined on context. Additional work may have to be done in future
outside 
the scope of this WG item. It was suggested that future work would allow
the UAC 
to request the proxy to insert a location on it's behalf, but this work
would 
only be done if people think it is desirable. therefore agreed to make
no 
recommendations on proxy usage.

previous agenda 12)	URI issues

Comments: 7, 64
Key questions:

In regard to comment 7, the review team had no answer to the question
but 
decided it did not impact the contents of
draft-ietf-sip-location-conveyance.

previous agenda 13)	Routeing query allowed issues

Comments: 11
Key questions:

Brian agreed to seek resolution of this comment on the GEOPRIV list, as
this is 
essentially an UPDATE to a GEOPRIV document. The complete list of WGLC
items for 
Brian to resolve as this action is 6, 11 and 26.

Action 2/4: Brian to address the issues relating to "Routeing query
allowed 
issues" GEOPRIV list and seek consensus there as to if and how this
should be 
documented.

previous agenda 14)	Retransmission allowed issues

Comments: 61A
Key questions:
	Is mechanism needed?

In regard to the proxy adding location, it was agreed that this is 
underspecified. Route-query-allowed is the new parameter, but
retransmission 
allowed is the RFC 4119 parameter.

Agreed that this also needs to be resolved with the (old) agenda item
13) issues.

previous agenda 15)	Terminology usage

Comments: 1, 19, 43A, 101A, 116B, 129A
Key questions
-	Are "by value" and "by reference" the appropriate terms?
-	Is LbyR a using protocol?
-	Are there any circumstances where we need to talk about LIS
rather than LS?

In regard to the "by value" and "by reference" concern, noted that by
value is 
XML and by reference is URL. In location-conveyance, the Geolocation
header 
field is always a URL. Various discussions around use of "internal" and 
"external", "direct location" and "indirect location". Whether we should
do this 
by definitions, or by inventing new terms?

Action 2/5: Henning to make strawman terminology proposal to the review
team. 
Also need to check as part of this discussion whether all instances of
the 
existing terminology should be changed or just a specific subset.

There was no current agreement on this, so the document remains
unchanged in 
regard to this terminology issue unless specific proposals can be
agreed.

In regards to the "LIS" usage, it was agreed that all remaining usages
of this 
could either be deleted or renamed, so that we do not have to mention
the names 
of the servers. In the examples, "lis" would become "ls". 

previous agenda 16)	Pull mechanisms

	Comments: 25, 144A
	Key questions:
	Are the mentioned pull mechanism valid, given that we don't
cover them at 
all?

Location by reference is not push. It was however agreed that the
editor's would 
try and delete all references to "pull" and "push" as it appeared that
this was 
a concept that did not help the document, i.e. use words like "defined a

mechanism for conveying the location", rather than "push".

5)	Other issues

It was identified that we use the term "conveyance" without explaining
what we 
mean by it. Either define, or change to a new term. Pointed out that the
first 
sentence of document defines it.

6)	Conclusion

No immediate need seen for another review team call. We have action
items to 
work out, and list consensus calls to complete, and the authors then
need to 
provide a new draft and a summary of the comment handling.

WG chairs and editor's will decide what future action is required by the
review 
team.

_______________________________________________
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