Hi,
Leaving access completely out of scope is of course the easiest course
but some synchronization must remain. In case of Skype, there is no way for
the access provider to tell whether the user is placing an emergency call or
chatting with their friends as the protocol used is opaque for the outsider.
This is true in any case the service provider uses a protocol not known or
understood by access provider and we must assume this can legally occur.
Thus, should anonymous access be required, a mechanism must exist to notify
the access provider about an attempted emergency call.
Yours,
Andres
On 3/24/10 3:14 AM, "Dawson, Martin" <[email protected]> wrote:
> Consider the access out of scope, certainly. Recommend to access-specific
> forums that they shouldn't *assume* the connecting device is actually the
> device making the emergency call (e.g. a WiFi device on a portable 3G router)
> so there's no reliable assumption the connecting device can provide an
> emergency flag.
>
> Then it's whatever ECRIT might recommend as appropriate on top of IP. I think
> Richard's questions are along the line of what the value of this specific
> "emergency flag" is at the IP level. It's not like anyone but the device user
> knows whether the access really is only required for emergency purposes. It's
> a valid question; access policy may just be to bar or allow (depending on
> whether it's a prohibitive or a permissive policy) access to emergency
> specific things - such as routes to PSAPs. A flag is not necessarily required
> to apply that sort of policy.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email protected]]
> Sent: Wednesday, 24 March 2010 10:14 AM
> To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard
> Aboba
> Cc: [email protected]; [email protected]
> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of
> serviceattacks on the emergency.com domain)
>
>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,
>> the DSL forum, etc. as to how a device is able to get an
>> unauthenticated IP context on their technology, for whatever
>> purpose, before the policies on permitting/prohibiting ECRIT
>
> but what is the concrete recommendation that you want to give here?
>
> - Drop the access/ISP part from the draft and say access/ISP is
> out-of-scope?
> - move this to EMU?
> - or deal with the EAP/NAI related aspects outside IETF as you seem to
> suggest (which is already partially the case today due to lack of
> guidance)?
>
>> is on others. I doubt that there's a reasonable assumption
>> that the connecting device can necessarily provide an
>> explicit "emergency intent" flag.
> maybe this is why some people do this via the NAI ;-)
>
> Dirk
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of ext Dawson, Martin
>> Sent: Tuesday, March 23, 2010 11:44 PM
>> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
>> Cc: [email protected]; [email protected]
>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial
>> of serviceattacks on the emergency.com domain)
>>
>> To elaborate on Brian's "counter point" - some jurisdictions
>> may prefer to *forbid* access to the emergency service from
>> unauthenticated/anonymous access as opposed to *require* it
>> to be supported. Noting this is the equivalent of saying
>> emergency calls for circuit service cannot be made from
>> public phone booths; this is still a possible policy within a
>> given jurisdiction.
>>
>> I'd also posit that not only is it not a priority for IETF
>> but that the question actually needs to be dealt with in more
>> specific forums first. The ECRIT emergency procedures occur
>> at or above the IP layer. Before anything that ECRIT
>> describes becomes relevant, there needs to be an IP context.
>>
>> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance,
>> the DSL forum, etc. as to how a device is able to get an
>> unauthenticated IP context on their technology, for whatever
>> purpose, before the policies on permitting/prohibiting ECRIT
>> procedures or anything else that can be done on IP can be
>> applied. This is easier on some access technologies than it
>> is on others. I doubt that there's a reasonable assumption
>> that the connecting device can necessarily provide an
>> explicit "emergency intent" flag.
>>
>> Cheers,
>> Martin
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of Brian Rosen
>> Sent: Wednesday, 24 March 2010 8:29 AM
>> To: Thomson, Martin; Richard Barnes; Bernard Aboba
>> Cc: [email protected]; [email protected]
>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial
>> of serviceattacks on the emergency.com domain)
>>
>> I think the relevant part of this is 'it's not a high
>> priority'. That is
>> policy of the work group, which we do have control over.
>>
>> If we have nothing else more important to do, then by all
>> means, let's waste
>> a ton of time on unauthenticated access. If we have other work to do,
>> perhaps we could defer this.
>>
>> I am not the chair, but in general, anyone can discuss
>> anything, regardless
>> of "priority" on the list. However, when it comes to
>> adopting work group
>> items, I think this should be way down our list.
>>
>> I might also suggest that unauthenticated access really isn't
>> within the
>> charter of the work group. It may be that the reason
>> unauthenticated access
>> may be needed is for emergency calling, but that means we may
>> (eventually)
>> need to ask some other work group to do work for a
>> requirement we generate.
>> It would seem that dealing with EAP is not within the domain
>> of this work
>> group.
>>
>> Brian
>>
>>
>> On 3/23/10 5:14 PM, "Thomson, Martin"
>> <[email protected]> wrote:
>>
>>>> A large percentage (in fact an overwhelming percentage) of
>> PSAPs DON'T
>>>> WANT
>>>> unauthenticated access. Their position is that they have lots of
>>>> relevant
>>>> experience, and its all bad (tens of thousands of calls
>> with no good
>>>> ones in
>>>> some cases).
>>>>
>>>> However, there are some PSAPs who want it, and there are some
>>>> regulatory
>>>> environments where there are some lawyers who think it's
>> required to
>>>> support
>>>> it in some environments.
>>>
>>> The good thing is: we don't set policy here. I'm not
>> seeing sufficient
>>> evidence that _everyone_ doesn't want this, only that some
>> don't want this.
>>>
>>> I can't comment on priority. That would be policy too.
>>>
>>> --Martin
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> _______________________________________________
>> Ecrit mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
> _______________________________________________
> Ecrit mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
