|
|
> 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx]
> On Behalf Of ext Dawson, Martin
> Sent: Tuesday, March 23, 2010 11:44 PM
> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
> Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> 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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx]
> On Behalf Of Brian Rosen
> Sent: Wednesday, 24 March 2010 8:29 AM
> To: Thomson, Martin; Richard Barnes; Bernard Aboba
> Cc: emu@xxxxxxxx; ecrit@xxxxxxxx
> 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"
> <Martin.Thomson@xxxxxxxxxx> 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
> Ecrit@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ecrit
|
|