From mlinsner@cisco.com Tue Aug 3 06:19:25 2010 Return-Path: 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 A37033A67F5 for ; Tue, 3 Aug 2010 06:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DdrUhjSeoA-M for ; Tue, 3 Aug 2010 06:19:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B287F3A659B for ; Tue, 3 Aug 2010 06:19:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF60V0xAZnwM/2dsb2JhbACgCnGnOZtThTkEiQI X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="142705012" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2010 13:19:51 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o73DJoNu009415 for ; Tue, 3 Aug 2010 13:19:51 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 03 Aug 2010 09:19:50 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: New work in ECRIT Thread-Index: AcszDo0Z7jRm4FMv+UqNT4Z3gBTsiw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 13:19:25 -0000 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- From mlinsner@cisco.com Tue Aug 3 06:29:49 2010 Return-Path: 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 14B0B3A659B for ; Tue, 3 Aug 2010 06:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_HI=-8] 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 2CVYEjF9+GRr for ; Tue, 3 Aug 2010 06:29:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 500573A67EF for ; Tue, 3 Aug 2010 06:29:46 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALa2V0yrRN+J/2dsb2JhbACgCnGnSZtUhTkEiQI X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208";a="567819379" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2010 13:30:15 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o73DUEEo006553 for ; Tue, 3 Aug 2010 13:30:14 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 03 Aug 2010 09:30:11 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: draft-patel-ecrit-sos-parameter Thread-Index: AcszD/8+fhl82yyIPEeleRujELf3jw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 13:29:49 -0000 In case you didn't notice, a new version of sos-parameter was issued last week. This draft was originally an AD sponsored draft and as time progressed that changed. http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-09 The current plan is to send the draft to DISPATCH, but first we would like the ECRIT community to review it for applicability in the emergency calling space. Please review and send comments to the ECRIT list by COB on Wednesday, 8/11/2010. Thanks, -Marc, Richard, Roger- From bernard_aboba@hotmail.com Tue Aug 3 10:25:17 2010 Return-Path: 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 ACFB13A6950 for ; Tue, 3 Aug 2010 10:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, 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 rsfcsiRAnhyz for ; Tue, 3 Aug 2010 10:25:16 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id BD0433A657C for ; Tue, 3 Aug 2010 10:25:15 -0700 (PDT) Received: from BLU137-W9 ([65.55.111.71]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 10:25:44 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8c4ca361-a619-4868-8436-a6cf301cdf38_" X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: , Date: Tue, 3 Aug 2010 10:25:44 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2010 17:25:44.0035 (UTC) FILETIME=[E7307330:01CB3330] Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:25:17 -0000 --_8c4ca361-a619-4868-8436-a6cf301cdf38_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My humble suggestion is that draft-rosen-ecrit-additional-data is both stra= ightforward and highly beneficial. While IETF tradition would suggest that= items with such a high benefit/cost ratio should be delayed indefinitely o= r abandoned in favor of items that are more intractable=2C I'd suggest a c= oncession to common sense in this isolated instance. Of course=2C in order to ensure that the WG does not debase itself in an or= gy of productivity=2C tradition requires that the WG take on a number of wo= rk items which are "hard" only because the wrong questions are being asked.= I'd assert that both Unauthenticated Access and PSAP callback fall in t= his category. =20 Unauthenticated Access is "hard" because it represents a solution without a= real problem. There is no regulatory requirement for this today=2C nor is= there likely to be one in the near future because the "solution" would its= elf be a problem and because technology such as femtocells will make the "p= roblem" disappear in due course. PSAP Callback is "hard" largely because of the disconnect between the PSTN = way of thinking and the reality of VOIP=2C which will result in extended (a= nd largely fruitless) "discussions"=2C until the passage of the leaves the = obvious solution in plain view=2C like a whale washed up on the beach. Ser= ializing other work items until this "hard" problem is "solved" will essent= ially cause them to wait in the queue until our teeth are but a memory.=20 > Date: Tue=2C 3 Aug 2010 09:19:50 -0400 > From: mlinsner@cisco.com > To: ecrit@ietf.org > Subject: [Ecrit] New work in ECRIT >=20 > During the meeting last week the following drafts were discussed in the > context of accepting them as WG items. >=20 > 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 >=20 > The chairs and ADs have reviewed the level of interest in these=2C compar= ed > the work to the current charter and believe these fit within the scope of > ECRIT. >=20 > We asked during the meeting if anyone objects to accepting any or all of > these drafts as WG items. So=2C now=2C we're asking on the list. >=20 > If you object to any of these drafts becoming WG items=2C please explain = if > you think the work is something ECRIT should not do=2C or if you simply h= ave > problems with current version of the particular draft. No response is a > show of support for all of this work. >=20 > Once the above question is answered=2C the chairs will devise a work plan= to > finish the accepted work. >=20 > Also discussed in the meeting was the priority order of getting these dra= fts > completed=2C and it was the general feeling that psap-callback=2C > unauthenticated-access=2C and trustworthy-location were the most difficul= t 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=2C please send it to the list. >=20 > Please respond by COB on Wednesday=2C 8/11/2010 if you have objections to= any > of this work=2C or you have strong feelings on the priority of the work. >=20 > Thanks=2C >=20 > -Marc=2C Richard=2C Roger- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_8c4ca361-a619-4868-8436-a6cf301cdf38_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My humble suggestion is that draft-rosen-ecrit-additional-data is both stra= ightforward and highly beneficial. =3B While IETF tradition would sugge= st that items with such a high benefit/cost ratio should be delayed indefin= itely or abandoned in favor of items that are more intractable=2C =3B I= 'd suggest a concession to common sense in this isolated instance.

O= f course=2C in order to ensure that the WG does not debase itself in an org= y of productivity=2C tradition requires that the WG take on a number of wor= k items which are "hard" only because the wrong questions are being asked.&= nbsp=3B =3B I'd assert that both Unauthenticated Access and PSAP callba= ck =3B fall in this category. =3B =3B

Unauthenticated = Access is "hard" because it represents a solution without a real problem.&n= bsp=3B There is no regulatory requirement for this today=2C nor is there li= kely 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" d= isappear in due course.

PSAP Callback is "hard" largely because of t= he disconnect between the PSTN way of thinking and the reality of VOIP=2C w= hich will result in extended (and largely fruitless) "discussions"=2C until= the passage of the leaves the obvious solution in plain view=2C like a wha= le washed up on the beach. =3B 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.


>=3B Date: Tue=2C 3 Aug 20= 10 09:19:50 -0400
>=3B From: mlinsner@cisco.com
>=3B To: ecrit@ie= tf.org
>=3B Subject: [Ecrit] New work in ECRIT
>=3B
>=3B Du= ring the meeting last week the following drafts were discussed in the
&g= t=3B context of accepting them as WG items.
>=3B
>=3B draft-rose= n-ecrit-additional-data
>=3B draft-schulzrinne-ecrit-psap-callback
= >=3B draft-schulzrinne-ecrit-unauthenticated-access
>=3B draft-tscho= fenig-ecrit-trustworthy-location
>=3B draft-rosen-ecrit-data-only-ea>=3B
>=3B The chairs and ADs have reviewed the level of interest = in these=2C compared
>=3B the work to the current charter and believe = these fit within the scope of
>=3B ECRIT.
>=3B
>=3B We aske= d during the meeting if anyone objects to accepting any or all of
>=3B= these drafts as WG items. So=2C now=2C we're asking on the list.
>= =3B
>=3B If you object to any of these drafts becoming WG items=2C pl= ease explain if
>=3B you think the work is something ECRIT should not = do=2C or if you simply have
>=3B problems with current version of the = particular draft. No response is a
>=3B show of support for all of th= is work.
>=3B
>=3B Once the above question is answered=2C the ch= airs will devise a work plan to
>=3B finish the accepted work.
>= =3B
>=3B Also discussed in the meeting was the priority order of gett= ing these drafts
>=3B completed=2C and it was the general feeling that= psap-callback=2C
>=3B unauthenticated-access=2C and trustworthy-locat= ion were the most difficult and
>=3B would take more time. Of those t= hree the general feeling was the
>=3B psap-callback was the highest pr= iority. If you have an opinion on which
>=3B draft should completed f= irst=2C please send it to the list.
>=3B
>=3B Please respond by = COB on Wednesday=2C 8/11/2010 if you have objections to any
>=3B of th= is work=2C or you have strong feelings on the priority of the work.
>= =3B
>=3B Thanks=2C
>=3B
>=3B -Marc=2C Richard=2C Roger->=3B
>=3B
>=3B _____________________________________________= __
>=3B Ecrit mailing list
>=3B Ecrit@ietf.org
>=3B https://= www.ietf.org/mailman/listinfo/ecrit
= --_8c4ca361-a619-4868-8436-a6cf301cdf38_-- From mlinsner@cisco.com Tue Aug 3 12:04:02 2010 Return-Path: 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 8225A3A6AE7 for ; Tue, 3 Aug 2010 12:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TcRP296mQGCO for ; Tue, 3 Aug 2010 12:04:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 077793A6985 for ; Tue, 3 Aug 2010 12:04:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMYEWEyrR7H+/2dsb2JhbACgFHGpHZtNhTkEiQ4 X-IronPort-AV: E=Sophos;i="4.55,311,1278288000"; d="scan'208";a="166952132" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 Aug 2010 19:04:25 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o73J4MMW015053 for ; Tue, 3 Aug 2010 19:04:23 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 03 Aug 2010 15:04:19 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: draft-ietf-ecrit-local-emergency-rph-namespace Thread-Index: AcszPqzIIwW3NfZ8akCBtOo3ZpG+Wg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:04:02 -0000 All, As you all know, RPH namespace is an ECRIT draft without a milestone. At the meeting last week Robert Sparks announced he is willing to AD sponsor this draft. Robert asks everyone to read the draft and comment on it to this list. Thanks, -Marc- From dirk.kroeselberg@nsn.com Tue Aug 3 12:12:41 2010 Return-Path: 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 EFBE43A69B9 for ; Tue, 3 Aug 2010 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yfwkAvECvKbW for ; Tue, 3 Aug 2010 12:12:38 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 697353A69B4 for ; Tue, 3 Aug 2010 12:12:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o73JD0og002731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Aug 2010 21:13:00 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o73JCxTn023301; Tue, 3 Aug 2010 21:12:59 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 21:13:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB333F.E2DDE300" Date: Tue, 3 Aug 2010 21:12:58 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AcszMOrSQNeJkrvjThyaRizVqqXXvgADlGcw References: From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Bernard Aboba" , , X-OriginalArrivalTime: 03 Aug 2010 19:13:00.0035 (UTC) FILETIME=[E3581D30:01CB333F] Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:12:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB333F.E2DDE300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard,=20 =20 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. =20 Thanks, Dirk =20 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 =20 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. =20 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.=20 > Date: Tue, 3 Aug 2010 09:19:50 -0400 > From: mlinsner@cisco.com > To: ecrit@ietf.org > Subject: [Ecrit] New work in ECRIT >=20 > During the meeting last week the following drafts were discussed in the > context of accepting them as WG items. >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Once the above question is answered, the chairs will devise a work plan to > finish the accepted work. >=20 > 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. >=20 > 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. >=20 > Thanks, >=20 > -Marc, Richard, Roger- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01CB333F.E2DDE300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

------_=_NextPart_001_01CB333F.E2DDE300-- From bernard_aboba@hotmail.com Tue Aug 3 14:20:13 2010 Return-Path: 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 ; 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 ; 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 ; 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: 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: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> From: Bernard Aboba To: "Kroeselberg, Dirk (NSN - DE/Munich)" 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, 3 Aug 2010 14:20:22 -0700 X-OriginalArrivalTime: 03 Aug 2010 21:20:38.0273 (UTC) FILETIME=[B8027F10:01CB3351] Cc: "" Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:20:13 -0000 --Apple-Mail-43--231969971 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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)" 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 --Apple-Mail-43--231969971 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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

--Apple-Mail-43--231969971-- From jmpolk@cisco.com Wed Aug 4 12:13:00 2010 Return-Path: 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 307B63A6886 for ; Wed, 4 Aug 2010 12:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QEqA0ResWL4h for ; Wed, 4 Aug 2010 12:12:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BD56C3A680B for ; Wed, 4 Aug 2010 12:12:57 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,316,1278288000"; d="scan'208";a="349194172" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2010 19:13:27 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o74JDRNk011748; Wed, 4 Aug 2010 19:13:27 GMT Message-Id: <201008041913.o74JDRNk011748@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Aug 2010 14:13:26 -0500 To: Marc Linsner , "'ecrit'" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:13:00 -0000 At 08:19 AM 8/3/2010, Marc Linsner wrote: >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 Of the 5 items above, each have their advocates and uses (some more than others). That said, I believe the data-only-ea is imperative and am willing to work on it any way I can. I believe we can't avoid doing the psap-callback item, as there are too many organizations that want something from us on this topic - or they will each do it their own way. If we can provide a basis or a complete solution for others to use, we should do this too. James >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 From hannes.tschofenig@nsn.com Wed Aug 4 23:04:44 2010 Return-Path: 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 DD1CA3A6AA8 for ; Wed, 4 Aug 2010 23:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 YG432c4fn7aX for ; Wed, 4 Aug 2010 23:04:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 058253A6A31 for ; Wed, 4 Aug 2010 23:04:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o75648gg032642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Aug 2010 08:04:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o75648eD019528; Thu, 5 Aug 2010 08:04:08 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 08:04:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 09:04:07 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502DE8D7C@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AcszDo0Z7jRm4FMv+UqNT4Z3gBTsiwBVKvNA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Marc Linsner" , "ecrit" X-OriginalArrivalTime: 05 Aug 2010 06:04:08.0690 (UTC) FILETIME=[047D8520:01CB3464] Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 06:04:45 -0000 X-List-Received-Date: Thu, 05 Aug 2010 06:04:45 -0000 Hi Marc,=20 I believe all of them are important but their timeline is quite different.=20 I expect the draft-rosen-ecrit-additional-data to be finished first since it builds on top of existing work from NENA. What is missing at the moment is the security and privacy writeup.=20 draft-rosen-ecrit-data-only-ea is also a fairly easy document and it again builds on top of the NENA i3 work. What is left is to align the approach of dealing with location with the NENA i3 specification (or at least check whether they say the same).=20 draft-tschofenig-ecrit-trustworthy-location does not require a protocol definition; instead the challenge is to present the problem in a clear way and to come to an agreement of the suggestions. I believe that this will take a bit more time.=20 Then, there are 2 hard problems: draft-schulzrinne-ecrit-psap-callback, and draft-schulzrinne-ecrit-unauthenticated-access (whereby the latter is even harder, I believe). From a milestone point of view I would put them last. draft-schulzrinne-ecrit-unauthenticated-access is quite useful and overlaps a bit with ECRIT Direct (i.e. the draft that provides a writeup about the case where there is no VSP/ASP in the signaling exchange).=20 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Marc Linsner > Sent: Tuesday, August 03, 2010 4:20 PM > To: 'ecrit' > Subject: [Ecrit] New work in ECRIT >=20 > During the meeting last week the following drafts were=20 > discussed in the > context of accepting them as WG items. >=20 > 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 >=20 > The chairs and ADs have reviewed the level of interest in=20 > these, compared > the work to the current charter and believe these fit within=20 > the scope of > ECRIT. >=20 > We asked during the meeting if anyone objects to accepting=20 > any or all of > these drafts as WG items. So, now, we're asking on the list. >=20 > If you object to any of these drafts becoming WG items,=20 > please explain if > you think the work is something ECRIT should not do, or if=20 > you simply have > problems with current version of the particular draft. No=20 > response is a > show of support for all of this work. >=20 > Once the above question is answered, the chairs will devise a=20 > work plan to > finish the accepted work. >=20 > Also discussed in the meeting was the priority order of=20 > getting these drafts > completed, and it was the general feeling that psap-callback, > unauthenticated-access, and trustworthy-location were the=20 > 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=20 > opinion on which > draft should completed first, please send it to the list. >=20 > Please respond by COB on Wednesday, 8/11/2010 if you have=20 > objections to any > of this work, or you have strong feelings on the priority of the work. >=20 > Thanks, >=20 > -Marc, Richard, Roger- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From hannes.tschofenig@nsn.com Wed Aug 4 23:21:18 2010 Return-Path: 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 6D0F43A685F for ; Wed, 4 Aug 2010 23:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 xrwsqkkBqhnm for ; Wed, 4 Aug 2010 23:21:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8F10C3A6884 for ; Wed, 4 Aug 2010 23:21:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o756LdH0003319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Aug 2010 08:21:39 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o756Lc46025273; Thu, 5 Aug 2010 08:21:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 08:21:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3466.757B2555" Date: Thu, 5 Aug 2010 09:21:36 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AcszMOsY6YiCVp4xSpWhPKEJInzzPQBMxpTQ References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Bernard Aboba" , , X-OriginalArrivalTime: 05 Aug 2010 06:21:37.0964 (UTC) FILETIME=[75E806C0:01CB3466] Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 06:21:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3466.757B2555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard,=20 a few comments to your statements below:=20 =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: Tuesday, August 03, 2010 8:26 PM To: mlinsner@cisco.com; ecrit@ietf.org Subject: Re: [Ecrit] New work in ECRIT =09 =09 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. =09 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. =20 =09 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.=20 =20 I have to disagree with you and here are my arguments. The document covers a number of scenarios, even though we always just short-cut the description and talk about "unauthenticated access": a) No access authorization=20 b) No ASP =20 c) Zero-balance ASP=20 =20 There are differences between the legacy telephony system and VoIP. No doubt. We do, however, see people moving towards IP-based networks and now the question is how the existing regulatory requirements will apply to an IP-based environment. With all the years we have had a hard time to figure out how this is going to work out particularly since there is no flag day. Regulators, as you know, try to claim that they are technology neutral and therefore they are likely going to stick with their requirements and assume that technical people will get the rest to work. Many people had looked at the requlatory space and have not come up with a consistent answer of what all the regulatory requirements for VoIP systems are (given that regulators are often not too explicit). Maybe we should interact with NENA and EENA to hear their view on the regulatory situation.=20 =20 Let me talk about the above three items in context of the legacy infrastructure:=20 For (a) and (c) there are regulatory requirements. (b) is a case that cannot happen in the legacy technology but is quite likely in the VoIP case (see the more verbose description at http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02).=20 =20 From a VoIP point of view I would be really surprised if (c) is not useful in a VoIP context as well. As mentioned in the previous paragraph, (b) might actually be desirable from a communication point of view and I hear the argument about the applicable jurisdiction all the time. (a) is clearly tough and maybe the only thing we can do in this document is to point out some of the challenges and discourage it. With the ESWs we have lots of presenters talking about this topic and we tried to convince people that (a) is not a good approach but nevertheless the feedback we got is that people from the regulatory side still see some value in it. I fear that just because we do not like it does not make it go away. For the same reason the 3GPP has worked on solutions for IMS in this space.=20 =09 In a nutshell, I believe that this document is very useful already if it only provides a way to describe the differences between the legacy technology and why certain concepts cannot be mapped 1-to-1. Talking about the architectural challenges and what aspects need to be considered will be useful for readers as well. There are simpler cases that can be tackled, such as (b) and (c), with a somewhat detailed description. =20 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. =20 =20 As we discussed during the IETF week I will interview some more emergency services people about the user interface experience to gather some more data about this aspect.=20 =20 Ciao Hannes =20 =09 =09 > Date: Tue, 3 Aug 2010 09:19:50 -0400 > From: mlinsner@cisco.com > To: ecrit@ietf.org > Subject: [Ecrit] New work in ECRIT >=20 > During the meeting last week the following drafts were discussed in the > context of accepting them as WG items. >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Once the above question is answered, the chairs will devise a work plan to > finish the accepted work. >=20 > 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. >=20 > 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. >=20 > Thanks, >=20 > -Marc, Richard, Roger- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit =09 ------_=_NextPart_001_01CB3466.757B2555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bernard,=20

a few=20 comments to your statements below:
 
From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: Tuesday, August 03, 2010 8:26 PM
To:=20 mlinsner@cisco.com; ecrit@ietf.org
Subject: Re: [Ecrit] New = work in=20 ECRIT

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

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

Unauthenticated Access is "hard" = because it=20 represents a solution without a real problem.  There is no = regulatory=20 requirement for this today, nor is there likely to be one in the near = future=20 because the "solution" would itself be a problem and because = technology such=20 as femtocells will make the "problem" disappear in due course. 
 
I have to=20 disagree with you and here are my arguments.  The document=20 covers a number of scenarios, even though we always just short-cut the = description and talk about "unauthenticated = access":
 a) = No access=20 authorization 
 b) = No=20 ASP  
 c) = Zero-balance=20 ASP 
 
There are=20 differences between the legacy telephony system and VoIP. No doubt. We = do,=20 however, see people moving towards IP-based networks and now the = question is=20 how the existing regulatory requirements will apply to an IP-based=20 environment. With all the years we have had a hard time to figure out = how this=20 is going to work out particularly since there is no flag day. = Regulators, as=20 you know, try to claim that they are technology neutral and therefore = they are=20 likely going to stick with their requirements and assume that = technical people=20 will get the rest to work. Many people had looked at the requlatory = space and=20 have not come up with a consistent answer of what all the regulatory=20 requirements for VoIP systems are (given that regulators are often not = too=20 explicit). Maybe we should interact with NENA and EENA to hear = their view=20 on the regulatory situation.
 
Let me talk=20 about the above three items in context of the legacy infrastructure:=20
For (a) and=20 (c) there are regulatory requirements. (b) is a case that cannot = happen=20 in the legacy technology but is quite likely in the VoIP case (see the = more=20 verbose description at ht= tp://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02).=20
 
From a VoIP=20 point of view I would be really surprised if (c) is not useful in = a VoIP=20 context as well. As = mentioned in=20 the previous paragraph, (b) might actually be desirable from a = communication=20 point of view and I hear the argument about the applicable = jurisdiction all=20 the time. (a) is clearly tough and maybe the only thing we can do = in this=20 document is to point out some of the challenges and discourage = it. With=20 the ESWs we have lots of presenters talking about this topic and = we tried=20 to convince people that (a) is not a good approach but nevertheless = the=20 feedback we got is that people from the regulatory side still see some = value=20 in it.  I fear that just because we do not like it does not make = it go=20 away. For the same reason the 3GPP has worked on solutions for IMS in = this=20 space.

 In a nutshell, I believe that this document = is very=20 useful already if it only provides a way to describe the = differences=20 between the legacy technology and why = certain concepts cannot=20 be mapped 1-to-1. Talking about the architectural = challenges=20 and what aspects need to be considered will be useful for readers = as=20 well. There are simpler cases that can be tackled, such as (b) and = (c), with a=20 somewhat detailed description.
 
PSAP Callback is "hard" = largely=20 because of the disconnect between the PSTN way of thinking and the = reality of=20 VOIP, which will result in extended (and largely fruitless) = "discussions",=20 until the passage of the leaves the obvious solution in plain view, = like a=20 whale washed up on the beach.  Serializing other work items until = this=20 "hard" problem is "solved" will essentially cause them to wait in the = queue=20 until our teeth are but a memory.  
 
As we=20 discussed during the IETF week I will interview some more emergency = services=20 people about the user interface experience to gather some more data = about this=20 aspect.
 
Ciao
Hannes
 


> = Date: Tue, 3=20 Aug 2010 09:19:50 -0400
> From: mlinsner@cisco.com
> To:=20 ecrit@ietf.org
> Subject: [Ecrit] New work in ECRIT
> =
>=20 During the meeting last week the following drafts were discussed in=20 the
> context of accepting them as WG items.
>
>=20 draft-rosen-ecrit-additional-data
>=20 draft-schulzrinne-ecrit-psap-callback
>=20 draft-schulzrinne-ecrit-unauthenticated-access
>=20 draft-tschofenig-ecrit-trustworthy-location
>=20 draft-rosen-ecrit-data-only-ea
>
> The chairs and ADs = have=20 reviewed the level of interest in these, compared
> the work to = the=20 current charter and believe these fit within the scope of
>=20 ECRIT.
>
> We asked during the meeting if anyone objects = to=20 accepting any or all of
> these drafts as WG items. So, now, = we're=20 asking on the list.
>
> If you object to any of these = drafts=20 becoming WG items, please explain if
> you think the work is = something=20 ECRIT should not do, or if you simply have
> problems with = current=20 version of the particular draft. No response is a
> show of = support for=20 all of this work.
>
> Once the above question is = answered, the=20 chairs will devise a work plan to
> finish the accepted = work.
>=20
> Also discussed in the meeting was the priority order of = getting these=20 drafts
> completed, and it was the general feeling that=20 psap-callback,
> unauthenticated-access, and = trustworthy-location were=20 the most difficult and
> would take more time. Of those three = the=20 general feeling was the
> psap-callback was the highest = priority. If you=20 have an opinion on which
> draft should completed first, please = send it=20 to the list.
>
> Please respond by COB on Wednesday, = 8/11/2010 if=20 you have objections to any
> of this work, or you have strong = feelings=20 on the priority of the work.
>
> Thanks,
>
> = -Marc,=20 Richard, Roger-
>
>
>=20 _______________________________________________
> Ecrit mailing=20 list
> Ecrit@ietf.org
>=20 = https://www.ietf.org/mailman/listinfo/ecrit
= ------_=_NextPart_001_01CB3466.757B2555-- From Martin.Dawson@andrew.com Thu Aug 5 01:50:04 2010 Return-Path: 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 80CEA3A684C for ; Thu, 5 Aug 2010 01:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eDoSns5JXG2M for ; Thu, 5 Aug 2010 01:49:50 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 4F0293A6829 for ; Thu, 5 Aug 2010 01:49:50 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:5349 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S353461Ab0HEIuU (ORCPT ); Thu, 5 Aug 2010 03:50:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 5 Aug 2010 03:50:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 5 Aug 2010 16:50:16 +0800 From: "Dawson, Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Bernard Aboba , "mlinsner@cisco.com" , "ecrit@ietf.org" Date: Thu, 5 Aug 2010 16:50:14 +0800 Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AcszMOsY6YiCVp4xSpWhPKEJInzzPQBMxpTQAAUQo2A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB8B0389SISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Subject: Re: [Ecrit] New work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:50:04 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB8B0389SISPE7MB1comm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some thoughts for people to "kick around". What's the equivalent of these scenarios in the PSTN world? Some examples: 1. A SIMless mobile phone is still able to initiate a circuit service ses= sion with the emergency call centre applicable to the location its calling = from 2. A registered mobile phone with a zero pre-paid balance is still able t= o initiate a circuit service session with the applicable emergency call cen= tre 3. A pay-phone can be used to initiate a circuit service session with the= applicable emergency call centre without inserting any money 4. A residential POTS connection can still be used to initiate a circuit = service session to the applicable emergency call centre even though there i= s no active line rental subscription These are all real examples applicable in one or more combinations in one o= r more parts of the world. With respect to broadband Internet connectivity, it is only necessary to su= bstitute "circuit service session" with "IP packet session" and to consider= the equivalent connectivity situations: 1. A SIMless device (wanting to be) connected to an LTE or WiMAX access (= there is no circuit service available on these RANs) 2. An LTE or WIMAX device with a zero prepaid balance 3. A WiFi device connected to a "non-free" public hotspot 4. A residential DSL connection (connected to the DSLAM) that does not ha= ve an active subscription The concepts are similar but the technical challenges associated with actua= lly permitting the desired IP packet session to be established with the app= ropriate emergency call centre are profound and vary considerably with each= technology. Some technical complication arises because layer 3 service has= to be established before the ECRIT procedures even become applicable - so = there's a catch-22. Considerable amounts of detail with respect to how such "unauthenticated ac= cess" might be achieved are network technology specific and outside the sco= pe of the IETF. One consideration with respect to whether it's even worth the investment of= human capital in "solving" this "problem" is that we live in a different w= orld than the one that defined mid-twentieth century telephony (well - many= of us do). We live in a world where access to the Internet is being tabled= as a fundamental human right. Certainly it's the case that it's much easie= r to assume that people have connectivity than it ever used to be. Some jur= isdictions have recently decided to disable SIMless calling to emergency se= rvices because its nuisance contribution far outweighed its value. Approxim= ately zero emergency calls from SIMless devices were genuine; it's not the = kind of world where people carry around an unregistered device just in case= they need to make an emergency call. So - we could put a lot of energy into trying to define the parameters of a= concept that will never have a material regulatory basis. Cheers, Martin ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, 5 August 2010 4:22 PM To: ext Bernard Aboba; mlinsner@cisco.com; ecrit@ietf.org Subject: Re: [Ecrit] New work in ECRIT Hi Bernard, a few comments to your statements below: ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Bernard Aboba Sent: Tuesday, August 03, 2010 8: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 stra= ightforward and highly beneficial. While IETF tradition would suggest that= items with such a high benefit/cost ratio should be delayed indefinitely o= r abandoned in favor of items that are more intractable, I'd suggest a con= cession 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 i= tems 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 t= here likely to be one in the near future because the "solution" would itsel= f be a problem and because technology such as femtocells will make the "pro= blem" disappear in due course. I have to disagree with you and here are my arguments. The document covers= a number of scenarios, even though we always just short-cut the descriptio= n and talk about "unauthenticated access": a) No access authorization b) No ASP c) Zero-balance ASP There are differences between the legacy telephony system and VoIP. No doub= t. We do, however, see people moving towards IP-based networks and now the = question is how the existing regulatory requirements will apply to an IP-ba= sed environment. With all the years we have had a hard time to figure out h= ow this is going to work out particularly since there is no flag day. Regul= ators, as you know, try to claim that they are technology neutral and there= fore they are likely going to stick with their requirements and assume that= technical people will get the rest to work. Many people had looked at the = requlatory space and have not come up with a consistent answer of what all = the regulatory requirements for VoIP systems are (given that regulators are= often not too explicit). Maybe we should interact with NENA and EENA to he= ar their view on the regulatory situation. Let me talk about the above three items in context of the legacy infrastruc= ture: For (a) and (c) there are regulatory requirements. (b) is a case that canno= t happen in the legacy technology but is quite likely in the VoIP case (see= the more verbose description at http://tools.ietf.org/html/draft-winterbot= tom-ecrit-direct-02). >From a VoIP point of view I would be really surprised if (c) is not useful = in a VoIP context as well. As mentioned in the previous paragraph, (b) migh= t actually be desirable from a communication point of view and I hear the a= rgument about the applicable jurisdiction all the time. (a) is clearly toug= h and maybe the only thing we can do in this document is to point out some = of the challenges and discourage it. With the ESWs we have lots of presente= rs talking about this topic and we tried to convince people that (a) is not= a good approach but nevertheless the feedback we got is that people from t= he regulatory side still see some value in it. I fear that just because we= do not like it does not make it go away. For the same reason the 3GPP has = worked on solutions for IMS in this space. In a nutshell, I believe that this document is very useful already if it o= nly provides a way to describe the differences between the legacy technolog= y and why certain concepts cannot be mapped 1-to-1. Talking about the archi= tectural challenges and what aspects need to be considered will be useful f= or readers as well. There are simpler cases that can be tackled, such as (b= ) and (c), with a somewhat detailed description. 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 obvi= ous solution in plain view, like a whale washed up on the beach. Serializi= ng 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. As we discussed during the IETF week I will interview some more emergency s= ervices people about the user interface experience to gather some more data= about this aspect. Ciao Hannes > 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 hav= e > 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 t= o > finish the accepted work. > > Also discussed in the meeting was the priority order of getting these dra= fts > 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 a= ny > 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 --_000_8B0A9FCBB9832F43971E38010638454F03EB8B0389SISPE7MB1comm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some thoughts for people to “kic= k around”.

 

What’s the equivalent of these scenarios in the PSTN world? Some examples:

 

  1. A SIMless mobile phone is still able to initiate a circuit service sessi= on with the emergency call centre applicable to the location its calling = from
  2. A registered mobile phone with a zero pre-paid balance is still able to = initiate a circuit service session with the applicable emergency call centre
  3. A pay-phone can be used to initiate a circuit service session with the applicable emergency call centre without inserting any money
  4. A residential POTS connection can still be used to initiate a circuit service session to the applicable emergency call centre even though th= ere is no active line rental subscription

 

These are all real examples applicable= in one or more combinations in one or more parts of the world.

 

With respect to broadband Internet connectivity, it is only necessary to substitute “circuit service ses= sion” with “IP packet session” and to consider the equivalent connectivity situations:

 

  1. A SIMless device (wanting to be) connected to an LTE or WiMAX access (th= ere is no circuit service available on these RANs)
  2. An LTE or WIMAX device with a zero prepaid balance
  3. A WiFi device connected to a “non-free” public hotspot<= /o:p>
  4. A residential DSL connection (connected to the DSLAM) that does not have= an active subscription

 

The concepts are similar but the techn= ical challenges associated with actually permitting the desired IP packet sessio= n to be established with the appropriate emergency call centre are profound and = vary considerably with each technology. Some technical complication arises becau= se layer 3 service has to be established before the ECRIT procedures even beco= me applicable – so there’s a catch-22.

 

Considerable amounts of detail with respect to how such “unauthenticated access” might be achieved = are network technology specific and outside the scope of the IETF.

 

One consideration with respect to whet= her it’s even worth the investment of human capital in “solvingR= 21; this “problem” is that we live in a different world than the on= e that defined mid-twentieth century telephony (well – many of us do). = We live in a world where access to the Internet is being tabled as a fundament= al human right. Certainly it’s the case that it’s much easier to assume that people have connectivity than it ever used to be. Some jurisdictions have recently decided to disable SIMless calling to emergency services because its nuisance contribution far outweighed its value. Approx= imately zero emergency calls from SIMless devices were genuine; it’s not the = kind of world where people carry around an unregistered device just in case they need to make an emergency call.

 

So – we could put a lot of energ= y into trying to define the parameters of a concept that will never have a material regulatory basis.

 

Cheers,
Martin

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN = - FI/Espoo)
Sent: Thursday, 5 August 201= 0 4:22 PM
To: ext Bernard Aboba; mlinsner@cisco.com; ec= rit@ietf.org
Subject: Re: [Ecrit] New wor= k in ECRIT

 

Hi Bernard,


a few comments to your statements below: =

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard Aboba
Sent: Tuesday, August 03, 20= 10 8:26 PM
To: mlinsner@cisco.com; ecrit@ietf.org
Subject: Re: [Ecrit] New wor= k 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 favo= r of items that are more intractable,  I'd suggest a concession to common s= ense 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. 

 

I have to disagree with you and here a= re my arguments.  = The document covers a number of scenarios, even though we always just short-cut= the description and talk about "unauthenticated access":=

 a) No access authorization = =

 b) No ASP  =

 c) Zero-balance ASP = =

 

There are differences between the lega= cy telephony system and VoIP. No doubt. We do, however, see people moving towa= rds IP-based networks and now the question is how the existing regulatory requirements will apply to an IP-based environment. With all the years we h= ave had a hard time to figure out how this is going to work out particularly si= nce there is no flag day. Regulators, as you know, try to claim that they are technology neutral and therefore they are likely going to stick with their requirements and assume that technical people will get the rest to work. Ma= ny people had looked at the requlatory space and have not come up with a consistent answer of what all the regulatory requirements for VoIP systems = are (given that regulators are often not too explicit). Maybe we should interact with NENA and EENA to hear their view on the regulatory situation.= =

 

Let me talk about the above three item= s in context of the legacy infrastructure:

For (a) and (c) there are regulat= ory requirements. (b) is a case that cannot happen in the legacy technology but= is quite likely in the VoIP case (see the more verbose description at http= ://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02).

 

From a VoIP point of view I would be really surprised if (c) is not useful in a VoIP context as well.=  As mentioned in the previous paragraph, (b) might actually be desirable from a communication point of view and I hear the argument about = the applicable jurisdiction all the time. (a) is clearly tough and maybe t= he only thing we can do in this document is to point out some of the challenges and discourage it. With the ESWs we have lots of presenters talking about this topic and we tried to convince people that (a= ) is not a good approach but nevertheless the feedback we got is that people fro= m the regulatory side still see some value in it.  I fear that just because we do not like it does not make it go away. For the same reason the 3GPP has worked on solutions for IMS in this space.


 In a nutshell, I believe that this document is very useful already if it only provides a w= ay to describe the differences between the legacy technology and why certain concepts cannot be mapped 1-to-1. Talking about the architectural challenges and what aspects need to be consider= ed will be useful for readers as well. There are simpler cases that can be tackled, such as (b) and (c), with a somewhat detailed description.<= /font>=

 
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" probl= em is "solved" will essentially cause them to wait in the queue unti= l our teeth are but a memory. =  =

 

As we discussed during the IETF week I will interview some more emergency services people about the user interface experience to gather some more data about this aspect. =

 

Ciao
Hannes

 


> 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 th= e
> 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, compa= red
> 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 pla= n 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 difficu= lt 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 whic= h
> draft should completed first, please send it to the list.
>
> Please respond by COB on Wednesday, 8/11/2010 if you have objections t= o 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

--_000_8B0A9FCBB9832F43971E38010638454F03EB8B0389SISPE7MB1comm_-- From Ray.Bellis@nominet.org.uk Thu Aug 5 02:42:59 2010 Return-Path: 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 63BB93A69DA for ; Thu, 5 Aug 2010 02:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zHr0wIAfY45n for ; Thu, 5 Aug 2010 02:42:58 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id D3AC73A68B5 for ; Thu, 5 Aug 2010 02:42:57 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=ee8zcnF9S9b0+jefIwzQLeFZdX0Kf/H4vVsgQacdpo+dkR2ABqx/BqyT JJlSo2ThEEh98+ddZsZkPgYGUhf/7ov7Ar0UgGyckdY+C7acRcBQkskeI auvxLvLVzQMfmKw; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1281001408; x=1312537408; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[Ecrit]=20New=20work=20in=20ECRIT|Date: =20Thu,=205=20Aug=202010=2009:43:24=20+0000|Message-ID: =20<04592C1A-197E-4B16-9D22-EFA0E979A84A@nominet.org.uk> |To:=20"Dawson,=20Martin"=20 |CC:=20"Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)"=20,=20ext=0D=0A=20Bernard=20Aboba =20,=20"mlinsner@cisco.com"=0D =0A=09,=20"ecrit@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|Content-ID:=20<8710f739-e4be-4e92-a25 5-1adf7e83d8e9>|In-Reply-To:=20<8B0A9FCBB9832F43971E38010 638454F03EB8B0389@SISPE7MB1.commscope.com>|References:=20 =0D=0A=20=0D=0A=20<3D3C75174CB95F42 AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net>=0D=0A =20<8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1. commscope.com>; bh=kuRsq2QVs5Wv5DtbO90LaM2Kl5Yw8BaOxratvYybOV8=; b=y8Pq2b71Ff4ZY9BSN9gxtwfVRUCKyi9JvahIhYh9787M+Nt7rZNP2hrb nooTEMVSx25cD1rQWCl2Hxegoe5O9Kz4uh6p4OG2XP+9h+yjB6Ole274H yRDXBSNiJ8xuT9a; X-IronPort-AV: E=Sophos;i="4.55,320,1278284400"; d="scan'208";a="26360876" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Aug 2010 10:43:26 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Thu, 5 Aug 2010 10:43:25 +0100 From: Ray Bellis To: "Dawson, Martin" Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AQHLMzDsLvg7CVEjzEya6ZeZaGCTN5LSVcQAgAAphwCAAA7aAA== Date: Thu, 5 Aug 2010 09:43:24 +0000 Message-ID: <04592C1A-197E-4B16-9D22-EFA0E979A84A@nominet.org.uk> References: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1.commscope.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: <8710f739-e4be-4e92-a255-1adf7e83d8e9> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ext, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:42:59 -0000 On 5 Aug 2010, at 09:50, Dawson, Martin wrote: > With respect to broadband Internet connectivity, it is only necessary to = substitute =93circuit service session=94 with =93IP packet session=94 and t= o consider the equivalent connectivity situations: > =20 > =95 A SIMless device (wanting to be) connected to an LTE or WiMAX access= (there is no circuit service available on these RANs) > =95 An LTE or WIMAX device with a zero prepaid balance > =95 A WiFi device connected to a =93non-free=94 public hotspot > =95 A residential DSL connection (connected to the DSLAM) that does not = have an active subscription The DSL example is (IMHO) incorrect - an inactive subscriber only has layer= 2 (typically ATM) and does not have any IP connectivity. Establishing layer 3 requires a PPP session with a complete IPCP handshake = with the ISP. Ray --=20 Ray Bellis, MA(Oxon) MIET Senior Researcher, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From Martin.Dawson@andrew.com Thu Aug 5 03:00:15 2010 Return-Path: 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 550393A6781 for ; Thu, 5 Aug 2010 03:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 zxyoaw84Hnk7 for ; Thu, 5 Aug 2010 03:00:14 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 541B73A69A0 for ; Thu, 5 Aug 2010 03:00:14 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:10659 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S29461113Ab0HEKAo convert rfc822-to-8bit (ORCPT ); Thu, 5 Aug 2010 05:00:44 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 5 Aug 2010 05:00:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 5 Aug 2010 18:00:42 +0800 From: "Dawson, Martin" To: Ray Bellis Date: Thu, 5 Aug 2010 18:00:40 +0800 Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AQHLMzDsLvg7CVEjzEya6ZeZaGCTN5LSVcQAgAAphwCAAA7aAIAAEXvj Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB8A7F74@SISPE7MB1.commscope.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net> <8B0A9FCBB9832F43971E38010638454F03EB8B0389@SISPE7MB1.commscope.com>, <04592C1A-197E-4B16-9D22-EFA0E979A84A@nominet.org.uk> In-Reply-To: <04592C1A-197E-4B16-9D22-EFA0E979A84A@nominet.org.uk> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Dawson@andrew.com Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:00:15 -0000 I agree. That's my point. It is, nevertheless, the corresponding situation to a POTS line (connected to a line card in the local exchange) that doesn't have an active subscription. It used to be the case in Australia (may still be) that a TripleZero call still be able to be made on such a line. From an end user perspective, it's the same situation - two wires running between the house and the Telco. The technicalities, however, are different and DSL certainly wasn't implemented with this constraint in mind. My suggestion is that it's not a worthwhile investment in effort to try and work out how these situations could still support access to the emergency service until such time as regulators insist it's a requirement. And given the technical complications and state connectedness of people generally, I think it would be unlikely that regulators would decide such impositions are necessary. The technicality at the moment is that any emergency call made over broadband Internet access (fixed, untethered, or mobile) is, by definition, VoIP and so traditional service impositions don't apply. For operators to self-impose these requirements is creating a rod for their own backs - and taking on some very gnarly challenges for probably no good reason. Cheers, Martin ________________________________________ From: Ray Bellis [Ray.Bellis@nominet.org.uk] Sent: Thursday, 5 August 2010 7:43 PM To: Dawson, Martin Cc: Tschofenig, Hannes (NSN - FI/Espoo); ext Bernard Aboba; mlinsner@cisco.com; ecrit@ietf.org Subject: Re: [Ecrit] New work in ECRIT On 5 Aug 2010, at 09:50, Dawson, Martin wrote: > With respect to broadband Internet connectivity, it is only necessary to substitute “circuit service session” with “IP packet session” and to consider the equivalent connectivity situations: > > • A SIMless device (wanting to be) connected to an LTE or WiMAX access (there is no circuit service available on these RANs) > • An LTE or WIMAX device with a zero prepaid balance > • A WiFi device connected to a “non-free” public hotspot > • A residential DSL connection (connected to the DSLAM) that does not have an active subscription The DSL example is (IMHO) incorrect - an inactive subscriber only has layer 2 (typically ATM) and does not have any IP connectivity. Establishing layer 3 requires a PPP session with a complete IPCP handshake with the ISP. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 From jgunn6@csc.com Thu Aug 5 04:16:45 2010 Return-Path: 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 1889B3A6A95; Thu, 5 Aug 2010 04:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 GReTLBNFu5b7; Thu, 5 Aug 2010 04:16:44 -0700 (PDT) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id 024713A6AED; Thu, 5 Aug 2010 04:16:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-164.messagelabs.com!1281007032!11469109!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 8123 invoked from network); 5 Aug 2010 11:17:13 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Aug 2010 11:17:13 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o75BHCwu005929; Thu, 5 Aug 2010 07:17:12 -0400 In-Reply-To: References: To: Marc Linsner MIME-Version: 1.0 X-KeepSent: 9A370283:14EE1E7E-85257776:003DDA78; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Thu, 5 Aug 2010 07:17:08 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 08/05/2010 07:17:34 AM, Serialize complete at 08/05/2010 07:17:34 AM Content-Type: multipart/alternative; boundary="=_alternative 003DFEB785257776_=" Cc: 'ecrit' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 11:16:45 -0000 This is a multipart message in MIME format. --=_alternative 003DFEB785257776_= Content-Type: text/plain; charset="US-ASCII" I plan to review it, but not until the second half of August. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Marc Linsner To: "'ecrit'" Date: 08/03/2010 03:04 PM Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace All, As you all know, RPH namespace is an ECRIT draft without a milestone. At the meeting last week Robert Sparks announced he is willing to AD sponsor this draft. Robert asks everyone to read the draft and comment on it to this list. Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 003DFEB785257776_= Content-Type: text/html; charset="US-ASCII"
I plan to review it, but not until the second half of August.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


From: Marc Linsner <mlinsner@cisco.com>
To: "'ecrit'" <ecrit@ietf.org>
Date: 08/03/2010 03:04 PM
Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace




All,

As you all know, RPH namespace is an ECRIT draft without a milestone.  At
the meeting last week Robert Sparks announced he is willing to AD sponsor
this draft.

Robert asks everyone to read the draft and comment on it to this list.

Thanks,

-Marc-


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

--=_alternative 003DFEB785257776_=-- From root@core3.amsl.com Fri Aug 6 00:45:03 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 08AB13A689D; Fri, 6 Aug 2010 00:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100806074503.08AB13A689D@core3.amsl.com> Date: Fri, 6 Aug 2010 00:45:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 07:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST Service List Boundary Extension Author(s) : K. Wolf Filename : draft-ietf-ecrit-lost-servicelistboundary-04.txt Pages : 16 Date : 2010-08-06 LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the LoST server, in its response, does not provide context information, that is, it does not provide any additional information about the geographical region for which the returned list of services is considered valid within. Therefore, this document proposes a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client to not miss a change in available services when moving. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboundary-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-servicelistboundary-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-06003205.I-D@ietf.org> --NextPart-- From khwolf1@gmail.com Fri Aug 6 01:16:56 2010 Return-Path: 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 7F8A83A67AC for ; Fri, 6 Aug 2010 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8xrtwVkB6KFY for ; Fri, 6 Aug 2010 01:16:55 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 75B6B3A67C0 for ; Fri, 6 Aug 2010 01:16:55 -0700 (PDT) Received: by iwn36 with SMTP id 36so1101136iwn.31 for ; Fri, 06 Aug 2010 01:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=d0MU+mmIEkuIiTYNLX7F8wQcn/a/T7sSaBZpCmK4Ktg=; b=N071/ruqJcA2k+My7QEd86NM1svXlElhJgYor8X8ApT9/akIo6qPTERzYNAr3BjkKV +3pQS8DQSC+R4bzIQAIwr+4nQzXYbmxkBcjUbBIHnQ3eBZLszQ4CoZitLLgDbLov+FAH ufaH/2yolzK4VXEsHKrLugwnpO10Gu0gBMKIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dwt6mpc0Lvac+AJuQSO/1ggR+azJ5Skz9g1y6SwJl8Fy8EmgeS8E8AoLYpUgymKYfU db3sRLeYIRE0xNK6o7tDCmYkRlRKMA249RZchPXJH2lpDqtRvDfmHqj9R4yGf8oatSjl nYAfrVspna8jikElqJQH5ZieSlf6cruoVC2dw= MIME-Version: 1.0 Received: by 10.231.14.200 with SMTP id h8mr12339385iba.188.1281082645341; Fri, 06 Aug 2010 01:17:25 -0700 (PDT) Received: by 10.231.39.73 with HTTP; Fri, 6 Aug 2010 01:17:25 -0700 (PDT) In-Reply-To: <20100806074503.08AB13A689D@core3.amsl.com> References: <20100806074503.08AB13A689D@core3.amsl.com> Date: Fri, 6 Aug 2010 10:17:25 +0200 Message-ID: From: Karl Heinz Wolf To: ECRIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-servicelistboundary-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:16:56 -0000 This updated draft addresses the issues raised during the Applications Area Review. The text was improved for readability, Relax NG corrected and one XML style change: the service list boundary request element does not have text content any more but uses an attribute to choose by value or by reference (). I would like to thank Joshua Bell from the Applications Area Review team. Karl Heinz On Fri, Aug 6, 2010 at 9:45 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : LoST Service List Boundary Ext= ension > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : K. Wolf > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ecrit-lost-servicelis= tboundary-04.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-08-06 > > LoST maps service identifiers and location information to service > contact URIs. =A0If a LoST client wants to discover available services > for a particular location, it will perform a > query to the LoST server. =A0However, the LoST server, in its response, > does not provide context information, that is, it does not provide > any additional information about the geographical region for which > the returned list of services is considered valid within. =A0Therefore, > this document proposes a Service List Boundary that returns a local > context along with the list of services returned, in order to assist > the client to not miss a change in available services when moving. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-servicelistboun= dary-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From dirk.kroeselberg@nsn.com Fri Aug 6 01:39:12 2010 Return-Path: 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 5EBAF3A68E4 for ; Fri, 6 Aug 2010 01:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mq04MxxJlYRh for ; Fri, 6 Aug 2010 01:39:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6BFA43A6903 for ; Fri, 6 Aug 2010 01:39:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o768dVE6032049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2010 10:39:31 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o768dV9D023400; Fri, 6 Aug 2010 10:39:31 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 10:39:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3542.E178D634" Date: Fri, 6 Aug 2010 10:39:23 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6702D4C617@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New work in ECRIT Thread-Index: AcszUbkZ1xU2YePHQ8SYC94l2OC3ZgB78XKA References: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: "ext Bernard Aboba" X-OriginalArrivalTime: 06 Aug 2010 08:39:28.0537 (UTC) FILETIME=[E1F71090:01CB3542] 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:39:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3542.E178D634 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QXJlIHlvdSBzYXlpbmcgdGhlIGlzc3VlIG9mIGhvdyB0byBnZXQgaW50byBhIGhvdHNwb3QgZm9y IGVtZXJnZW5jeSB3aXRob3V0IGNyZWRlbnRpYWxzIHdpbGwgZ28gYXdheSBiZWNhdXNlIHRoZXJl IHdpbGwgYmUgRmVtdG9jZWxscyBhcm91bmQgYW55d2F5PyBOb3Qgc3VyZSB0aGlzIHdpbGwgYmUg dGhlIGdlbmVyYWwgY2FzZSBzb29uLg0KDQpIb3dldmVyLCB0aGVyZSBhcmUgYWxzbyBpc3N1ZXMg dGhhdCBhcHBseSB0byBGZW10byBhY2Nlc3MgKG5vdCBzdWJzY3JpYmVkL3ByZXBhaWQgZW1wdHkv Q1NHIGNvbmZpZ3VyYXRpb25zIGV0YykuIFRoZSBpZGVhIGlzIG5vdCB0byBsaW1pdCBjb25zaWRl cmF0aW9ucyB0byBvbmUgc3BlY2lmaWMgcmFkaW8gdGVjaG5vbG9neSBsaWtlIFdpRmkuDQoNCiAN Cg0KRGlyaw0KDQogDQoNCkZyb206IGV4dCBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZF9h Ym9iYUBob3RtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDMsIDIwMTAgMTE6MjAg UE0NClRvOiBLcm9lc2VsYmVyZywgRGlyayAoTlNOIC0gREUvTXVuaWNoKQ0KQ2M6IDxtbGluc25l ckBjaXNjby5jb20+OyA8ZWNyaXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBOZXcg d29yayBpbiBFQ1JJVA0KDQogDQoNCldpdGggZmVtdG9jZWxscywgZW1lcmdlbmN5IGNhbGxzIChp bmNsdWRpbmcgbm9uLXNlcnZpY2UgaW5pdGlhbGl6ZWQgb25lcykgY2FuIGJlIG1hZGUgaW5kb29y cywgd2l0aG91dCB0aGUgaGFuZHNldCBoYXZpbmcgdG8gb2J0YWluIGFjY2VzcyB0byBhIGNvcnBv cmF0ZSBvciBob3RzcG90IG5ldHdvcmsuICBBcyBhIHJlc3VsdCwgYSBjb21wYW55IGNvdWxkIGZv cmVnbyB0aGUgY2hhbGxlbmdlLCBleHBlbnNlIGFuZCBsaWFiaWxpdHkgYXNzb2NpYXRlZCB3aXRo IGVuZ2luZWVyaW5nIHVuYXV0aGVudGljYXRlZCBlbWVyZ2VuY3kgY2FsbGluZyBmb3Igbm9uLWVt cGxveWVlcy4gDQoNCk9uIEF1ZyAzLCAyMDEwLCBhdCAxMjoxMiBQTSwgIktyb2VzZWxiZXJnLCBE aXJrIChOU04gLSBERS9NdW5pY2gpIiA8ZGlyay5rcm9lc2VsYmVyZ0Buc24uY29tPiB3cm90ZToN Cg0KCUJlcm5hcmQsIA0KDQoJIA0KDQoJY291bGQgeW91IGNsYXJpZnkgeW91ciBjb21tZW50IHJl Z2FyZGluZyB0aGUgcmVsYXRpb24gb2YgZmVtdG9jZWxscyB0byB0aGUgdW5hdXRoZW50aWNhdGVk IGRyYWZ0PyBJdCBpcyBjb3JyZWN0IHRoYXQgc29tZSBmZW10b2NlbGwgY29uZmlndXJhdGlvbnMg YXJlIGNvbnNpZGVyZWQgYW4gaXNzdWUgZm9yIGVtZXJnZW5jeSBhY2Nlc3MsIGJ1dCBJIGFtIG5v dCBzdXJlIHdoaWNoIHJlbGF0aW9uIHRvIHVuYXV0aGVudGljYXRlZCB5b3UgYXJlIHBvaW50aW5n IGF0Lg0KDQoJIA0KDQoJVGhhbmtzLA0KDQoJRGlyaw0KDQoJIA0KDQoJRnJvbTogZWNyaXQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBleHQgQmVybmFyZCBBYm9iYQ0KCVNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMywgMjAxMCA3OjI2 IFBNDQoJVG86IG1saW5zbmVyQGNpc2NvLmNvbTsgZWNyaXRAaWV0Zi5vcmcNCglTdWJqZWN0OiBS ZTogW0Vjcml0XSBOZXcgd29yayBpbiBFQ1JJVA0KDQoJIA0KDQoJTXkgaHVtYmxlIHN1Z2dlc3Rp b24gaXMgdGhhdCBkcmFmdC1yb3Nlbi1lY3JpdC1hZGRpdGlvbmFsLWRhdGEgaXMgYm90aCBzdHJh aWdodGZvcndhcmQgYW5kIGhpZ2hseSBiZW5lZmljaWFsLiAgV2hpbGUgSUVURiB0cmFkaXRpb24g d291bGQgc3VnZ2VzdCB0aGF0IGl0ZW1zIHdpdGggc3VjaCBhIGhpZ2ggYmVuZWZpdC9jb3N0IHJh dGlvIHNob3VsZCBiZSBkZWxheWVkIGluZGVmaW5pdGVseSBvciBhYmFuZG9uZWQgaW4gZmF2b3Ig b2YgaXRlbXMgdGhhdCBhcmUgbW9yZSBpbnRyYWN0YWJsZSwgIEknZCBzdWdnZXN0IGEgY29uY2Vz c2lvbiB0byBjb21tb24gc2Vuc2UgaW4gdGhpcyBpc29sYXRlZCBpbnN0YW5jZS4NCgkNCglPZiBj b3Vyc2UsIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBXRyBkb2VzIG5vdCBkZWJhc2UgaXRz ZWxmIGluIGFuIG9yZ3kgb2YgcHJvZHVjdGl2aXR5LCB0cmFkaXRpb24gcmVxdWlyZXMgdGhhdCB0 aGUgV0cgdGFrZSBvbiBhIG51bWJlciBvZiB3b3JrIGl0ZW1zIHdoaWNoIGFyZSAiaGFyZCIgb25s eSBiZWNhdXNlIHRoZSB3cm9uZyBxdWVzdGlvbnMgYXJlIGJlaW5nIGFza2VkLiAgIEknZCBhc3Nl cnQgdGhhdCBib3RoIFVuYXV0aGVudGljYXRlZCBBY2Nlc3MgYW5kIFBTQVAgY2FsbGJhY2sgIGZh bGwgaW4gdGhpcyBjYXRlZ29yeS4gICANCgkNCglVbmF1dGhlbnRpY2F0ZWQgQWNjZXNzIGlzICJo YXJkIiBiZWNhdXNlIGl0IHJlcHJlc2VudHMgYSBzb2x1dGlvbiB3aXRob3V0IGEgcmVhbCBwcm9i bGVtLiAgVGhlcmUgaXMgbm8gcmVndWxhdG9yeSByZXF1aXJlbWVudCBmb3IgdGhpcyB0b2RheSwg bm9yIGlzIHRoZXJlIGxpa2VseSB0byBiZSBvbmUgaW4gdGhlIG5lYXIgZnV0dXJlIGJlY2F1c2Ug dGhlICJzb2x1dGlvbiIgd291bGQgaXRzZWxmIGJlIGEgcHJvYmxlbSBhbmQgYmVjYXVzZSB0ZWNo bm9sb2d5IHN1Y2ggYXMgZmVtdG9jZWxscyB3aWxsIG1ha2UgdGhlICJwcm9ibGVtIiBkaXNhcHBl YXIgaW4gZHVlIGNvdXJzZS4NCgkNCglQU0FQIENhbGxiYWNrIGlzICJoYXJkIiBsYXJnZWx5IGJl Y2F1c2Ugb2YgdGhlIGRpc2Nvbm5lY3QgYmV0d2VlbiB0aGUgUFNUTiB3YXkgb2YgdGhpbmtpbmcg YW5kIHRoZSByZWFsaXR5IG9mIFZPSVAsIHdoaWNoIHdpbGwgcmVzdWx0IGluIGV4dGVuZGVkIChh bmQgbGFyZ2VseSBmcnVpdGxlc3MpICJkaXNjdXNzaW9ucyIsIHVudGlsIHRoZSBwYXNzYWdlIG9m IHRoZSBsZWF2ZXMgdGhlIG9idmlvdXMgc29sdXRpb24gaW4gcGxhaW4gdmlldywgbGlrZSBhIHdo YWxlIHdhc2hlZCB1cCBvbiB0aGUgYmVhY2guICBTZXJpYWxpemluZyBvdGhlciB3b3JrIGl0ZW1z IHVudGlsIHRoaXMgImhhcmQiIHByb2JsZW0gaXMgInNvbHZlZCIgd2lsbCBlc3NlbnRpYWxseSBj YXVzZSB0aGVtIHRvIHdhaXQgaW4gdGhlIHF1ZXVlIHVudGlsIG91ciB0ZWV0aCBhcmUgYnV0IGEg bWVtb3J5LiANCgkNCgkNCgk+IERhdGU6IFR1ZSwgMyBBdWcgMjAxMCAwOToxOTo1MCAtMDQwMA0K CT4gRnJvbTogbWxpbnNuZXJAY2lzY28uY29tDQoJPiBUbzogZWNyaXRAaWV0Zi5vcmcNCgk+IFN1 YmplY3Q6IFtFY3JpdF0gTmV3IHdvcmsgaW4gRUNSSVQNCgk+IA0KCT4gRHVyaW5nIHRoZSBtZWV0 aW5nIGxhc3Qgd2VlayB0aGUgZm9sbG93aW5nIGRyYWZ0cyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUN Cgk+IGNvbnRleHQgb2YgYWNjZXB0aW5nIHRoZW0gYXMgV0cgaXRlbXMuDQoJPiANCgk+IGRyYWZ0 LXJvc2VuLWVjcml0LWFkZGl0aW9uYWwtZGF0YQ0KCT4gZHJhZnQtc2NodWx6cmlubmUtZWNyaXQt cHNhcC1jYWxsYmFjaw0KCT4gZHJhZnQtc2NodWx6cmlubmUtZWNyaXQtdW5hdXRoZW50aWNhdGVk LWFjY2Vzcw0KCT4gZHJhZnQtdHNjaG9mZW5pZy1lY3JpdC10cnVzdHdvcnRoeS1sb2NhdGlvbg0K CT4gZHJhZnQtcm9zZW4tZWNyaXQtZGF0YS1vbmx5LWVhDQoJPiANCgk+IFRoZSBjaGFpcnMgYW5k IEFEcyBoYXZlIHJldmlld2VkIHRoZSBsZXZlbCBvZiBpbnRlcmVzdCBpbiB0aGVzZSwgY29tcGFy ZWQNCgk+IHRoZSB3b3JrIHRvIHRoZSBjdXJyZW50IGNoYXJ0ZXIgYW5kIGJlbGlldmUgdGhlc2Ug Zml0IHdpdGhpbiB0aGUgc2NvcGUgb2YNCgk+IEVDUklULg0KCT4gDQoJPiBXZSBhc2tlZCBkdXJp bmcgdGhlIG1lZXRpbmcgaWYgYW55b25lIG9iamVjdHMgdG8gYWNjZXB0aW5nIGFueSBvciBhbGwg b2YNCgk+IHRoZXNlIGRyYWZ0cyBhcyBXRyBpdGVtcy4gU28sIG5vdywgd2UncmUgYXNraW5nIG9u IHRoZSBsaXN0Lg0KCT4gDQoJPiBJZiB5b3Ugb2JqZWN0IHRvIGFueSBvZiB0aGVzZSBkcmFmdHMg YmVjb21pbmcgV0cgaXRlbXMsIHBsZWFzZSBleHBsYWluIGlmDQoJPiB5b3UgdGhpbmsgdGhlIHdv cmsgaXMgc29tZXRoaW5nIEVDUklUIHNob3VsZCBub3QgZG8sIG9yIGlmIHlvdSBzaW1wbHkgaGF2 ZQ0KCT4gcHJvYmxlbXMgd2l0aCBjdXJyZW50IHZlcnNpb24gb2YgdGhlIHBhcnRpY3VsYXIgZHJh ZnQuIE5vIHJlc3BvbnNlIGlzIGENCgk+IHNob3cgb2Ygc3VwcG9ydCBmb3IgYWxsIG9mIHRoaXMg d29yay4NCgk+IA0KCT4gT25jZSB0aGUgYWJvdmUgcXVlc3Rpb24gaXMgYW5zd2VyZWQsIHRoZSBj aGFpcnMgd2lsbCBkZXZpc2UgYSB3b3JrIHBsYW4gdG8NCgk+IGZpbmlzaCB0aGUgYWNjZXB0ZWQg d29yay4NCgk+IA0KCT4gQWxzbyBkaXNjdXNzZWQgaW4gdGhlIG1lZXRpbmcgd2FzIHRoZSBwcmlv cml0eSBvcmRlciBvZiBnZXR0aW5nIHRoZXNlIGRyYWZ0cw0KCT4gY29tcGxldGVkLCBhbmQgaXQg d2FzIHRoZSBnZW5lcmFsIGZlZWxpbmcgdGhhdCBwc2FwLWNhbGxiYWNrLA0KCT4gdW5hdXRoZW50 aWNhdGVkLWFjY2VzcywgYW5kIHRydXN0d29ydGh5LWxvY2F0aW9uIHdlcmUgdGhlIG1vc3QgZGlm ZmljdWx0IGFuZA0KCT4gd291bGQgdGFrZSBtb3JlIHRpbWUuIE9mIHRob3NlIHRocmVlIHRoZSBn ZW5lcmFsIGZlZWxpbmcgd2FzIHRoZQ0KCT4gcHNhcC1jYWxsYmFjayB3YXMgdGhlIGhpZ2hlc3Qg cHJpb3JpdHkuIElmIHlvdSBoYXZlIGFuIG9waW5pb24gb24gd2hpY2gNCgk+IGRyYWZ0IHNob3Vs ZCBjb21wbGV0ZWQgZmlyc3QsIHBsZWFzZSBzZW5kIGl0IHRvIHRoZSBsaXN0Lg0KCT4gDQoJPiBQ bGVhc2UgcmVzcG9uZCBieSBDT0Igb24gV2VkbmVzZGF5LCA4LzExLzIwMTAgaWYgeW91IGhhdmUg b2JqZWN0aW9ucyB0byBhbnkNCgk+IG9mIHRoaXMgd29yaywgb3IgeW91IGhhdmUgc3Ryb25nIGZl ZWxpbmdzIG9uIHRoZSBwcmlvcml0eSBvZiB0aGUgd29yay4NCgk+IA0KCT4gVGhhbmtzLA0KCT4g DQoJPiAtTWFyYywgUmljaGFyZCwgUm9nZXItDQoJPiANCgk+IA0KCT4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+IEVjcml0IG1haWxpbmcgbGlzdA0K CT4gRWNyaXRAaWV0Zi5vcmcNCgk+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCg0K ------_=_NextPart_001_01CB3542.E178D634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0K ZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8 Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9REUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRp diBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPkFyZSB5b3Ugc2F5aW5nIHRoZSBpc3N1ZSBvZiBob3cgdG8gZ2V0 IGludG8gYSBob3RzcG90IGZvcg0KZW1lcmdlbmN5IHdpdGhvdXQgY3JlZGVudGlhbHMgd2lsbCBn byBhd2F5IGJlY2F1c2UgdGhlcmUgd2lsbCBiZSBGZW10b2NlbGxzDQphcm91bmQgYW55d2F5PyBO b3Qgc3VyZSB0aGlzIHdpbGwgYmUgdGhlIGdlbmVyYWwgY2FzZSBzb29uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPkhvd2V2ZXIsIHRoZXJlIGFyZSBhbHNvIGlzc3VlcyB0aGF0IGFwcGx5IHRvIEZl bXRvIGFjY2VzcyAobm90DQpzdWJzY3JpYmVkL3ByZXBhaWQgZW1wdHkvQ1NHIGNvbmZpZ3VyYXRp b25zIGV0YykuIFRoZSBpZGVhIGlzIG5vdCB0byBsaW1pdA0KY29uc2lkZXJhdGlvbnMgdG8gb25l IHNwZWNpZmljIHJhZGlvIHRlY2hub2xvZ3kgbGlrZSBXaUZpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkRpcms8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBleHQgQmVybmFyZCBBYm9iYQ0KW21haWx0bzpiZXJuYXJkX2Fib2Jh QGhvdG1haWwuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDAzLCAyMDEw IDExOjIwIFBNPGJyPg0KPGI+VG86PC9iPiBLcm9lc2VsYmVyZywgRGlyayAoTlNOIC0gREUvTXVu aWNoKTxicj4NCjxiPkNjOjwvYj4gJmx0O21saW5zbmVyQGNpc2NvLmNvbSZndDs7ICZsdDtlY3Jp dEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFY3JpdF0gTmV3IHdvcmsg aW4gRUNSSVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5XaXRoIGZlbXRvY2VsbHMs IGVtZXJnZW5jeQ0KY2FsbHMgKGluY2x1ZGluZyBub24tc2VydmljZSBpbml0aWFsaXplZCBvbmVz KSBjYW4gYmUgbWFkZSBpbmRvb3JzLCB3aXRob3V0IHRoZQ0KaGFuZHNldCBoYXZpbmcgdG8gb2J0 YWluIGFjY2VzcyB0byBhIGNvcnBvcmF0ZSBvciBob3RzcG90IG5ldHdvcmsuICZuYnNwO0FzIGEN CnJlc3VsdCwgYSBjb21wYW55IGNvdWxkIGZvcmVnbyB0aGUgY2hhbGxlbmdlLCBleHBlbnNlIGFu ZCBsaWFiaWxpdHkgYXNzb2NpYXRlZA0Kd2l0aCBlbmdpbmVlcmluZyB1bmF1dGhlbnRpY2F0ZWQg ZW1lcmdlbmN5IGNhbGxpbmcgZm9yIG5vbi1lbXBsb3llZXMuJm5ic3A7PGJyPg0KPGJyPg0KT24g QXVnIDMsIDIwMTAsIGF0IDEyOjEyIFBNLCAmcXVvdDtLcm9lc2VsYmVyZywgRGlyayAoTlNOIC0g REUvTXVuaWNoKSZxdW90Ow0KJmx0OzxhIGhyZWY9Im1haWx0bzpkaXJrLmtyb2VzZWxiZXJnQG5z bi5jb20iPmRpcmsua3JvZXNlbGJlcmdAbnNuLmNvbTwvYT4mZ3Q7DQp3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5CZXJuYXJkLA0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuDQps YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5jb3VsZCB5b3UgY2xhcmlmeSB5b3VyIGNvbW1l bnQgcmVnYXJkaW5nIHRoZSByZWxhdGlvbiBvZg0KZmVtdG9jZWxscyB0byB0aGUgdW5hdXRoZW50 aWNhdGVkIGRyYWZ0PyBJdCBpcyBjb3JyZWN0IHRoYXQgc29tZSBmZW10b2NlbGwNCmNvbmZpZ3Vy YXRpb25zIGFyZSBjb25zaWRlcmVkIGFuIGlzc3VlIGZvciBlbWVyZ2VuY3kgYWNjZXNzLCBidXQg SSBhbSBub3Qgc3VyZQ0Kd2hpY2ggcmVsYXRpb24gdG8gdW5hdXRoZW50aWNhdGVkIHlvdSBhcmUg cG9pbnRpbmcgYXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3Bhbg0KbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bhbg0KbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4NCmxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkRpcms8L3Nw YW4+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuDQpsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxk aXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YQ0KaHJlZj0ibWFpbHRvOmVj cml0LWJvdW5jZXNAaWV0Zi5vcmciPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+DQpbbWFpbHRv OmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+ZXh0IEJlcm5hcmQg QWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDAzLCAyMDEwIDc6MjYgUE08 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptbGluc25lckBjaXNjby5jb20iPm1saW5z bmVyQGNpc2NvLmNvbTwvYT47IDxhDQpocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0 QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBOZXcgd29yayBp biBFQ1JJVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+TXkgaHVtYmxlIHN1Z2dlc3Rpb24NCmlzIHRoYXQgZHJhZnQtcm9zZW4t ZWNyaXQtYWRkaXRpb25hbC1kYXRhIGlzIGJvdGggc3RyYWlnaHRmb3J3YXJkIGFuZCBoaWdobHkN CmJlbmVmaWNpYWwuJm5ic3A7IFdoaWxlIElFVEYgdHJhZGl0aW9uIHdvdWxkIHN1Z2dlc3QgdGhh dCBpdGVtcyB3aXRoIHN1Y2ggYQ0KaGlnaCBiZW5lZml0L2Nvc3QgcmF0aW8gc2hvdWxkIGJlIGRl bGF5ZWQgaW5kZWZpbml0ZWx5IG9yIGFiYW5kb25lZCBpbiBmYXZvciBvZg0KaXRlbXMgdGhhdCBh cmUgbW9yZSBpbnRyYWN0YWJsZSwmbmJzcDsgSSdkIHN1Z2dlc3QgYSBjb25jZXNzaW9uIHRvIGNv bW1vbiBzZW5zZQ0KaW4gdGhpcyBpc29sYXRlZCBpbnN0YW5jZS48YnI+DQo8YnI+DQpPZiBjb3Vy c2UsIGluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBXRyBkb2VzIG5vdCBkZWJhc2UgaXRzZWxm IGluIGFuIG9yZ3kgb2YNCnByb2R1Y3Rpdml0eSwgdHJhZGl0aW9uIHJlcXVpcmVzIHRoYXQgdGhl IFdHIHRha2Ugb24gYSBudW1iZXIgb2Ygd29yayBpdGVtcw0Kd2hpY2ggYXJlICZxdW90O2hhcmQm cXVvdDsgb25seSBiZWNhdXNlIHRoZSB3cm9uZyBxdWVzdGlvbnMgYXJlIGJlaW5nDQphc2tlZC4m bmJzcDsmbmJzcDsgSSdkIGFzc2VydCB0aGF0IGJvdGggVW5hdXRoZW50aWNhdGVkIEFjY2VzcyBh bmQgUFNBUA0KY2FsbGJhY2smbmJzcDsgZmFsbCBpbiB0aGlzIGNhdGVnb3J5LiZuYnNwOyZuYnNw OyA8YnI+DQo8YnI+DQpVbmF1dGhlbnRpY2F0ZWQgQWNjZXNzIGlzICZxdW90O2hhcmQmcXVvdDsg YmVjYXVzZSBpdCByZXByZXNlbnRzIGEgc29sdXRpb24NCndpdGhvdXQgYSByZWFsIHByb2JsZW0u Jm5ic3A7IFRoZXJlIGlzIG5vIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnQgZm9yIHRoaXMNCnRvZGF5 LCBub3IgaXMgdGhlcmUgbGlrZWx5IHRvIGJlIG9uZSBpbiB0aGUgbmVhciBmdXR1cmUgYmVjYXVz ZSB0aGUNCiZxdW90O3NvbHV0aW9uJnF1b3Q7IHdvdWxkIGl0c2VsZiBiZSBhIHByb2JsZW0gYW5k IGJlY2F1c2UgdGVjaG5vbG9neSBzdWNoIGFzDQpmZW10b2NlbGxzIHdpbGwgbWFrZSB0aGUgJnF1 b3Q7cHJvYmxlbSZxdW90OyBkaXNhcHBlYXIgaW4gZHVlIGNvdXJzZS48YnI+DQo8YnI+DQpQU0FQ IENhbGxiYWNrIGlzICZxdW90O2hhcmQmcXVvdDsgbGFyZ2VseSBiZWNhdXNlIG9mIHRoZSBkaXNj b25uZWN0IGJldHdlZW4gdGhlDQpQU1ROIHdheSBvZiB0aGlua2luZyBhbmQgdGhlIHJlYWxpdHkg b2YgVk9JUCwgd2hpY2ggd2lsbCByZXN1bHQgaW4gZXh0ZW5kZWQNCihhbmQgbGFyZ2VseSBmcnVp dGxlc3MpICZxdW90O2Rpc2N1c3Npb25zJnF1b3Q7LCB1bnRpbCB0aGUgcGFzc2FnZSBvZiB0aGUN CmxlYXZlcyB0aGUgb2J2aW91cyBzb2x1dGlvbiBpbiBwbGFpbiB2aWV3LCBsaWtlIGEgd2hhbGUg d2FzaGVkIHVwIG9uIHRoZQ0KYmVhY2guJm5ic3A7IFNlcmlhbGl6aW5nIG90aGVyIHdvcmsgaXRl bXMgdW50aWwgdGhpcyAmcXVvdDtoYXJkJnF1b3Q7IHByb2JsZW0NCmlzICZxdW90O3NvbHZlZCZx dW90OyB3aWxsIGVzc2VudGlhbGx5IGNhdXNlIHRoZW0gdG8gd2FpdCBpbiB0aGUgcXVldWUgdW50 aWwNCm91ciB0ZWV0aCBhcmUgYnV0IGEgbWVtb3J5LiA8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IERh dGU6IFR1ZSwgMyBBdWcgMjAxMCAwOToxOTo1MCAtMDQwMDxicj4NCiZndDsgRnJvbTogPGEgaHJl Zj0ibWFpbHRvOm1saW5zbmVyQGNpc2NvLmNvbSI+bWxpbnNuZXJAY2lzY28uY29tPC9hPjxicj4N CiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbRWNyaXRdIE5ldyB3b3JrIGluIEVDUklUPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IER1cmluZyB0aGUgbWVldGluZyBsYXN0IHdlZWsgdGhlIGZvbGxvd2luZyBk cmFmdHMgd2VyZSBkaXNjdXNzZWQgaW4gdGhlPGJyPg0KJmd0OyBjb250ZXh0IG9mIGFjY2VwdGlu ZyB0aGVtIGFzIFdHIGl0ZW1zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBkcmFmdC1yb3Nlbi1lY3Jp dC1hZGRpdGlvbmFsLWRhdGE8YnI+DQomZ3Q7IGRyYWZ0LXNjaHVsenJpbm5lLWVjcml0LXBzYXAt Y2FsbGJhY2s8YnI+DQomZ3Q7IGRyYWZ0LXNjaHVsenJpbm5lLWVjcml0LXVuYXV0aGVudGljYXRl ZC1hY2Nlc3M8YnI+DQomZ3Q7IGRyYWZ0LXRzY2hvZmVuaWctZWNyaXQtdHJ1c3R3b3J0aHktbG9j YXRpb248YnI+DQomZ3Q7IGRyYWZ0LXJvc2VuLWVjcml0LWRhdGEtb25seS1lYTxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGUgY2hhaXJzIGFuZCBBRHMgaGF2ZSByZXZpZXdlZCB0aGUgbGV2ZWwgb2Yg aW50ZXJlc3QgaW4gdGhlc2UsIGNvbXBhcmVkPGJyPg0KJmd0OyB0aGUgd29yayB0byB0aGUgY3Vy cmVudCBjaGFydGVyIGFuZCBiZWxpZXZlIHRoZXNlIGZpdCB3aXRoaW4gdGhlIHNjb3BlIG9mPGJy Pg0KJmd0OyBFQ1JJVC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgYXNrZWQgZHVyaW5nIHRoZSBt ZWV0aW5nIGlmIGFueW9uZSBvYmplY3RzIHRvIGFjY2VwdGluZyBhbnkgb3IgYWxsIG9mPGJyPg0K Jmd0OyB0aGVzZSBkcmFmdHMgYXMgV0cgaXRlbXMuIFNvLCBub3csIHdlJ3JlIGFza2luZyBvbiB0 aGUgbGlzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgeW91IG9iamVjdCB0byBhbnkgb2YgdGhl c2UgZHJhZnRzIGJlY29taW5nIFdHIGl0ZW1zLCBwbGVhc2UgZXhwbGFpbiBpZjxicj4NCiZndDsg eW91IHRoaW5rIHRoZSB3b3JrIGlzIHNvbWV0aGluZyBFQ1JJVCBzaG91bGQgbm90IGRvLCBvciBp ZiB5b3Ugc2ltcGx5IGhhdmU8YnI+DQomZ3Q7IHByb2JsZW1zIHdpdGggY3VycmVudCB2ZXJzaW9u IG9mIHRoZSBwYXJ0aWN1bGFyIGRyYWZ0LiBObyByZXNwb25zZSBpcyBhPGJyPg0KJmd0OyBzaG93 IG9mIHN1cHBvcnQgZm9yIGFsbCBvZiB0aGlzIHdvcmsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9u Y2UgdGhlIGFib3ZlIHF1ZXN0aW9uIGlzIGFuc3dlcmVkLCB0aGUgY2hhaXJzIHdpbGwgZGV2aXNl IGEgd29yayBwbGFuIHRvPGJyPg0KJmd0OyBmaW5pc2ggdGhlIGFjY2VwdGVkIHdvcmsuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEFsc28gZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIHdhcyB0aGUgcHJp b3JpdHkgb3JkZXIgb2YgZ2V0dGluZyB0aGVzZQ0KZHJhZnRzPGJyPg0KJmd0OyBjb21wbGV0ZWQs IGFuZCBpdCB3YXMgdGhlIGdlbmVyYWwgZmVlbGluZyB0aGF0IHBzYXAtY2FsbGJhY2ssPGJyPg0K Jmd0OyB1bmF1dGhlbnRpY2F0ZWQtYWNjZXNzLCBhbmQgdHJ1c3R3b3J0aHktbG9jYXRpb24gd2Vy ZSB0aGUgbW9zdCBkaWZmaWN1bHQNCmFuZDxicj4NCiZndDsgd291bGQgdGFrZSBtb3JlIHRpbWUu IE9mIHRob3NlIHRocmVlIHRoZSBnZW5lcmFsIGZlZWxpbmcgd2FzIHRoZTxicj4NCiZndDsgcHNh cC1jYWxsYmFjayB3YXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkuIElmIHlvdSBoYXZlIGFuIG9waW5p b24gb24gd2hpY2g8YnI+DQomZ3Q7IGRyYWZ0IHNob3VsZCBjb21wbGV0ZWQgZmlyc3QsIHBsZWFz ZSBzZW5kIGl0IHRvIHRoZSBsaXN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgcmVzcG9u ZCBieSBDT0Igb24gV2VkbmVzZGF5LCA4LzExLzIwMTAgaWYgeW91IGhhdmUgb2JqZWN0aW9ucyB0 bw0KYW55PGJyPg0KJmd0OyBvZiB0aGlzIHdvcmssIG9yIHlvdSBoYXZlIHN0cm9uZyBmZWVsaW5n cyBvbiB0aGUgcHJpb3JpdHkgb2YgdGhlIHdvcmsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r cyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgLU1hcmMsIFJpY2hhcmQsIFJvZ2VyLTxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjwvZGl2Pg0K DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CB3542.E178D634-- From hannes.tschofenig@nsn.com Fri Aug 13 06:30:59 2010 Return-Path: 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 F15DF3A69F7; Fri, 13 Aug 2010 06:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.213 X-Spam-Level: X-Spam-Status: No, score=-101.213 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_50=0.001, 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 NMVw-HmWEJyF; Fri, 13 Aug 2010 06:30:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 1FE443A6781; Fri, 13 Aug 2010 06:30:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7DDVKmk009938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2010 15:31:20 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7DDVJtt026193; Fri, 13 Aug 2010 15:31:20 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 15:31:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3AEB.CE7194D1" Date: Fri, 13 Aug 2010 16:31:15 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9C03B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Available ECRIT/GEOPRIV Code Thread-Index: Acs6683iPtZ5c/NaSbSsUJMAlQJArA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , X-OriginalArrivalTime: 13 Aug 2010 13:31:17.0138 (UTC) FILETIME=[CECBCF20:01CB3AEB] Subject: [Ecrit] Available ECRIT/GEOPRIV Code X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 13:30:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3AEB.CE7194D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 I am trying to figure out what code is available from the ECRIT/GEOPRIV group. Here is the list I was able to come up with. Anything missing? -------------------------------------------- DHCP Location Encoders Webpage for encoding and decoding RFC 3825/RFC 3825bis location data.=20 http://geopriv.dreamhosters.com/dhcloc/ Simple web-interface for RFC 4776 encoder:=20 http://ecrit.labs.nic.at/rfc4776.php Code for RFC 3825 encoder/decoder:=20 http://www.enum.at/index.php?id=3D529 Javascript support for RFC 3825 (option 123) and RFC 4776 (option 99) http://github.com/bifurcation/dhcp-loc Displaying PIDF-LOs in a Browser http://held-location.sourceforge.net/held_js/pidflo.html SIP based emergency services client implementation: http://ecrit.labs.nic.at/cgi-bin/trac.cgi Wireshark Patches:=20 http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/Wireshark-Patches DHCPv4 option 123 for coordinate-based location information DHCPv4 option 137 for the LoST Server Domain Name RFC4776 civic location configuration for DHCPv4 patch Wireshark 1.2.0 now includes all the patches Ecritdroid This application adds support for ECRIT (Emergency Context Resolution with Internet Technologies) calling to your Android phone. http://code.google.com/p/ecritdroid/ =20 =20 Asterisk Patch Asterisk patch can be used to get location by value out of the (multipart) body of a SIP message.=20 http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/Asterisk-Patches LoST client, server http://ecrit.net.informatik.uni-goettingen.de/wp/ HELD client:=20 http://sourceforge.net/projects/heldandlost/files/ Internet Geolocation Toolkit http://igtk.sourceforge.net/index.html LIS discovery, and HELD client, DHCP client, LoST client LoST server, and client=20 http://honamsun.cs.columbia.edu/index.html Web and Ajax based client available.=20 Krakau LoST server, client=20 http://ecrit.sourceforge.net/ HELD client and server http://held-location.sourceforge.net/ http://sourceforge.net/projects/held-location/files/ Firefox add-on "geolocation-HELD" Geolocation-provider for Firefox 3.1beta using the HELD protocol=20 http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/firefox-geolocation Firefox HELD Implementation The first pre-beta version of Firefox 4.0, released today, includes a minimal version of HELD, as a location provider for the W3C Geolocation API. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ -------------------------------------------- Unfortunately, a lot of the code I am aware of is not publically available. For example, I was not able to get hold of the code from the US DoT NG991 project. I doubt that the code from the REACH112 project will be available open source either.=20 Ciao Hannes ------_=_NextPart_001_01CB3AEB.CE7194D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Available ECRIT/GEOPRIV Code

Hi all, =

I am trying to = figure out what code is available from the ECRIT/GEOPRIV group. Here is = the list I was able to come up with. Anything missing?

--------------------------------------------=

DHCP Location = Encoders
Webpage for = encoding and decoding RFC 3825/RFC 3825bis location data.
http://geopriv.dreamhosters.com/dhcloc/<= /A>

Simple = web-interface for RFC 4776 encoder:
http://ecrit.labs.nic.at/rfc4776.php=

Code for RFC 3825 = encoder/decoder:
http://www.enum.at/index.php?id=3D529

Javascript support = for RFC 3825 (option 123) and RFC 4776 (option 99)
http://github.com/bifurcation/dhcp-loc

Displaying = PIDF-LOs in a Browser
http://held-location.sourceforge.net/held_js/pidflo.html

SIP based = emergency services client implementation:
http://ecrit.labs.nic.at/cgi-bin/trac.cgi

Wireshark Patches: =
http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/Wireshark-P= atches
DHCPv4 option 123 = for coordinate-based location information
DHCPv4 option 137 = for the LoST Server Domain Name
RFC4776 civic = location configuration for DHCPv4 patch
Wireshark 1.2.0 = now includes all the patches

Ecritdroid
This application = adds support for ECRIT (Emergency Context Resolution with Internet = Technologies) calling to your Android phone.

http://code.google.com/p/ecritdroid/=
        =           
        =          
Asterisk = Patch
Asterisk patch = can be used to get location by value out of the (multipart) body of a = SIP message.
= http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/Asterisk-Pa= tches

LoST client, = server
http://ecrit.net.informatik.uni-goettingen.de/wp/

HELD client: =
http://sourceforge.net/projects/heldandlost/files/<= /U>

Internet = Geolocation Toolkit
http://igtk.sourceforge.net/index.html
LIS discovery, = and HELD client, DHCP client, LoST client

LoST server, and = client
http://honamsun.cs.columbia.edu/index.html
Web and Ajax = based client available.

Krakau LoST = server, client
http://ecrit.sourceforge.net/

HELD client and = server
http://held-location.sourceforge.net/
http://sourceforge.net/projects/held-location/files/

Firefox add-on = "geolocation-HELD"
Geolocation-provider for Firefox 3.1beta using the HELD = protocol
http://ecrit.labs.nic.at/cgi-bin/trac.cgi/wiki/firefox-geo= location

Firefox HELD = Implementation
The first = pre-beta version of Firefox 4.0, released today, includes = a
minimal version = of HELD, as a location provider for the W3C
Geolocation = API.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/lat= est-trunk/


--------------------------------------------=

Unfortunately, a = lot of the code I am aware of is not publically available. For example, = I was not able to get hold of the code from the US DoT NG991 project. I = doubt that the code from the REACH112 project will be available open = source either.

Ciao
Hannes

------_=_NextPart_001_01CB3AEB.CE7194D1-- From mlinsner@cisco.com Fri Aug 13 07:08:07 2010 Return-Path: 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 826D23A6846 for ; Fri, 13 Aug 2010 07:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hhWIW+Sy5JTv for ; Fri, 13 Aug 2010 07:08:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 893C73A6950 for ; Fri, 13 Aug 2010 07:08:06 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANruZExAaMHG/2dsb2JhbACgOXGhVZtEhToEiV8 X-IronPort-AV: E=Sophos;i="4.55,363,1278288000"; d="scan'208";a="233987509" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2010 14:08:43 +0000 Received: from [10.116.195.116] (rtp-mlinsner-8713.cisco.com [10.116.195.116]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7DE8cPc028430 for ; Fri, 13 Aug 2010 14:08:40 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Fri, 13 Aug 2010 10:08:36 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: New Work Thread-Index: Acs68QVDxuTLI2AWyUWKBecVx0X0LQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 14:08:07 -0000 We recently asked for any objections to taking on the following documents as workgroup items. We have consensus to take this work on, now we have to commit to a realistic timeframe for completion. We're suggesting the following and would like your comments to include: 1) Are willing to work/contribute on the document? 2) Are willing to commit to the timeframe shown? The chairs commit to hosting virtual interim meetings at intervals necessary to meet the timeframes. Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - draft-rosen-ecrit-data-only-ea Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access Jan 2012 - draft-tschofenig-ecrit-trustworthy-location Mar 2012 - draft-schulzrinne-ecrit-psap-callback We realize the timeframes appear to out there but past experience tells us to be conservative. There's no penalty for getting them done early. We MUST have commitment to work on these before the ADs will give us the milestones. Please send your comments including which drafts you are willing to work on by COB Friday, August 20, 2010. Thanks, -Marc, Richard, Roger- From br@brianrosen.net Fri Aug 13 07:40:45 2010 Return-Path: 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 B69413A68B2 for ; Fri, 13 Aug 2010 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, 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 vL5uxLAbM5P8 for ; Fri, 13 Aug 2010 07:40:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 92D113A6838 for ; Fri, 13 Aug 2010 07:40:44 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.42]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OjvRe-00074z-43; Fri, 13 Aug 2010 09:41:18 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 13 Aug 2010 10:41:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F71FA39-1C72-4BA0-AA6C-DA5D78730567@brianrosen.net> References: To: Marc Linsner X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: 'ecrit' Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 14:40:46 -0000 Seems reasonable to me assuming the work group comments on what they = don't like so authors can address issues. I, of course, am willing to work on -additional-data and -data-only. I = will commit to comment/contribute to -trustworthy and -callback. I will = review -unauthenticated as needed. Brian On Aug 13, 2010, at 10:08 AM, Marc Linsner wrote: > We recently asked for any objections to taking on the following = documents as > workgroup items. We have consensus to take this work on, now we have = to > commit to a realistic timeframe for completion. We're suggesting the > following and would like your comments to include: >=20 > 1) Are willing to work/contribute on the document? > 2) Are willing to commit to the timeframe shown? >=20 > The chairs commit to hosting virtual interim meetings at intervals = necessary > to meet the timeframes. >=20 > Mar 2011 - draft-rosen-ecrit-additional-data > Apr 2011 - draft-rosen-ecrit-data-only-ea > Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access > Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > Mar 2012 - draft-schulzrinne-ecrit-psap-callback >=20 > We realize the timeframes appear to out there but past experience = tells us > to be conservative. There's no penalty for getting them done early. >=20 > We MUST have commitment to work on these before the ADs will give us = the > milestones. >=20 > Please send your comments including which drafts you are willing to = work on > by COB Friday, August 20, 2010. >=20 > Thanks, >=20 > -Marc, Richard, Roger- >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Fri Aug 13 10:35:19 2010 Return-Path: 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 BC0113A6902 for ; Fri, 13 Aug 2010 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.609 X-Spam-Level: X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, 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 Txv-MfqC8DWf for ; Fri, 13 Aug 2010 10:35:03 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id B68253A67EE for ; Fri, 13 Aug 2010 10:35:02 -0700 (PDT) Received: from BLU137-W33 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 10:35:38 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_552df169-4334-4df6-9569-8c14a549f84e_" X-Originating-IP: [131.107.0.72] From: Bernard Aboba To: , Date: Fri, 13 Aug 2010 10:35:38 -0700 Importance: Normal In-Reply-To: <8F71FA39-1C72-4BA0-AA6C-DA5D78730567@brianrosen.net> References: , <8F71FA39-1C72-4BA0-AA6C-DA5D78730567@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Aug 2010 17:35:38.0425 (UTC) FILETIME=[F19AAA90:01CB3B0D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 17:35:20 -0000 --_552df169-4334-4df6-9569-8c14a549f84e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will commit to working on -trustworthy and will commit to closely followi= ng additional-data and data-only=2C since both of these documents appear to= be useful.=20 I'll also commit to review unauthenticated and callback=2C though I admit t= o being uneasy about them.=20 > From: br@brianrosen.net > Date: Fri=2C 13 Aug 2010 10:41:16 -0400 > To: mlinsner@cisco.com > CC: ecrit@ietf.org > Subject: Re: [Ecrit] New Work >=20 > Seems reasonable to me assuming the work group comments on what they don'= t like so authors can address issues. >=20 > I=2C of course=2C am willing to work on -additional-data and -data-only. = I will commit to comment/contribute to -trustworthy and -callback. I will= review -unauthenticated as needed. >=20 > Brian >=20 > On Aug 13=2C 2010=2C at 10:08 AM=2C Marc Linsner wrote: >=20 > > We recently asked for any objections to taking on the following documen= ts as > > workgroup items. We have consensus to take this work on=2C now we have= to > > commit to a realistic timeframe for completion. We're suggesting the > > following and would like your comments to include: > >=20 > > 1) Are willing to work/contribute on the document? > > 2) Are willing to commit to the timeframe shown? > >=20 > > The chairs commit to hosting virtual interim meetings at intervals nece= ssary > > to meet the timeframes. > >=20 > > Mar 2011 - draft-rosen-ecrit-additional-data > > Apr 2011 - draft-rosen-ecrit-data-only-ea > > Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access > > Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > > Mar 2012 - draft-schulzrinne-ecrit-psap-callback > >=20 > > We realize the timeframes appear to out there but past experience tells= us > > to be conservative. There's no penalty for getting them done early. > >=20 > > We MUST have commitment to work on these before the ADs will give us th= e > > milestones. > >=20 > > Please send your comments including which drafts you are willing to wor= k on > > by COB Friday=2C August 20=2C 2010. > >=20 > > Thanks=2C > >=20 > > -Marc=2C Richard=2C Roger- > >=20 > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --_552df169-4334-4df6-9569-8c14a549f84e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will commit to working on -trustworthy and will commit to closely followi= ng additional-data and data-only=2C since both of these documents appear to= be useful.

I'll also commit to review unauthenticated and callback= =2C though I admit to being uneasy about them.

>=3B From: br@bria= nrosen.net
>=3B Date: Fri=2C 13 Aug 2010 10:41:16 -0400
>=3B To: = mlinsner@cisco.com
>=3B CC: ecrit@ietf.org
>=3B Subject: Re: [Ecr= it] New Work
>=3B
>=3B Seems reasonable to me assuming the work = group comments on what they don't like so authors can address issues.
&g= t=3B
>=3B I=2C of course=2C am willing to work on -additional-data an= d -data-only. I will commit to comment/contribute to -trustworthy and -cal= lback. I will review -unauthenticated as needed.
>=3B
>=3B Bria= n
>=3B
>=3B On Aug 13=2C 2010=2C at 10:08 AM=2C Marc Linsner wro= te:
>=3B
>=3B >=3B We recently asked for any objections to tak= ing on the following documents as
>=3B >=3B workgroup items. We hav= e consensus to take this work on=2C now we have to
>=3B >=3B commit = to a realistic timeframe for completion. We're suggesting the
>=3B &g= t=3B following and would like your comments to include:
>=3B >=3B >=3B >=3B 1) Are willing to work/contribute on the document?
>= =3B >=3B 2) Are willing to commit to the timeframe shown?
>=3B >= =3B
>=3B >=3B The chairs commit to hosting virtual interim meetings= at intervals necessary
>=3B >=3B to meet the timeframes.
>=3B = >=3B
>=3B >=3B Mar 2011 - draft-rosen-ecrit-additional-data
&g= t=3B >=3B Apr 2011 - draft-rosen-ecrit-data-only-ea
>=3B >=3B Dec = 2011 - draft-schulzrinne-ecrit-unauthenticated-access
>=3B >=3B Jan = 2012 - draft-tschofenig-ecrit-trustworthy-location
>=3B >=3B Mar 201= 2 - draft-schulzrinne-ecrit-psap-callback
>=3B >=3B
>=3B >= =3B We realize the timeframes appear to out there but past experience tells= us
>=3B >=3B to be conservative. There's no penalty for getting th= em done early.
>=3B >=3B
>=3B >=3B We MUST have commitment t= o work on these before the ADs will give us the
>=3B >=3B milestones= .
>=3B >=3B
>=3B >=3B Please send your comments including wh= ich drafts you are willing to work on
>=3B >=3B by COB Friday=2C Aug= ust 20=2C 2010.
>=3B >=3B
>=3B >=3B Thanks=2C
>=3B >= =3B
>=3B >=3B -Marc=2C Richard=2C Roger-
>=3B >=3B
>= =3B >=3B
>=3B >=3B
>=3B >=3B ____________________________= ___________________
>=3B >=3B Ecrit mailing list
>=3B >=3B Ec= rit@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit>=3B
>=3B _______________________________________________
>= =3B Ecrit mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.= org/mailman/listinfo/ecrit
= --_552df169-4334-4df6-9569-8c14a549f84e_-- From rbarnes@bbn.com Fri Aug 13 12:50:44 2010 Return-Path: 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 ; 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 ; 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 ; 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 ) id 1Ok0He-000AXl-Pf; Fri, 13 Aug 2010 15:51:19 -0400 Message-Id: From: "Richard L. Barnes" To: "Kroeselberg, Dirk (NSN - DE/Munich)" 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: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:50:44 -0000 --Apple-Mail-2-626679398 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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: ; > 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)" > 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 --Apple-Mail-2-626679398 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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:

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.
 
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
>  To: "'Richard L. Barnes'" , "'Kroeselberg, Dirk \(NSN - DE/Munich\)'" References: <8C51C7A529FC9D49843ACF5AE2FFBF6702D1061B@DEMUEXC030.nsn-intra.net> <8C51C7A529FC9D49843ACF5AE2FFBF6702D4C617@DEMUEXC030.nsn-intra.net> In-Reply-To: Date: Fri, 13 Aug 2010 13:29:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01CB3AEB.832C3870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJ47uoLAj2qY3CYsMufR5JD7r4MQC0swZMAhLr/S4DVMlSLwLn1cc7Ak5dDTKUB+4NcA== Content-Language: en-us X-OriginalArrivalTime: 13 Aug 2010 20:29:11.0385 (UTC) FILETIME=[30364490:01CB3B26] 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:31:19 -0000 ------=_NextPart_000_00B4_01CB3AEB.832C3870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: ; 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)" 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 ------=_NextPart_000_00B4_01CB3AEB.832C3870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

 

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

 

------=_NextPart_000_00B4_01CB3AEB.832C3870-- From hannes.tschofenig@gmx.net Sat Aug 14 11:18:43 2010 Return-Path: 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 0DB213A68E8 for ; Sat, 14 Aug 2010 11:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 TRRMtDDiPbk6 for ; Sat, 14 Aug 2010 11:18:42 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id B9A263A685C for ; Sat, 14 Aug 2010 11:18:40 -0700 (PDT) Received: (qmail invoked by alias); 14 Aug 2010 18:19:16 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.5]) [88.115.222.204] by mail.gmx.net (mp010) with SMTP; 14 Aug 2010 20:19:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1912jk1U6d1rosucHpoikoiQan8pzPoDCiZDvDdKg yk5Rjo7z77iuni Message-ID: <4C66DE23.7000001@gmx.net> Date: Sat, 14 Aug 2010 21:19:15 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: 'ecrit' Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 18:18:43 -0000 Hi Marc, Richard, Roger, I am willing to work on the documents. The milestones are seem to be a good estimate. Ciao Hannes On 8/13/2010 5:08 PM, Marc Linsner wrote: > We recently asked for any objections to taking on the following documents as > workgroup items. We have consensus to take this work on, now we have to > commit to a realistic timeframe for completion. We're suggesting the > following and would like your comments to include: > > 1) Are willing to work/contribute on the document? > 2) Are willing to commit to the timeframe shown? > > The chairs commit to hosting virtual interim meetings at intervals necessary > to meet the timeframes. > > Mar 2011 - draft-rosen-ecrit-additional-data > Apr 2011 - draft-rosen-ecrit-data-only-ea > Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access > Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > Mar 2012 - draft-schulzrinne-ecrit-psap-callback > > We realize the timeframes appear to out there but past experience tells us > to be conservative. There's no penalty for getting them done early. > > We MUST have commitment to work on these before the ADs will give us the > milestones. > > Please send your comments including which drafts you are willing to work on > by COB Friday, August 20, 2010. > > Thanks, > > -Marc, Richard, Roger- > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > From Milan.Patel@InterDigital.com Sun Aug 15 05:24:03 2010 Return-Path: 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 E29F73A6783 for ; Sun, 15 Aug 2010 05:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 SAOMvBE0g3wJ for ; Sun, 15 Aug 2010 05:24:02 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 199453A6765 for ; Sun, 15 Aug 2010 05:24:01 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Aug 2010 08:24:36 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Aug 2010 08:24:36 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000E6FB28F@SABRE.InterDigital.com> In-Reply-To: <4C66DE23.7000001@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New Work Thread-Index: Acs73TmemVIx8794R2eMOVJvHhSqrwAl2cyw References: <4C66DE23.7000001@gmx.net> From: "Patel, Milan" To: "Hannes Tschofenig" , "Marc Linsner" Importance: normal Priority: normal X-OriginalArrivalTime: 15 Aug 2010 12:24:36.0598 (UTC) FILETIME=[D31D5960:01CB3C74] Cc: ecrit Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 12:24:04 -0000 Hi Marc, Richard & Roger, I will continue to work on the Call Back draft.=20 Best regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, August 14, 2010 7:19 PM To: Marc Linsner Cc: 'ecrit' Subject: Re: [Ecrit] New Work Hi Marc, Richard, Roger, I am willing to work on the documents. The milestones are seem to be a=20 good estimate. Ciao Hannes On 8/13/2010 5:08 PM, Marc Linsner wrote: > We recently asked for any objections to taking on the following documents as > workgroup items. We have consensus to take this work on, now we have to > commit to a realistic timeframe for completion. We're suggesting the > following and would like your comments to include: > > 1) Are willing to work/contribute on the document? > 2) Are willing to commit to the timeframe shown? > > The chairs commit to hosting virtual interim meetings at intervals necessary > to meet the timeframes. > > Mar 2011 - draft-rosen-ecrit-additional-data > Apr 2011 - draft-rosen-ecrit-data-only-ea > Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access > Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > Mar 2012 - draft-schulzrinne-ecrit-psap-callback > > We realize the timeframes appear to out there but past experience tells us > to be conservative. There's no penalty for getting them done early. > > We MUST have commitment to work on these before the ADs will give us the > milestones. > > Please send your comments including which drafts you are willing to work on > by COB Friday, August 20, 2010. > > Thanks, > > -Marc, Richard, Roger- > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit =20 =20 =20 Milan Patel=20 Consultant InterDigital Communications, LLC Tel.: +44 7917 678 250 Fax:=20 Email: Milan.Patel@InterDigital.com http://www.InterDigital.com This e-mail is intended only for the use of the individual or entity to = which it is addressed, and may contain information that is privileged, = confidential and/or otherwise protected from disclosure to anyone other = than its intended recipient. Unintended transmission shall not = constitute waiver of any privilege or confidentiality obligation. If you = received this communication in error, please do not review, copy or = distribute it, notify me immediately by email, and delete the original = message and any attachments. Unless expressly stated in this e-mail, = nothing in this message or any attachment should be construed as a = digital or electronic signature. From root@core3.amsl.com Sun Aug 15 20:15:03 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8EDD33A693F; Sun, 15 Aug 2010 20:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100816031502.8EDD33A693F@core3.amsl.com> Date: Sun, 15 Aug 2010 20:15:02 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 03:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Using Imprecise Location for Emergency Context Resolution Author(s) : R. Barnes, M. Lepinski Filename : draft-ietf-ecrit-rough-loc-03.txt Pages : 19 Date : 2010-08-15 Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-rough-loc-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-rough-loc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-15200052.I-D@ietf.org> --NextPart-- From rbarnes@bbn.com Sun Aug 15 20:38:52 2010 Return-Path: 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 980103A6957; Sun, 15 Aug 2010 20:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.167 X-Spam-Level: X-Spam-Status: No, score=-101.167 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_50=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 kdBEfrM6YxXm; Sun, 15 Aug 2010 20:38:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9F98A3A6848; Sun, 15 Aug 2010 20:38:50 -0700 (PDT) Received: from [128.89.253.40] (port=63254 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OkqXl-000GGs-EG; Sun, 15 Aug 2010 23:39:26 -0400 Message-Id: From: "Richard L. Barnes" To: Internet-Drafts@ietf.org In-Reply-To: <20100816031502.8EDD33A693F@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 15 Aug 2010 23:39:24 -0400 References: <20100816031502.8EDD33A693F@core3.amsl.com> X-Mailer: Apple Mail (2.936) Cc: ecrit@ietf.org, i-d-announce@ietf.org Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 03:38:52 -0000 Hey all, As promised in Maastricht, here's an update to rough-loc. The diff looks kind of big and scary, but it's mostly just reformatting and clarification. The changes in this draft were mainly in response to reviews by Hannes and Martin. My responses to their comments are included below, with my comments in [RLB:...] brackets. More review and comment would definitely be welcome, but I generally think this is getting pretty mature. --Richard ===== Hannes Tschofenig ===== * Document structure: I don't understand why "Location filtering" is a sub-section of "Determining sufficient location precision". Section "Civic address considerations" is the only sub-section and this typically does not look good. [RLB: Re-organized with the following structure: 3. Location Precision Requirements . . . . . . . . . . . . . . . 5 4. Location Filtering . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Filter Region for a Known Location . . . . . . . . . . . . 6 4.2. Constructing a Location Filter . . . . . . . . . . . . . . 8 4.3. Civic Address Considerations . . . . . . . . . . . . . . . 11 4.4. Maintaining Location Filters . . . . . . . . . . . . . . . 12 4.5. Applying Location Filters . . . . . . . . . . . . . . . . 12 ] I wonder whether is so clear to the reader why the LIS has to create the location filter in a way that it has to consider all the emergency services. [RLB: Added a paragraph to clarify] The description of the non-emergency services use case is a bit confusing, I believe. We focused with our discussion on the emergency services case. [RLB: Revised this to bring it more in line with the new location- conveyance; see if it meets your concerns.] Section 3.2 provides a pseudo-algorithm for the location filter concept. Have you tried to implement the proposed mechanism to increase our confidence? [RLB: No, but it seems pretty straightforward. Do you think it looks incorrect?] * References: [RLB: Following fixes: -- -servicelistboundary from normative to informative -- -mapping-arch replaced by RFC 5582 -- Added reference to draft-ietf-ecrit-location-hiding-req in introduction ] I don't think we expect the human to check the location. The advantage of having location information at the end host is to allow him to * learn about the available emergency service numbers available to that specific region, and (as discussed more extensively end of last year) to * route the emergency call directly to the PSAP (potentially without any involvement of the VSP/ASP). [RLB: Added a couple of sentences to the introduction clarifying this.] You should better say "any emergency service URN" since non-emergency service URNs may be treated entirely different. The same is true for item 2 in your list. [RLB: Done: s/service URN/emergency service URN/g] * Editorial: Please look at the subject headings and use capitalized characters. Example: s/Location filtering/Location Filtering [RLB: Done.] s/"A filter can used to determine whether a location is usable for emergency call routing in the following way:"/"A filter can be used to determine whether a location is usable for emergency call routing in the following way:" [RLB: Done.] Please replace the term "Target" with the term "Device" in the security consideration section based on the discussions we had in the lo-sec document. [RLB: Done] I would write "operationally difficult" rather than "not generally possible". [RLB: Done] Don't talk about "valid" as there is a special semantic attached to that word. Instead, the response to the LoST query contains a element that can be used by the recipient as a hint to skip subsequent queries for the same Service URN when the location falls within the indicated service boundary. [RLB: What semantic do you understand for "valid"? I'm pretty sure that the usage here (i.e., "mapping is valid" == "PSAP information is correct for service URN location") is consistent with the usage in RFC 5222 and RFC 5582. See, e.g., Section 5.2 of 5222. (Even if the doesn't contain *all* possible locations, it is at least a set where the same mapping is valid, which is good enough for our purposes.) Keep in mind that this is separate from the *address* validation function in LoST, which deals addresses, not mappings.] " A consequence of this is that given a set of service boundaries for different services, the intersection of those service boundaries is the region in which two mappings are valid. " This sentence is a bit wrong. At least you shouldn't say "two mappings" in the later part of the sentence when you start generically. [RLB: Changed "two mappings" to "all of the corresponding mappings"] s/"then the intersection is the are where both of these mappings are valid"/then the intersection is the area where both of these mappings are valid" [RLB: Done] * Acknowledgements Weren't there more reviewers? Not many people are listed. [RLB: I added you and Martin :) ] ===== Martin Thomson ===== The introductory text in this document implies larger scope than is actually delivered. In many cases, statements are prefaced with "if precise location information is available" or similar, but no guidance is given where the location information is not "precise". [RLB: That's in part because it depends a lot on the positioning mechanism. If you've got a generic IP-geo table, for example, you could just compare the location values in the table against the filter regions and see if they fit. (If so, you're good to go; otherwise, there's a possibility of routing errors.) With a system that gradually converges, you could use the location filter as a trigger for when to terminate the process and return a value (when you're sufficiently within a filter region). We tried to state this briefly with the phrase "These cases may arise when computing precise location is an expensive or time-consuming operation (e.g., in the case of wireless triangulation), and location is needed quickly", but we can add some more text to clarify if you think it's necessary. Suggestions welcome :) ] As the document is read, I infer that the goal of the document is to describe how to provide degraded location information without resulting in routing failures for emergency calling. I understand that there might be a desire to weasel around this issue, but it is better to clearly define the scope of the document up front. [RLB: Added a paragraph to the introduction to clarify] I don't think that you can avoid discussion of where location information crosses a service boundary. In the context of a more limited scope, it could be significantly easier to manage. [RLB: Not clear what to do with this. Suggested text?] (As an aside: In reading this document from the perspective of its advertised scope, I believe that there are shortcomings in LoST with respect to low quality input location. A single LoST server is able to provide multiple mappings, but it provides no means to distinguish them. Furthermore, it is unable to provide a redirect to multiple servers where an ambiguity spans regions covered by different servers. This has only a peripheral impact on this document - the procedures described in the document would effectively work around this limitation.) [RLB: Agreed; IIRC, there was some discussion of this during the development of LoST, but no real resolution. Also agree that this document is not the right place to solve them.] I don't know that filter is the right word to use for what this document describes. Filter, to me, implies that the information is refined somehow, where the opposite is true. "Mask" might be a better fit. [RLB: "Mask" doesn't seem right either, since you're not chopping off parts of the input location (as you would with, say, a bit mask). Maybe something like "partition"?] (Almost editorial comment) On mechanism, I think that there are two methods that could be used here. The document describes a more complex mechanism that is employed ahead of time. There are obvious benefits to this approach, but it might also be viable to apply the method after deriving location information. From my perspective, describing the method from the perspective of the initial request would also flow better. You then describe the assembly of the wide area filter/mask as an optimisation. By all means characterise the optimisation as important or even necessary. [RLB: That's a really good idea. I've re-factored the requirements and filtering sections and added a quick section on single-point filtering. ] It's unclear to me how two regions defined using civic addresses can be intersected. For that matter, I'm not sure that I know how to express a civic address region succinctly, but that's a LoST problem. I don't think that the algorithm as described in 3.2.2 is implementable. [RLB: It is implementable *iff* one has a mechanism for intersecting civic boundaries. Which is jurisdiction-specific, as noted.] On discussion of emergency and non-emergency services, I think that one point needs to be made clearer up front. The location reference is provided so that authorized services can retrieve location information suitable to their needs. This document assumes that emergency services will always be authorized. That's probably an assumption worth stating. Following up on non-emergency, there is a suggestion that there could be another protocol for discovering what the authorization policy is for a given location reference. I'd prefer to see that this be left unstated. In the cases we're talking about, this is probably something that goes with the standard terms of service agreement between provider and their customers; I see little point in implying that there is a need for a protocol for this interaction. Also remove the unprovable statement: "Non-emergency LBSs will generally require more precise information than is required for emergency call routing." [RLB: Added a paragraph discussing authorization, with a reference to draft-barnes-policy-uri as a way for clients to find out about authorization policy. Changed "will generally" to "may" in the problem sentence.] In the security section you talk about repeated randomization. That's the subject of a note in . There is a trade-off between using a fixed offset, which might be revealed when the location changes, and a randomized offset, which might reveal the original area if repeated requests are made while the target is stationary. [RLB: That's true, but all the fuzzing in this document is by reference to draft-ietf-geopriv-policy. Do you think there's a need for text in this document?] Purely editorial "precise" isn't a terrible word, but it might be prudent to make it clear what you are talking about. Where you talk about "precise enough" or "precise information", you are actually referring to location information that has a region of uncertainty that is entirely contained with a region of interest (the service boundary). [RLB: That is exactly what I intended. Added text and an informative reference to the Terminology section] Section 3 mentions two, but lists three. s/course/coarse/ in one place s/servuce/service/g [RLB: Think these are fixed now] Section 3.2.1 is quite difficult to read on the first pass. Yes, it is succinct and correct, but it does suffer a little from being a little too terse. URI and URN are easily confused, so might I suggest that each is prefaced accordingly to distinguish them: "mapped/ resulting URI" and "service URN" might be easier to understand. Expanding the algorithm a little might help readability as well. Also, you mention iteration through the set of URI tuples (hypen or no- hypen) but don't mention that you are computing the intersection of the service regions that correspond to each URI in the tuple. Initially, it was confusing because my natural inclination was to think of the URI and service region as the tuple. [RLB: Think these should be overcome by revised description of the algorithm] From hannu.hietalahti@nokia.com Mon Aug 16 00:38:53 2010 Return-Path: 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 838083A696E for ; Mon, 16 Aug 2010 00:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jdLqUovZV8L2 for ; Mon, 16 Aug 2010 00:38:51 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C98293A68B8 for ; Mon, 16 Aug 2010 00:38:51 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7G7dIsA004398; Mon, 16 Aug 2010 02:39:22 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 10:38:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 10:38:49 +0300 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.108]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 16 Aug 2010 09:38:45 +0200 From: To: , , Date: Mon, 16 Aug 2010 09:38:44 +0200 Thread-Topic: [Ecrit] New Work Thread-Index: Acs73TmemVIx8794R2eMOVJvHhSqrwAl2cywACeZ+4A= Message-ID: <5BAF85033CB5F3439C4DE153165522B1020A421219@NOK-EUMSG-06.mgdnok.nokia.com> References: <4C66DE23.7000001@gmx.net> <61CAF342FE1EE34EAC8FB19B765914000E6FB28F@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB28F@SABRE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Aug 2010 07:38:49.0666 (UTC) FILETIME=[1128EA20:01CB3D16] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 07:38:53 -0000 Dear all, thanks for sharing the time estimates. This is a very useful discussion for= those who are dependent on IETF work! 3GPP is committed to use IETF based solution for callback if one exists. Si= nce regulatory requirements to support callback do exist on some markets, w= e never removed the requirement from our requirement specifications but 3GP= P TS 22.101 in its clause 10.1.3 says that callback must be supported if (= =3Das soon as) there is means to recognise a call as being a callback from = PSAP. This requirement for marking of callback is the main thing 3GPP needs from = the protocol solution. The time line for 3GPP Rel-10 aims at freezing in March 2011 and if callbac= k draft is completed a year later, then it will unfortunately miss the time= window for Rel-10. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext Patel, Milan >Sent: 15 August, 2010 15:25 >To: Hannes Tschofenig; Marc Linsner >Cc: ecrit >Subject: Re: [Ecrit] New Work > >Hi Marc, Richard & Roger, > >I will continue to work on the Call Back draft.=20 >Best regards, >Milan > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of Hannes Tschofenig >Sent: Saturday, August 14, 2010 7:19 PM >To: Marc Linsner >Cc: 'ecrit' >Subject: Re: [Ecrit] New Work > >Hi Marc, Richard, Roger, > >I am willing to work on the documents. The milestones are seem to be a=20 >good estimate. > >Ciao >Hannes > >On 8/13/2010 5:08 PM, Marc Linsner wrote: >> We recently asked for any objections to taking on the following >documents as >> workgroup items. We have consensus to take this work on, now we have >to >> commit to a realistic timeframe for completion. We're suggesting the >> following and would like your comments to include: >> >> 1) Are willing to work/contribute on the document? >> 2) Are willing to commit to the timeframe shown? >> >> The chairs commit to hosting virtual interim meetings at intervals >necessary >> to meet the timeframes. >> >> Mar 2011 - draft-rosen-ecrit-additional-data >> Apr 2011 - draft-rosen-ecrit-data-only-ea >> Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access >> Jan 2012 - draft-tschofenig-ecrit-trustworthy-location >> Mar 2012 - draft-schulzrinne-ecrit-psap-callback >> >> We realize the timeframes appear to out there but past experience >tells us >> to be conservative. There's no penalty for getting them done early. >> >> We MUST have commitment to work on these before the ADs will give us >the >> milestones. >> >> Please send your comments including which drafts you are willing to >work on >> by COB Friday, August 20, 2010. >> >> Thanks, >> >> -Marc, Richard, Roger- >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> =20 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > > >=20 >=20 >=20 >Milan Patel=20 >Consultant >InterDigital Communications, LLC > > >Tel.: +44 7917 678 250 >Fax:=20 >Email: Milan.Patel@InterDigital.com >http://www.InterDigital.com > > >This e-mail is intended only for the use of the individual or=20 >entity to which it is addressed, and may contain information=20 >that is privileged, confidential and/or otherwise protected=20 >from disclosure to anyone other than its intended recipient.=20 >Unintended transmission shall not constitute waiver of any=20 >privilege or confidentiality obligation. If you received this=20 >communication in error, please do not review, copy or=20 >distribute it, notify me immediately by email, and delete the=20 >original message and any attachments. Unless expressly stated=20 >in this e-mail, nothing in this message or any attachment=20 >should be construed as a digital or electronic signature. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >= From Gabor.Bajko@nokia.com Mon Aug 16 18:21:50 2010 Return-Path: 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 4A57E3A65A5 for ; Mon, 16 Aug 2010 18:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NF3ep9mSmOeB for ; Mon, 16 Aug 2010 18:21:49 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E82D13A6835 for ; Mon, 16 Aug 2010 18:21:48 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7H1MLUJ019040 for ; Tue, 17 Aug 2010 04:22:22 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 04:22:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 04:21:56 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 17 Aug 2010 03:21:56 +0200 From: To: Date: Tue, 17 Aug 2010 03:21:54 +0200 Thread-Topic: New Work Thread-Index: Acs68QVDxuTLI2AWyUWKBecVx0X0LQCq8N2gAANqG9A= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Aug 2010 01:21:56.0831 (UTC) FILETIME=[9545DEF0:01CB3DAA] X-Nokia-AV: Clean Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 01:21:50 -0000 I am willing to work on draft-schulzrinne-ecrit-unauthenticated-access. The= deadline seems realistic to me. - gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of e= xt Marc Linsner Sent: Friday, August 13, 2010 7:09 AM To: 'ecrit' Subject: [Ecrit] New Work We recently asked for any objections to taking on the following documents a= s workgroup items. We have consensus to take this work on, now we have to commit to a realistic timeframe for completion. We're suggesting the following and would like your comments to include: 1) Are willing to work/contribute on the document? 2) Are willing to commit to the timeframe shown? The chairs commit to hosting virtual interim meetings at intervals necessar= y to meet the timeframes. Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - draft-rosen-ecrit-data-only-ea Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access Jan 2012 - draft-tschofenig-ecrit-trustworthy-location Mar 2012 - draft-schulzrinne-ecrit-psap-callback We realize the timeframes appear to out there but past experience tells us to be conservative. There's no penalty for getting them done early. We MUST have commitment to work on these before the ADs will give us the milestones. Please send your comments including which drafts you are willing to work on by COB Friday, August 20, 2010. Thanks, -Marc, Richard, Roger- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From dirk.kroeselberg@nsn.com Tue Aug 17 05:31:25 2010 Return-Path: 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 58BD53A6953 for ; Tue, 17 Aug 2010 05:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, 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 RKXJQBI-uuzG for ; Tue, 17 Aug 2010 05:31:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D16023A694A for ; Tue, 17 Aug 2010 05:31:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7HCVp5S020563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Aug 2010 14:31:51 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7HCVpGQ000976 for ; Tue, 17 Aug 2010 14:31:51 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 14:31:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Aug 2010 14:31:49 +0200 Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF6702E6220E@DEMUEXC030.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New Work Thread-Index: Acs68QVDxuTLI2AWyUWKBecVx0X0LQCq8N2gAANqG9AAF2k04A== References: From: "Kroeselberg, Dirk (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Aug 2010 12:31:50.0477 (UTC) FILETIME=[2A8D87D0:01CB3E08] Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:31:25 -0000 the same is true for me. Deadline looks fine. Dirk -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Gabor.Bajko@nokia.com Sent: Tuesday, August 17, 2010 3:22 AM To: ecrit@ietf.org Subject: Re: [Ecrit] New Work I am willing to work on draft-schulzrinne-ecrit-unauthenticated-access. The deadline seems realistic to me. - gabor -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Marc Linsner Sent: Friday, August 13, 2010 7:09 AM To: 'ecrit' Subject: [Ecrit] New Work We recently asked for any objections to taking on the following documents as workgroup items. We have consensus to take this work on, now we have to commit to a realistic timeframe for completion. We're suggesting the following and would like your comments to include: 1) Are willing to work/contribute on the document? 2) Are willing to commit to the timeframe shown? The chairs commit to hosting virtual interim meetings at intervals necessary to meet the timeframes. Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - draft-rosen-ecrit-data-only-ea Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access Jan 2012 - draft-tschofenig-ecrit-trustworthy-location Mar 2012 - draft-schulzrinne-ecrit-psap-callback We realize the timeframes appear to out there but past experience tells us to be conservative. There's no penalty for getting them done early. We MUST have commitment to work on these before the ADs will give us the milestones. Please send your comments including which drafts you are willing to work on by COB Friday, August 20, 2010. 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 From mccann.stephen@gmail.com Tue Aug 17 08:04:51 2010 Return-Path: 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 15F4A3A697F for ; Tue, 17 Aug 2010 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 xhW7GpZRNwLW for ; Tue, 17 Aug 2010 08:04:50 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C909D3A687B for ; Tue, 17 Aug 2010 08:04:49 -0700 (PDT) Received: by bwz9 with SMTP id 9so2963530bwz.31 for ; Tue, 17 Aug 2010 08:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=itRYGqlyZ1cQr0STwP/mkk4Dcmt4HXp3jB971F5EV2Q=; b=tIVqbkHZksDaM9fExvJ/B8BlM0Xt3h9eYGQQvx+uSk0HY2/SjXlwGrP7Occ/imkK3R 3jy3SxE2CFpKPcDSr54B9APzo7McxE1HlWtstIdkOoE1W4kBEIAstrnuK6ujRqaCgLjT pHk404qjreJ13Z0F1Du8xJIdKcoDUzm3t/02o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JTyB0MMTq3RaRVKRL3BbUtALMEleKw4Be8b42/Fe/6gfs0sQ43uyBnR6pEJXd/qbg8 0k7U/jeuV0d+uve+UawmkgmdZMsvjhli8KSHnBzjqsYl7wtZw8PDA0q9f6OLLxN4bqv0 kU3tMaXvlu5hiQGi3lxu0OCF7dh/dL0PVBQkA= MIME-Version: 1.0 Received: by 10.204.60.5 with SMTP id n5mr4450977bkh.162.1282057524663; Tue, 17 Aug 2010 08:05:24 -0700 (PDT) Received: by 10.204.84.228 with HTTP; Tue, 17 Aug 2010 08:05:24 -0700 (PDT) In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF6702E6220E@DEMUEXC030.nsn-intra.net> References: <8C51C7A529FC9D49843ACF5AE2FFBF6702E6220E@DEMUEXC030.nsn-intra.net> Date: Tue, 17 Aug 2010 16:05:24 +0100 Message-ID: From: Stephen McCann To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:04:51 -0000 Mark, I'm also content to work on draft-schulzrinne-ecrit-unauthenticated-access within the specified deadlines. Kind regards Stephen On 17 August 2010 13:31, Kroeselberg, Dirk (NSN - DE/Munich) wrote: > the same is true for me. Deadline looks fine. > > Dirk > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Gabor.Bajko@nokia.com > Sent: Tuesday, August 17, 2010 3:22 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] New Work > > I am willing to work on draft-schulzrinne-ecrit-unauthenticated-access. > The deadline seems realistic to me. > > - gabor > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Marc Linsner > Sent: Friday, August 13, 2010 7:09 AM > To: 'ecrit' > Subject: [Ecrit] New Work > > We recently asked for any objections to taking on the following > documents as > workgroup items. =A0We have consensus to take this work on, now we have t= o > commit to a realistic timeframe for completion. =A0We're suggesting the > following and would like your comments to include: > > 1) Are willing to work/contribute on the document? > 2) Are willing to commit to the timeframe shown? > > The chairs commit to hosting virtual interim meetings at intervals > necessary > to meet the timeframes. > > Mar 2011 - draft-rosen-ecrit-additional-data > Apr 2011 - draft-rosen-ecrit-data-only-ea > Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access > Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > Mar 2012 - draft-schulzrinne-ecrit-psap-callback > > We realize the timeframes appear to out there but past experience tells > us > to be conservative. =A0There's no penalty for getting them done early. > > We MUST have commitment to work on these before the ADs will give us the > milestones. > > Please send your comments including which drafts you are willing to work > on > by COB Friday, August 20, 2010. > > 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Tue Aug 17 16:52:37 2010 Return-Path: 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 C00B03A690C for ; Tue, 17 Aug 2010 16:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 k0F4L+IgdnKP for ; Tue, 17 Aug 2010 16:52:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 09F373A683A for ; Tue, 17 Aug 2010 16:52:31 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,224,1280707200"; d="scan'208";a="234457153" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2010 23:53:06 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7HNr6VL021116; Tue, 17 Aug 2010 23:53:06 GMT Message-Id: <201008172353.o7HNr6VL021116@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Aug 2010 18:53:05 -0500 To: Marc Linsner , "'ecrit'" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 23:52:37 -0000 I will commit to work on the data-only ID, and possibly psap-callback. I think I share Hannu's concerns about psap-callback taking so long to get done. I mean, in 6 months this WG will have only 3 docs to work on, surely we can get this one done sooner if we try. Otherwise, the proposed milestones appear fine to me. James At 09:08 AM 8/13/2010, Marc Linsner wrote: >We recently asked for any objections to taking on the following documents as >workgroup items. We have consensus to take this work on, now we have to >commit to a realistic timeframe for completion. We're suggesting the >following and would like your comments to include: > >1) Are willing to work/contribute on the document? >2) Are willing to commit to the timeframe shown? > >The chairs commit to hosting virtual interim meetings at intervals necessary >to meet the timeframes. > >Mar 2011 - draft-rosen-ecrit-additional-data >Apr 2011 - draft-rosen-ecrit-data-only-ea >Dec 2011 - draft-schulzrinne-ecrit-unauthenticated-access >Jan 2012 - draft-tschofenig-ecrit-trustworthy-location >Mar 2012 - draft-schulzrinne-ecrit-psap-callback > >We realize the timeframes appear to out there but past experience tells us >to be conservative. There's no penalty for getting them done early. > >We MUST have commitment to work on these before the ADs will give us the >milestones. > >Please send your comments including which drafts you are willing to work on >by COB Friday, August 20, 2010. > >Thanks, > >-Marc, Richard, Roger- > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Tue Aug 17 17:20:46 2010 Return-Path: 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 266C83A67E7 for ; Tue, 17 Aug 2010 17:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.672 X-Spam-Level: X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, 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 CIhtveeYZT6z for ; Tue, 17 Aug 2010 17:20:45 -0700 (PDT) Received: from blu0-omc1-s28.blu0.hotmail.com (blu0-omc1-s28.blu0.hotmail.com [65.55.116.39]) by core3.amsl.com (Postfix) with ESMTP id ECD653A6765 for ; Tue, 17 Aug 2010 17:20:44 -0700 (PDT) Received: from BLU137-DS11 ([65.55.116.7]) by blu0-omc1-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 17:21:20 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'James M. Polk'" , "'Marc Linsner'" , "'ecrit'" References: <201008172353.o7HNr6VL021116@sj-core-3.cisco.com> In-Reply-To: <201008172353.o7HNr6VL021116@sj-core-3.cisco.com> Date: Tue, 17 Aug 2010 17:21:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKrAtEZ8AUUOCoPIzbGDAScf0u1AJTb3Cgk1Tg9wA= Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2010 00:21:20.0134 (UTC) FILETIME=[480BB260:01CB3E6B] Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 00:20:46 -0000 Getting PSAP callback "done" on schedule won't matter much if the resulting solution isn't implemented and deployed. So I wouldn't worry as much about IETF schedules as much as much as deployability. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, August 17, 2010 4:53 PM To: Marc Linsner; 'ecrit' Subject: Re: [Ecrit] New Work I will commit to work on the data-only ID, and possibly psap-callback. I think I share Hannu's concerns about psap-callback taking so long to get done. I mean, in 6 months this WG will have only 3 docs to work on, surely we can get this one done sooner if we try. Otherwise, the proposed milestones appear fine to me. James At 09:08 AM 8/13/2010, Marc Linsner wrote: >We recently asked for any objections to taking on the following >documents as workgroup items. We have consensus to take this work on, >now we have to commit to a realistic timeframe for completion. We're >suggesting the following and would like your comments to include: > >1) Are willing to work/contribute on the document? >2) Are willing to commit to the timeframe shown? > >The chairs commit to hosting virtual interim meetings at intervals >necessary to meet the timeframes. > >Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - >draft-rosen-ecrit-data-only-ea Dec 2011 - >draft-schulzrinne-ecrit-unauthenticated-access >Jan 2012 - draft-tschofenig-ecrit-trustworthy-location >Mar 2012 - draft-schulzrinne-ecrit-psap-callback > >We realize the timeframes appear to out there but past experience tells >us to be conservative. There's no penalty for getting them done early. > >We MUST have commitment to work on these before the ADs will give us >the milestones. > >Please send your comments including which drafts you are willing to >work on by COB Friday, August 20, 2010. > >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 From jmpolk@cisco.com Tue Aug 17 17:28:00 2010 Return-Path: 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 859803A67E7 for ; Tue, 17 Aug 2010 17:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.353 X-Spam-Level: X-Spam-Status: No, score=-110.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 A7vqaXTFnUnZ for ; Tue, 17 Aug 2010 17:27:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6E1CE3A635F for ; Tue, 17 Aug 2010 17:27:59 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,225,1280707200"; d="scan'208";a="353037735" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 18 Aug 2010 00:28:35 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7I0SYdO004822; Wed, 18 Aug 2010 00:28:34 GMT Message-Id: <201008180028.o7I0SYdO004822@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Aug 2010 19:28:33 -0500 To: "Bernard Aboba" , "'James M. Polk'" , "'Marc Linsner'" , "'ecrit'" From: "James M. Polk" In-Reply-To: References: <201008172353.o7HNr6VL021116@sj-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 00:28:00 -0000 fair but Hannu was most likely correct that if this takes as long as till spring `12, then it'll miss an entire window into 3GPP for deployment, which is (at least one of) the largest group(s) wanting this spec`d in the IETF, right? I'm not always a fan of 3GPP, but their requirements should (i.e., can) be a goal for us here, right? James At 07:21 PM 8/17/2010, Bernard Aboba wrote: >Getting PSAP callback "done" on schedule won't matter much if the resulting >solution isn't implemented and deployed. So I wouldn't worry as much about >IETF schedules as much as much as deployability. > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Tuesday, August 17, 2010 4:53 PM >To: Marc Linsner; 'ecrit' >Subject: Re: [Ecrit] New Work > >I will commit to work on the data-only ID, and possibly psap-callback. > >I think I share Hannu's concerns about psap-callback taking so long to get >done. I mean, in 6 months this WG will have only 3 docs to work on, surely >we can get this one done sooner if we try. > >Otherwise, the proposed milestones appear fine to me. > >James > >At 09:08 AM 8/13/2010, Marc Linsner wrote: > >We recently asked for any objections to taking on the following > >documents as workgroup items. We have consensus to take this work on, > >now we have to commit to a realistic timeframe for completion. We're > >suggesting the following and would like your comments to include: > > > >1) Are willing to work/contribute on the document? > >2) Are willing to commit to the timeframe shown? > > > >The chairs commit to hosting virtual interim meetings at intervals > >necessary to meet the timeframes. > > > >Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - > >draft-rosen-ecrit-data-only-ea Dec 2011 - > >draft-schulzrinne-ecrit-unauthenticated-access > >Jan 2012 - draft-tschofenig-ecrit-trustworthy-location > >Mar 2012 - draft-schulzrinne-ecrit-psap-callback > > > >We realize the timeframes appear to out there but past experience tells > >us to be conservative. There's no penalty for getting them done early. > > > >We MUST have commitment to work on these before the ADs will give us > >the milestones. > > > >Please send your comments including which drafts you are willing to > >work on by COB Friday, August 20, 2010. > > > >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 From Martin.Thomson@andrew.com Tue Aug 17 19:59:11 2010 Return-Path: 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 86D943A6800 for ; Tue, 17 Aug 2010 19:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599] 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 3JjVIeTj7gEZ for ; Tue, 17 Aug 2010 19:59:10 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 7C58C3A65A5 for ; Tue, 17 Aug 2010 19:59:10 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:19904 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S394786Ab0HRC7p (ORCPT ); Tue, 17 Aug 2010 21:59:45 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 17 Aug 2010 21:59:45 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 18 Aug 2010 10:59:43 +0800 From: "Thomson, Martin" To: Marc Linsner , 'ecrit' Date: Wed, 18 Aug 2010 11:02:04 +0800 Thread-Topic: New Work Thread-Index: Acs68QVDxuTLI2AWyUWKBecVx0X0LQDkFzrg Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35ABD7@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 02:59:11 -0000 SSBhbSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGNhbGxiYWNrIGFuZCB0cnVzdHdvcnRo eSBpdGVtcy4gIEkgY2FuIGNvbnRyaWJ1dGUgdG8gb3RoZXIgaXRlbXMgb24gYW4gYWRob2MgYmFz aXMuICBJIGludGVuZCB0byBhdCBsZWFzdCBwcm92aWRlIHJldmlld3MgZm9yIGFsbCBvZiB0aGUg d29yay4NCg0KVGhlIHRpbWVmcmFtZXMgc2VlbSBvcHRpbWlzdGljLCBidXQgdGhhdCdzIE9LLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFy YyBMaW5zbmVyDQo+IFNlbnQ6IFNhdHVyZGF5LCAxNCBBdWd1c3QgMjAxMCAxMjowOSBBTQ0KPiBU bzogJ2Vjcml0Jw0KPiBTdWJqZWN0OiBbRWNyaXRdIE5ldyBXb3JrDQo+IA0KPiBXZSByZWNlbnRs eSBhc2tlZCBmb3IgYW55IG9iamVjdGlvbnMgdG8gdGFraW5nIG9uIHRoZSBmb2xsb3dpbmcNCj4g ZG9jdW1lbnRzIGFzDQo+IHdvcmtncm91cCBpdGVtcy4gIFdlIGhhdmUgY29uc2Vuc3VzIHRvIHRh a2UgdGhpcyB3b3JrIG9uLCBub3cgd2UgaGF2ZQ0KPiB0bw0KPiBjb21taXQgdG8gYSByZWFsaXN0 aWMgdGltZWZyYW1lIGZvciBjb21wbGV0aW9uLiAgV2UncmUgc3VnZ2VzdGluZyB0aGUNCj4gZm9s bG93aW5nIGFuZCB3b3VsZCBsaWtlIHlvdXIgY29tbWVudHMgdG8gaW5jbHVkZToNCj4gDQo+IDEp IEFyZSB3aWxsaW5nIHRvIHdvcmsvY29udHJpYnV0ZSBvbiB0aGUgZG9jdW1lbnQ/DQo+IDIpIEFy ZSB3aWxsaW5nIHRvIGNvbW1pdCB0byB0aGUgdGltZWZyYW1lIHNob3duPw0KPiANCj4gVGhlIGNo YWlycyBjb21taXQgdG8gaG9zdGluZyB2aXJ0dWFsIGludGVyaW0gbWVldGluZ3MgYXQgaW50ZXJ2 YWxzDQo+IG5lY2Vzc2FyeQ0KPiB0byBtZWV0IHRoZSB0aW1lZnJhbWVzLg0KPiANCj4gTWFyIDIw MTEgLSBkcmFmdC1yb3Nlbi1lY3JpdC1hZGRpdGlvbmFsLWRhdGENCj4gQXByIDIwMTEgLSBkcmFm dC1yb3Nlbi1lY3JpdC1kYXRhLW9ubHktZWENCj4gRGVjIDIwMTEgLSBkcmFmdC1zY2h1bHpyaW5u ZS1lY3JpdC11bmF1dGhlbnRpY2F0ZWQtYWNjZXNzDQo+IEphbiAyMDEyIC0gZHJhZnQtdHNjaG9m ZW5pZy1lY3JpdC10cnVzdHdvcnRoeS1sb2NhdGlvbg0KPiBNYXIgMjAxMiAtIGRyYWZ0LXNjaHVs enJpbm5lLWVjcml0LXBzYXAtY2FsbGJhY2sNCj4gDQo+IFdlIHJlYWxpemUgdGhlIHRpbWVmcmFt ZXMgYXBwZWFyIHRvIG91dCB0aGVyZSBidXQgcGFzdCBleHBlcmllbmNlIHRlbGxzDQo+IHVzDQo+ IHRvIGJlIGNvbnNlcnZhdGl2ZS4gIFRoZXJlJ3Mgbm8gcGVuYWx0eSBmb3IgZ2V0dGluZyB0aGVt IGRvbmUgZWFybHkuDQo+IA0KPiBXZSBNVVNUIGhhdmUgY29tbWl0bWVudCB0byB3b3JrIG9uIHRo ZXNlIGJlZm9yZSB0aGUgQURzIHdpbGwgZ2l2ZSB1cw0KPiB0aGUNCj4gbWlsZXN0b25lcy4NCj4g DQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgaW5jbHVkaW5nIHdoaWNoIGRyYWZ0cyB5b3Ug YXJlIHdpbGxpbmcgdG8NCj4gd29yayBvbg0KPiBieSBDT0IgRnJpZGF5LCBBdWd1c3QgMjAsIDIw MTAuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtTWFyYywgUmljaGFyZCwgUm9nZXItDQo+IA0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo= From Martin.Thomson@andrew.com Tue Aug 17 20:22:07 2010 Return-Path: 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 A9B553A67EC for ; Tue, 17 Aug 2010 20:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599] 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 I1OTWw6e7u5V for ; Tue, 17 Aug 2010 20:22:06 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 1E6FA3A65A5 for ; Tue, 17 Aug 2010 20:22:04 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:62833 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S30621400Ab0HRDWj (ORCPT ); Tue, 17 Aug 2010 22:22:39 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 17 Aug 2010 22:22:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 18 Aug 2010 11:22:35 +0800 From: "Thomson, Martin" To: 'ecrit' Date: Wed, 18 Aug 2010 11:24:53 +0800 Thread-Topic: Thoughts on -rosen-ecrit-additional-data Thread-Index: Acs+hOxww8KnIqDeRd25dXIbow8IHQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {90564AA5-44DC-49FF-835E-1895FC4D5171} x-cr-hashedpuzzle: AOlA A9nt BMjI CZub CqIr DvCy EhXd Fti1 F9iO GFAL GXYX GlTT IBLf JxGP KLLg KvsE; 1; ZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {90564AA5-44DC-49FF-835E-1895FC4D5171}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Wed, 18 Aug 2010 03:24:53 GMT; VABoAG8AdQBnAGgAdABzACAAbwBuACAALQByAG8AcwBlAG4ALQBlAGMAcgBpAHQALQBhAGQAZABpAHQAaQBvAG4AYQBsAC0AZABhAHQAYQA= acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 03:22:07 -0000 V2hhdCB0aGlzIGRyYWZ0IGF0dGVtcHRzIHRvIGRvIGlzIGNvcnJhbCBhIG51bWJlciBvZiBkaWZm ZXJlbnQgLSBhbGJlaXQgc3VwZXJmaWNpYWxseSByZWxhdGVkIC0gYmVhc3RzIGludG8gdGhlIHNh bWUgcGVuLiAgSXQgdGhlbiBhcHBsaWVzIGEgdmVyeSBnZW5lcmljIGxhYmVsIGFuZCBsZWF2ZXMg aXQgYXQgdGhhdC4NCg0KWW91IHNlZSwgdGhlcmUncyBhbHJlYWR5IGEgbWVjaGFuaXNtIGZvciB0 aGUgZ2VuZXJpYyBidWNrZXQ6IG11bHRpcGFydC9taXhlZC4NCg0KV2hhdCBpZiB0aGlzIGRvY3Vt ZW50IGluc3RlYWQgY29uY2VudHJhdGVkIG9uIGlkZW50aWZ5aW5nIHRoZSBkaWZmZXJlbnQgdHlw ZXMgb2YgY2FsbCBpbmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGJlIHJlbGV2YW50IHRvIGFuIGVtZXJn ZW5jeSBjYWxsLCBkZWZpbmVkIGEgcHVycG9zZSBsYWJlbCBmb3IgZWFjaCwgYW5kIGRlZmluZWQg Zm9ybWF0cyBmb3IgdGhvc2UgdGhhdCBkb24ndCBhbHJlYWR5IGhhdmUgZm9ybWF0cyAodkNhcmQg ZG9lcyBuaWNlbHksIHRoYW5rcykuICBOZXcgZm9ybWF0cyBuZWVkIG5ldyBNSU1FIHR5cGVzIHRv by4NCg0KVGhlIGdlbmVyaWMgY29udGFpbmVyIGlkZWEgaXMgbm90IHJlYWxseSBuZWNlc3Nhcnks IHBhcnRpY3VsYXJseSB3aGVuIGl0IGlzIGNsZWFyIHRoYXQgdGhpcyBpbmZvcm1hdGlvbiBjYW4g Y29tZSBmcm9tIG11bHRpcGxlIHNvdXJjZXMuDQoNCi0tTWFydGluDQoNCnAucy4gIEknbGwgcG9p bnQgb3V0IHRoZSBzdHJvbmcgc2ltaWxhcml0aWVzIGJldHdlZW4gQ2FsbC1JbmZvIGFuZCB0aGUg SFRUUCBMaW5rIGhlYWRlciBbMV0sIHN1YnN0aXR1dGluZyAicmVsIiBmb3IgInB1cnBvc2UiLiAg VGhlcmUgaXMgYSBsb3Qgb2Yga25vd2xlZGdlIGFuZCBleHBlcmllbmNlIGJ1aWx0IGludG8gdGhh dCBzcGVjaWZpY2F0aW9uIHRoYXQgY291bGQgYmUgcmVsaWVkIHVwb24gaGVyZS4NCg0KWzFdIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5vdHRpbmdoYW0taHR0cC1saW5rLWhlYWRl cg0KDQoNCg0K From hannu.hietalahti@nokia.com Wed Aug 18 00:19:45 2010 Return-Path: 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 438033A6A24 for ; Wed, 18 Aug 2010 00:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 C-CIUPj-3PZc for ; Wed, 18 Aug 2010 00:19:44 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EEC0B3A681A for ; Wed, 18 Aug 2010 00:19:43 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7I7JRfN006800; Wed, 18 Aug 2010 02:19:50 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 10:19:45 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 10:19:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 10:19:39 +0300 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.108]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 18 Aug 2010 09:19:38 +0200 From: To: , , , Date: Wed, 18 Aug 2010 09:19:36 +0200 Thread-Topic: [Ecrit] New Work Thread-Index: Acs+bE/pQG9pSu/aTCmL1QEN76QbrAANYvsw Message-ID: <5BAF85033CB5F3439C4DE153165522B1020A486933@NOK-EUMSG-06.mgdnok.nokia.com> References: <201008172353.o7HNr6VL021116@sj-core-3.cisco.com> <201008180028.o7I0SYdO004822@sj-core-3.cisco.com> In-Reply-To: <201008180028.o7I0SYdO004822@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Aug 2010 07:19:39.0373 (UTC) FILETIME=[B85BA1D0:01CB3EA5] X-Nokia-AV: Clean Subject: Re: [Ecrit] New Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:19:45 -0000 Hi James, and sorry to corner you to a 3GPP-friendly situation ;-) In psap-callback (and sos-parameter) 3GPP needs an indication of callback (= and special registration) to trigger specific processing of the request. 3GPP would prefer to use generic IETF based mechanisms for such indications= , as is already shown by us postponing the question to wait for IETF soluti= on, even at the cost of leaving this critical part out of Rel-9 which is th= e first release expected to contain a full emergency call support. Regulatory emergency call requirements and EPC/LTE deployments make the pro= tocol solution for callback and emergency registration more urgent than the= y used to be in specification drafting phase. Thanks Martin for volunteering to work on callback! BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of ext James M. Polk >Sent: 18 August, 2010 03:29 >To: Bernard Aboba; 'James M. Polk'; 'Marc Linsner'; 'ecrit' >Subject: Re: [Ecrit] New Work > >fair > >but Hannu was most likely correct that if this takes as long as till=20 >spring `12, then it'll miss an entire window into 3GPP for=20 >deployment, which is (at least one of) the largest group(s) wanting=20 >this spec`d in the IETF, right? > >I'm not always a fan of 3GPP, but their requirements should (i.e.,=20 >can) be a goal for us here, right? > >James > >At 07:21 PM 8/17/2010, Bernard Aboba wrote: >>Getting PSAP callback "done" on schedule won't matter much=20 >if the resulting >>solution isn't implemented and deployed. So I wouldn't=20 >worry as much about >>IETF schedules as much as much as deployability. >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >On Behalf Of >>James M. Polk >>Sent: Tuesday, August 17, 2010 4:53 PM >>To: Marc Linsner; 'ecrit' >>Subject: Re: [Ecrit] New Work >> >>I will commit to work on the data-only ID, and possibly psap-callback. >> >>I think I share Hannu's concerns about psap-callback taking=20 >so long to get >>done. I mean, in 6 months this WG will have only 3 docs to=20 >work on, surely >>we can get this one done sooner if we try. >> >>Otherwise, the proposed milestones appear fine to me. >> >>James >> >>At 09:08 AM 8/13/2010, Marc Linsner wrote: >> >We recently asked for any objections to taking on the following >> >documents as workgroup items. We have consensus to take=20 >this work on, >> >now we have to commit to a realistic timeframe for=20 >completion. We're >> >suggesting the following and would like your comments to include: >> > >> >1) Are willing to work/contribute on the document? >> >2) Are willing to commit to the timeframe shown? >> > >> >The chairs commit to hosting virtual interim meetings at intervals >> >necessary to meet the timeframes. >> > >> >Mar 2011 - draft-rosen-ecrit-additional-data Apr 2011 - >> >draft-rosen-ecrit-data-only-ea Dec 2011 - >> >draft-schulzrinne-ecrit-unauthenticated-access >> >Jan 2012 - draft-tschofenig-ecrit-trustworthy-location >> >Mar 2012 - draft-schulzrinne-ecrit-psap-callback >> > >> >We realize the timeframes appear to out there but past=20 >experience tells >> >us to be conservative. There's no penalty for getting them=20 >done early. >> > >> >We MUST have commitment to work on these before the ADs will give us >> >the milestones. >> > >> >Please send your comments including which drafts you are willing to >> >work on by COB Friday, August 20, 2010. >> > >> >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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >= From hannes.tschofenig@nsn.com Wed Aug 18 01:07:12 2010 Return-Path: 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 698123A6A28 for ; Wed, 18 Aug 2010 01:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 EmnVq4wwPEXK for ; Wed, 18 Aug 2010 01:07:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id CC9EF3A67A5 for ; Wed, 18 Aug 2010 01:07:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7I87efd022148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Aug 2010 10:07:40 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7I87eXb032666; Wed, 18 Aug 2010 10:07:40 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 10:07:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Aug 2010 11:07:38 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Thoughts on -rosen-ecrit-additional-data Thread-Index: Acs+hOxww8KnIqDeRd25dXIbow8IHQAJzsFw References: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Thomson, Martin" , "ecrit" X-OriginalArrivalTime: 18 Aug 2010 08:07:40.0283 (UTC) FILETIME=[6D839CB0:01CB3EAC] Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:07:12 -0000 This would be worth a try.=20 This would leave us with a number of=20 * defined MIME types (for the data that is exchanged),=20 * a description about the security and privacy mechanisms, and=20 * a description of how the information is conveyed (reference within Call-Info). Right?=20 Ciao Hannes=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of ext Thomson, Martin > Sent: Wednesday, August 18, 2010 6:25 AM > To: 'ecrit' > Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data >=20 > What this draft attempts to do is corral a number of=20 > different - albeit superficially related - beasts into the=20 > same pen. It then applies a very generic label and leaves it at that. >=20 > You see, there's already a mechanism for the generic bucket:=20 > multipart/mixed. >=20 > What if this document instead concentrated on identifying the=20 > different types of call information that might be relevant to=20 > an emergency call, defined a purpose label for each, and=20 > defined formats for those that don't already have formats=20 > (vCard does nicely, thanks). New formats need new MIME types too. >=20 > The generic container idea is not really necessary,=20 > particularly when it is clear that this information can come=20 > from multiple sources. >=20 > --Martin >=20 > p.s. I'll point out the strong similarities between=20 > Call-Info and the HTTP Link header [1], substituting "rel"=20 > for "purpose". There is a lot of knowledge and experience=20 > built into that specification that could be relied upon here. >=20 > [1] http://tools.ietf.org/html/draft-nottingham-http-link-header >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Wed Aug 18 05:56:34 2010 Return-Path: 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 4C2AF3A6889 for ; Wed, 18 Aug 2010 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 iZHjyLCrbH69 for ; Wed, 18 Aug 2010 05:56:33 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 419933A693E for ; Wed, 18 Aug 2010 05:56:33 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.48]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OliCT-0002xx-5z; Wed, 18 Aug 2010 07:57:02 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> Date: Wed, 18 Aug 2010 08:57:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0F928C89-0594-4141-8F31-2807B3E4730B@brianrosen.net> References: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: ecrit , "ext Thomson, Martin" Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 12:56:34 -0000 I'm certainly not worried about the decoration around the data, so = multipart/mime is fine with me. I care about two aspects: 1. There is a URI in a SIP message (Call-Info header) that points to the = data structure, retrievable with a simple https GET 2. There is a precise, interoperable definition of each of the allowed = components I don't care how the components or the outer envelope is structured. I would point out that in the proposed structure, there are two vCard = thingies - contact information on the source of the data, and = "subscriber" contact information. Of course one could have two vCards, = each in a part, but something has to mark which one is which. Brian On Aug 18, 2010, at 4:07 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > This would be worth a try.=20 >=20 > This would leave us with a number of=20 > * defined MIME types (for the data that is exchanged),=20 > * a description about the security and privacy mechanisms, and=20 > * a description of how the information is conveyed (reference within > Call-Info). >=20 > Right?=20 >=20 > Ciao > Hannes=20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >> On Behalf Of ext Thomson, Martin >> Sent: Wednesday, August 18, 2010 6:25 AM >> To: 'ecrit' >> Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data >>=20 >> What this draft attempts to do is corral a number of=20 >> different - albeit superficially related - beasts into the=20 >> same pen. It then applies a very generic label and leaves it at = that. >>=20 >> You see, there's already a mechanism for the generic bucket:=20 >> multipart/mixed. >>=20 >> What if this document instead concentrated on identifying the=20 >> different types of call information that might be relevant to=20 >> an emergency call, defined a purpose label for each, and=20 >> defined formats for those that don't already have formats=20 >> (vCard does nicely, thanks). New formats need new MIME types too. >>=20 >> The generic container idea is not really necessary,=20 >> particularly when it is clear that this information can come=20 >> from multiple sources. >>=20 >> --Martin >>=20 >> p.s. I'll point out the strong similarities between=20 >> Call-Info and the HTTP Link header [1], substituting "rel"=20 >> for "purpose". There is a lot of knowledge and experience=20 >> built into that specification that could be relied upon here. >>=20 >> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Wed Aug 18 12:33:04 2010 Return-Path: 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 D49693A67D4; Wed, 18 Aug 2010 12:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 lTTSLfMyay51; Wed, 18 Aug 2010 12:33:00 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id F08983A6A20; Wed, 18 Aug 2010 12:32:56 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 18 Aug 2010 12:33:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Aug 2010 12:33:31 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657513D6C051@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <44665C62-58C6-4492-81C5-6AC2209E07DB@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] Minutes for IETF78 Thread-Index: Acs/BWXXRAJxprfpQwmh9zaofORsCQABednA References: <44665C62-58C6-4492-81C5-6AC2209E07DB@nostrum.com> From: "Roger Marshall" To: Cc: ecrit-chairs@ietf.org Subject: Re: [Ecrit] [RAI] Minutes for IETF78 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:33:05 -0000 The ECRIT meeting minutes for IETF78-Maastricht have been posted on the Meeting materials page (https://datatracker.ietf.org/meeting/78/materials.html). =20 Please let me know within the next 5 days if there are any reasons for making revisions. -roger marshall rmarshall@telecomsys.com ECRIT secretary CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From James.Winterbottom@andrew.com Wed Aug 18 13:22:24 2010 Return-Path: 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 75F643A69A5 for ; Wed, 18 Aug 2010 13:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599] 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 Sp6tt4T8yBXa for ; Wed, 18 Aug 2010 13:22:23 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 5101E3A67FB for ; Wed, 18 Aug 2010 13:22:23 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:20031 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S398949Ab0HRUW6 convert rfc822-to-8bit (ORCPT ); Wed, 18 Aug 2010 15:22:58 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 18 Aug 2010 15:22:57 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 19 Aug 2010 04:22:55 +0800 From: "Winterbottom, James" To: Brian Rosen , "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Thu, 19 Aug 2010 04:22:53 +0800 Thread-Topic: [Ecrit] Thoughts on -rosen-ecrit-additional-data Thread-Index: Acs+1ODj4lFfIOl9R5KwxbZWaX7hSgAPedKw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7ED8F6@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> <0F928C89-0594-4141-8F31-2807B3E4730B@brianrosen.net> In-Reply-To: <0F928C89-0594-4141-8F31-2807B3E4730B@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: ecrit , "Thomson, Martin" Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:22:24 -0000 My concern a bit is that we are already finding some things in the access provider information working group that don't logically fit into a vCARD, and won't, necessarily, be conveyed in a SIP header. This makes the current set of proposals rather ugly and bordering on unworkable. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, 18 August 2010 10:57 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: ecrit; Thomson, Martin > Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data > > I'm certainly not worried about the decoration around the data, so > multipart/mime is fine with me. > > I care about two aspects: > 1. There is a URI in a SIP message (Call-Info header) that points to the > data structure, retrievable with a simple https GET > 2. There is a precise, interoperable definition of each of the allowed > components > > I don't care how the components or the outer envelope is structured. > > I would point out that in the proposed structure, there are two vCard > thingies - contact information on the source of the data, and "subscriber" > contact information. Of course one could have two vCards, each in a part, > but something has to mark which one is which. > > Brian > > > > On Aug 18, 2010, at 4:07 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > This would be worth a try. > > > > This would leave us with a number of > > * defined MIME types (for the data that is exchanged), > > * a description about the security and privacy mechanisms, and > > * a description of how the information is conveyed (reference within > > Call-Info). > > > > Right? > > > > Ciao > > Hannes > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of ext Thomson, Martin > >> Sent: Wednesday, August 18, 2010 6:25 AM > >> To: 'ecrit' > >> Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data > >> > >> What this draft attempts to do is corral a number of > >> different - albeit superficially related - beasts into the > >> same pen. It then applies a very generic label and leaves it at that. > >> > >> You see, there's already a mechanism for the generic bucket: > >> multipart/mixed. > >> > >> What if this document instead concentrated on identifying the > >> different types of call information that might be relevant to > >> an emergency call, defined a purpose label for each, and > >> defined formats for those that don't already have formats > >> (vCard does nicely, thanks). New formats need new MIME types too. > >> > >> The generic container idea is not really necessary, > >> particularly when it is clear that this information can come > >> from multiple sources. > >> > >> --Martin > >> > >> p.s. I'll point out the strong similarities between > >> Call-Info and the HTTP Link header [1], substituting "rel" > >> for "purpose". There is a lot of knowledge and experience > >> built into that specification that could be relied upon here. > >> > >> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header > >> > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Aug 18 13:49:55 2010 Return-Path: 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 EC4ED3A6979 for ; Wed, 18 Aug 2010 13:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, 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 aKSzePac4PbT for ; Wed, 18 Aug 2010 13:49:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 62AC43A6405 for ; Wed, 18 Aug 2010 13:49:53 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.48]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OlpaW-0000Zs-IB; Wed, 18 Aug 2010 15:50:22 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120EB7ED8F6@SISPE7MB1.commscope.com> Date: Wed, 18 Aug 2010 16:50:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <473478BD-ECD5-4DB6-A607-4A2D9684C4C4@brianrosen.net> References: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> <0F928C89-0594-4141-8F31-2807B3E4730B@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880120EB7ED8F6@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ecrit , "Thomson, Martin" Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:49:56 -0000 The vCard is just for contact data. Other info would be in another = component, which if we did what Martin is suggesting would mean we = create a new mime type. Brian On Aug 18, 2010, at 4:22 PM, Winterbottom, James wrote: > My concern a bit is that we are already finding some things in the = access provider information working group that don't logically fit into = a vCARD, and won't, necessarily, be conveyed in a SIP header. This makes = the current set of proposals rather ugly and bordering on unworkable. >=20 > Cheers > James >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Brian Rosen >> Sent: Wednesday, 18 August 2010 10:57 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: ecrit; Thomson, Martin >> Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data >>=20 >> I'm certainly not worried about the decoration around the data, so >> multipart/mime is fine with me. >>=20 >> I care about two aspects: >> 1. There is a URI in a SIP message (Call-Info header) that points to = the >> data structure, retrievable with a simple https GET >> 2. There is a precise, interoperable definition of each of the = allowed >> components >>=20 >> I don't care how the components or the outer envelope is structured. >>=20 >> I would point out that in the proposed structure, there are two vCard >> thingies - contact information on the source of the data, and = "subscriber" >> contact information. Of course one could have two vCards, each in a = part, >> but something has to mark which one is which. >>=20 >> Brian >>=20 >>=20 >>=20 >> On Aug 18, 2010, at 4:07 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: >>=20 >>> This would be worth a try. >>>=20 >>> This would leave us with a number of >>> * defined MIME types (for the data that is exchanged), >>> * a description about the security and privacy mechanisms, and >>> * a description of how the information is conveyed (reference within >>> Call-Info). >>>=20 >>> Right? >>>=20 >>> Ciao >>> Hannes >>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of ext Thomson, Martin >>>> Sent: Wednesday, August 18, 2010 6:25 AM >>>> To: 'ecrit' >>>> Subject: [Ecrit] Thoughts on -rosen-ecrit-additional-data >>>>=20 >>>> What this draft attempts to do is corral a number of >>>> different - albeit superficially related - beasts into the >>>> same pen. It then applies a very generic label and leaves it at = that. >>>>=20 >>>> You see, there's already a mechanism for the generic bucket: >>>> multipart/mixed. >>>>=20 >>>> What if this document instead concentrated on identifying the >>>> different types of call information that might be relevant to >>>> an emergency call, defined a purpose label for each, and >>>> defined formats for those that don't already have formats >>>> (vCard does nicely, thanks). New formats need new MIME types too. >>>>=20 >>>> The generic container idea is not really necessary, >>>> particularly when it is clear that this information can come >>>> from multiple sources. >>>>=20 >>>> --Martin >>>>=20 >>>> p.s. I'll point out the strong similarities between >>>> Call-Info and the HTTP Link header [1], substituting "rel" >>>> for "purpose". There is a lot of knowledge and experience >>>> built into that specification that could be relied upon here. >>>>=20 >>>> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@andrew.com Wed Aug 18 15:45:36 2010 Return-Path: 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 CC2693A698D for ; Wed, 18 Aug 2010 15:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.029 X-Spam-Level: X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599] 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 vhEW3PcIzgqC for ; Wed, 18 Aug 2010 15:45:35 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id CB4503A6909 for ; Wed, 18 Aug 2010 15:45:35 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:18359 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S394480Ab0HRWqK (ORCPT ); Wed, 18 Aug 2010 17:46:10 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 18 Aug 2010 17:46:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 19 Aug 2010 06:46:06 +0800 From: "Thomson, Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ecrit Date: Thu, 19 Aug 2010 06:48:26 +0800 Thread-Topic: [Ecrit] Thoughts on -rosen-ecrit-additional-data Thread-Index: Acs+hOxww8KnIqDeRd25dXIbow8IHQAJzsFwAB7AvRA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35ACA4@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03ED35ABEC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502ED5613@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Ecrit] Thoughts on -rosen-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:45:36 -0000 VGhhdCdzIGFib3V0IHJpZ2h0LiAgVGhlcmUgYXJlIHByb2JhYmx5IHNvbWUgd3JpbmtsZXMgdG8g d29yayBvdXQsIGJ1dCB0aGF0IHdvdWxkIGJlIHRoZSBpZGVhLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28p DQo+IFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5 LCAxOCBBdWd1c3QgMjAxMCA2OjA4IFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IGVjcml0DQo+ IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFRob3VnaHRzIG9uIC1yb3Nlbi1lY3JpdC1hZGRpdGlvbmFs LWRhdGENCj4gDQo+IFRoaXMgd291bGQgYmUgd29ydGggYSB0cnkuDQo+IA0KPiBUaGlzIHdvdWxk IGxlYXZlIHVzIHdpdGggYSBudW1iZXIgb2YNCj4gKiBkZWZpbmVkIE1JTUUgdHlwZXMgKGZvciB0 aGUgZGF0YSB0aGF0IGlzIGV4Y2hhbmdlZCksDQo+ICogYSBkZXNjcmlwdGlvbiBhYm91dCB0aGUg c2VjdXJpdHkgYW5kIHByaXZhY3kgbWVjaGFuaXNtcywgYW5kDQo+ICogYSBkZXNjcmlwdGlvbiBv ZiBob3cgdGhlIGluZm9ybWF0aW9uIGlzIGNvbnZleWVkIChyZWZlcmVuY2Ugd2l0aGluDQo+IENh bGwtSW5mbykuDQo+IA0KPiBSaWdodD8NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4gT24gQmVoYWxmIE9mIGV4dCBU aG9tc29uLCBNYXJ0aW4NCj4gPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxOCwgMjAxMCA2OjI1 IEFNDQo+ID4gVG86ICdlY3JpdCcNCj4gPiBTdWJqZWN0OiBbRWNyaXRdIFRob3VnaHRzIG9uIC1y b3Nlbi1lY3JpdC1hZGRpdGlvbmFsLWRhdGENCj4gPg0KPiA+IFdoYXQgdGhpcyBkcmFmdCBhdHRl bXB0cyB0byBkbyBpcyBjb3JyYWwgYSBudW1iZXIgb2YNCj4gPiBkaWZmZXJlbnQgLSBhbGJlaXQg c3VwZXJmaWNpYWxseSByZWxhdGVkIC0gYmVhc3RzIGludG8gdGhlDQo+ID4gc2FtZSBwZW4uICBJ dCB0aGVuIGFwcGxpZXMgYSB2ZXJ5IGdlbmVyaWMgbGFiZWwgYW5kIGxlYXZlcyBpdCBhdA0KPiB0 aGF0Lg0KPiA+DQo+ID4gWW91IHNlZSwgdGhlcmUncyBhbHJlYWR5IGEgbWVjaGFuaXNtIGZvciB0 aGUgZ2VuZXJpYyBidWNrZXQ6DQo+ID4gbXVsdGlwYXJ0L21peGVkLg0KPiA+DQo+ID4gV2hhdCBp ZiB0aGlzIGRvY3VtZW50IGluc3RlYWQgY29uY2VudHJhdGVkIG9uIGlkZW50aWZ5aW5nIHRoZQ0K PiA+IGRpZmZlcmVudCB0eXBlcyBvZiBjYWxsIGluZm9ybWF0aW9uIHRoYXQgbWlnaHQgYmUgcmVs ZXZhbnQgdG8NCj4gPiBhbiBlbWVyZ2VuY3kgY2FsbCwgZGVmaW5lZCBhIHB1cnBvc2UgbGFiZWwg Zm9yIGVhY2gsIGFuZA0KPiA+IGRlZmluZWQgZm9ybWF0cyBmb3IgdGhvc2UgdGhhdCBkb24ndCBh bHJlYWR5IGhhdmUgZm9ybWF0cw0KPiA+ICh2Q2FyZCBkb2VzIG5pY2VseSwgdGhhbmtzKS4gIE5l dyBmb3JtYXRzIG5lZWQgbmV3IE1JTUUgdHlwZXMgdG9vLg0KPiA+DQo+ID4gVGhlIGdlbmVyaWMg Y29udGFpbmVyIGlkZWEgaXMgbm90IHJlYWxseSBuZWNlc3NhcnksDQo+ID4gcGFydGljdWxhcmx5 IHdoZW4gaXQgaXMgY2xlYXIgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGNhbiBjb21lDQo+ID4gZnJv bSBtdWx0aXBsZSBzb3VyY2VzLg0KPiA+DQo+ID4gLS1NYXJ0aW4NCj4gPg0KPiA+IHAucy4gIEkn bGwgcG9pbnQgb3V0IHRoZSBzdHJvbmcgc2ltaWxhcml0aWVzIGJldHdlZW4NCj4gPiBDYWxsLUlu Zm8gYW5kIHRoZSBIVFRQIExpbmsgaGVhZGVyIFsxXSwgc3Vic3RpdHV0aW5nICJyZWwiDQo+ID4g Zm9yICJwdXJwb3NlIi4gIFRoZXJlIGlzIGEgbG90IG9mIGtub3dsZWRnZSBhbmQgZXhwZXJpZW5j ZQ0KPiA+IGJ1aWx0IGludG8gdGhhdCBzcGVjaWZpY2F0aW9uIHRoYXQgY291bGQgYmUgcmVsaWVk IHVwb24gaGVyZS4NCj4gPg0KPiA+IFsxXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1ub3R0aW5naGFtLWh0dHAtbGluay1oZWFkZXINCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEVjcml0IG1haWxp bmcgbGlzdA0KPiA+IEVjcml0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KPiA+DQo= From rbarnes@bbn.com Fri Aug 20 09:26:04 2010 Return-Path: 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 286A13A6A8C for ; Fri, 20 Aug 2010 09:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 xKvhkFZgfFZ2 for ; Fri, 20 Aug 2010 09:26:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 43F0C3A6937 for ; Fri, 20 Aug 2010 09:26:02 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:53682) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmUQP-000KTn-Cw for ecrit@ietf.org; Fri, 20 Aug 2010 12:26:37 -0400 Message-Id: <85163B44-783D-42D2-BFC7-1C91B5E8E42C@bbn.com> From: "Richard L. Barnes" To: ecrit@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Aug 2010 12:26:37 -0400 X-Mailer: Apple Mail (2.936) Subject: [Ecrit] Patent on MMS to 9-1-1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:26:04 -0000 Not directly related to ECRIT, but might be of interest to some folks: From andreaf@cs.columbia.edu Mon Aug 23 15:10:04 2010 Return-Path: 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 07B1B3A6B20 for ; Mon, 23 Aug 2010 15:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 u4n5DY1pcTps for ; Mon, 23 Aug 2010 15:10:01 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 0F9323A684D for ; Mon, 23 Aug 2010 15:10:00 -0700 (PDT) Received: from irtdesk1.cs.columbia.edu (irtdesk1.cs.columbia.edu [128.59.22.127]) (user=agf2104 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o7NMAWWa025095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Aug 2010 18:10:33 -0400 (EDT) Message-ID: <4C72F1D8.8050904@cs.columbia.edu> Date: Mon, 23 Aug 2010 18:10:32 -0400 From: Andrea G Forte User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Subject: [Ecrit] New Version Notification for draft-forte-lost-extensions-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 22:10:04 -0000 Dear all, we have submitted a new version of the draft on LoST extensions for non-emergency services. As per previous discussion in the working group this draft has been submitted as an individual submission. We have incorporated the comments from some previous discussion on the mailing list. You can find the abstract below. We would like to know if there is anyone from the working group who strongly opposes to this draft. URL: https://datatracker.ietf.org/doc/draft-forte-lost-extensions/ Regards, -Andrea From br@brianrosen.net Tue Aug 24 09:33:15 2010 Return-Path: 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 75A573A6B78 for ; Tue, 24 Aug 2010 09:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 t1sTbup0SrCp for ; Tue, 24 Aug 2010 09:33:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 9AD833A6B8E for ; Tue, 24 Aug 2010 09:33:07 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.29]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OnwRL-0002nf-VB for ecrit@ietf.org; Tue, 24 Aug 2010 11:33:36 -0500 From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2010 12:33:35 -0400 Message-Id: <35BBAD48-1C67-411A-B904-E54B6EE29AF8@brianrosen.net> To: ecrit Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: [Ecrit] Validation of a missing element X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 16:33:15 -0000 Referring to RFC5222, Section 8.4.2, suppose you sent a civic without an = A1 record, but all of the other elements you sent were "valid" (whatever = that means with a missing A1). Do we agree that the validation response can contain A1 invalid, even = though the element wasn't in the location sent in the request? Suppose in a particular LoST database, there was a requirement to = validate down to BLD for at least some civic addresses. If the query = location was missing BLD, the response could have an invalid BLD, right? The text could have been more clear about this, but it seems clear to me = that we have to allow both of these. Brian From rbarnes@bbn.com Tue Aug 24 09:43:18 2010 Return-Path: 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 BC0993A6B86 for ; Tue, 24 Aug 2010 09:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 febUiUYWHyMq for ; Tue, 24 Aug 2010 09:43:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CC9803A6BA9 for ; Tue, 24 Aug 2010 09:40:40 -0700 (PDT) Received: from ros-dhcp192-1-51-64.bbn.com ([192.1.51.64]:58883) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OnwYe-000A8g-Ex; Tue, 24 Aug 2010 12:41:08 -0400 Message-Id: From: "Richard L. Barnes" To: Brian Rosen In-Reply-To: <35BBAD48-1C67-411A-B904-E54B6EE29AF8@brianrosen.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Aug 2010 12:41:07 -0400 References: <35BBAD48-1C67-411A-B904-E54B6EE29AF8@brianrosen.net> X-Mailer: Apple Mail (2.936) Cc: ecrit Subject: Re: [Ecrit] Validation of a missing element X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 16:43:18 -0000 That seems sensible to me, "null" being an incorrect value. Do you mean to suggest some action here? A modification to some document? An erratum? --Richard On Aug 24, 2010, at 12:33 PM, Brian Rosen wrote: > Referring to RFC5222, Section 8.4.2, suppose you sent a civic > without an A1 record, but all of the other elements you sent were > "valid" (whatever that means with a missing A1). > > Do we agree that the validation response can contain A1 invalid, > even though the element wasn't in the location sent in the request? > > Suppose in a particular LoST database, there was a requirement to > validate down to BLD for at least some civic addresses. If the > query location was missing BLD, the response could have an invalid > BLD, right? > > The text could have been more clear about this, but it seems clear > to me that we have to allow both of these. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Aug 24 10:06:28 2010 Return-Path: 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 8FFE23A6358 for ; Tue, 24 Aug 2010 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, 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 RZlZpj-uwzTt for ; Tue, 24 Aug 2010 10:06:27 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id B60AB3A6A35 for ; Tue, 24 Aug 2010 10:06:27 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.29]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Onwxb-0004ie-CP; Tue, 24 Aug 2010 12:06:56 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 24 Aug 2010 13:06:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35BBAD48-1C67-411A-B904-E54B6EE29AF8@brianrosen.net> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: ecrit Subject: Re: [Ecrit] Validation of a missing element X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:06:28 -0000 I don't think it warrants an erratum, but perhaps if we ever did a -bis = we could improve the wording. Brian On Aug 24, 2010, at 12:41 PM, Richard L. Barnes wrote: > That seems sensible to me, "null" being an incorrect value. >=20 > Do you mean to suggest some action here? A modification to some = document? An erratum? >=20 > --Richard >=20 >=20 > On Aug 24, 2010, at 12:33 PM, Brian Rosen wrote: >=20 >> Referring to RFC5222, Section 8.4.2, suppose you sent a civic without = an A1 record, but all of the other elements you sent were "valid" = (whatever that means with a missing A1). >>=20 >> Do we agree that the validation response can contain A1 invalid, even = though the element wasn't in the location sent in the request? >>=20 >> Suppose in a particular LoST database, there was a requirement to = validate down to BLD for at least some civic addresses. If the query = location was missing BLD, the response could have an invalid BLD, right? >>=20 >> The text could have been more clear about this, but it seems clear to = me that we have to allow both of these. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Thu Aug 26 06:29:44 2010 Return-Path: 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 1DF333A682D for ; Thu, 26 Aug 2010 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 PG0ZdVYou++w for ; Thu, 26 Aug 2010 06:29:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 234813A6869 for ; Thu, 26 Aug 2010 06:29:43 -0700 (PDT) Received: from [192.1.255.185] (port=52819 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OocX1-000MCA-Cg; Thu, 26 Aug 2010 09:30:15 -0400 Message-Id: From: "Richard L. Barnes" To: es-coordination@lists.cs.columbia.edu, ecrit Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Aug 2010 09:30:14 -0400 X-Mailer: Apple Mail (2.936) Subject: [Ecrit] ESW8 being rescheduled X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:29:44 -0000 Dear colleagues, We had previously announced that the 8th Emergency Services Workshop would be held 20-22 September 2010. Due to scheduling conflicts, ESW8 is being rescheduled. It will not be held on the previously-announced dates, 20-22 Sept. 2010. New dates will be announced as soon as possible; we expect that they will be in November. We apologize for any inconvenience this change may have caused, and we hope that you will be able to join us on the new dates. Sincerely, ESW8 Program Committee From wwwrun@rfc-editor.org Thu Aug 26 10:01:01 2010 Return-Path: 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 571A23A6AB2; Thu, 26 Aug 2010 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 4ZPUKcqbxMxc; Thu, 26 Aug 2010 10:01:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 508B43A69D2; Thu, 26 Aug 2010 10:01:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 184E5E065E; Thu, 26 Aug 2010 10:01:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100826170133.184E5E065E@rfc-editor.org> Date: Thu, 26 Aug 2010 10:01:33 -0700 (PDT) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 5964 on Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:01:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5964 Title: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries Author: J. Winterbottom, M. Thomson Status: Standards Track Stream: IETF Date: August 2010 Mailbox: james.winterbottom@andrew.com, martin.thomson@andrew.com Pages: 11 Characters: 21269 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-specifying-holes-03.txt URL: http://www.rfc-editor.org/rfc/rfc5964.txt This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS TRACK] This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From RMarshall@telecomsys.com Fri Aug 27 11:45:43 2010 Return-Path: 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 CDE3C3A69E9 for ; Fri, 27 Aug 2010 11:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.099 X-Spam-Level: X-Spam-Status: No, score=-101.099 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_50=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 vWKs065xugTH for ; Fri, 27 Aug 2010 11:45:42 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 570723A6A89 for ; Fri, 27 Aug 2010 11:45:42 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 27 Aug 2010 11:45:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Aug 2010 11:45:09 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657513F3F710@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Validation of a missing element Thread-Index: ActDrsfS186ce8TyT12mTCpQr9FnswCYwGag References: <35BBAD48-1C67-411A-B904-E54B6EE29AF8@brianrosen.net> From: "Roger Marshall" To: "Brian Rosen" , "Richard L. Barnes" Cc: ecrit Subject: Re: [Ecrit] Validation of a missing element X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:45:43 -0000 (I'm not sure if what's being asked is meant to be a general question, or only applicable to A1 and BLD, since leaving off A3 might be more consequential than leaving of A1 in this example.) A sample query that Brian refers to without including A1 (e.g., Bavaria, a national subdivision) might include something like: DE Munich Otto-Hahn-Ring 6 81675 And the suggestion (I think) is that the response comes back including validation elements: country A3 A6 PC A1 HNO Rather than doing the above, which seems unexpected (how did the LoST server know to insert A1 in the response?), isn't this what civic profiles are for? =20 I imagine that use of a civic profile could list which elements are required. If one or more required elements are not provided, then all other (peer or child) elements are tagged as or , along with the appropriate error (see below). 5222 reads (doesn't it?) that if A1 is not included in the query, it would not be included in the response. I also don't think that a LoST server could always determine which other child elements would be valid, if A1 is not known. Based on the existing RFC5222, I guess I'd expect to see as a response, the following: country PC !-since these are not dependent on A1 A3 A6 HNO !-since these may not be definitive unless you know your in A1 (Bavaria) In section 13.1, it also seems like one of the two following errors would be useful: locationProfileUnrecognized None of the profiles in the request were recognized by the server (see Section 12). locationInvalid The geodetic or civic location in the request was invalid. For example, the longitude or latitude values fall outside the acceptable ranges. ...or some new message that states that the special civic profile was not matched, element for element. If we're talking bis action, I'd rather see the return more like: A1 country PC A3 A6 HNO -roger marshall. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, August 24, 2010 10:07 AM To: Richard L. Barnes Cc: ecrit Subject: Re: [Ecrit] Validation of a missing element I don't think it warrants an erratum, but perhaps if we ever did a -bis we could improve the wording. Brian On Aug 24, 2010, at 12:41 PM, Richard L. Barnes wrote: > That seems sensible to me, "null" being an incorrect value. >=20 > Do you mean to suggest some action here? A modification to some document? An erratum? >=20 > --Richard >=20 >=20 > On Aug 24, 2010, at 12:33 PM, Brian Rosen wrote: >=20 >> Referring to RFC5222, Section 8.4.2, suppose you sent a civic without an A1 record, but all of the other elements you sent were "valid" (whatever that means with a missing A1). >>=20 >> Do we agree that the validation response can contain A1 invalid, even though the element wasn't in the location sent in the request? >>=20 >> Suppose in a particular LoST database, there was a requirement to validate down to BLD for at least some civic addresses. If the query location was missing BLD, the response could have an invalid BLD, right? >>=20 >> The text could have been more clear about this, but it seems clear to me that we have to allow both of these. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From wwwrun@core3.amsl.com Tue Aug 31 08:11:38 2010 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BD1523A696D; Tue, 31 Aug 2010 08:11:38 -0700 (PDT) To: jmpolk@cisco.com,andy@hxr.us,br@brianrosen.net,hgs@cs.columbia.edu From: IETF Secretariat Message-Id: <20100831151138.BD1523A696D@core3.amsl.com> Date: Tue, 31 Aug 2010 08:11:38 -0700 (PDT) X-Mailman-Approved-At: Tue, 31 Aug 2010 08:22:29 -0700 Cc: marc.linsner@cisco.com, ecrit@ietf.org, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, ipr-announce@ietf.org Subject: [Ecrit] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 15:11:38 -0000 Dear James Polk, Andrew Newton, Brian Rosen, Henning Schulzrinne: An IPR disclosure that pertains to your Internet-Draft entitled "Framework for Emergency Calling using Internet Multimedia" (draft-ietf-ecrit-framework) was submitted to the IETF Secretariat on 2010-08-30 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1395/). The title of the IPR disclosure is "Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11." The IETF Secretariat From mlinsner@cisco.com Tue Aug 31 14:10:49 2010 Return-Path: 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 C0C5F3A6AED for ; Tue, 31 Aug 2010 14:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MF-p-2Krhhqt for ; Tue, 31 Aug 2010 14:10:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9B0653A6B15 for ; Tue, 31 Aug 2010 14:10:33 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIcMfUxAaMHG/2dsb2JhbACgWXGkRZwehTcEihE X-IronPort-AV: E=Sophos;i="4.56,300,1280707200"; d="scan'208";a="581455608" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2010 21:10:58 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7VLAu02000251 for ; Tue, 31 Aug 2010 21:10:57 GMT User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 31 Aug 2010 17:10:54 -0400 From: Marc Linsner To: "'ecrit'" Message-ID: Thread-Topic: IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11 Thread-Index: ActJUP9SM/4WqRmJokWHype8pivcVQ== In-Reply-To: <20100831151138.BD1523A696D@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Ecrit] FW: IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 21:10:49 -0000 ------ Forwarded Message From: IETF Secretariat Date: Tue, 31 Aug 2010 08:11:38 -0700 (PDT) To: James Polk , , , Henning Schulzrinne Cc: , , , , , , Subject: IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11 Dear James Polk, Andrew Newton, Brian Rosen, Henning Schulzrinne: An IPR disclosure that pertains to your Internet-Draft entitled "Framework for Emergency Calling using Internet Multimedia" (draft-ietf-ecrit-framework) was submitted to the IETF Secretariat on 2010-08-30 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1395/). The title of the IPR disclosure is "Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-framework-11." The IETF Secretariat ------ End of Forwarded Message