[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