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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 21 Mar 2006 16:06:36 -0700

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 23 Mar 2006 06:19:38 -0700

Patti wrote:
> 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).

I don't believe this requirement applies to UACs. End-users, service providers, and enterprises abide the local regulations, not UACs or devices.

Jean-François

---

From: "McCalmont, Patti" <[email-masked]>
Date: Thu, 23 Mar 2006 08:55:40 -0600

If the UAC is the entity that is directly requesting emergency assistance, then it too should abide by local regulations. I do realize that in most cases there will be some other entity, e.g. service provider, that will interact but if the location isn't there, how can local regulations be abided to?

Patti

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 7:20 AM
To: McCalmont, Patti
Cc: [email-masked]
Subject: RE: [Sip] comments on location conveyance draft

Jean-François

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 23 Mar 2006 10:09:11 -0500

And if the "local" totalitarian regulation says that phones should have location tracking on all the time, should the phone whose home is in some non-totalitarian region obey that?

Think mobility.

Mike

> From: McCalmont, Patti [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 9:56 AM
> To: Jean-Francois Mule
> Cc: [email-masked]
> If the UAC is the entity that is directly requesting 
> emergency assistance, then it too should abide by local 
> regulations. I do realize that in most cases there will be 
> some other entity, e.g. service provider, that will interact 
> but if the location isn't there, how can local regulations be 
> abided to?
> 
> Patti
> 
> > for an emergency call if local jurisdiction (laws of that particular
> > country) requires it.
> > 
> > dictated by the local laws (where the emergency event occurs).
> 
> I don't believe this requirement applies to UACs. End-users, 
> service providers, and enterprises abide the local 
> regulations, not UACs or devices.
> 
> Jean-François
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "McCalmont, Patti" <[email-masked]>
Date: Thu, 23 Mar 2006 09:16:16 -0600

The issue is, if you are making an emergency call and in a country that requires your location so that it can dispatch responders to help you, then it is necessary for location to be conveyed to the PSAP. If not by the UAC, then somewhere in the network prior to the call reaching the PSAP, so I don't have an issue if location is obtained by reference or the UACs service provider. If the UAC is the holder of the location and there is no other entity in the path that will provide it, then it puts the responsibility on the UAC.

Patti

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 9:09 AM
To: McCalmont, Patti; Jean-Francois Mule
Cc: [email-masked]
Subject: RE: [Sip] comments on location conveyance draft

Think mobility.

Mike

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 23 Mar 2006 09:07:38 -0700

Patti,

   I may understand the motivations, but again, I don't believe any formal requirements around the applicability of to-be-defined, local, or country-specific laws should be in the SIP location conveyance draft.

Jean-François

You wrote:
> The issue is, if you are making an emergency call and in a country
> that requires your location so that it can dispatch responders to help
> you, then it is necessary for location to be conveyed to the PSAP. If
> not by the UAC, then somewhere in the network prior to the call
> reaching the PSAP, so I don't have an issue if location is obtained by
> reference or the UACs service provider. If the UAC is the holder of
> the location and there is no other entity in the path that will
> provide it, then it puts the responsibility on the UAC.
> 
> Patti

---

From: "McCalmont, Patti" <[email-masked]>
Date: Tue, 28 Mar 2006 09:04:31 -0600

James,

I'm not opposed to moving this into the BCP but would like to see the
following sentence re-written (last sentence before Section 7):

"This capability MUST be configurable, but is not RECOMMENDED as the
default configuration of any UA. Local policies will dictate this
ability."

Reword the "Local policies will dictate this ability."

To

"Local policies MUST be followed."

Patti

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 7:16 PM
To: Dale R. Worley; McCalmont, Patti
Cc: Sip; [email-masked]
Subject: RE: [Sip] comments on location conveyance draft

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.

At 12:35 PM 3/23/2006 -0500, Dale R. Worley wrote:
>On Wed, 2006-03-22 at 19:30 -0600, McCalmont, Patti wrote:
for
>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: Tue, 28 Mar 2006 13:14:31 -0600

>"Local policies MUST be followed."

I'm ok with this.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 30 Mar 2006 14:43:21 -0700

James wrote:
> Sent: Monday, March 27, 2006 6:16 PM
> Cc: Sip
> WG.  How about, in the interests of keeping most emergency related
> stuff in
> 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
Yes, not sure about fair but sounds like the place to put it.

> Or do you two still want this explicit in the Location doc?
No, again to me, this requirement does not belong in the sip location
doc.

> I also think we can add an informative reference in the location doc
> to the

The reverse is ok (pointer to sip loc in phone bcp) but adding more
(informative) references to early BCP drafts in the sip loc conveyance
draft is not a good idea imo.
The hope is that SIP location conveyance can move faster than the ecrit
phone bcp.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 30 Mar 2006 14:51:59 -0700

Patti,

> "Local policies MUST be followed."
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is this proper use of RFC2119 requirement verbs?
This change is not leading to a satisfactory requirement imo for at least 2 reasons:
1/ How can an implementor meet this requirement other than providing configuration settings to enable/disable the capability (hence the first requirement is enough)?
2/ the wording leads to asking the question "by whom?": who should follow local policies? Usually, seeking the subject of a passive sentence for a requirement is an indication that it is hard to enforce it, even more so in those context. To me, it is up to the end-users or service provider -> leave this up to other national regulatory bodies to enforce this as MUST...

In short, I like the previous version better.
Jean-François

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 30 Mar 2006 14:53:36 -0700

> >"Local policies MUST be followed."

I don't believe this is a good change as-is.

Jean-François

---

From: "McCalmont, Patti" <[email-masked]>
Date: Fri, 31 Mar 2006 12:21:47 -0600

In-line

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 3:52 PM
To: McCalmont, Patti; James M. Polk; Dale R. Worley
Cc: Sip
Subject: RE: [Sip] comments on location conveyance draft

Patti,

<PLM> Configuration settings would work but have the addition to prohibit disabling for emergency services. I see the dilemma as location can change in a mobile environment to a country that allows location to be withheld for emergency calls.

<PLM> I agree that it will be national regulatory bodies that do the enforcement but the device must be capable of abiding by those regulations.