Hi Ted,

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 would imagine that at least Section 6 "Special Considerations for Emergency Calls" would go away.
Additionally, the security consideration section might also be affected.


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.

I agree that a simple copy-and-paste operation from the SIP Location Conveyance document to the Phone BCP is not sufficient.

I do, however, believe that it is better not to speak about emergency services in this document since we already have the Phone BCP. With the same argument I would like to remove Section 5.3 "Emergency Shape Representations" from draft-ietf-geopriv-pdif-lo-profile-06.txt.

Ciao
Hannes

                        
                        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

Reply via email to