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

["Stastny Richard" <[e-mail]>]

James wrote:

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

 >  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.
 
That people may ignore things is IMHO outside the scope of the WG
Nevertheless i think the indication is required

>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.
 
Good question, but I am doing requirements here and not solutions

 >   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"?
 
e.g. an exploding airbag
But Hannes already proposed to remove this as out of scope


>    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.
 
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

>    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?
 
Where is the problem here?

>    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?

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
>section.
 
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
>a PSAP/ECC?
 
It does not care whether it is routed dirrect to a PSAP or via an ESRP

>    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?
 
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.


>    S3.  Identification of the contacting person or device

>If my AOR is [e-mail] 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...
 
exactly

>    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
 
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
 


 >   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
 
Same as above

>    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
 
Automatic emergency calls is a big project in Europe within the EC.
 
But again, see above


Richard


>cheers,
>James

 >                               *******************
>                 Truth is not to be argued... it is to be presented

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


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