Subject: [Sip] Notes of review conference call for draft-ietf-sip-location-conveyance

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sat, 28 Apr 2007 22:00:14 +0200

The following are the notes of the conference call held on location
conveyance held last week. Comments are welcome, but please address any
comments on anything but accuracy to a separate thread (i.e. change the
subject of your email).

These will also be posted on the review site in due course.

Regards

Keith

Notes of review team call on WGLC comments on draft-ietf-sip-location-
conveyance-07 held on 25th April 2007

1)	Roll call

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

2)	Agenda bash

No changes.

Keith noted that the key questions mentioned in the agenda were only his
view of 
the comments made, in order to give some direction to the discussion,
and people 
should refer to the comment in the case of dispute over the meaning.

3)	Methodology

Keith outlined the methodology of the review calls, which was:

-	to give a first discussion of key points;
-	if new comments arise from discussion, they should be identified
verbally 
and ensure they are documented;
-	comments discussed can have resolution agreed in the call, or
defer, or 
take to list, or leave to authors to make a judgement.

d to handle it?

Main issues discussed here was on whether the examples should conform to
RFC 
4119 (as they currently do in showing point usage) or should reflect
later 
updates still formally with the working group. There was discussion, but
no 
agreement, on whether we could remove the PIDF-LO from the example
altogether 
(replace content by an ellipsis or some such device) as this part of the
example 
does not relate to any requirements in this SIP extension.

Remaining issues in this agenda item were not discussed due to lack of
time.

12)	URI issues

Comments: 7, 64
Key questions:

Issues in this agenda item were not discussed due to lack of time.

13)	Routeing query allowed issues

Comments: 11
Key questions:

Issues in this agenda item were not discussed due to lack of time.

14)	Retransmission allowed issues

Comments: 61A
Key questions:
	Is mechanism needed?

Issues in this agenda item were not discussed due to lack of time.

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?

Issues in this agenda item were not discussed due to lack of time.

16)	Pull mechanisms

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

Issues in this agenda item were not discussed due to lack of time.

As we did not complete, it was agreed to hold another review call on
Tuesday May 
1st at 10:00 - 12:00 Eastern. Keith indicated that the same bridge
details would 
apply.

James agreed to provide a preliminary update of the draft in time for
the 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

Further the review team should try and represent previous consensus of
the 
working group (SIP or GEOPRIV) as appropriate. Should regard themselves
as 
acting on behalf of the working group.

4)	 
Issues relating to multiple locations

Comments: 2, 3, (66), 78, 94, 96, 153, 164

Key questions: 
-	Do we want multiple locations?
-	If there are multiple locations, which should be used?
-	If a 424 is returned, which location does it relate to?
-	Which location does the warning refer to?
-	In what circumstances can multiple locations cause a call to
fail - or can 
one be used and ignore the rest?
-	If you have a location by value, do you need to also resolve any
location 
by reference?
-	Anything different for multiple locations in responses?

After discussion it was agreed that the following would be recommended.
This 
summary would be taken to the list by Keith for a WG consensus call:

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

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

It was also discussed if we should agreed that if a location is already
present 
in a request, one should not add another, as it is not possible to
resolve which 
location sender the 424 response relates to. As this may not be a
restriction 
based on later discussion of improvements to the error handling, we will
hold 
this decision until we have resolution of the error handling issues.

There was discussion of Warning header meanings in regard to multiple
locations 
in error. It was considered that there needs to be some form of
correlation 
between Warning headers and specific locations. See later in the
discussion for 
further details of resolution process.

The issues of multiple locations in responses was deferred to later in
the 
meeting under the "location in responses" agenda point.

5)	Security issues

Comments: 21, 27, 117A, 129C, 129D, 168, 181A, 181B, 137
Key questions:
-	Any issues with mandating multipart MIME?
-	Signing versus encryption issues?
-	Document security issues when retrieving location by reference?
-	Are mechanisms different for LbyrR and LbyV?
-	Is security considerations section adequate?
-	Are self signed certificates out of scope?
-	Is mandating a retry without TLS in scope?

The review team agreed that the extension would assume that conformant 
implementations supported multipart MIME. This was seen as an
implementation 
problem of existing specifications, rather than a problem with the 
specifications themselves. Discussion identified that the real problem
was with 
gateways which would send an error message to requests containing
multipart MIME.

As regards the signing versus encryption, agreed that clarification was
required 
in the document, but this was a matter of an editorial pass.

The security for dereferencing related to two issues:

-	security of the reference. Part of this centred around the issue
of 
whether the reference contained the identity of the user sending the
information. 
It was agreed that the reference is just a URL, and therefore does not 
consititute an identity.

-	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.
Hannes is 
going to send text to the review team

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

-	security of the dereferencing procedure. This was regarded as
being out of 
scope, as the dereferencing protocol was also out of scope.

It is also a known limitation that existing mechanisms do not allow a UA
to 
request proxy implementation. This is believed to be a separable
problem. 

Need to spell out that need same protection for location by value and
location 
by reference in the security considerations. Hanne's point - wants more
text 
saying TLS is used and "we really mean it". Brian will offer text here.

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

In regard to the adequacy of the security considerations Hannes had
agreed to 
suggest some text. It was noted that the philosophy of the document was
to put 
the RFC 2119 language regarding security in the main procedures, and
merely 
comment on the security provided in the security considerations section.

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

In regard to the self-signed certificates issue (comment 137) it was
agreed that 
the appropriate document to cover this issue in regard to location was
draft-
ietf-sip-certs. It was proposed therefore to remove all text in the
document 
relating to self-signed certifications.

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

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.

The issue relating to retry without TLS if the request fails with TLS on
an 
emergency call was dealt with as part of a general consideration of all 
emergency call issues in the next agenda item.

6)	Emergency issues

	Comments: 129B, 167A, 169
	Key questions:
	Should we cover emergency at all in this document?

It was agreed that section 6 and therefore all text relating to
emergency calls 
should be removed. It was agreed that it was the responsibility of ECRIT
to 
apply location-conveyance to emergency calling applications. 

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

Noted that James was not wonderfully happy with this, and may reraise
the 
discussion once he sees the impact of the decision on the text.

7)	Response usage

Comments: 29, 150
Key questions:
-	Is location allowed in responses, and if so, what are the
procedures for 
error handling?
-	What are the associated Require: and Supported: procedures?

It was identified that if location was allowed in responses, we would
have two 
possible semantics:

-	the conveyance of location information about the UAS;
-	the echoing of location information about the UAC for the
purpose of 
loopback testing.

It was agreed that we can only support one of these; that location
conveyance in 
the reverse direction can always be covered by an in-dialog request
initiated in 
the reverse direction, and that the loopback testing is a needed
procedure. It 
was therefore agreed that:

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

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

Removing location conveyance in responses probably simplifies the needed
text 
for Supported and Require headers. James will add text that allows the 
geolocation option-tag in a Supported header. A Require header in a
response 
should never include geolocation.

8)	Error handling issues

Comments: 30, 79, 84, 85, 110, 147
Key questions:
-	Dialog usage - does 424 clear the dialog or just the specific
usage?
-	Can Warning only appear in 424?
-	Do we need all the warnings given?
-	Do we need 701?
-	What mechanism should we use to indicate URL schemes?
-	Do we always return an error, or can we just ignore a problem?	

In regard to the dialog usage, it was agreed that 424 just ends the
usage in a 
response to an in-dialog request, and that the transation is retained.
Text will 
be inserted to reflect this.

In regard to the remainder of the issues, there was a discussion that
resulted 
in a view that the existing error mechanisms were insufficient. This
centred 
around the following points:

-	difficulties with correlation already identified earlier in the
call
-	may want to be able to indicate problems with a location when
the call can 
still proceed (e.g. emergency calls should still be addressed to a PSAP
even if 
the location cannot be used) and therefore no 424 is ever sent.

Henning did not like the whole Warning header idea any more as a result
of this 
discussion, and suggested a new Location-Error header that gives
detailed header 
values (to be used in 424 and 200).  This could be along the lines of
the 
History-Info header. Suggested an identity tag to tell the UAC which
error 
applies to which location in the request (when more than one location
was 
inserted in the request - perhaps by a proxy in which the UAC doesn't
know the 
proxy did).

Rather than design on the fly as part of the resolution discussion, this
agenda 
item was parked at this point. Henning agreed to elaborate by email, and
from 
that point we would decide whether the way forward to resolve this was
by a new 
i-d documenting the proposal, followed by WG consensus call, or by an
email 
proposal to the WG list. 

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.

9)	Method usage

Comments: 62, 69, 73, 74
Key questions:
-	INFO?
-	Mid call location updates use what mechanism?
-	REFER?
-	PUBLISH?
-	BYE?

For location update in the middle of an INVITE dialog, it was agreed
that UPDATE 
was the correct method to use, unless there was a reason to send to send
a 
reINVITE for some other purpose at the same time as this occurred. Text
in the 
document already says use UPDATE for this purpose. 

Given that the only function of putting Geolocation in INFO would be for
the 
same purpose, it was agreed that the Geolocation header would not be
specified 
for the INFO method.

For PUBLISH it was agreed that Geolocation would be allowed in this
method, but 
text would clearly state that any usage was not to duplicate mechanisms
where 
the PIDF-LO should appear in the event package carried by PUBLISH. No
use case 
identified at moment that fulfils this constraint, but this should not
preclude 
the availability of a generic protocol mechanism if such a use case does
appear 
in the future.

The same consideration about no use case, but not precluding the
availability of 
a generic protocol mechanism if such a use case does appear in the
future, 
applied to the other methods listed in the key questions. Therefore
Geolocation 
will be allowed in these methods. This also includes PRACK, but does not
include 
ACK and CANCEL, as these are not always end-to-end.

10)	Body issues

Comments: 159
Key questions:
-	What additional information is needed to describe bodies?

The issue here is what happens if the Content-Type of the body is
understood, 
but there is no recognisable Geolocation header (corrupt or removed by
some 
intermediate entity). Agreed that the Content-Type is sufficient
description of 
a location, and therefore the location could be used by a UAS when
conforming to 
this document (SHOULD strength). However the UAC procedure will remain
MUST send 
the Geolocation header.

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?

Main issues discussed here was on whether the examples should conform to
RFC 
4119 (as they currently do in showing point usage) or should reflect
later 
updates still formally with the working group. There was discussion, but
no 
agreement, on whether we could remove the PIDF-LO from the example
altogether 
(replace content by an ellipsis or some such device) as this part of the
example 
does not relate to any requirements in this SIP extension.

Remaining issues in this agenda item were not discussed due to lack of
time.

12)	URI issues

Comments: 7, 64
Key questions:

Issues in this agenda item were not discussed due to lack of time.

13)	Routeing query allowed issues

Comments: 11
Key questions:

Issues in this agenda item were not discussed due to lack of time.

14)	Retransmission allowed issues

Comments: 61A
Key questions:
	Is mechanism needed?

Issues in this agenda item were not discussed due to lack of time.

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?

Issues in this agenda item were not discussed due to lack of time.

16)	Pull mechanisms

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

Issues in this agenda item were not discussed due to lack of time.

As we did not complete, it was agreed to hold another review call on
Tuesday May 
1st at 10:00 - 12:00 Eastern. Keith indicated that the same bridge
details would 
apply.

James agreed to provide a preliminary update of the draft in time for
the 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