> 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 > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
