Re: [Ecrit] New work in ECRIT
Bernard Aboba <bernard_aboba@hotmail.com> Tue, 03 August 2010 21:20 UTC
Return-Path: <bernard_aboba@hotmail.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 4F8E73A681A for <ecrit@core3.amsl.com>; Tue, 3 Aug 2010 14:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level:
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, HTML_MESSAGE=0.001]
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 nPQRwkiuDYzD for <ecrit@core3.amsl.com>; Tue, 3 Aug 2010 14:20:10 -0700 (PDT)
Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by core3.amsl.com (Postfix) with ESMTP id C50113A68B9 for <ecrit@ietf.org>; Tue, 3 Aug 2010 14:20:09 -0700 (PDT)
Received: from BLU0-SMTP41 ([65.55.116.72]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 14:20:38 -0700
X-Originating-IP: [166.205.142.113]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU0-SMTP41196C4E8945CEC5EA65DF93AE0@phx.gbl>
Received: from [10.10.138.167] ([166.205.142.113]) by BLU0-SMTP41.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 14:20:31 -0700
References: <C87D8FB6.2760A%mlinsner@cisco.com> <BLU137-W933692C5ED6EC042DF1F893AE0@phx.gbl> <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>
In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-43--231969971"
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7E18)
Mime-Version: 1.0 (iPhone Mail 7E18)
Date: Tue, 03 Aug 2010 14:20:22 -0700
X-OriginalArrivalTime: 03 Aug 2010 21:20:38.0273 (UTC) FILETIME=[B8027F10:01CB3351]
Cc: "<ecrit@ietf.org>" <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: Tue, 03 Aug 2010 21:20:13 -0000
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] New work in ECRIT Marc Linsner
- Re: [Ecrit] New work in ECRIT Bernard Aboba
- Re: [Ecrit] New work in ECRIT Kroeselberg, Dirk (NSN - DE/Munich)
- Re: [Ecrit] New work in ECRIT Bernard Aboba
- Re: [Ecrit] New work in ECRIT James M. Polk
- Re: [Ecrit] New work in ECRIT Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] New work in ECRIT Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] New work in ECRIT Dawson, Martin
- Re: [Ecrit] New work in ECRIT Ray Bellis
- Re: [Ecrit] New work in ECRIT Dawson, Martin
- Re: [Ecrit] New work in ECRIT Kroeselberg, Dirk (NSN - DE/Munich)
- Re: [Ecrit] New work in ECRIT Richard L. Barnes
- Re: [Ecrit] New work in ECRIT Bernard Aboba