Subject: RE: [Sip] comments on location conveyance draft

From: "McCalmont, Patti" <[email-masked]>
Date: Wed, 22 Mar 2006 19:30:55 -0600

James,

I would like to make an additional comment on the requirement that
pertains to disabling location.

<New> A UAC MUST be prevented from disabling conveyance of location for
an emergency call if local jurisdiction (laws of that particular
country) requires it.

Rational: UACs must abide by regulations for emergency calls as dictated
by the local laws (where the emergency event occurs).

Patti

>   UAC-10 A UAC MUST allow its user to be able to disable providing 
>          location within any SIP request message.  It is RECOMMENDED 
>          this not be the default configuration of any UA.  
category:  compliance requirement? should this be informative as this is
           based on "local laws"? or is this a hard requirement that
           UACs compliant to this SIP location conveyance RFC have to
           do?
proposal:  reword to integrate the motivation below.
>
>   Motivation:  local laws may give this right to all users within a 
>          jurisdiction, even when the request is initiating an 
>          emergency call.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Tuesday, March 21, 2006 5:07 PM
To: James M. Polk; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] comments on location conveyance draft

James and Brian,

Here is a follow-up on SIP location conveyance draft and one of the
open issues we discussed in the meeting. It relates to moving the
requirements to an annex and expand on one of Jonathan's comment.

To recap what I stated at the mike, section 3 of draft02 contains both
design requirements (ones you used to craft the location conveyance
solution), and, compliance or implementation requirements
(requirements applicable to SIP entities implementing the RFC-to-be).
The former set could be deleted, moved into an annex or put in a
Specific section outlining the requirements that lead to the 
solution. Some of the compliance requirements should remain in the
core document imo to guide implementers and help interop.

Here is a first cut at the dichotomy. If you find this is helpful and
folks agree with the approach, I'd be willing to continue or propose
new text.

Jean-Francois.
[email-masked]

--- re: draft-ietf-sip-location-conveyance-02.txt, in
>3.  Requirements for SIP Location Conveyance
>
>  The following subsections address the requirements placed on
>  the user agent client, the user agent server, as well as SIP 
>  proxies when conveying location.

>   UAC-1  The SIP INVITE Method [RFC3261] MUST support Location 
>          Conveyance.
category: design requirement; met by the proposed solution in I-D
proposal: move to annex or simply remove.

>
>   UAC-2  The SIP MESSAGE method [RFC3428] MUST support Location 
>          Conveyance.
category: design requirement; met by the proposed solution in I-D
proposal: move to annex or simply remove.

>
>   UAC-3  SIP Requests within a dialog SHOULD support Location 
>          Conveyance.
category: compliance requirement?; partially met by the proposed
          solution in the I-D since the location header is not allowed
          in ACK and CANCEL requests.
proposal: reword to capture the table in section 4.1, here is a basic
          example with poor wording:
          [To claim compliance with this document,] a UAC MUST be
          capable of supporting Location Conveyance in SIP Requests
          within a dialog as indicated in table xxx.

>   UAC-4  Other SIP Requests MAY support Location Conveyance.
category: design requirement. 
          Not met by the solution since ACK and CAN are marked "-".
          Indeed, per RFC 3261 section 19.1.1., entries marked "m" are
          mandatory, those marked "o" are optional, and those marked 
          "-" are not allowed.
proposal: move to annex or simply remove. If you agree with the reword
          above, you also fold this design requirement.

>   UAC-5  There MUST be one, mandatory to implement means of 
>          transmitting location confidentially.
category: design requirement. 
proposal: remove or reword (i don't understand the requirement here).
note:     starting a 2119 requirement by words like "there" or "it" is
          usually a sign that it should be reworded. 
>   Motivation:  interoperability 
>
>   UAC-6  It MUST be possible for a UAC to update location conveyed 
>          prior to dialog establishment.
>   Motivation: in case a UAC has moved prior to the establishment of a 
>          dialog between UAs, the UAC must be able to send new location
>          information.
category: compliance or design requirement?
proposal: reword to inject the clearer motivation text in the actual
          requirement. Not sure whether the requirement is on a UAC to
          be "able" to send new location or the UAS to be capable of
          receiving and processing location updates.

>   UAC-7  The privacy and security rules established within [RFC3693] 
>          that would categorize SIP as a 'using protocol' MUST be met.
>          See Section 7 for analysis.
category:  design requirement as written
proposal:  delete as it is addressed in section 7 (also does not only
           belong to UAC).
          
>   UAC-8  The PIDF-LO [RFC4119] is a mandatory to implement format for 
>          location conveyance within SIP, whether included by-value or 
>          by-reference.
category:  design requirement as written
proposal:  reword to capture the UAC requirement, for e.g., 
           a UAC MUST support/comply with/implement the PIDF-LO 
           location format defined in [RFC4119] as a PIDF-LO. 

>
>   Motivation:  interoperability 
note:      Especially for interoperability, it would be a plus to
           also indicate the level of requirement for PIDF-LO
           "by-value" or "by-value" (is one of them a MUST, are both
           SHOULD to comply with the SIP Location conveyance RFC)?
           If this is specified elsewhere, mention it and add a
           pointer.

>   UAC-9  A UAC MUST be capable of transmitting a SIP request without 
>          protecting the PIDF-LO message body.  It is RECOMMENDED this 
>          not be the default configuration of any UA.  This requirement
>          is orthogonal to the use of TLS or IPSec hop-by-hop between 
>          SIP elements.
category:  compliance requirement
proposal:  clarify requirement: how or when does a UAC decide to not
           "protect" the PIDF-LO msg body part? 
           from a pure requirement point of view, I think you want a
           MUST for UAC to be capable of protecting the msg body part,
           *and*, a MAY for the UAC to be able to transmit without it
           (in some circumstances).

>   Motivation:  If a SIP request is part of an emergency call, 
>          therefore includes the UAC's location, the UAC may understand
>          through local policy or configuration that a proxy server 
>          will need to learn the UAC's location to route the message 
>          correctly.  Using S/MIME on the PIDF-LO defeats this 
>          capability in proxies.
note: some of the motivation text should be injected in the requirement.
          I would recommend getting rid of the "motivation"
          sub-paragraphs in favor of improved requirement text.

>   UAC-10 A UAC MUST allow its user to be able to disable providing 
>          location within any SIP request message.  It is RECOMMENDED 
>          this not be the default configuration of any UA.  
category:  compliance requirement? should this be informative as this is
           based on "local laws"? or is this a hard requirement that
           UACs compliant to this SIP location conveyance RFC have to
           do?
proposal:  reword to integrate the motivation below.
>
>   Motivation:  local laws may give this right to all users within a 
>          jurisdiction, even when the request is initiating an 
>          emergency call.

if this walk through is helpful, I can volunteer to continue or just
propose new text.

_______________________________________________
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

_______________________________________________
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

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 23 Mar 2006 12:35:10 -0500

> an emergency call if local jurisdiction (laws of that particular

I think a requirement like this should be put into the draft.  Not
because I think that necessarily every UAC should follow this rule --
there are a host of complex issues here -- but because stating this as a
requirement will tend to cause UACs to be non-compliant only when
someone gave the issue serious consideration, instead of being non-
compliant because the implementer overlooked the issue.

(I would rephrase the requirement something like this:  "A UAC MUST
convey its location for an emergency call if it is required by the local
jurisdiction.")

Dale

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Mar 2006 19:16:27 -0600

Dale and Patti

Brian Rosen and I are also writing the Emergency Phone BCP out of the ECRIT 
WG.  How about, in the interests of keeping most emergency related stuff in 
ECRIT docs, that we make sure the Location Conveyance doc doesn't prevent 
this disabling, and the Phone BCP makes this disabling strictly enforced 
like you want?

This way your requirement is written where folks should know to look for 
emergency related features/functions, and we don't really cross WGs too much.

I'm trying to maintain the balance I was told to maintain by one of the new 
RAI Area Directors that was at the ECRIT interim meeting (you can guess 
who) who reeeeeally wanted the Location doc to stay away from emergency 
related issues as much as possible.  This is one I believe we can directly 
address in the Phone BCP doc to your liking.

Is this a fair compromise?

Or do you two still want this explicit in the Location doc?

I also think we can add an informative reference in the location doc to the 
phone BCP doc for a pointer of where other work around this can be found.

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 28 Mar 2006 21:22:51 -0500

> Dale and Patti

I don't have strong opinions on these subjects, and I'm sure that others
who are directly involved can assess the value of my opinions better
than I can...

Dale