From bernard_aboba@hotmail.com Sun May 1 18:13:42 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE0BE0677 for ; Sun, 1 May 2011 18:13:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcvSQwCaqkal for ; Sun, 1 May 2011 18:13:41 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id 75CF3E0664 for ; Sun, 1 May 2011 18:13:41 -0700 (PDT) Received: from BLU152-W30 ([65.55.116.74]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 May 2011 18:13:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1c24ba21-f04d-49b2-8395-d25f3eb795dc_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sun, 1 May 2011 18:13:40 -0700 Importance: Normal In-Reply-To: <6F840F10-3D46-42F5-9A27-EAEE107E07F1@cs.tcd.ie> References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com>, <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net>, <4DB93DAA.5070408@cs.tcd.ie>, , <4DB95963.2080908@cs.tcd.ie>, <8B0A9FCBB9832F43971E38010638454F040474FA2F@SISPE7MB1.commscope.com>, <6F840F10-3D46-42F5-9A27-EAEE107E07F1@cs.tcd.ie> MIME-Version: 1.0 X-OriginalArrivalTime: 02 May 2011 01:13:41.0159 (UTC) FILETIME=[2C67D370:01CC0866] Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 01:13:42 -0000 --_1c24ba21-f04d-49b2-8395-d25f3eb795dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Part of the issues in the DISCUSS were raised in Bernard=20 > Aboba's OPS-DIR review. I recommend all his review to be=20 > addressed. I included in my DISCUSS those issues that seemed=20 > to me critical. FYI=2C the review is available here: https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D933&k2=3D56267&= tid=3D1304298146 Detailed comments are available here: http://www.drizzle.com/~aboba/ops-di= r/draft-ietf-ecrit-phonebcp = --_1c24ba21-f04d-49b2-8395-d25f3eb795dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Part of the issues in the DISCUSS were raised in Bernard=20
>=3B Aboba's OPS-DIR review. I recommend all his review to be=20
>=3B addressed. I included in my DISCUSS those issues that seemed=20
>=3B to me critical. 
FYI=2C the review is available here:
https:= //www.ietf.org/ibin/c5i?mid=3D6&=3Brid=3D49&=3Bgid=3D0&=3Bk1=3D933= &=3Bk2=3D56267&=3Btid=3D1304298146

Detailed comments are avail= able here: =3B http://www.drizzle.com/~aboba/ops-dir/draft-ietf-ecrit-p= honebcp


= --_1c24ba21-f04d-49b2-8395-d25f3eb795dc_-- From brian.rosen@neustar.biz Mon May 2 13:33:59 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4012E078A; Mon, 2 May 2011 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgARLjwVn4ER; Mon, 2 May 2011 13:33:56 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5CE0784; Mon, 2 May 2011 13:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1304368432; x=1619720791; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=zrsx9eJZz0geiMNp9OTiC4hJQUydtjPgl4POVSwAmJU=; b=dQ+7V5xb1yPQp7jkGm6HPC3mJQLX25Ttj16XVYys0jL8fgDVzhFHWuei8uCGy2 skg0tCcZgWaWVa8/LllzRfFg== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44662869; Mon, 02 May 2011 16:33:51 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 2 May 2011 16:33:51 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" , The IESG Date: Mon, 2 May 2011 16:33:47 -0400 Thread-Topic: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) Thread-Index: AcwJCD7X0tl8fVkeSkaT60r9iSHCuQ== Message-ID: <42E18CEE-6EB6-48A8-A2BA-877B843E0681@neustar.biz> References: <8BEBE8CA-9CAC-404F-8E04-1A9732E25242@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 2mwCb3IH3DMVM09rNhjZeQ== Content-Type: multipart/alternative; boundary="_000_42E18CEE6EB648A8A2BA877B843E0681neustarbiz_" MIME-Version: 1.0 Subject: [Ecrit] Fwd: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 20:34:00 -0000 --_000_42E18CEE6EB648A8A2BA877B843E0681neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Had some issues with sending to ecrit and IESG, which have been fixed Begin forwarded message: From: Brian Rosen > Date: April 27, 2011 8:52:05 PM EDT To: Dan Romascanu > Cc: The IESG >, ecrit-chairs@tools.ietf= .org, draft-ietf-ecrit-phonebcp@tools.i= etf.org, "ecrit@ietf.org Org" > Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with= DISCUSS and COMMENT) Please see inline for my responses to this: On Apr 27, 2011, at 8:41 AM, Dan Romascanu wrote: Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR re= view. I recommend all his review to be addressed. I included in my DISCUSS = those issues that seemed to me critical. 1. A number of the recommendations made would appear to assume an all-IP NG= 911 "NENA i3" architecture, as opposed to the "NENA i2" transitional architectu= re. In those cases, the recommendations would represent "Best Future Practice" rather th= an "Best Current Practice". We have tried to base our BCP on other IETF BCPs. Of course, there is wide= variation. This document represents what we think devices should do going= forward. The IETF has no document type called "Best Future Practice". In a number of cases normative language appears to be used in ways differen= t from those described in RFC 2119. In some cases, the term "SHOULD" is used in situations where statutes or regulations may mandate behavior. We believe this to be the best choice. It's MUST except in specified circu= mstances. The circumstances are when regulations say otherwise. I agree here with Bernard that the BCP status is probably adequate, but in = some places the requirements need clarification. Bernard also writes: Overall, I was left with the question as to whether the recommendations in this document applied beyond "all-IP" deployments based on the framework document, to transitional "NENA i2" environments as well. I suspect that the "INT" requirements would also apply to gateways between IP and legacy PSAPs, but this isn't stated explicitly. This is not intended to be a transition document. Transition needs to be c= onsidered in the context of current, nation specific emergency services. i= 2 is U.S. specific, and major changes were made in the Canadian version and= are proposed in the British version of how VoIP is supported in their curr= ent TDM based systems. We believe therefore that the IETF is not the appro= priate venue for a transition document. I also find odd the fact that the document does not refer at least informat= ionaly to the NENA i2 and i3 architectures. The behavior of the system and = requirements may be different in i2 and i3 environments. There are places w= here behavior should be configurable or negotiated to allow for better beha= vior in a transitional environment. There are also places where behavior wi= ll be prescribed by local statues or regulations, so that configuration and= /or negotiation is a practical requirement. It would be inappropriate to refer to i2 and i3 in -phonebcp. I do think w= e could refer to it in -framework however, and we will draft a paragraph th= at does that. 2. I had a hard time translating some of the AN (Access Networks related) r= equirements. For example: AN-5 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration, it MUST require every device that connects to the network to support end system measured location. If I am an operator of an AN that does not support location configuration h= ow should I read the requirement? Is this an administrative requirement, or= should the network be designed so that devices that do not support end sys= tem measured location (and have it activated?) cannot connect to the networ= k? I think it's very clear. You have a choice - implement an LCP or require a= ll devices on your net to support end system measured location. HOW you do= that is up to you. It's access network specific. It may very well be L2 = specific. 3. ED-3 is confusing. I think that it tries to state that string recognitio= n MUST be supported and that the endpoints SHOULD provide this function, bu= t if this is not the case the SP MAY do it. If I am correct than this needs= to be an ED/SP requirement, and I would like the cases of exception to be = clarified. If I mis-understood please help me understand, maybe with some t= ext changes. You understand it correctly. SP-7 is the requirement on the SP. While we = could combine this, I personally think it makes more sense as it is. 4. Section 17.2: The registration process is Expert review by ECRIT working group, its successor, or, in their absence, the IESG. I suggest to define this policy as Expert Review as per RFC 5226 and have a= Designated Expert nominated. The designated expert can than use help from = ECRIT, IESG, or other in the future. We will do this ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Pete's part of the DISCUSS that states that section 12 points to = a security hole that needs to be addressed We agree. We will have to do something for this --_000_42E18CEE6EB648A8A2BA877B843E0681neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Had some issues with sendi= ng to ecrit and IESG, which have been fixed

Begin forwarde= d message:

From: Brian Rosen <br@brianrosen.net>
= Date: April 27, 2011 8:52:05 PM EDT
= To: D= an Romascanu <dromasca@avaya.com>
Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phon= ebcp-17: (with DISCUSS and COMMENT)

Please see= inline for my responses to this:
On Apr 27, 2011, at 8:41 AM, Dan Romas= canu wrote:


Part of the issues in the DISCUSS were raised in Bernard Aboba= 's OPS-DIR review. I recommend all his review to be addressed. I included i= n my DISCUSS those issues that seemed to me critical.

1. A numbe= r of the recommendations made would appear to assume an all-IP NG911
"NENA i3" architecture, as opposed to t= he "NENA i2" transitional architecture.  In those
cases, the recommendations would represent "Best Fut= ure Practice" rather than
"Best = Current Practice".
We have tried to base our BCP on other I= ETF BCPs.  Of course, there is wide variation.  This document rep= resents what we think devices should do going forward.  The IETF has n= o document type called "Best Future Practice".


In a number of cases normat= ive language appears to be used in ways different from
those described in RFC 2119.  In some cases, th= e term "SHOULD" is used in
situat= ions where statutes or regulations may mandate behavior.
We= believe this to be the best choice.  It's MUST except in specified ci= rcumstances.  The circumstances are when regulations say otherwise.

<= br>
I agree here with Bernard that th= e BCP status is probably adequate, but in some places the requirements need= clarification.

Bernard also writes:

Overall, I was l= eft with the question as to whether the
recommendations in this document applied beyond "all-IP"
deployments based on the framework document,= to transitional
"NENA i2" enviro= nments as well.  I suspect that the "INT"
requirements would also apply to gateways between IP and
<= /blockquote>
legacy PSAPs, but this isn't stated e= xplicitly.  
This is not intended to be a transition d= ocument.  Transition needs to be considered in the context of current,= nation specific emergency services.  i2 is U.S. specific, and major c= hanges were made in the Canadian version and are proposed in the British ve= rsion of how VoIP is supported in their current TDM based systems.  We= believe therefore that the IETF is not the appropriate venue for a transit= ion document.


I also find odd the fact that the document does not refer at= least informationaly to the NENA i2 and i3 architectures. The behavior of = the system and requirements may be different in i2 and i3 environments. The= re are places where behavior should be configurable or negotiated to allow = for better behavior in a transitional environment. There are also places wh= ere behavior will be prescribed by local statues or regulations, so that co= nfiguration and/or negotiation is a practical requirement.
= It would be inappropriate to refer to i2 and i3 in -phonebcp.  I do th= ink we could refer to it in -framework however, and we will draft a paragra= ph that does that.


2. I had a hard time translating some of the AN (Access= Networks related) requirements. For example:

 AN-5 Access= networks supporting copper, fiber or other hard wired IP
<= blockquote type=3D"cite">  packet service SHOULD support location conf= iguration.  If the network
=  does not support location configuration, it MUST require every device=
 that connects to the netw= ork to support end system measured location.

If I am an operator = of an AN that does not support location configuration how should I read the= requirement? Is this an administrative requirement, or should the network = be designed so that devices that do not support end system measured locatio= n (and have it activated?) cannot connect to the network?
= I think it's very clear.  You have a choice - implement an LCP or requ= ire all devices on your net to support end system measured location.  = HOW you do that is up to you.  It's access network specific.  It = may very well be L2 specific.


3. ED-3 is confusing. I think that it tries = to state that string recognition MUST be supported and that the endpoints S= HOULD provide this function, but if this is not the case the SP MAY do it. = If I am correct than this needs to be an ED/SP requirement, and I would lik= e the cases of exception to be clarified. If I mis-understood please help m= e understand, maybe with some text changes.
You understand= it correctly.  SP-7 is the requirement on the SP.  While we coul= d combine this, I personally think it makes more sense as it is.


4. Sectio= n 17.2:

The
 registration process is Expert review b= y ECRIT working group, its
 = ;successor, or, in their absence, the IESG.  

I suggest to d= efine this policy as Expert Review as per RFC 5226 and have a Designated Ex= pert nominated. The designated expert can than use help from ECRIT, IESG, o= r other in the future.
We will do this



<= blockquote type=3D"cite">--------------------------------------------------= --------------------
COMMENT:
=
------------------------------------= ----------------------------------

I support Pete's part of the D= ISCUSS that states that section 12 points to a security hole that needs to = be addressed
We agree.  We will have to do something f= or this




= --_000_42E18CEE6EB648A8A2BA877B843E0681neustarbiz_-- From bernard_aboba@hotmail.com Mon May 2 19:33:52 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F81E075B; Mon, 2 May 2011 19:33:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPe6lz-0oXwi; Mon, 2 May 2011 19:33:51 -0700 (PDT) Received: from blu0-omc4-s14.blu0.hotmail.com (blu0-omc4-s14.blu0.hotmail.com [65.55.111.153]) by ietfa.amsl.com (Postfix) with ESMTP id E0CECE06EF; Mon, 2 May 2011 19:33:50 -0700 (PDT) Received: from BLU152-W42 ([65.55.111.135]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 19:33:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3e7cf799-7e43-4d9a-93b2-d13f02bf8107_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: , , "iesg@ietf.org" Date: Mon, 2 May 2011 19:33:50 -0700 Importance: Normal In-Reply-To: <42E18CEE-6EB6-48A8-A2BA-877B843E0681@neustar.biz> References: <8BEBE8CA-9CAC-404F-8E04-1A9732E25242@brianrosen.net>, <42E18CEE-6EB6-48A8-A2BA-877B843E0681@neustar.biz> MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2011 02:33:50.0758 (UTC) FILETIME=[89902460:01CC093A] Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 02:33:52 -0000 --_3e7cf799-7e43-4d9a-93b2-d13f02bf8107_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below.=20 From: Brian.Rosen@neustar.biz To: ecrit@ietf.org=3B iesg@ietf.org Date: Mon=2C 2 May 2011 16:33:47 -0400 Subject: Fwd: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (wit= h DISCUSS and COMMENT) Had some issues with sending to ecrit and IESG=2C which have been fixed Begin forwarded message:From: Brian Rosen Date: April 27=2C 2011 8:52:05 PM EDT To: Dan Romascanu Cc: The IESG =2C ecrit-chairs@tools.ietf.org=2C draft-ietf-e= crit-phonebcp@tools.ietf.org=2C "ecrit@ietf.org Org" Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with= DISCUSS and COMMENT) Please see inline for my responses to this: On Apr 27=2C 2011=2C at 8:41 AM=2C Dan Romascanu wrote: Part of the issues in the DISCUSS were raised in Bernard Aboba's OPS-DIR re= view. I recommend all his review to be addressed. I included in my DISCUSS = those issues that seemed to me critical.=20 1. A number of the recommendations made would appear to assume an all-IP NG= 911 "NENA i3" architecture=2C as opposed to the "NENA i2" transitional architec= ture. In those=20 cases=2C the recommendations would represent "Best Future Practice" rather = than=20 "Best Current Practice". We have tried to base our BCP on other IETF BCPs. Of course=2C there is wi= de variation. This document represents what we think devices should do goi= ng forward. The IETF has no document type called "Best Future Practice". [BA] As noted in the review=2C I don't have a problem with the document bei= ng a BCP.=20 In a number of cases normative language appears to be used in ways differen= t from=20 those described in RFC 2119. In some cases=2C the term "SHOULD" is used in situations where statutes or regulations may mandate behavior. We believe this to be the best choice. It's MUST except in specified circu= mstances. The circumstances are when regulations say otherwise. I agree here with Bernard that the BCP status is probably adequate=2C but i= n some places the requirements need clarification.=20 [BA] That's my take as well.=20 Bernard also writes:=20 Overall=2C I was left with the question as to whether the recommendations in this document applied beyond "all-IP" deployments based on the framework document=2C to transitional "NENA i2" environments as well. I suspect that the "INT" requirements would also apply to gateways between IP and legacy PSAPs=2C but this isn't stated explicitly. =20 This is not intended to be a transition document. Transition needs to be c= onsidered in the context of current=2C nation specific emergency services. = i2 is U.S. specific=2C and major changes were made in the Canadian version= and are proposed in the British version of how VoIP is supported in their = current TDM based systems. We believe therefore that the IETF is not the a= ppropriate venue for a transition document. [BA] I don't have a problem with the document not covering transitional cas= es -- but it wasn't clear whether that was the intent or not. IMHO=2C cla= rifying that would be helpful. =20 I also find odd the fact that the document does not refer at least informat= ionaly to the NENA i2 and i3 architectures. The behavior of the system and = requirements may be different in i2 and i3 environments. There are places w= here behavior should be configurable or negotiated to allow for better beha= vior in a transitional environment. There are also places where behavior wi= ll be prescribed by local statues or regulations=2C so that configuration a= nd/or negotiation is a practical requirement. It would be inappropriate to refer to i2 and i3 in -phonebcp. I do think w= e could refer to it in -framework however=2C and we will draft a paragraph = that does that. [BA] Dan's comment=2C not mine. =20 2. I had a hard time translating some of the AN (Access Networks related) r= equirements. For example:=20 AN-5 Access networks supporting copper=2C fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration=2C it MUST require every device that connects to the network to support end system measured location. If I am an operator of an AN that does not support location configuration h= ow should I read the requirement? Is this an administrative requirement=2C = or should the network be designed so that devices that do not support end s= ystem measured location (and have it activated?) cannot connect to the netw= ork?=20 I think it's very clear. You have a choice - implement an LCP or require a= ll devices on your net to support end system measured location. HOW you do= that is up to you. It's access network specific. It may very well be L2 = specific. [BA] Dan's comment=2C not mine.=20 3. ED-3 is confusing. I think that it tries to state that string recognitio= n MUST be supported and that the endpoints SHOULD provide this function=2C = but if this is not the case the SP MAY do it. If I am correct than this nee= ds to be an ED/SP requirement=2C and I would like the cases of exception to= be clarified. If I mis-understood please help me understand=2C maybe with = some text changes.=20 You understand it correctly. SP-7 is the requirement on the SP. While we = could combine this=2C I personally think it makes more sense as it is. [BA] Dan's comment. 4. Section 17.2:=20 The registration process is Expert review by ECRIT working group=2C its successor=2C or=2C in their absence=2C the IESG. =20 I suggest to define this policy as Expert Review as per RFC 5226 and have a= Designated Expert nominated. The designated expert can than use help from = ECRIT=2C IESG=2C or other in the future.=20 We will do this [BA] This comment came from another Ops-dir reviewer. =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Pete's part of the DISCUSS that states that section 12 points to = a security hole that needs to be addressed We agree. We will have to do something for this [BA] Dan's comment.=20 = --_3e7cf799-7e43-4d9a-93b2-d13f02bf8107_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments below.

From: Brian.Rosen@neustar.biz
To: ecrit@ietf.org= =3B iesg@ietf.org
Date: Mon=2C 2 May 2011 16:33:47 -0400
Subject: Fwd= : Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS an= d COMMENT)

Had some issues wit= h sending to ecrit and IESG=2C which have been fixed

Begin= forwarded message:

= From: Brian Rosen = <=3Bbr@brianrosen.net>=3B
<= /span>
Date: = April= 27=2C 2011 8:52:05 PM EDT
To: Dan Romascanu <=3Bdromasca@avaya.com>=3B
Subject: Re: Dan Romascanu's D= iscuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)
<= /span>

Please see inline for my responses to this:
On Apr = 27=2C 2011=2C at 8:41 AM=2C Dan Romascanu wrote:


Part of the issues in the DISCUSS were raised in Bern= ard Aboba's OPS-DIR review. I recommend all his review to be addressed. I i= ncluded in my DISCUSS those issues that seemed to me critical.

1. A number of the recommenda= tions made would appear to assume an all-IP NG911
"NENA i3" architecture=2C as opposed to the "NENA i2" transitional archi= tecture.  =3BIn those
cases=2C the recomme= ndations would represent "Best Future Practice" rather than
"Best Current Practice".
We have tried to bas= e our BCP on other IETF BCPs.  =3BOf course=2C there is wide variation.=  =3BThis document represents what we think devices should do going for= ward.  =3BThe IETF has no document type called "Best Future Practice".<= br>
[BA] As noted in the review=2C= I don't have a problem with the document being a BCP.

<= blockquote>
In a number of cases normative lang= uage appears to be used in ways different from
those described in RFC 2119.  =3BIn some cases=2C the term "SHOULD" is= used in
situations where statutes or regulatio= ns may mandate behavior.
We believe this to be the best cho= ice.  =3BIt's MUST except in specified circumstances.  =3BThe circu= mstances are when regulations say otherwise.



I agree here with Bernard th= at the BCP status is probably adequate=2C but in some places the requiremen= ts need clarification.

[BA] That's my take as well.

Bernard also writes:

Overall=2C I was left with the question as to whether = the
recommendations in this document applied be= yond "all-IP"
deployments based on the framewor= k document=2C to transitional
"NENA i2" environ= ments as well.  =3BI suspect that the "INT"
requirements would also apply to gateways between IP and
<= blockquote>legacy PSAPs=2C but this isn't stated explicitly.  =3B
This is not intended to be a transition document.  =3BTransi= tion needs to be considered in the context of current=2C nation specific em= ergency services.  =3Bi2 is U.S. specific=2C and major changes were mad= e in the Canadian version and are proposed in the British version of how Vo= IP is supported in their current TDM based systems.  =3BWe believe ther= efore that the IETF is not the appropriate venue for a transition document.=

[BA] I don't have a problem w= ith the document not covering transitional cases -- but it wasn't clear whe= ther that was the intent or not. =3B =3B IMHO=2C clarifying that wo= uld be helpful. =3B


I also find odd the fact that the document does not refer at least= informationaly to the NENA i2 and i3 architectures. The behavior of the sy= stem and requirements may be different in i2 and i3 environments. There are= places where behavior should be configurable or negotiated to allow for be= tter behavior in a transitional environment. There are also places where be= havior will be prescribed by local statues or regulations=2C so that config= uration and/or negotiation is a practical requirement.
It w= ould be inappropriate to refer to i2 and i3 in -phonebcp.  =3BI do thin= k we could refer to it in -framework however=2C and we will draft a paragra= ph that does that.


[BA] Dan's comment=2C not mine. = =3B


2. I had a = hard time translating some of the AN (Access Networks related) requirements= . For example:

&= nbsp=3BAN-5 Access networks supporting copper=2C fiber or other hard wired = IP
 =3Bpacket service SHOULD support locat= ion configuration.  =3BIf the network
&nbs= p=3Bdoes not support location configuration=2C it MUST require every device=
 =3Bthat connects to the network to suppo= rt end system measured location.

If I am an operator of an AN that does not support location = configuration how should I read the requirement? Is this an administrative = requirement=2C or should the network be designed so that devices that do no= t support end system measured location (and have it activated?) cannot conn= ect to the network?
I think it's very clear.  =3BYou h= ave a choice - implement an LCP or require all devices on your net to suppo= rt end system measured location.  =3BHOW you do that is up to you. &nbs= p=3BIt's access network specific.  =3BIt may very well be L2 specific.<= br>
[BA] Dan's comment=2C not mine= .

3. ED-3 is confus= ing. I think that it tries to state that string recognition MUST be support= ed and that the endpoints SHOULD provide this function=2C but if this is no= t the case the SP MAY do it. If I am correct than this needs to be an ED/SP= requirement=2C and I would like the cases of exception to be clarified. If= I mis-understood please help me understand=2C maybe with some text changes= .
You understand it correctly.  =3BSP-7 is the require= ment on the SP.  =3BWhile we could combine this=2C I personally think i= t makes more sense as it is.

[= BA] Dan's comment.


4. Section 17.2:

The
 =3Bregist= ration process is Expert review by ECRIT working group=2C its
 =3Bsuccessor=2C or=2C in their absence=2C the IESG. &n= bsp=3B

I suggest t= o define this policy as Expert Review as per RFC 5226 and have a Designated= Expert nominated. The designated expert can than use help from ECRIT=2C IE= SG=2C or other in the future.
We will do this

[BA] This comment came from an= other Ops-dir reviewer. =3B

-----------------------------------------------------= -----------------
COMMENT:
-------------------------------------------------------------------= ---

I support Pete= 's part of the DISCUSS that states that section 12 points to a security hol= e that needs to be addressed
We agree.  =3BWe will have= to do something for this


[BA] Dan's comment.





= --_3e7cf799-7e43-4d9a-93b2-d13f02bf8107_-- From christer.holmberg@ericsson.com Tue May 3 05:46:05 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A41E07CD for ; Tue, 3 May 2011 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ib7r8wIuTsP for ; Tue, 3 May 2011 05:46:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C80DCE0769 for ; Tue, 3 May 2011 05:46:04 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-10-4dbff90b1eea Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FB.1B.28525.B09FFBD4; Tue, 3 May 2011 14:46:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 3 May 2011 14:46:03 +0200 From: Christer Holmberg To: ECRIT Date: Tue, 3 May 2011 14:46:01 +0200 Thread-Topic: Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A0585194DE2510BESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:46:05 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194DE2510BESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi PSAP callback fans, I've submitted a draft, draft-holmberg-ecrit-callback-00.txt, which extends= the PSAP callback "token" mechanism (previously presented by Cullen), by a= lso informing the home registrar about the token value (allowing the home n= etwork to detect PSAP callbacks). I realize much text is still missing from the draft, but I hope what is now= provided will be enough for the WG to decide whether to start working on a= solution based on the one described in draft. And, if so, whether to use t= he draft as base document. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194DE2510BESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi PSAP callback fans,
 
I've submitted a draft, draft-holmberg-ecrit-callback= -00.txt, which extends the PSAP callback "token" mechanism (previ= ously presented by Cullen), by also informing the home registrar about the = token value (allowing the home network to detect PSAP callbacks).
 
I realize much text is still missing from the draft, = but I hope what is now provided will be enough for the WG to decide whether= to start working on a solution based on the one described in draft. And, i= f so, whether to use the draft as base document.
 
Regards,
 
Christer
 
--_000_7F2072F1E0DE894DA4B517B93C6A0585194DE2510BESESSCMS0356e_-- From christer.holmberg@ericsson.com Wed May 11 01:37:52 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00874E06A0 for ; Wed, 11 May 2011 01:37:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vneWslAu0FiN for ; Wed, 11 May 2011 01:37:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8E6E0686 for ; Wed, 11 May 2011 01:37:51 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-79-4dca4adeaa81 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5E.48.28525.EDA4ACD4; Wed, 11 May 2011 10:37:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 11 May 2011 10:37:49 +0200 From: Christer Holmberg To: ECRIT Date: Wed, 11 May 2011 10:37:48 +0200 Thread-Topic: Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8gGJkHzA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:37:52 -0000 Hi, =20 I have received some off-line comments that it might be possible to merge t= his draft with draft-ietf-ecrit-psap-callback. I have no problem with that. However, the document define different mechanisms, so we would need to deci= ded whether we are going to go forward with one of those, or both. In any case, I would like the WG to discuss and make a decission. Regards, Christer ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: 3. toukokuuta 2011 15:46 To: ECRIT Subject: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 =09 =09 =20 Hi PSAP callback fans, =20 I've submitted a draft, draft-holmberg-ecrit-callback-00.txt, which extend= s the PSAP callback "token" mechanism (previously presented by Cullen), by = also informing the home registrar about the token value (allowing the home = network to detect PSAP callbacks). =20 I realize much text is still missing from the draft, but I hope what is no= w provided will be enough for the WG to decide whether to start working on = a solution based on the one described in draft. And, if so, whether to use = the draft as base document. =20 Regards, =20 Christer =09 From RMarshall@telecomsys.com Wed May 11 21:24:30 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3EE06F3 for ; Wed, 11 May 2011 21:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u5UhMYhn0Rf for ; Wed, 11 May 2011 21:24:30 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2823DE065D for ; Wed, 11 May 2011 21:24:30 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 11 May 2011 21:24:29 -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, 11 May 2011 21:22:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575196BD50D@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT Minutes uploaded - IETF80 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8gGJkHzAAClbcGA= References: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> From: "Roger Marshall" To: "ECRIT" Subject: [Ecrit] ECRIT Minutes uploaded - IETF80 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 04:24:30 -0000 I have uploaded the ECRIT minutes from IETF80. I apologize for the delay in doing so. -roger. 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 rbarnes@bbn.com Thu May 12 05:23:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E491E06D7 for ; Thu, 12 May 2011 05:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J9yVNoxn70A for ; Thu, 12 May 2011 05:23:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4DE06D3 for ; Thu, 12 May 2011 05:23:48 -0700 (PDT) Received: from [128.89.254.244] (port=52974 helo=[10.71.2.203]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKUvj-0002Dp-1T; Thu, 12 May 2011 08:23:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <8C837214C95C864C9F34F3635C2A6575196BD50D@SEA-EXCHVS-2.telecomsys.com> Date: Thu, 12 May 2011 08:23:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3B25A193-260A-47B4-9C0B-98EDF7F91000@bbn.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> <8C837214C95C864C9F34F3635C2A6575196BD50D@SEA-EXCHVS-2.telecomsys.com> To: "Roger Marshall" X-Mailer: Apple Mail (2.1082) Cc: ECRIT Subject: Re: [Ecrit] ECRIT Minutes uploaded - IETF80 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 12:23:50 -0000 Thanks! On May 12, 2011, at 12:22 AM, Roger Marshall wrote: > I have uploaded the ECRIT minutes from IETF80. I apologize for the > delay in doing so. >=20 > -roger. >=20 >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. From stephen.farrell@cs.tcd.ie Fri Apr 29 00:14:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815CEE067C; Fri, 29 Apr 2011 00:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyp3RLvz1gSX; Fri, 29 Apr 2011 00:14:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC5E068B; Fri, 29 Apr 2011 00:14:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1E6C6153A7D; Fri, 29 Apr 2011 08:14:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1304061246; bh=aD7t9 UNzwPm/WBhtwm/9e96Y+FFBFOALyhnORFT0B/A=; b=j307ZKRRsGlVwc5NBy9Pq dWSHTeJiHAUN+RBmIZQ59bHB3SO+yCVnDgh0LZc6gLEJg1FhdKSk4E+vCTlV2xhi Ume3CztYJZkYeRBSPsLRwicmwhBqK0TJdJjIHtNv4YV1kVIBsg1heUUxBHiB7mrC G19s6qe1eHVcC/BJUK1Fq0AQz8WsTRI0XsJqHT6wbX+PDq77Vf3oBv8vQX1Z8373 trfhE3f9Mu+vaS9yWh5N8C129Bk3o9IlZTRmBM90p9jXlxIN7eu2JepCDXK90Qxk 7XRYOvndhxPZFun+NTisNIleRvxAJ/z3Ug/W9AFu82vv7IGY2wsX0ljgySMmDzG8 w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Jt+w+tTMi7cY; Fri, 29 Apr 2011 08:14:06 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.77.60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2D68B153A80; Fri, 29 Apr 2011 08:14:04 +0100 (IST) References: <20110427020138.5421.87853.idtracker@ietfa.amsl.com> <5B3D3910-8AC2-4410-940A-D68F94498BE6@brianrosen.net> <4DB93DAA.5070408@cs.tcd.ie> <4DB95963.2080908@cs.tcd.ie> <8B0A9FCBB9832F43971E38010638454F040474FA2F@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040474FA2F@SISPE7MB1.commscope.com> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6F840F10-3D46-42F5-9A27-EAEE107E07F1@cs.tcd.ie> X-Mailer: iPhone Mail (8G4) From: Stephen Farrell Date: Fri, 29 Apr 2011 08:13:59 +0100 To: "Dawson, Martin" X-Mailman-Approved-At: Thu, 12 May 2011 08:23:56 -0700 Cc: "ecrit-chairs@tools.ietf.org" , The IESG , "ecrit@ietf.org Org" , "draft-ietf-ecrit-framework@tools.ietf.org" Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 07:14:19 -0000 On 29 Apr 2011, at 03:05, "Dawson, Martin" wro= te: >> I understand what you're saying. How about if it said that devices must b= e able to do this and should actually do it, which'd be something like: >>=20 >> "a caller's device must be able to, and should, obtain..." >=20 > I think that's more in the right spirit. To tighten it further it could be= : >=20 > "...must be able and attempt to obtain..." - after that it's a matter of d= istinguishing what it must do if it succeeds in getting location and should d= o if it did not. That'd work for me, Thanks, S >=20 > Regards, > Martin >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of S= tephen Farrell > Sent: Thursday, 28 April 2011 10:11 PM > To: Richard L. Barnes > Cc: ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-framework@tools.ietf.org= ; ecrit@ietf.org Org; The IESG > Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framewo= rk-12: (with DISCUSS and COMMENT) >=20 >=20 > Hi Richard, >=20 > On 28/04/11 12:50, Richard L. Barnes wrote: >> Hey Stephen, >>=20 >> Couple of points inline below. >>=20 >>>>> (1) Section 3 says: "a caller must obtain his location...prior to maki= ng >>>>> emergency calls." That seems overstated - if I can't find my location=20= >>>>> are you saying that the call can't happen? (A "should" would be right >>>>> here I think.) >>>> This is in an overview section, it's not MUST and it's properly qualifi= ed later. Anyone in emergency services will tell you that the three most im= portant things about emergency calling are location, location and location (= which is a U.S. specific reference to a joke about real estate) >>>> We usually get all these rules must this, must that, and when you enqui= re what happens when something fails and you can't follow the rules, you fin= d they take them and deal with them. >>>>=20 >>>> I'd prefer not to change it in the document, but of course we can (to s= hould). >>>=20 >>> Well, I think must just isn't correct, even though this isn't 2119 >>> language so some other wording is needed. I'd be fine with "really >>> should" or anything that's accurate. >>=20 >> I agree that we're sort of arguing style/taste here. =20 >=20 > Disagree. I think that "must" is misleading here. >=20 >> But I did want to emphasize that location actually is *really* > important for this process. This whole document is about how you do > urgent, location-based call routing. >>=20 >> In order for an emergency call to work, somebody needs to know the caller= 's location, either the caller himself or his VoIP provider. In general, th= e latter case is infeasible; the only case where that really happens is for c= arrier-provided VoIP services, like the Comcast "digital voice" service that= they sell alongside their Internet service. For all other VoIP services i= n all other classes of network, the end device needs to do the location bits= , because it's the only device that talks to both the access network (for lo= cation) and VoIP system (for call delivery). >>=20 >> Given that location is such an important thing that so often has to be do= ne by the end device, it seems to me that saying "must" here sets the proper= context for the reader. >=20 > I understand what you're saying. How about if it said that devices must > be able to do this and should actually do it, which'd be something like: >=20 > "a caller's device must be able to, and should, obtain..." >=20 >>>>> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would= >>>>> xmpp be more likely to be useful? (Just checking.) >>>> We've considered xmpp. We would have to extend xmpp in several ways, a= nd then extend framework and phonebcp in ways compatible with the extensions= . Absent the extensions in at least draft form, we'll probably update -fram= ework and -phonebcp later. >>>=20 >>> Fair enough. >>>=20 >>>>> (3) How would any of this work with p2psip? (Just checking again.) >>>> Same as above, but fall back to sip is something p2psip devices do. >>>=20 >>> Not sure I understand quite. Are you saying that a p2psip device >>> where the user has no account with a service provider can still >>> make an emergency call by following this framework and the phonebcp? >>> I'd have thought that a sentence is needed somewhere about that. >>=20 >> There are two key parts to the framework: >> (1) Figuring out where to send a call, and=20 >> (2) Sending the call to the PSAP >>=20 >> The first part is not dependent on SIP at all -- you can plug in any URI y= ou want into LoST, including XMPP. I've done demos using the "wave:" URI sc= heme to allow PSAPs to invite emergency callers to join a Google Wave collab= oration space. >>=20 >> The second part can also in principle be done over any protocol, but ther= e are some features that you lose relative to this document. In particular,= this document embeds the caller's geolocation in the call signaling, and ma= rks the call as an emergency call. So if you were to use XMPP, you would lo= se these features, but still be able to talk to a PSAP. If you were to use P= 2PSIP, I think the main challenge would be making sure that the call marking= would not interfere with call routing -- I think in principle it shouldn't,= but I don't know the P2PSIP specs very well. =20 >=20 > A sentence that just said that p2psip isn't covered here would > be fine from my p-o-v. Given that this is largely about SIP, > and p2psip exists, I think that'd be helpful to the reader who > could otherwise be mislead. >=20 > I'm not asking that this framework say how to handle emergency > calling in p2psip if that's not a well-known thing. (I'm not > sure how that'd best be worded though sorry.) >=20 > S. >=20 >>=20 >> Hope this helps, >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Tue May 24 18:55:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E908E0791; Tue, 24 May 2011 18:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPHt30jwqzzr; Tue, 24 May 2011 18:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2BE0753; Tue, 24 May 2011 18:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110525015542.14675.4183.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2011 18:55:42 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 01:55:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Trustworthy Location Information Author(s) : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-02.txt Pages : 21 Date : 2011-05-24 For some location-based applications, such as emergency calling or roadside assistance, it is important to be able to determine whether location information is trustworthy. This document outlines potential threats to trustworthy location and analyzes the operational issues with potential solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-trustworthy-location-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-trustworthy-location-02= .txt From christer.holmberg@ericsson.com Mon May 30 05:00:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9735FE06C8 for ; Mon, 30 May 2011 05:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ewwJTS9qxTG for ; Mon, 30 May 2011 05:00:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6BE0721 for ; Mon, 30 May 2011 05:00:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-09-4de386d2b496 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.E4.09774.2D683ED4; Mon, 30 May 2011 14:00:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 30 May 2011 14:00:18 +0200 From: Christer Holmberg To: ECRIT Date: Mon, 30 May 2011 14:00:17 +0200 Thread-Topic: Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8gGJkHzAA8KfrWA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2A694B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DE2510B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E0F1465@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 12:00:21 -0000 Hi, Does silence mean that the WG has no interest in working with a PSAP callba= ck mechanism, and if someone wants a solution they should specify it themse= lves? I understand that people are busy etc, but PSAP callback in general hasn't = been discussed on the list since Prague, so I would like to know whether th= ere is interest. Regards, Christer =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Christer Holmberg > Sent: 11. toukokuuta 2011 11:38 > To: ECRIT > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 >=20 > Hi, > =20 > I have received some off-line comments that it might be=20 > possible to merge this draft with draft-ietf-ecrit-psap-callback. >=20 > I have no problem with that. >=20 > However, the document define different mechanisms, so we=20 > would need to decided whether we are going to go forward with=20 > one of those, or both. >=20 > In any case, I would like the WG to discuss and make a decission. >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________ >=20 > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 3. toukokuuta 2011 15:46 > To: ECRIT > Subject: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > =09 > =09 > =20 > Hi PSAP callback fans, > =20 > I've submitted a draft,=20 > draft-holmberg-ecrit-callback-00.txt, which extends the PSAP=20 > callback "token" mechanism (previously presented by Cullen),=20 > by also informing the home registrar about the token value=20 > (allowing the home network to detect PSAP callbacks). > =20 > I realize much text is still missing from the draft,=20 > but I hope what is now provided will be enough for the WG to=20 > decide whether to start working on a solution based on the=20 > one described in draft. And, if so, whether to use the draft=20 > as base document. > =20 > Regards, > =20 > Christer > =09 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From md3135@att.com Mon May 30 10:12:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9EE06D9 for ; Mon, 30 May 2011 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8suqBbnsA58f for ; Mon, 30 May 2011 10:12:24 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id E0833E06CA for ; Mon, 30 May 2011 10:12:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1306775543!20153807!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5951 invoked from network); 30 May 2011 17:12:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 May 2011 17:12:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4UHBITi030704 for ; Mon, 30 May 2011 13:11:18 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4UHBBrN030649 for ; Mon, 30 May 2011 13:11:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 30 May 2011 13:12:16 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBE74@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8gGJkHzAA8KfrWAACvp2Bg== From: "DOLLY, MARTIN C (ATTSI)" To: , Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 17:12:25 -0000 Q2hyaXN0ZXINCg0KV2UgbmVlZCBjYWxsYmFjayBpbiBOQQ0KDQpNYXJ0aW4NCg0KTWFydGluIEMu IERvbGx5DQpTZW50IHRvIHlvdSBieSBBVCZULi4uIEFtZXJpY2EncyBGYXN0ZXN0IE1vYmlsZSBC cm9hZGJhbmQgTmV0d29yay4gUmV0aGluayBQb3NzaWJsZS4NCisxLjYwOS45MDMuMzM2MA0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3Jn IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NClNl bnQ6IE1vbiBNYXkgMzAgMDg6MDA6MTcgMjAxMQ0KU3ViamVjdDogUmU6IFtFY3JpdF0gRHJhZnQg bmV3OiBkcmFmdC1ob2xtYmVyZy1lY3JpdC1jYWxsYmFjay0wMA0KDQoNCkhpLA0KDQpEb2VzIHNp bGVuY2UgbWVhbiB0aGF0IHRoZSBXRyBoYXMgbm8gaW50ZXJlc3QgaW4gd29ya2luZyB3aXRoIGEg UFNBUCBjYWxsYmFjayBtZWNoYW5pc20sIGFuZCBpZiBzb21lb25lIHdhbnRzIGEgc29sdXRpb24g dGhleSBzaG91bGQgc3BlY2lmeSBpdCB0aGVtc2VsdmVzPw0KDQpJIHVuZGVyc3RhbmQgdGhhdCBw ZW9wbGUgYXJlIGJ1c3kgZXRjLCBidXQgUFNBUCBjYWxsYmFjayBpbiBnZW5lcmFsIGhhc24ndCBi ZWVuIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBzaW5jZSBQcmFndWUsIHNvIEkgd291bGQgbGlrZSB0 byBrbm93IHdoZXRoZXIgdGhlcmUgaXMgaW50ZXJlc3QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlY3JpdC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gDQo+IE9uIEJlaGFs ZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KPiBTZW50OiAxMS4gdG91a29rdXV0YSAyMDExIDExOjM4 DQo+IFRvOiBFQ1JJVA0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBEcmFmdCBuZXc6IGRyYWZ0LWhv bG1iZXJnLWVjcml0LWNhbGxiYWNrLTAwDQo+IA0KPiBIaSwNCj4gIA0KPiBJIGhhdmUgcmVjZWl2 ZWQgc29tZSBvZmYtbGluZSBjb21tZW50cyB0aGF0IGl0IG1pZ2h0IGJlIA0KPiBwb3NzaWJsZSB0 byBtZXJnZSB0aGlzIGRyYWZ0IHdpdGggZHJhZnQtaWV0Zi1lY3JpdC1wc2FwLWNhbGxiYWNrLg0K PiANCj4gSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGF0Lg0KPiANCj4gSG93ZXZlciwgdGhlIGRv Y3VtZW50IGRlZmluZSBkaWZmZXJlbnQgbWVjaGFuaXNtcywgc28gd2UgDQo+IHdvdWxkIG5lZWQg dG8gZGVjaWRlZCB3aGV0aGVyIHdlIGFyZSBnb2luZyB0byBnbyBmb3J3YXJkIHdpdGggDQo+IG9u ZSBvZiB0aG9zZSwgb3IgYm90aC4NCj4gDQo+IEluIGFueSBjYXNlLCBJIHdvdWxkIGxpa2UgdGhl IFdHIHRvIGRpc2N1c3MgYW5kIG1ha2UgYSBkZWNpc3Npb24uDQo+IA0KPiBSZWdhcmRzLA0KPiAN Cj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiANCj4gCUZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgDQo+IFttYWlsdG86ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQo+IAlTZW50OiAz LiB0b3Vrb2t1dXRhIDIwMTEgMTU6NDYNCj4gCVRvOiBFQ1JJVA0KPiAJU3ViamVjdDogW0Vjcml0 XSBEcmFmdCBuZXc6IGRyYWZ0LWhvbG1iZXJnLWVjcml0LWNhbGxiYWNrLTAwDQo+IAkNCj4gCQ0K PiAJCSANCj4gCUhpIFBTQVAgY2FsbGJhY2sgZmFucywNCj4gCSANCj4gCUkndmUgc3VibWl0dGVk IGEgZHJhZnQsIA0KPiBkcmFmdC1ob2xtYmVyZy1lY3JpdC1jYWxsYmFjay0wMC50eHQsIHdoaWNo IGV4dGVuZHMgdGhlIFBTQVAgDQo+IGNhbGxiYWNrICJ0b2tlbiIgbWVjaGFuaXNtIChwcmV2aW91 c2x5IHByZXNlbnRlZCBieSBDdWxsZW4pLCANCj4gYnkgYWxzbyBpbmZvcm1pbmcgdGhlIGhvbWUg cmVnaXN0cmFyIGFib3V0IHRoZSB0b2tlbiB2YWx1ZSANCj4gKGFsbG93aW5nIHRoZSBob21lIG5l dHdvcmsgdG8gZGV0ZWN0IFBTQVAgY2FsbGJhY2tzKS4NCj4gCSANCj4gCUkgcmVhbGl6ZSBtdWNo IHRleHQgaXMgc3RpbGwgbWlzc2luZyBmcm9tIHRoZSBkcmFmdCwgDQo+IGJ1dCBJIGhvcGUgd2hh dCBpcyBub3cgcHJvdmlkZWQgd2lsbCBiZSBlbm91Z2ggZm9yIHRoZSBXRyB0byANCj4gZGVjaWRl IHdoZXRoZXIgdG8gc3RhcnQgd29ya2luZyBvbiBhIHNvbHV0aW9uIGJhc2VkIG9uIHRoZSANCj4g b25lIGRlc2NyaWJlZCBpbiBkcmFmdC4gQW5kLCBpZiBzbywgd2hldGhlciB0byB1c2UgdGhlIGRy YWZ0IA0KPiBhcyBiYXNlIGRvY3VtZW50Lg0KPiAJIA0KPiAJUmVnYXJkcywNCj4gCSANCj4gCUNo cmlzdGVyDQo+IAkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3Jp dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From christer.holmberg@ericsson.com Mon May 30 23:23:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA6E0674 for ; Mon, 30 May 2011 23:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNyfN2NaSCIx for ; Mon, 30 May 2011 23:23:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 18366E06D4 for ; Mon, 30 May 2011 23:23:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-fa-4de48949b70b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AD.D9.09774.94984ED4; Tue, 31 May 2011 08:23:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 31 May 2011 08:23:04 +0200 From: Christer Holmberg To: "DOLLY, MARTIN C (ATTSI)" , "ecrit@ietf.org" Date: Tue, 31 May 2011 08:23:04 +0200 Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwJkA8JHPfXp4KURXOXv0FvywvR8gGJkHzAA8KfrWAACvp2BgAbhghg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2A6C00@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBE74@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBE74@gaalpa1msgusr7e.ugd.att.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 06:23:08 -0000 Hi Martin, It's also needed in 3GPP. But, if ECRIT is only going to discuss this for 30 minutes, 3 times a year = during the IETF meetings, we will never get a solution in time :) So, at this point I am not asking the WG for a decission on mechanism, but = to indicate whether there is interest to work on a solution in the first pl= ace. I am sure 3GPP, and others, are interested in knowing that. Regards, Christer > -----Original Message----- > From: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com]=20 > Sent: 30. toukokuuta 2011 20:12 > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 >=20 > Christer >=20 > We need callback in NA >=20 > Martin >=20 > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband=20 > Network. Rethink Possible. > +1.609.903.3360 >=20 > ----- Original Message ----- > From: ecrit-bounces@ietf.org > To: ECRIT > Sent: Mon May 30 08:00:17 2011 > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 >=20 >=20 > Hi, >=20 > Does silence mean that the WG has no interest in working with=20 > a PSAP callback mechanism, and if someone wants a solution=20 > they should specify it themselves? >=20 > I understand that people are busy etc, but PSAP callback in=20 > general hasn't been discussed on the list since Prague, so I=20 > would like to know whether there is interest. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Christer Holmberg > > Sent: 11. toukokuuta 2011 11:38 > > To: ECRIT > > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > >=20 > > Hi, > > =20 > > I have received some off-line comments that it might be possible to=20 > > merge this draft with draft-ietf-ecrit-psap-callback. > >=20 > > I have no problem with that. > >=20 > > However, the document define different mechanisms, so we=20 > would need to=20 > > decided whether we are going to go forward with one of=20 > those, or both. > >=20 > > In any case, I would like the WG to discuss and make a decission. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > ________________________________ > >=20 > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 3. toukokuuta 2011 15:46 > > To: ECRIT > > Subject: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > > =09 > > =09 > > =20 > > Hi PSAP callback fans, > > =20 > > I've submitted a draft, > > draft-holmberg-ecrit-callback-00.txt, which extends the=20 > PSAP callback=20 > > "token" mechanism (previously presented by Cullen), by also=20 > informing=20 > > the home registrar about the token value (allowing the home=20 > network to=20 > > detect PSAP callbacks). > > =20 > > I realize much text is still missing from the draft,=20 > but I hope what=20 > > is now provided will be enough for the WG to decide whether=20 > to start=20 > > working on a solution based on the one described in draft.=20 > And, if so,=20 > > whether to use the draft as base document. > > =20 > > Regards, > > =20 > > Christer > > =09 > > _______________________________________________ > > 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 christer.holmberg@ericsson.com Tue May 31 23:26:14 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0768E074F for ; Tue, 31 May 2011 23:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whI29uO1k4uL for ; Tue, 31 May 2011 23:26:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3EDE0689 for ; Tue, 31 May 2011 23:26:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d0-4de5db834bfa Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 59.ED.20773.38BD5ED4; Wed, 1 Jun 2011 08:26:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 08:26:11 +0200 From: Christer Holmberg To: Brian Rosen Date: Wed, 1 Jun 2011 08:26:09 +0200 Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 Thread-Index: AcwfnXGeXySb7JnyRlSI5roKKydqcwAhMj5Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C38@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBE74@gaalpa1msgusr7e.ugd.att.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6C00@ESESSCMS0356.eemea.ericsson.se> <3FF6D498-0DC5-4D27-B40A-106EED8CF8E9@brianrosen.net> In-Reply-To: <3FF6D498-0DC5-4D27-B40A-106EED8CF8E9@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: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:26:14 -0000 Hi Brian, I don't know the time limits for the follow up callback, but as I have said= in previous discussions, the need is to be able to have a dedicated callba= ck indicator, so that the home and visited networks can provide special tre= atment (e.g. disable services) for the callback (the draft I submitted prov= ides such mechanism). 3GPP has had to move the requirement for this forward all the way since Rel= -7 (2006!), due to the lack of a solution, so I would really really like to= know whether ECRIT is willing to work on a solution or not. If not, I woul= d suggest that ECRIT informs 3GPP about that. Regards, Christer =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 31. toukokuuta 2011 16:00 > To: Christer Holmberg > Cc: DOLLY, MARTIN C (ATTSI); ecrit@ietf.org > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 >=20 > I guess this all depends on what the goals are. >=20 > There are two kinds of call back. >=20 > One is when there is a unexpected loss of connectivity, or an=20 > inadvertent hang up, or a call from a responder moments after=20 > the actual emergency call happened. >=20 > This kind of call back is to the Contact address, and should=20 > get back to the device that placed the call. >=20 > The other is a follow up call. It may happen hours to days=20 > later. This call is to the AoR, and it should follow the=20 > normal call behavior with respect to call forwarding, device=20 > selection, etc. >=20 > ISTM that the problems of a call back to the Contact address,=20 > given it was an emergency call to begin with are=20 > straightforward. I'd be willing to work on that. >=20 > A call back to an AoR is a normal call, no special processing=20 > is needed. >=20 > Note that today, all we have is the AoR call, with no special=20 > processing. >=20 > The other k > On May 31, 2011, at 2:23 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi Martin, > >=20 > > It's also needed in 3GPP. > >=20 > > But, if ECRIT is only going to discuss this for 30 minutes,=20 > 3 times a=20 > > year during the IETF meetings, we will never get a solution=20 > in time :) > >=20 > > So, at this point I am not asking the WG for a decission on=20 > mechanism, but to indicate whether there is interest to work=20 > on a solution in the first place. I am sure 3GPP, and others,=20 > are interested in knowing that. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >> -----Original Message----- > >> From: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com] > >> Sent: 30. toukokuuta 2011 20:12 > >> To: Christer Holmberg; ecrit@ietf.org > >> Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > >>=20 > >> Christer > >>=20 > >> We need callback in NA > >>=20 > >> Martin > >>=20 > >> Martin C. Dolly > >> Sent to you by AT&T... America's Fastest Mobile Broadband Network.=20 > >> Rethink Possible. > >> +1.609.903.3360 > >>=20 > >> ----- Original Message ----- > >> From: ecrit-bounces@ietf.org > >> To: ECRIT > >> Sent: Mon May 30 08:00:17 2011 > >> Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > >>=20 > >>=20 > >> Hi, > >>=20 > >> Does silence mean that the WG has no interest in working=20 > with a PSAP=20 > >> callback mechanism, and if someone wants a solution they should=20 > >> specify it themselves? > >>=20 > >> I understand that people are busy etc, but PSAP callback=20 > in general=20 > >> hasn't been discussed on the list since Prague, so I would like to=20 > >> know whether there is interest. > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] On Behalf > >>> Of Christer Holmberg > >>> Sent: 11. toukokuuta 2011 11:38 > >>> To: ECRIT > >>> Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > >>>=20 > >>> Hi, > >>>=20 > >>> I have received some off-line comments that it might be=20 > possible to=20 > >>> merge this draft with draft-ietf-ecrit-psap-callback. > >>>=20 > >>> I have no problem with that. > >>>=20 > >>> However, the document define different mechanisms, so we > >> would need to > >>> decided whether we are going to go forward with one of > >> those, or both. > >>>=20 > >>> In any case, I would like the WG to discuss and make a decission. > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>>=20 > >>>=20 > >>> ________________________________ > >>>=20 > >>> From: ecrit-bounces@ietf.org > >>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > >>> Sent: 3. toukokuuta 2011 15:46 > >>> To: ECRIT > >>> Subject: [Ecrit] Draft new: draft-holmberg-ecrit-callback-00 > >>> =09 > >>> =09 > >>> =20 > >>> Hi PSAP callback fans, > >>> =20 > >>> I've submitted a draft, > >>> draft-holmberg-ecrit-callback-00.txt, which extends the > >> PSAP callback > >>> "token" mechanism (previously presented by Cullen), by also > >> informing > >>> the home registrar about the token value (allowing the home > >> network to > >>> detect PSAP callbacks). > >>> =20 > >>> I realize much text is still missing from the draft, > >> but I hope what > >>> is now provided will be enough for the WG to decide whether > >> to start > >>> working on a solution based on the one described in draft.=20 > >> And, if so, > >>> whether to use the draft as base document. > >>> =20 > >>> Regards, > >>> =20 > >>> Christer > >>> =09 > >>> _______________________________________________ > >>> 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 >=20 > =