At 11:40 AM -0400 4/27/07, Richard Barnes wrote:
>Ted,
>
>I think the proposal was to remove Section 6 entirely, and any other bits of
>emergency-specific text elsewhere, from the location conveyance document to
>phonebcp/framework. In terms of the other bits, I only see two non-normative
>mentions after a brief scan:
>-- Last paragraph of Section 1
So, this text:
In this document, we frequently refer to the "emergency case". This
refers to a specific, important use of sip location conveyance where
the location of the caller is used to determine which Public Safety
Answering Point (PSAP) should receive an emergency call request for
help (e.g. a call to 1-1-2 or 9-1-1). This is an example of
location-based routing. The location conveyed is also used by the
PSAP to dispatch first responders to the caller's location. There
are special security considerations which make the emergency case
unique, compared to a normal location conveyance within SIP.
>-- Last sentence of Section 4.3
The last sentence of this:
A location recipient would need to dereference the sips-URI in the
Geolocation header to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location conveyance
and delivery in this way (i.e. location-by-reference), it is
RECOMMENDED that entities outside this domain be able to reach the
dereferencing LIS server, otherwise this model of implementation is
only viable within the atlanta.example.com domain. This will likely
not suit some services already being considered in the IETF at the
time of this writing, such as emergency calling.
And section 6, which I talked about in my first message.
Having reviewed this again, I don't believe that it is appropriate to
remove the text in Section 1, since the emergency use case was and
is an important driver for both location based routing and location
conveyance. Removing that context doesn't help the reader. An
additional pointer there to the ECRIT documents and a statement
that the full context is in them might be valuable as a way of pointing
out that the location-conveyance draft will not provide that.
I think much the same is true for the last sentence in 4.3; replacing
it with a statement like "For special considerations relevant to
dereferencing location in emergency call situations, see [CITATION]"
would be better.
I believe the issues in Section 6 could be covered in the ECRIT phonebcp
document, but I continue to believe that they will need to be re-written
to fit into that document.
I assume that any change to this text will require an update to the
Security Considerations, which currently have this:
UAC implementations MUST make such capabilities
conditional on explicit user permission, and SHOULD alert a user
that location is being conveyed. Emergency calls have their own
rules in this regard, as detailed in Section 6. Proxies inserting
location for location-based routing are unable to meet this
requirement, and such use is NOT RECOMMENDED. Proxies conveying
location using this extension MUST have the permission of the target
to do so.
regards,
Ted Hardie
>Hope this helps to clarify,
>--Richard
>
>
>Ted Hardie wrote:
>>At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:
>>>(As SIP WG chair)
>>>
>>>During the review of the WGLC comments, we have identified some issues
>>>where we need consensus calls on the list. These are in one call per
>>>message.
>>>
>>>There is an amount of text (primarily section 6) within
>>>draft-ietf-sip-location-conveyance related to emergency calls. It is
>>>proposed to remove this text on the basis that there are charter items
>>>within the IETF ECRIT working group that fully specify this application
>>>of location conveyance to this particular purpose. The editor's will
>>>make sure that all the removed text is reflected in appropriately in the
>>>concerned ECRIT documents.
>>
>>I don't think we can answer this question without the actual bits to
>>be removed. Can you cite in more detail?
>>
>>I'd also like to point out that section 6 has a number of elements
>>where the baseline assumption of SIP and ECRIT may differ. This,
>>for example:
>>
>> Thus S/MIME protection of location MUST NOT
>> be used. TLS protection of location SHOULD be used, however, if
>> establishment of the TLS connection fails, the call set-up
>> operation, including location conveyance, MUST be retried without
>> TLS.
>>
>>The context in SIP and the larger document here makes it clear
>>that "S/MIME protection of location" means encrypting the location,
>>rather than signing it. But location signing is a topic of interest to
>>ECRIT, and the resulting baseline assumptions may be different.
>>Increased clarity on exactly what is meant will hopefully result,
>>but remember this will end up in some document with a bunch of
>>other context to it.
>>
>>I also believe that this section:
>>
>> Both the "retransmission-allowed" and "routing-query-allowed" SHOULD
>> be set to "yes". Querying for routing may be performed by proxies
>> providing a routing service for emergency calls even if
>> retransmission-allowed or routing-query-allowed is set to "no" or is
>> not present. Proxies routing on the location MUST set the
>> "message-routed-on-this-uri" parameter.
>>
>>would have to be substantially re-written to fit into phonebcp (presuming
>>that is where it lands). To make sense there, I believe it would have to
>>repeat
>>context from location-conveyance (even with the existing normative
>>reference). That's always an invitation to things getting out of synch
>>in the future, and has to be considered.
>>
>>Put another way, I don't think you're going to be able to just shift
>>the text en masse and be done.
>>
>> regards,
>> Ted
>>
>>
>>>We will assume that this removal represents WG consensus unless we hear
>>>otherwise from the WG in 7 calendar days from the posting of this
>>>message.
>>>
>>>Regards
>>>
>>>Keith
>>>
>>>
>>>_______________________________________________
>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use [EMAIL PROTECTED] for questions on current sip
>>>Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
>>Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
