Subject: [Ecrit] RE: Review: draft-ietf-ecrit-phonebcp-01.txt

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:10 -0400

Shida

Thank you for your review.  I will be releasing a new version of -framework
and -phonebcp today.  I have resolved all of your comments except as noted
below:

>  T2: Section 4.3.
>  - I don't really see how location determined by network can
>    be explicitly overridden by the location user enters. Even
>    if device manages to override location information it obtained
>    through DHCP, L7-LCP or LLDP-MED, same provider that provided
>    the location can still insert the location by reference.
It is a truism with the PSAP people that whatever the caller SAYS is his
location is believed over what the system tells them.  If the system says
the caller is at 100 Main Street, but the caller insists he is at 250 North
Avenue, the responders will be sent to North Avenue and not Main Street.
They may question the caller more carefully, but they assume that the caller
knows more about the actual situation than the network does.

For a carrier, the liability of being wrong ("you say you are on North, I
think you are on Main") is too high to accept.  The text now says you can 
send where the network thinks the guy is, but you route on the user's
version of location.

The example I use for this case is a "Pringles Can" antenna on a WiFi AP.
You can put a remote LAN a mile or more away from the carrier's nominal
demarc point.  The user knows what he has done, the carrier does not.

> 
>  - Although not a normative text, "Location must be validated" seems a bit

>    too strong. I don't have a strong feeling for this but I prefer
something 
>    like a should rather than a must.. 
The PSAPs insist it is a MUST.  The text is now somewhat clearer about this
than in used to be, but the access network MUST validate before you put a
location in the LIS.  Validation on locations received from the LIS is
optional.

>    > Question is what if UA doesn't support LoST? I guess it can't really
>      forward the call to proxy to simply obtain PSAP URI could it? As it
>      would probably end up making the actual emergency call...
The text has been improved in this area, so I may have resolved this
completely.  Generally, the proxy looks for all possible cases: no dial
string recognition, dial string recognition but no LoST, LoST.  It fixes the
first two one way or another.  It routes the third per normal SIP
procedures.

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