Subject: [Ecrit] draft-stastny-ecrit-requirements-00 review

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Mar 2005 22:45:27 -0600

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 [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 9 Mar 2005 07:11:21 +0100

>I have a few comments about certain requirements within your ID:
 
a  few? ;-)

>Thus, this requirement doesn't really accomplish much.
 
That people may ignore things is IMHO outside the scope of the WG
Nevertheless i think the indication is required

>while providing a true false sense of security to the UA owner.
 
Good question, but I am doing requirements here and not solutions

>External events.... smoke signals? seriously, what do you mean by "external
 
e.g. an exploding airbag
But Hannes already proposed to remove this as out of scope

 
No, especially with resitential devices the location must come from the 
infrastructure. Since humans are very unreliable, especially on the road
they are only a last resort

>knowledge. Is this really desired?
 
Where is the problem here?

>what's a transient time to you?

When the last PSAP is reachable directly via the Internet

>What's an ESRP? you didn't explode the acronym in a terms and definitions
 
Sorry for this , this is from Hennings drafts and I assumed it is common knowlegde
Emergency Service Routing Proxy

>Why would a UA care how its message got routed as long as it got routed to
 
It does not care whether it is routed dirrect to a PSAP or via an ESRP

>PSAP/ECC received the message, it also received the Location of the UA?
 
I am not talking here about routing. Routing is already done and you may route
the call to the correct proxy direct from the device to the PSAP without diclosing 
your location be evaluation the route at the device.
 
I am talking here if 
1 you have your location (the location required fro routing
may not be as exact as the one needed for dispathing - you may route to a national
emergency center per default.
 
2. you do not want to diclose your location

Some countries may allow you to do so, some won't.
 
3. You may nor have a location at all, but you still are able to make an
emergency call.

>going to get any more than that. But I guess this is why it's a SHOULD...
 
exactly

>I don't believe this is in scope of the WG or the IETF, so this requirement
 
Some, e.g. Hannes thinks otherwise
I personally was not sure
 
 I did this input basically to be able to decide on a high level what is 
within the scope, and what is must and should.
 
Before the WG goes into detail, this should be made transparent.
and rough consensus reached
So bring this up tomorrow

>I don't believe this is in scope of the WG or the IETF, so this requirement
 
Same as above

>I don't believe this is in scope of the WG or the IETF, so this requirement
 
Automatic emergency calls is a big project in Europe within the EC.
 
But again, see above

Richard