[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] RE: Review: draft-ietf-ecrit-phonebcp-01.txt
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 tFrom ecrit-bounces at ietf.org Wed Sep 19 17:07:18 2007
Return-path: <ecrit-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1IY6kW-0002VD-8z; Wed, 19 Sep 2007 17:06:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kU-0002V1-P0
for ecrit at ietf.org; Wed, 19 Sep 2007 17:06:19 -0400
Received: from ebru.winwebhosting.com ([74.52.236.50])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6kP-0006aX-Fv
for ecrit at ietf.org; Wed, 19 Sep 2007 17:06:18 -0400
Received: from [209.173.53.233] (helo=BROSLT41xp)
by ebru.winwebhosting.com with esmtpa (Exim 4.68)
(envelope-from <br at brianrosen.net>)
id 1IY6kC-0003wm-8b; Wed, 19 Sep 2007 16:06:00 -0500
From: "Brian Rosen" <br at brianrosen.net>
To: <shida at ntt-at.com>, "'ECRIT b'" <ecrit at ietf.org>,
"'James M. Polk'" <jmpolk at cisco.com>
References: <4643F859.9010301 at ntt-at.com>
Date: Wed, 19 Sep 2007 17:06:10 -0400
Message-ID: <10fe01c7fb00$e91a5fa0$640fa8c0 at cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceTiT3NijQWX4y1TBi+Ov7viDiRBBnW5Vzg
In-Reply-To: <4643F859.9010301 at ntt-at.com>
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc:
Subject: [Ecrit] RE: Review: draft-ietf-ecrit-phonebcp-01.txt
X-BeenThere: ecrit at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit at ietf.org>
List-Help: <mailto:ecrit-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>,
<mailto:ecrit-request at ietf.org?subject=subscribe>
Errors-To: ecrit-bounces at ietf.org
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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit