Re: [Ecrit] New work in ECRIT

"Richard L. Barnes" <rbarnes@bbn.com> Fri, 13 August 2010 19:50 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DDA3A69B9 for <ecrit@core3.amsl.com>; Fri, 13 Aug 2010 12:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.748
X-Spam-Level:
X-Spam-Status: No, score=-101.748 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MBgca6gCs8j for <ecrit@core3.amsl.com>; Fri, 13 Aug 2010 12:50:42 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 553863A63D3 for <ecrit@ietf.org>; Fri, 13 Aug 2010 12:50:42 -0700 (PDT)
Received: from [128.89.253.41] (port=50052 helo=[172.27.16.50]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Ok0He-000AXl-Pf; Fri, 13 Aug 2010 15:51:19 -0400
Message-Id: <ECD74775-D3F7-440B-8F50-491853F08D06@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>
In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6702D4C617@DEMUEXC030.nsn-intra.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-2-626679398"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 13 Aug 2010 15:51:13 -0400
References: <C87D8FB6.2760A%mlinsner@cisco.com> <BLU137-W933692C5ED6EC042DF1F893AE0@phx.gbl> <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> <BLU0-SMTP41196C4E8945CEC5EA65DF93AE0@phx.gbl> <8C51C7A529FC9D49843ACF5AE2FFBF6702D4C617@DEMUEXC030.nsn-intra.net>
X-Mailer: Apple Mail (2.936)
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] New work in ECRIT
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 19:50:44 -0000

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