Subject: Re: [Ecrit] Review of draft-ietf-ecrit-phonebcp-02.txt

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 5 Nov 2007 09:53:22 +0100

hi hannes,

>    ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to
>    civic) from the form of location the determination mechanism
>    supplied.
>
> You cannot put a "MUST NOT" requirement here since we need this translation
> in case we receive location information from DHCP and use it with
> SIP Location Conveyance. In some sense this contradicts requirement ED-39.
>

I do not see a need for conversion from civic to geo when receiving
DHCP location information and using SIP Location conveyance. If I get
DHCP civic location, I map it to the appropriate PIDF-LO fields for
civic location. If I get DHCP geo location, I put the coordinates to
the PIDF-LO. It is a different format, but no civic/geo conversion.

karl heinz

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 Nov 2007 17:31:45 -0500

Thanks for your review.  I've made the changes you asked for, except for the
following
> 
>    ED-10 Devices SHOULD NOT have one button emergency calling
>    initiation.
> 
> "
I think a BCP should have information like this.  It's a common mistake,
PSAPs don't want it repeated, and there is no other place to put it.

> A few selected technical issues:
> 
I think this was covered in some comments others made.  The text
specifically discusses converting geo to civic or civic to geo.  You don't
do that with DHCP to SIP Conveyance.

> 
>    AN-4 Access networks supporting copper, fiber or other hard wired IP
>    packet service SHOULD support location configuration.  If the network
>    does not support location configuration, it MUST require every device
>    that connects to the network to support end system measured location.
> 
> I am not sure what this sentence means but I thought we concluded that end
> hosts
> have to support a range of location configuration protocols and networks
> have to
> at least support one of them. This sentence sounds different to me.
This requirement states that the access network must decide how location
configuration is done.  It doesn't say which protocol (which is covered
elsewhere), it says that unless it requires every device to self measure,
then it has to take on the responsibility for LCP.  Rewording suggestions to
make it more clear would be welcome.  This is "you can't punt, you must do
something".

> 
> 
> 
>    ED-19/SP-13 Where proxies provide location on behalf of endpoints,
>    the proxy MUST provide a mechanism to supply emergency dial strings
>    to the device if the device recognizes them, or the proxy MUST track
>    the location of the device with sufficient accuracy and timeliness to
>    be able to recognize the local dial string at the time of an
>    emergency call.
> 
> The environments where proxies add location on behalf of the end points
> are
> exactly those where the proxy has a relationship to the access network.
> Hence, the proxy can also detect the visited emergency dial string.
> 
> We NEVER EVER agreed that the proxy supplies emergency dial strings to the
> device.
> I know that there was once a draft about this subject and I saw this issue
> showing up in various presentations but we don't need it.
> As such, I suggest to delete this sentence rather quickly.
There was a bunch of follow-up messages on this point.  
I changed the text to say "the service provider MUST ensure that either the
End device is provided with the local dial strings for its current location
where the end device recognizes dialstrings, or that the service provider
can detect the appropriate local dialstrings at the time of the call."

While IMS does have the visited network configure the end device, I don't
want to prohibit the service provider from having any other mechanism that
results in local dialstrings being recognized as emergency calls.

> 
> 
> 
>    ED-25 Software which uses LCPs SHOULD locate and use the actual
>    hardware network interface.
> 
> 
> Not so sure what this should tell us.
This is the "don't use the tunnel, use the direct network interface.  I
improved the wording somewhat.

> 
>    AN-15 Placement of NAT devices should consider the effect of the NAT
>    on the LCP.
> 
> 
> We have to consider this already for the design of the LCP.We don't need
> to repeat it here.
I can delete this.  I don't think it hurts.  I don't think it is in conflict
with recent consensus language in, for example, HELD, and I think it's
helpful to remind everyone this is an issue.

> 
> 
>    ED-35 If a UA has more than one location available to it, it MUST
>    choose one location to use to route the call towards the PSAP.
> 
> Shouldn't we just point to the PIDF-LO profile document?
I don't think PIDF-LO profile is explicit about this.  In some sense, this
is not a real requirement, because LoST requires only one.  On the other
hand, it comes up a lot.  It's a simple statement of fact, and I'd like to
keep it.

> 
>    SP-20 Proxies handling emergency calls MUST insert a default location
>    if the call does not contain a location.
> 
> 
> Proxies should only add a default location if the they are unable to
> determine the location of the end point.
> I would add this qualification.
Done

> 
>    AN-23/SP-21 Default locations MUST be marked with method=Default and
>    an appropriate provided-by in the PIDF-LO.
> 
> 
> So far, there is no method field indicating "default" in
> http://www.iana.org/assignments/method-tokens
> We would have to add it.
Yes, we need to.  I will prepare an I-D on this.

> 
>    ED-40/AN-24 To prevent against spoofing of the DHCP server, elements
>    implementing DHCP for location configuration SHOULD use [RFC3118].
> 
> Delete this since the DHCP document already says it. Additionally,
> you should consider that RFC 3118 is largely a theoretical aspect,
> i.e., not deployable.
I deleted it.

> 
> 
> Delete the section about "uninitialized devices" per decision at the
> last IETF meeting.
I do not recall this discussion and it does not appear to be in the minutes
of the meeting with respect to -framework or -phonebcp.  Perhaps you could
refresh my memory. 

> 
> 
> 9.1.  Use of TLS
> 
> I think you might want to capture some of the discussions we had around
> * TLS session resumption
> * TLS session resumption without server side state
> * TLS Ciphersuite usage to ensure proper performance
Have you got time to suggest some text?  If I don't hear from you, I'll try
to do something myself.

> 
> There is some repetition between Section 9.2 and Section 8 when it comes
> to the service URN usage.
> Maybe there is room for simplification
As of this writing, I haven't made the improvements suggested in the meeting
to expand proxy insertion of location, which may change the text in this
area.  When I get to that (today or tomorrow), I'll see if I can improve
this.  At the moment, I don't see anything I really want to change.

> 
> Regarding ED-77:
> 
>    ED-77 In its response to the test, the PSAP MAY include a text body
>    (text/plain) indicating the identity of the PSAP, the requested
>    service, and the location reported with the call.
> 
> I recall in one of the document reviews that someone spotted a security
> vulnerability, namely that an adversary would use emergency call test
> mechanisms to determine the location of someone else.
> Do you think that this could be a problem?
There is of course, a balance of forces here.  If you can steal or fabricate
a location reference, and the LIS is not hiding location, then you can use
the PSAPs credentials to dereference for you.  Please remember the dictum
about treating the reference with the same care as you do the value.

Balance that against the need to see that the location being reported is
indeed where you are when location references are used.  I certainly can add
text alerting the reader to this vulnerability, but I think the balance
favors sending the result back.