[Ecrit] draft-stastny-ecrit-requirements-00 review
"James M. Polk" <jmpolk@cisco.com> Wed, 09 March 2005 05:36 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29917; Wed, 9 Mar 2005 00:36:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8tuB-0002eb-9C; Wed, 09 Mar 2005 00:38:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tqB-0006FS-Bo; Wed, 09 Mar 2005 00:34:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8tq9-0006FJ-3d for ecrit@megatron.ietf.org; Wed, 09 Mar 2005 00:34:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29721 for <ecrit@ietf.org>; Wed, 9 Mar 2005 00:34:33 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8tsg-0002bU-5W for ecrit@ietf.org; Wed, 09 Mar 2005 00:37:14 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 21:48:42 -0800
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j295YYuC010238 for <ecrit@ietf.org>; Tue, 8 Mar 2005 21:34:34 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA13212 for <ecrit@ietf.org>; Tue, 8 Mar 2005 21:34:27 -0800 (PST)
Message-Id: <4.3.2.7.2.20050308222121.025827e8@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Mar 2005 22:45:27 -0600
To: "'ecrit@ietf.org'" <ecrit@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Subject: [Ecrit] draft-stastny-ecrit-requirements-00 review
X-BeenThere: ecrit@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@ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Richard I have a few comments about certain requirements within your ID: M2. The possibility to make contact to the proper ECC has to be verified and indicated to the user and/or the User Agent. Any indication (tone, flashing light, display icon visible) will be gradually ignored by most humans soon after becoming available to them. Thus, this requirement doesn't really accomplish much. Technically, how does the UA (the phone) know which PSAP/ECC is the "right" PSAP/ECC? For example, I live outside of Fort Worth, Texas - when I power my phone back up when I land in a lovely place such as Minneapolis, how does my phone contact and then know it contacted the Minneapolis PSAP/ECC without a PSAP Certificate authority and my UA having access to verify the key sent back in the reply was the Minneapolis PSAP/ECC and not my home Fort Worth PSAP/ECC? This seems like a great impersonation attack opportunity waiting to happen, while providing a true false sense of security to the UA owner. M3. The communication may be established on user request or by external events. External events.... smoke signals? seriously, what do you mean by "external events"? M4. To achieve this, the device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. I think the user will have quite a say in whether they are indeed a "last resort". With residential services, it will be often that the user will type in their home address and have that be their PIDF-LO civic address used from any phone in that home. M5. The capability to locate the responsible ECC must be available in the public Infrastructure without the additional need for a service provider. this means the IP address of each and every PSAP/ECC in the world is public knowledge. Is this really desired? M6. For a transient time the device and the UA may use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. what's a transient time to you? What's an ESRP? you didn't explode the acronym in a terms and definitions section. Why would a UA care how its message got routed as long as it got routed to a PSAP/ECC? S1. Transmission of the current location of the contacting device to the ECC Why is this a SHOULD? Isn't this a MUST to do any routing? And if location from the INVITE is used to route the call, and Proxies are not don't delete message bodies, then why wouldn't it be logical to conclude that if the PSAP/ECC received the message, it also received the Location of the UA? S3. Identification of the contacting person or device If my AOR is jp3520@yahoo.com with no display name, then the PSAP/ECC isn't going to get any more than that. But I guess this is why it's a SHOULD... S4. Safeguards to protect the emergency infrastructure and ECC facilities against malicious attacks, especially to prevent DoS attacks. I don't believe this is in scope of the WG or the IETF, so this requirement should be removed S5. Provide all possible means of communication, not only speech, but also text (IM), Video, etc., (for disabled persons and better display of the situation) I don't believe this is in scope of the WG or the IETF, so this requirement should be removed S6. Capabilities to contact ECC by automatic means and for the transfer of additional information (alarm equipment, cars, buses, trucks with dangerous loads, ...) I don't believe this is in scope of the WG or the IETF, so this requirement should be removed cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
- [Ecrit] draft-stastny-ecrit-requirements-00 review James M. Polk
- Re: [Ecrit] draft-stastny-ecrit-requirements-00 r… Stastny Richard