Re: [Ecrit] New work in ECRIT

I was considering a scenario where a Femtocell provides access to an
existing carrier network inside the building, where signals might not
otherwise propagate.   So if a visitor had a cellular handset that could
make an emergency call, they could use that, regardless of whether they
could obtain access to an alternative network or not.  Presumably the
regulators have already decided what the requirements for emergency service
are for the cellular network (e.g. no SIM, SIM but ok if no credit, etc.),
and the handset meets those requirements.

The end result is that the building occupant satisfies the regulatory
requirement for "unauthenticated" emergency access without having to modify
their own network or VOIP deployment

From: Richard L. Barnes [mailto:rbarnes@bbn.com] 
Sent: Friday, August 13, 2010 12:51 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: ext Bernard Aboba; ecrit@ietf.org
Subject: Re: [Ecrit] New work in ECRIT

Yeah, I'm as confused as Dirk here.  The IP network behind the femtocell
would still have to have a way to provide unauthenticated emergency calling,
just like any other IP network.  (I don't think it's possible to punt this
to IMS emergency calling, since that only covers the case where the VoIP
service being used is offered by the femtocell/IP-access provider.)

On Aug 6, 2010, at 4:39 AM, Kroeselberg, Dirk (NSN - DE/Munich) wrote:

Are you saying the issue of how to get into a hotspot for emergency without
credentials will go away because there will be Femtocells around anyway? Not
sure this will be the general case soon.

However, there are also issues that apply to Femto access (not
subscribed/prepaid empty/CSG configurations etc). The idea is not to limit
considerations to one specific radio technology like WiFi.

Dirk

From: ext Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Tuesday, August 03, 2010 11:20 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: <mlinsner@cisco.com>; <ecrit@ietf.org>
Subject: Re: [Ecrit] New work in ECRIT

With femtocells, emergency calls (including non-service initialized ones)
can be made indoors, without the handset having to obtain access to a
corporate or hotspot network.  As a result, a company could forego the
challenge, expense and liability associated with engineering unauthenticated
emergency calling for non-employees. 

On Aug 3, 2010, at 12:12 PM, "Kroeselberg, Dirk (NSN - DE/Munich)"
<dirk.kroeselberg@nsn.com> wrote:

Bernard,

could you clarify your comment regarding the relation of femtocells to the
unauthenticated draft? It is correct that some femtocell configurations are
considered an issue for emergency access, but I am not sure which relation
to unauthenticated you are pointing at.

Thanks,

Dirk

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
ext Bernard Aboba
Sent: Tuesday, August 03, 2010 7:26 PM
To: mlinsner@cisco.com; ecrit@ietf.org
Subject: Re: [Ecrit] New work in ECRIT

My humble suggestion is that draft-rosen-ecrit-additional-data is both
straightforward and highly beneficial.  While IETF tradition would suggest
that items with such a high benefit/cost ratio should be delayed
indefinitely or abandoned in favor of items that are more intractable,  I'd
suggest a concession to common sense in this isolated instance.

Of course, in order to ensure that the WG does not debase itself in an orgy
of productivity, tradition requires that the WG take on a number of work
items which are "hard" only because the wrong questions are being asked.
I'd assert that both Unauthenticated Access and PSAP callback  fall in this
category.   

Unauthenticated Access is "hard" because it represents a solution without a
real problem.  There is no regulatory requirement for this today, nor is
there likely to be one in the near future because the "solution" would
itself be a problem and because technology such as femtocells will make the
"problem" disappear in due course.

PSAP Callback is "hard" largely because of the disconnect between the PSTN
way of thinking and the reality of VOIP, which will result in extended (and
largely fruitless) "discussions", until the passage of the leaves the
obvious solution in plain view, like a whale washed up on the beach.
Serializing other work items until this "hard" problem is "solved" will
essentially cause them to wait in the queue until our teeth are but a
memory. 

> Date: Tue, 3 Aug 2010 09:19:50 -0400
> From: mlinsner@cisco.com
> To: ecrit@ietf.org
> Subject: [Ecrit] New work in ECRIT
> 
> During the meeting last week the following drafts were discussed in the
> context of accepting them as WG items.
> 
> draft-rosen-ecrit-additional-data
> draft-schulzrinne-ecrit-psap-callback
> draft-schulzrinne-ecrit-unauthenticated-access
> draft-tschofenig-ecrit-trustworthy-location
> draft-rosen-ecrit-data-only-ea
> 
> The chairs and ADs have reviewed the level of interest in these, compared
> the work to the current charter and believe these fit within the scope of
> ECRIT.
> 
> We asked during the meeting if anyone objects to accepting any or all of
> these drafts as WG items. So, now, we're asking on the list.
> 
> If you object to any of these drafts becoming WG items, please explain if
> you think the work is something ECRIT should not do, or if you simply have
> problems with current version of the particular draft. No response is a
> show of support for all of this work.
> 
> Once the above question is answered, the chairs will devise a work plan to
> finish the accepted work.
> 
> Also discussed in the meeting was the priority order of getting these
drafts
> completed, and it was the general feeling that psap-callback,
> unauthenticated-access, and trustworthy-location were the most difficult
and
> would take more time. Of those three the general feeling was the
> psap-callback was the highest priority. If you have an opinion on which
> draft should completed first, please send it to the list.
> 
> Please respond by COB on Wednesday, 8/11/2010 if you have objections to
any
> of this work, or you have strong feelings on the priority of the work.
> 
> Thanks,
> 
> -Marc, Richard, Roger-
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit