From Gabor.Bajko@nokia.com Fri Feb 4 11:10:35 2011 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 BF2053A69CF; Fri, 4 Feb 2011 11:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jeAQMW87vpZn; Fri, 4 Feb 2011 11:10:33 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 2E3373A69D5; Fri, 4 Feb 2011 11:10:32 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p14JDiIQ027670; Fri, 4 Feb 2011 21:13:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 21:13:29 +0200 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 4 Feb 2011 20:13:29 +0100 Received: from 008-AM1MPN1-013.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Fri, 4 Feb 2011 20:13:29 +0100 From: To: , Thread-Topic: New Non-WG Mailing List: paws -- Protocol to Access White Space database (PAWS) Thread-Index: AcvEnkY2nnLD6X4FQD+rsR6jo9zMZw== Date: Fri, 4 Feb 2011 19:09:12 +0000 Message-ID: <8A7EBBAE1E9F0945A9FE03703E0AE9AEC66985@008-AM1MPN1-013.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2011 19:13:29.0607 (UTC) FILETIME=[9B643170:01CBC49F] X-Nokia-AV: Clean Subject: [Ecrit] FW: New Non-WG Mailing List: paws -- Protocol to Access White Space database (PAWS) 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, 04 Feb 2011 19:10:35 -0000 FYI This new work is likely to make use of some of the technologies defined by = these wgs. -gabor >-----Original Message----- >From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-=20 >bounces@ietf.org] On Behalf Of ext IETF Secretariat >Sent: 03 February, 2011 21:54 >To: IETF Announcement list >Subject: New Non-WG Mailing List: paws -- Protocol to Access White=20 >Space database (PAWS) > >A new IETF non-working group email list has been created. > >List address: paws@ietf.org >Archive: http://www.ietf.org/mail-archive/web/paws/ >To subscribe: https://www.ietf.org/mailman/listinfo/paws > >Description: >As nations struggle to provide spectrum in a finite swath of useful=20 >spectrum, especially spectrum for use with wireless Internet bandwidth,=20 >there are problems with incumbents in a given band. The incumbents may=20 >use the spectrum inefficiently, especially geographically - there may=20 >be large swaths of country where a particular band is not used at all,=20 >and others where use is only in a portion of the band. > >Recently, techniques have been developed that attempt to share spectrum=20 >between incumbents and new users. The generic term for this is "white=20 >space". For example, in over the air TV bands, spectrum is divided into=20 >channels, and in any one area, usually not all channels have TV=20 >transmitters in range. There is a desire among many regulators to make=20 >this prime spectrum available for Internet access and other uses, as=20 >long as the new use does not interfere with the existing TV band use. > >Multiple database(s) are expected to exist which contains the=20 >information about available channels for use at a given location. A=20 >device is required to query the database for available channels and=20 >associated information. There are several scenarios that the US=20 >regulation permits which include a simple tower/client arrangement=20 >where the tower queries the database on behalf of itself and its client=20 >TVBDs as well as ad hoc mobile networks where at least one TVBD in the=20 >ad hoc net has another path to the Internet and can query the database=20 >with it. > >This BoF will explore the various aspects of specifying a messaging=20 >interface betwen the devices and the database. > >For additional information, please contact the list administrators. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From rjsparks@nostrum.com Mon Feb 7 14:37:05 2011 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 1DB353A6F31 for ; Mon, 7 Feb 2011 14:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 kUJfd34MuYAN for ; Mon, 7 Feb 2011 14:37:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E346E3A6961 for ; Mon, 7 Feb 2011 14:37:03 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p17Mb8Hp054234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 7 Feb 2011 16:37:08 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 16:37:07 -0600 Message-Id: To: ecrit@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Ecrit] Requesting IETF LC for phonebcp 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, 07 Feb 2011 22:37:05 -0000 All - I've requested IETFLC for the phonebcp draft. There are still some = outstanding questions/comments from John Elwell that should be treated = as last call comments. Also, something needs to register the sos.*.test URNs. I think this = document could do that. RjS= From iesg-secretary@ietf.org Mon Feb 7 14:46:42 2011 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 DCA7E3A6FB3; Mon, 7 Feb 2011 14:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 MGcuXdcgwong; Mon, 7 Feb 2011 14:46:42 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE483A6EFE; Mon, 7 Feb 2011 14:46:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207224642.18449.10118.idtracker@localhost> Date: Mon, 07 Feb 2011 14:46:42 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (Best Current Practice for Communications Services in support of Emergency Calling) to BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:46:43 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Best Current Practice for Communications Services in support of Emergency Calling' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/ No IPR declarations have been submitted directly on this I-D. From jmpolk@cisco.com Mon Feb 7 14:50:10 2011 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 03A163A6EFE for ; Mon, 7 Feb 2011 14:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 k8+QAa9ftXLW for ; Mon, 7 Feb 2011 14:50:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A860A3A6FBF for ; Mon, 7 Feb 2011 14:50:06 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG8FUE2tJXHB/2dsb2JhbAClJXOePZsWhVoEhHo Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2011 22:50:11 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p17MoB5T019815; Mon, 7 Feb 2011 22:50:11 GMT Message-Id: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Feb 2011 16:50:09 -0600 To: Robert Sparks From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ecrit@ietf.org Subject: Re: [Ecrit] Requesting IETF LC for phonebcp 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, 07 Feb 2011 22:50:10 -0000 Robert (dare I say this) Now that Location Conveyance (a norm ref in phonebcp) is down to the final open issue -- with the hope that this issue realistically can be solved on Thursday's design team call -- we (probably meaning at least me) need to review phonebcp wrt the recent changes to Location Conveyance. In other words, I'm not sure phonebcp has had meaningful edits since Location Conveyance deleted all the "inserted-by", "inserter=" cruft that halved the size of that ID, as well as Location Conveyance adopting a "you break it you bought it" attitude wrt SIP intermediaries inserting location. This will likely impact some of the finer details within phonebcp. James At 04:37 PM 2/7/2011, Robert Sparks wrote: >All - > >I've requested IETFLC for the phonebcp draft. There are still some >outstanding questions/comments from John Elwell that should be >treated as last call comments. >Also, something needs to register the sos.*.test URNs. I think this >document could do that. > >RjS >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From rjsparks@nostrum.com Mon Feb 7 14:58:05 2011 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 EB2A13A6FC1 for ; Mon, 7 Feb 2011 14:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 Yw-8HnOkV431 for ; Mon, 7 Feb 2011 14:58:05 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C6D113A6FB9 for ; Mon, 7 Feb 2011 14:58:04 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p17Mw2Iw055989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Feb 2011 16:58:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com> Date: Mon, 7 Feb 2011 16:58:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com> References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com> To: "James M. Polk" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Requesting IETF LC for phonebcp 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, 07 Feb 2011 22:58:06 -0000 Please do. I think you'll find, though, that this document deferred to = location conveyance for those finer details. If you spot otherwise, = let's fix it. RjS On Feb 7, 2011, at 4:50 PM, James M. Polk wrote: > Robert >=20 > (dare I say this) >=20 > Now that Location Conveyance (a norm ref in phonebcp) is down to the = final open issue -- with the hope that this issue realistically can be = solved on Thursday's design team call -- we (probably meaning at least = me) need to review phonebcp wrt the recent changes to Location = Conveyance. In other words, I'm not sure phonebcp has had meaningful = edits since Location Conveyance deleted all the "inserted-by", = "inserter=3D" cruft that halved the size of that ID, as well as Location = Conveyance adopting a "you break it you bought it" attitude wrt SIP = intermediaries inserting location. This will likely impact some of the = finer details within phonebcp. >=20 > James >=20 > At 04:37 PM 2/7/2011, Robert Sparks wrote: >> All - >>=20 >> I've requested IETFLC for the phonebcp draft. There are still some = outstanding questions/comments from John Elwell that should be treated = as last call comments. >> Also, something needs to register the sos.*.test URNs. I think this = document could do that. >>=20 >> RjS >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From gunnar.hellstrom@omnitor.se Tue Feb 8 01:28:37 2011 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 B0C973A7083 for ; Tue, 8 Feb 2011 01:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 9Ky9Y7JbVZ06 for ; Tue, 8 Feb 2011 01:28:37 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 64AD83A6CC4 for ; Tue, 8 Feb 2011 01:28:35 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 8 Feb 2011 10:28:34 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id A1A023A141 for ; Tue, 8 Feb 2011 10:28:33 +0100 (CET) Message-ID: <4D510CC4.2050605@omnitor.se> Date: Tue, 08 Feb 2011 10:28:36 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ecrit@ietf.org References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com> <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com> In-Reply-To: <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 09:28:37 -0000 I think I discussed a need for a minor change in September. It is in the Media chapter 14. This statement: "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both [RFC3428] and [RFC4975]." It looks strange to require both IM protocols of the endpoint. Usually they support one. The requirement would be suitable for a PSAP. So, the agreement was to change to: "ED-75 Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975]." ( maybe there is now even an interest to add XMPP to that list, or do we then open for a heap of complications regarding addressing and location information etc. ) I do not regard this to be a subtantial issue, so I did not want to bother the ietf mail list with it. /Gunnar ------------------------------------------------------------------------ >> At 04:37 PM 2/7/2011, Robert Sparks wrote: >>> All - >>> >>> I've requested IETFLC for the phonebcp draft. There are still some outstanding questions/comments from John Elwell that should be treated as last call comments. >>> Also, something needs to register the sos.*.test URNs. I think this document could do that. >>> >>> RjS >>> _______________________________________________ >>> 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 bernard_aboba@hotmail.com Tue Feb 8 05:33:10 2011 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 8D5623A7134 for ; Tue, 8 Feb 2011 05:33:10 -0800 (PST) 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 QDvtoudOXntN for ; Tue, 8 Feb 2011 05:33:09 -0800 (PST) Received: from blu0-omc3-s2.blu0.hotmail.com (blu0-omc3-s2.blu0.hotmail.com [65.55.116.77]) by core3.amsl.com (Postfix) with ESMTP id 580183A6CAE for ; Tue, 8 Feb 2011 05:33:09 -0800 (PST) Received: from BLU152-W48 ([65.55.116.72]) by blu0-omc3-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 05:33:15 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d1aa194a-7e4f-4438-afff-f2e5a7ccbd33_" X-Originating-IP: [12.191.171.2] From: Bernard Aboba To: , Date: Tue, 8 Feb 2011 05:33:15 -0800 Importance: Normal In-Reply-To: <4D510CC4.2050605@omnitor.se> References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com>, <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com>, <4D510CC4.2050605@omnitor.se> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2011 13:33:15.0643 (UTC) FILETIME=[BD5F7CB0:01CBC794] Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 13:33:10 -0000 --_d1aa194a-7e4f-4438-afff-f2e5a7ccbd33_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with this comment -- both should be required in the PSAP=2C not the= endpoint.=20 On XMPP support for emergency services=2C that is probably something to bring to the XMPP WG (or the XSF). The question will remain open until there is documentation=2C either describing how it can be done=2C or explaining why it is not supported. Until then=2C phonebcp should probably remain silent.=20 > Date: Tue=2C 8 Feb 2011 10:28:36 +0100 > From: gunnar.hellstrom@omnitor.se > To: ecrit@ietf.org > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue >=20 > I think I discussed a need for a minor change in September. >=20 > It is in the Media chapter 14. >=20 > This statement: > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both=20 > [RFC3428] and [RFC4975]." >=20 > It looks strange to require both IM protocols of the endpoint. Usually=20 > they support one. The requirement would be suitable for a PSAP. >=20 > So=2C the agreement was to change to: >=20 > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support either=20 > [RFC3428] or [RFC4975]." >=20 > ( maybe there is now even an interest to add XMPP to that list=2C or do w= e=20 > then open for a heap of complications regarding addressing and location=20 > information etc. ) >=20 > I do not regard this to be a subtantial issue=2C so I did not want to=20 > bother the ietf mail list with it. >=20 > /Gunnar > ------------------------------------------------------------------------ > >> At 04:37 PM 2/7/2011=2C Robert Sparks wrote: > >>> All - > >>> > >>> I've requested IETFLC for the phonebcp draft. There are still some ou= tstanding questions/comments from John Elwell that should be treated as las= t call comments. > >>> Also=2C something needs to register the sos.*.test URNs. I think this= document could do that. > >>> > >>> RjS > >>> _______________________________________________ > >>> 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 = --_d1aa194a-7e4f-4438-afff-f2e5a7ccbd33_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with this comment -- both should be required in the PSAP=2C not the= endpoint.

On XMPP support for emergency services=2C that is probab= ly something
to bring to the XMPP WG (or the XSF). =3B The question = will remain open
until there is documentation=2C either describing how i= t can be done=2C or
explaining why it is not supported. =3B Until th= en=2C phonebcp should probably
remain silent.


>=3B Date: T= ue=2C 8 Feb 2011 10:28:36 +0100
>=3B From: gunnar.hellstrom@omnitor.se=
>=3B To: ecrit@ietf.org
>=3B Subject: Re: [Ecrit] Requesting IET= F LC for phonebcp - Minor IM issue
>=3B
>=3B I think I discussed= a need for a minor change in September.
>=3B
>=3B It is in the = Media chapter 14.
>=3B
>=3B This statement:
>=3B "ED-75 End= points supporting Instant Messaging (IM) MUST support both
>=3B [RFC3= 428] and [RFC4975]."
>=3B
>=3B It looks strange to require both = IM protocols of the endpoint. Usually
>=3B they support one. The req= uirement would be suitable for a PSAP.
>=3B
>=3B So=2C the agree= ment was to change to:
>=3B
>=3B "ED-75 Endpoints supporting Ins= tant Messaging (IM) MUST support either
>=3B [RFC3428] or [RFC4975]."=
>=3B
>=3B ( maybe there is now even an interest to add XMPP to = that list=2C or do we
>=3B then open for a heap of complications rega= rding addressing and location
>=3B information etc. )
>=3B
&= gt=3B I do not regard this to be a subtantial issue=2C so I did not want to=
>=3B bother the ietf mail list with it.
>=3B
>=3B /Gunnar=
>=3B ----------------------------------------------------------------= --------
>=3B >=3B>=3B At 04:37 PM 2/7/2011=2C Robert Sparks wrote= :
>=3B >=3B>=3B>=3B All -
>=3B >=3B>=3B>=3B
>=3B= >=3B>=3B>=3B I've requested IETFLC for the phonebcp draft. There are= still some outstanding questions/comments from John Elwell that should be = treated as last call comments.
>=3B >=3B>=3B>=3B Also=2C somethi= ng needs to register the sos.*.test URNs. I think this document could do th= at.
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B RjS
>=3B= >=3B>=3B>=3B _______________________________________________
>= =3B >=3B>=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B Ecri= t@ietf.org
>=3B >=3B>=3B>=3B https://www.ietf.org/mailman/listin= fo/ecrit
>=3B >=3B _______________________________________________>=3B >=3B Ecrit mailing list
>=3B >=3B Ecrit@ietf.org
>= =3B >=3B https://www.ietf.org/mailman/listinfo/ecrit
>=3B __________= _____________________________________
>=3B Ecrit mailing list
>= =3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/ecrit = --_d1aa194a-7e4f-4438-afff-f2e5a7ccbd33_-- From br@brianrosen.net Tue Feb 8 07:29:58 2011 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 B45AE3A6784 for ; Tue, 8 Feb 2011 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[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 iBNjOkFIIt4l for ; Tue, 8 Feb 2011 07:29:56 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 9C4383A6765 for ; Tue, 8 Feb 2011 07:29:56 -0800 (PST) X-ASG-Debug-ID: 1297178095-00f27e0f8316cd30001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id oa2dLEYnn08iRLKj; Tue, 08 Feb 2011 07:14:55 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.213]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PmpHC-00080Q-OW; Tue, 08 Feb 2011 07:14:53 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue Content-Type: multipart/alternative; boundary=Apple-Mail-1-1043291877 From: Brian Rosen In-Reply-To: Date: Tue, 8 Feb 2011 10:14:31 -0500 Message-Id: <1B44C0C7-C0BF-4FCF-93A9-08610F63DE84@brianrosen.net> References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com>, <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com>, <4D510CC4.2050605@omnitor.se> To: Bernard Aboba X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1297178095 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.54746 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: ecrit@ietf.org Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 15:29:58 -0000 --Apple-Mail-1-1043291877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, I agree. I'm certain we will have a rev due to LC comments, and I will fix the = text in that rev. concur with Bernard on xmpp. Brian On Feb 8, 2011, at 8:33 AM, Bernard Aboba wrote: > I agree with this comment -- both should be required in the PSAP, not = the endpoint.=20 >=20 > On XMPP support for emergency services, that is probably something > to bring to the XMPP WG (or the XSF). The question will remain open > until there is documentation, either describing how it can be done, or > explaining why it is not supported. Until then, phonebcp should = probably > remain silent.=20 >=20 >=20 > > Date: Tue, 8 Feb 2011 10:28:36 +0100 > > From: gunnar.hellstrom@omnitor.se > > To: ecrit@ietf.org > > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM = issue > >=20 > > I think I discussed a need for a minor change in September. > >=20 > > It is in the Media chapter 14. > >=20 > > This statement: > > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both=20= > > [RFC3428] and [RFC4975]." > >=20 > > It looks strange to require both IM protocols of the endpoint. = Usually=20 > > they support one. The requirement would be suitable for a PSAP. > >=20 > > So, the agreement was to change to: > >=20 > > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support = either=20 > > [RFC3428] or [RFC4975]." > >=20 > > ( maybe there is now even an interest to add XMPP to that list, or = do we=20 > > then open for a heap of complications regarding addressing and = location=20 > > information etc. ) > >=20 > > I do not regard this to be a subtantial issue, so I did not want to=20= > > bother the ietf mail list with it. > >=20 > > /Gunnar > > = ------------------------------------------------------------------------ > > >> At 04:37 PM 2/7/2011, Robert Sparks wrote: > > >>> All - > > >>> > > >>> I've requested IETFLC for the phonebcp draft. There are still = some outstanding questions/comments from John Elwell that should be = treated as last call comments. > > >>> Also, something needs to register the sos.*.test URNs. I think = this document could do that. > > >>> > > >>> RjS > > >>> _______________________________________________ > > >>> 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-1-1043291877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, I agree.

I'm certain we = will have a rev due to LC comments, and I will fix the text in that = rev.

concur with Bernard on = xmpp.

Brian

On Feb 8, = 2011, at 8:33 AM, Bernard Aboba wrote:

I = agree with this comment -- both should be required in the PSAP, not the = endpoint. 

On = XMPP support for emergency services, that is probably something
to = bring to the XMPP WG (or the XSF).  The question will remain = open
until there is documentation, either describing how it can be = done, or
explaining why it is not supported.  Until then, = phonebcp should probably
remain silent. 


> Date: Tue, = 8 Feb 2011 10:28:36 +0100
> From: gunnar.hellstrom@omnitor.se
> To: ecrit@ietf.org
> Subject: Re: = [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue
> 
> I think I = discussed a need for a minor change in September.
> 
> It is in the Media = chapter 14.
> 
> This = statement:
> "ED-75 Endpoints supporting Instant Messaging (IM) = MUST support both 
> [RFC3428] and = [RFC4975]."
> 
> It looks strange = to require both IM protocols of the endpoint. Usually 
> they support one. = The requirement would be suitable for a PSAP.
> 
> So, the agreement = was to change to:
> 
> "ED-75 Endpoints = supporting Instant Messaging (IM) MUST support either 
> [RFC3428] or = [RFC4975]."
> 
> ( maybe there is = now even an interest to add XMPP to that list, or do we 
> then open for a = heap of complications regarding addressing and location 
> information etc. = )
> 
> I = do not regard this to be a subtantial issue, so I did not want to 
> bother the ietf = mail list with it.
> 
> /Gunnar
> = ------------------------------------------------------------------------> >> At 04:37 PM 2/7/2011, Robert Sparks wrote:
> = >>> All -
> >>>
> >>> I've = requested IETFLC for the phonebcp draft. There are still some = outstanding questions/comments from John Elwell that should be treated = as last call comments.
> >>> Also, something needs to = register the sos.*.test URNs. I think this document could do = that.
> >>>
> >>> RjS
> >>> = _______________________________________________
> >>> = 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
____________________________________________= ___
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail-1-1043291877-- From bernard_aboba@hotmail.com Tue Feb 8 07:41:31 2011 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 C86473A67AD for ; Tue, 8 Feb 2011 07:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 HBF8Kg5WSnEK for ; Tue, 8 Feb 2011 07:41:30 -0800 (PST) Received: from blu0-omc2-s12.blu0.hotmail.com (blu0-omc2-s12.blu0.hotmail.com [65.55.111.87]) by core3.amsl.com (Postfix) with ESMTP id 980073A6765 for ; Tue, 8 Feb 2011 07:41:30 -0800 (PST) Received: from BLU152-W13 ([65.55.111.73]) by blu0-omc2-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 07:41:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_32a29a35-c3a2-4bf2-9a95-b8606ff7b62e_" X-Originating-IP: [12.191.171.2] From: Bernard Aboba To: Date: Tue, 8 Feb 2011 07:41:37 -0800 Importance: Normal In-Reply-To: <1B44C0C7-C0BF-4FCF-93A9-08610F63DE84@brianrosen.net> References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com>, <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com>, <4D510CC4.2050605@omnitor.se> , <1B44C0C7-C0BF-4FCF-93A9-08610F63DE84@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2011 15:41:37.0249 (UTC) FILETIME=[ABE34D10:01CBC7A6] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 15:41:31 -0000 --_32a29a35-c3a2-4bf2-9a95-b8606ff7b62e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI=2C I raised the question of support for emergency services on the XMPP = WG mailing list (see http://www.ietf.org/mail-archive/web/xmpp/current/msg0= 2388.html ).=20 Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue From: br@brianrosen.net Date: Tue=2C 8 Feb 2011 10:14:31 -0500 CC: gunnar.hellstrom@omnitor.se=3B ecrit@ietf.org To: bernard_aboba@hotmail.com Yes=2C I agree. I'm certain we will have a rev due to LC comments=2C and I will fix the tex= t in that rev. concur with Bernard on xmpp. Brian On Feb 8=2C 2011=2C at 8:33 AM=2C Bernard Aboba wrote:I agree with this com= ment -- both should be required in the PSAP=2C not the endpoint.=20 On XMPP support for emergency services=2C that is probably something to bring to the XMPP WG (or the XSF). The question will remain open until there is documentation=2C either describing how it can be done=2C or explaining why it is not supported. Until then=2C phonebcp should probably remain silent.=20 > Date: Tue=2C 8 Feb 2011 10:28:36 +0100 > From: gunnar.hellstrom@omnitor.se > To: ecrit@ietf.org > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue >=20 > I think I discussed a need for a minor change in September. >=20 > It is in the Media chapter 14. >=20 > This statement: > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both=20 > [RFC3428] and [RFC4975]." >=20 > It looks strange to require both IM protocols of the endpoint. Usually=20 > they support one. The requirement would be suitable for a PSAP. >=20 > So=2C the agreement was to change to: >=20 > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support either=20 > [RFC3428] or [RFC4975]." >=20 > ( maybe there is now even an interest to add XMPP to that list=2C or do w= e=20 > then open for a heap of complications regarding addressing and location=20 > information etc. ) >=20 > I do not regard this to be a subtantial issue=2C so I did not want to=20 > bother the ietf mail list with it. >=20 > /Gunnar > ------------------------------------------------------------------------ > >> At 04:37 PM 2/7/2011=2C Robert Sparks wrote: > >>> All - > >>> > >>> I've requested IETFLC for the phonebcp draft. There are still some ou= tstanding questions/comments from John Elwell that should be treated as las= t call comments. > >>> Also=2C something needs to register the sos.*.test URNs. I think this= document could do that. > >>> > >>> RjS > >>> _______________________________________________ > >>> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit = --_32a29a35-c3a2-4bf2-9a95-b8606ff7b62e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI=2C I raised the question of support for emergency services on the XMPP = WG mailing list (see http://www.ietf.org/mail-archive/web/xmpp/current/msg0= 2388.html ).

Subject: Re: [Ecrit] Requestin= g IETF LC for phonebcp - Minor IM issue
From: br@brianrosen.net
Date:= Tue=2C 8 Feb 2011 10:14:31 -0500
CC: gunnar.hellstrom@omnitor.se=3B ecr= it@ietf.org
To: bernard_aboba@hotmail.com

Yes=2C I agre= e.

I'm certain we will have a rev due to LC comments=2C = and I will fix the text in that rev.

concur with B= ernard on xmpp.

Brian

On F= eb 8=2C 2011=2C at 8:33 AM=2C Bernard Aboba wrote:

I agr= ee with this comment -- both should be required in the PSAP=2C not the endp= oint. =3B

On XMP= P support for emergency services=2C that is probably something
to bring = to the XMPP WG (or the XSF). =3B The question will remain open
until= there is documentation=2C either describing how it can be done=2C or
ex= plaining why it is not supported. =3B Until then=2C phonebcp should pro= bably
remain silent. =3B


>=3B Date: Tue=2C 8 Feb 2011 10:28:36 +0100
>=3B Fro= m: =3Bgunnar.hellstrom@omnitor.se
>=3B To:=  =3Becrit@ietf.org
>=3B Subject: Re: [Ecrit] Requesting= IETF LC for phonebcp - Minor IM issue
>=3B =3B
>=3B I think I discussed a need for a mi= nor change in September.
>=3B=  =3B
>=3B It is in the Media chapter 14.
>=3B =3B
>=3B This statement:>=3B "ED-75 Endpoints supporting Instant Messaging (IM) MUST support bo= th =3B
>=3B [RFC34= 28] and [RFC4975]."
>=3B = =3B
>=3B It looks strange to require both IM protocols of the e= ndpoint. Usually =3B>=3B they support one. The requirement would be suitable for a PSAP.
= >=3B =3B
>=3B So= =2C the agreement was to change to:
>=3B =3B
>=3B "ED-75 Endpoints supporting Instant Me= ssaging (IM) MUST support either&n= bsp=3B
>=3B [RFC3428] or [RFC4975]."
>=3B =3B
>=3B ( maybe there is now even= an interest to add XMPP to that list=2C or do we =3B
>=3B then open for a heap of complicati= ons regarding addressing and location =3B
>=3B information etc. )
>=3B =3B
>=3B I do not regard this to be= a subtantial issue=2C so I did not want to =3B
>=3B bother the ietf mail list with it.
&g= t=3B =3B
>=3B /Gun= nar
>=3B -------------------------------------------------------------= -----------
>=3B >=3B>=3B At 04:37 PM 2/7/2011=2C Robert Sparks wr= ote:
>=3B >=3B>=3B>=3B All -
>=3B >=3B>=3B>=3B
>= =3B >=3B>=3B>=3B I've requested IETFLC for the phonebcp draft. There = are still some outstanding questions/comments from John Elwell that should = be treated as last call comments.
>=3B >=3B>=3B>=3B Also=2C some= thing needs to register the sos.*.test URNs. I think this document could do= that.
>=3B >=3B>=3B>=3B
>=3B >=3B>=3B>=3B RjS
>= =3B >=3B>=3B>=3B _______________________________________________
&= gt=3B >=3B>=3B>=3B Ecrit mailing list
>=3B >=3B>=3B>=3B =3BEcrit@ietf.org
>=3B >=3B>=3B>=3B =3Bhttps://www.ietf.org/mailman/listinf= o/ecrit
>=3B >=3B ______________________________________________= _
>=3B >=3B Ecrit mailing list
>=3B >=3B =3BEcrit@= ietf.org
>=3B >=3B = =3Bhttps://www.ietf.org/mailman/listinfo/ecrit
>=3B ________= _______________________________________
>=3B Ecrit mailing list
>= =3B =3BEcrit@ietf.org
>=3B =3Bhttps://www.ietf.org/mailman/listinfo/ecrit_______________________________________________
Ecrit mailing list
= Ecrit@ietf.org
https://www.ietf.org= /mailman/listinfo/ecrit

= = --_32a29a35-c3a2-4bf2-9a95-b8606ff7b62e_-- From rbarnes@bbn.com Tue Feb 8 12:25:45 2011 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 32BA23A6857 for ; Tue, 8 Feb 2011 12:25:45 -0800 (PST) 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=[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 udQJPkBg+ZIt for ; Tue, 8 Feb 2011 12:25:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E6D5A3A672E for ; Tue, 8 Feb 2011 12:25:42 -0800 (PST) Received: from [128.89.252.183] (port=63205 helo=[10.242.10.142]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pmu8D-000I2r-QB; Tue, 08 Feb 2011 15:25:50 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1B44C0C7-C0BF-4FCF-93A9-08610F63DE84@brianrosen.net> Date: Tue, 8 Feb 2011 14:25:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201102072250.p17MoB5T019815@rcdn-core2-6.cisco.com>, <56B8D23B-9A04-4547-B144-EEEB77BF4AF8@nostrum.com>, <4D510CC4.2050605@omnitor.se> <1B44C0C7-C0BF-4FCF-93A9-08610F63DE84@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 20:25:45 -0000 (I saw this on the XMPP list first, so my extended reply is there. I = just sent it, so can't provide a link yet.) I do not think we should add XMPP to phonebcp at this point. Even = though XMPP for emergency services is a great idea, it would not be a = trivial addition. Let's let phonebcp go to RFC and handle XMPP in an = update. --Richard On Feb 8, 2011, at 9:14 AM, Brian Rosen wrote: > Yes, I agree. >=20 > I'm certain we will have a rev due to LC comments, and I will fix the = text in that rev. >=20 > concur with Bernard on xmpp. >=20 > Brian >=20 > On Feb 8, 2011, at 8:33 AM, Bernard Aboba wrote: >=20 >> I agree with this comment -- both should be required in the PSAP, not = the endpoint.=20 >>=20 >> On XMPP support for emergency services, that is probably something >> to bring to the XMPP WG (or the XSF). The question will remain open >> until there is documentation, either describing how it can be done, = or >> explaining why it is not supported. Until then, phonebcp should = probably >> remain silent.=20 >>=20 >>=20 >> > Date: Tue, 8 Feb 2011 10:28:36 +0100 >> > From: gunnar.hellstrom@omnitor.se >> > To: ecrit@ietf.org >> > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM = issue >> >=20 >> > I think I discussed a need for a minor change in September. >> >=20 >> > It is in the Media chapter 14. >> >=20 >> > This statement: >> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support = both=20 >> > [RFC3428] and [RFC4975]." >> >=20 >> > It looks strange to require both IM protocols of the endpoint. = Usually=20 >> > they support one. The requirement would be suitable for a PSAP. >> >=20 >> > So, the agreement was to change to: >> >=20 >> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support = either=20 >> > [RFC3428] or [RFC4975]." >> >=20 >> > ( maybe there is now even an interest to add XMPP to that list, or = do we=20 >> > then open for a heap of complications regarding addressing and = location=20 >> > information etc. ) >> >=20 >> > I do not regard this to be a subtantial issue, so I did not want to=20= >> > bother the ietf mail list with it. >> >=20 >> > /Gunnar >> > = ------------------------------------------------------------------------ >> > >> At 04:37 PM 2/7/2011, Robert Sparks wrote: >> > >>> All - >> > >>> >> > >>> I've requested IETFLC for the phonebcp draft. There are still = some outstanding questions/comments from John Elwell that should be = treated as last call comments. >> > >>> Also, something needs to register the sos.*.test URNs. I think = this document could do that. >> > >>> >> > >>> RjS >> > >>> _______________________________________________ >> > >>> 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 >> _______________________________________________ >> 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 mlinsner@cisco.com Tue Feb 8 12:39:19 2011 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 D975E3A6859 for ; Tue, 8 Feb 2011 12:39:19 -0800 (PST) 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 H-r2IFwuCO1w for ; Tue, 8 Feb 2011 12:39:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 94FEC3A6835 for ; Tue, 8 Feb 2011 12:39:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHc4UU1AZnwM/2dsb2JhbAClOHOhT5s5hVoEhHuGb4Mu Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 20:39:26 +0000 Received: from [10.116.195.126] (rtp-mlinsner-87113.cisco.com [10.116.195.126]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18KdPDd019689 for ; Tue, 8 Feb 2011 20:39:25 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 08 Feb 2011 15:39:20 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 20:39:20 -0000 +1 -----Original Message----- From: "Richard L. Barnes" Date: Tue, 8 Feb 2011 14:25:46 -0600 To: Brian Rosen Cc: Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue > > >(I saw this on the XMPP list first, so my extended reply is there. I >just sent it, so can't provide a link yet.) > >I do not think we should add XMPP to phonebcp at this point. Even though >XMPP for emergency services is a great idea, it would not be a trivial >addition. Let's let phonebcp go to RFC and handle XMPP in an update. > >--Richard > > > > >On Feb 8, 2011, at 9:14 AM, Brian Rosen wrote: > >> Yes, I agree. >> >> I'm certain we will have a rev due to LC comments, and I will fix the >>text in that rev. >> >> concur with Bernard on xmpp. >> >> Brian >> >> On Feb 8, 2011, at 8:33 AM, Bernard Aboba wrote: >> >>> I agree with this comment -- both should be required in the PSAP, not >>>the endpoint. >>> >>> On XMPP support for emergency services, that is probably something >>> to bring to the XMPP WG (or the XSF). The question will remain open >>> until there is documentation, either describing how it can be done, or >>> explaining why it is not supported. Until then, phonebcp should >>>probably >>> remain silent. >>> >>> >>> > Date: Tue, 8 Feb 2011 10:28:36 +0100 >>> > From: gunnar.hellstrom@omnitor.se >>> > To: ecrit@ietf.org >>> > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue >>> > >>> > I think I discussed a need for a minor change in September. >>> > >>> > It is in the Media chapter 14. >>> > >>> > This statement: >>> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both >>> > [RFC3428] and [RFC4975]." >>> > >>> > It looks strange to require both IM protocols of the endpoint. >>>Usually >>> > they support one. The requirement would be suitable for a PSAP. >>> > >>> > So, the agreement was to change to: >>> > >>> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support >>>either >>> > [RFC3428] or [RFC4975]." >>> > >>> > ( maybe there is now even an interest to add XMPP to that list, or >>>do we >>> > then open for a heap of complications regarding addressing and >>>location >>> > information etc. ) >>> > >>> > I do not regard this to be a subtantial issue, so I did not want to >>> > bother the ietf mail list with it. >>> > >>> > /Gunnar >>> > >>>------------------------------------------------------------------------ >>> > >> At 04:37 PM 2/7/2011, Robert Sparks wrote: >>> > >>> All - >>> > >>> >>> > >>> I've requested IETFLC for the phonebcp draft. There are still >>>some outstanding questions/comments from John Elwell that should be >>>treated as last call comments. >>> > >>> Also, something needs to register the sos.*.test URNs. I think >>>this document could do that. >>> > >>> >>> > >>> RjS >>> > >>> _______________________________________________ >>> > >>> 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 >>> _______________________________________________ >>> 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 Feb 8 15:17:59 2011 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 6D2323A67A1 for ; Tue, 8 Feb 2011 15:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.54 X-Spam-Level: X-Spam-Status: No, score=-110.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 FrmYDMqVo7YX for ; Tue, 8 Feb 2011 15:17:58 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 840FE3A6841 for ; Tue, 8 Feb 2011 15:17:58 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 23:18:06 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18NI6oh029374; Tue, 8 Feb 2011 23:18:06 GMT Message-Id: <201102082318.p18NI6oh029374@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Feb 2011 17:18:05 -0600 To: Marc Linsner , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue 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, 08 Feb 2011 23:17:59 -0000 + another At 02:39 PM 2/8/2011, Marc Linsner wrote: >+1 > >-----Original Message----- >From: "Richard L. Barnes" >Date: Tue, 8 Feb 2011 14:25:46 -0600 >To: Brian Rosen >Cc: >Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue > > > > > > >(I saw this on the XMPP list first, so my extended reply is there. I > >just sent it, so can't provide a link yet.) > > > >I do not think we should add XMPP to phonebcp at this point. Even though > >XMPP for emergency services is a great idea, it would not be a trivial > >addition. Let's let phonebcp go to RFC and handle XMPP in an update. > > > >--Richard > > > > > > > > > >On Feb 8, 2011, at 9:14 AM, Brian Rosen wrote: > > > >> Yes, I agree. > >> > >> I'm certain we will have a rev due to LC comments, and I will fix the > >>text in that rev. > >> > >> concur with Bernard on xmpp. > >> > >> Brian > >> > >> On Feb 8, 2011, at 8:33 AM, Bernard Aboba wrote: > >> > >>> I agree with this comment -- both should be required in the PSAP, not > >>>the endpoint. > >>> > >>> On XMPP support for emergency services, that is probably something > >>> to bring to the XMPP WG (or the XSF). The question will remain open > >>> until there is documentation, either describing how it can be done, or > >>> explaining why it is not supported. Until then, phonebcp should > >>>probably > >>> remain silent. > >>> > >>> > >>> > Date: Tue, 8 Feb 2011 10:28:36 +0100 > >>> > From: gunnar.hellstrom@omnitor.se > >>> > To: ecrit@ietf.org > >>> > Subject: Re: [Ecrit] Requesting IETF LC for phonebcp - Minor IM issue > >>> > > >>> > I think I discussed a need for a minor change in September. > >>> > > >>> > It is in the Media chapter 14. > >>> > > >>> > This statement: > >>> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support both > >>> > [RFC3428] and [RFC4975]." > >>> > > >>> > It looks strange to require both IM protocols of the endpoint. > >>>Usually > >>> > they support one. The requirement would be suitable for a PSAP. > >>> > > >>> > So, the agreement was to change to: > >>> > > >>> > "ED-75 Endpoints supporting Instant Messaging (IM) MUST support > >>>either > >>> > [RFC3428] or [RFC4975]." > >>> > > >>> > ( maybe there is now even an interest to add XMPP to that list, or > >>>do we > >>> > then open for a heap of complications regarding addressing and > >>>location > >>> > information etc. ) > >>> > > >>> > I do not regard this to be a subtantial issue, so I did not want to > >>> > bother the ietf mail list with it. > >>> > > >>> > /Gunnar > >>> > > >>>------------------------------------------------------------------------ > >>> > >> At 04:37 PM 2/7/2011, Robert Sparks wrote: > >>> > >>> All - > >>> > >>> > >>> > >>> I've requested IETFLC for the phonebcp draft. There are still > >>>some outstanding questions/comments from John Elwell that should be > >>>treated as last call comments. > >>> > >>> Also, something needs to register the sos.*.test URNs. I think > >>>this document could do that. > >>> > >>> > >>> > >>> RjS > >>> > >>> _______________________________________________ > >>> > >>> 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 > >>> _______________________________________________ > >>> 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 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Mon Feb 21 05:28:55 2011 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 F134D3A6F97 for ; Mon, 21 Feb 2011 05:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 XBW8M6qUEk+H for ; Mon, 21 Feb 2011 05:28:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 0A2CD3A6F37 for ; Mon, 21 Feb 2011 05:28:52 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2011 13:29:33 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp047) with SMTP; 21 Feb 2011 14:29:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/MUudfgAHMRl6nYhq8m2Fp01LbmllYIzZzxACXkQ +vm0FMxKUz30FK From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2011 15:29:31 +0200 Message-Id: <65BBFC7F-D8EA-47D3-AC34-EBF169CCC179@gmx.net> To: ecrit , geopriv@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [Ecrit] Reminder to register for the 8th Emergency Services Workshop 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, 21 Feb 2011 13:28:55 -0000 Hi all,=20 This is a reminder to register for the 8th Emergency Services Workshop = (ESW8). Most of you are familiar with our series of emergency services = workshops, which date back to our first workshop in 2006. Many of us = will get together in Budapest on 13-15 April 2011 to discuss current = challenges in the emergency services work and to reach out to those = deploying emergency services systems in Europe.=20 I believe we have put together a really nice workshop agenda for you. If = you follow the links on the workshop page, = http://www.emergency-services-coordination.info/esw8.html, you will find = the more recent agenda and also further information about our meeting = venue.=20 I am looking forward to see you at the workshop! Ciao Hannes From br@brianrosen.net Tue Feb 22 10:24:25 2011 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 7101C3A695D for ; Tue, 22 Feb 2011 10:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.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 8r4bdCzWZo7k for ; Tue, 22 Feb 2011 10:24:24 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id EE63F3A68C8 for ; Tue, 22 Feb 2011 10:24:23 -0800 (PST) X-ASG-Debug-ID: 1298399103-011a9f1754ea410003-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id obQdBhumub8AiDXN; Tue, 22 Feb 2011 10:25:03 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=malt-lt60.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Prwo9-0001CD-VW; Tue, 22 Feb 2011 10:18:03 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4D61266D.1030104@ericsson.com> Date: Tue, 22 Feb 2011 13:17:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D61266D.1030104@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1298399103 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.56091 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: ecrit Org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.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: Tue, 22 Feb 2011 18:24:25 -0000 Thank you for this review. It shows once again what a brand new set of = eyes can do for document. My thanks, again, to all the GenART = reviewers and the system. See inline for my responses On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft. For background on Gen-ART, please see the FAQ = at >=20 > Please resolve these comments along with any other comments you may = receive. >=20 > Document: draft-ietf-ecrit-phonebcp-16.txt > Reviewer: Miguel Garcia > Review Date: 2011-02-20 > IETF LC End Date: 2011-02-21 >=20 > Summary: This draft is on the right track but has open issues, = described in the review. >=20 > Major issues: None >=20 > Minor issues: >=20 > - I don't understand the last sentence in Section 6.2.1, which reads: >=20 > Where a civic form of location is provided, all > fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be > specified. >=20 > what I don't understand is the meaning of "MUST be able to be = specified". And I don't understand if this is a requirement for the = service provider, for the access network, or for the end device. Can you = explain what is the intention of the sentence? The notion is that the location configuration protocol may generate a = PIDF that contains any of the elements defined in 4119/5139. All = downstream elements must pass all fields. It applies to all the = entities. Any suggestions for rewording to make this more clear would = be appreciated. >=20 >=20 >=20 > - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem = with the sentence that reads: >=20 > If the access network supports more than one location > configuration protocol, all such protocols MUST return the same > location, within the constraints of the protocols deployed. >=20 > I don't understand how this requirement can be achieved. Assume that = an access network supports several location configuration protocols, = which are able to determine the location by different means. Ideally all = protocols should return the same location, but in practice, it will be = difficult, due to the different accuracy and confidence among the = various protocols. Additionally, I believe there is nothing the access = network administrator can do to make sure that all location protocols = will return the same location for a given device. >=20 > Conclusion: I consider this sentence to be a hope rather than a = requirement. Perhaps it can be rephrased saying that ".... it is = expected that all such protocols will return the same location ....". This is a PROTOCOL issue and not a location determination issue. Think = of the protocol as being a transport mechanism for the location. Each = transport must return the same location. This is saying if you have = more than one protocol and more than one location determination = mechanism, all protocols must return the same location >=20 >=20 >=20 > - Section 6.5., requirement AN-15/INT-17. It seems that this = requirement is duplicated from the second sentence of requirements = AN-13/INT-14 (see my previous comment). So, there should be only one = requirement with the same text, and my previous comment should apply. Yes, that is a problem. I propose to delete the sentence in the prior = section, and leave this one. >=20 >=20 >=20 > - Section 7, Requirement ED-51. I think this requirement also applies = to the Service Provider (at least the configuration part of it), so it = should get an SP number as well. Yeah, I see the problem. It might be easier to just delete the = sentence, but I could add an AN requirement. Anyone else have an = opinion? >=20 >=20 >=20 > - Section 9.2, first bullet point. The text reads: >=20 > If > the device cannot interpret local dial strings, the Request-URI > SHOULD be a dial string URI [RFC4967] with the dialed digits. >=20 > I don't understand how this requirement can be enforced. If someone = has not read this document and has not implemented local dial strings, = how can you put a requirement around dial string URIs to that person who = has not implemented dial string URIs and possibly not read your draft? If the device implementer didn't read the document, then it wouldn't = conform to this document. If they did, then they should use dial = strings. The device generates this, it doesn't get it from other = entity. I don't understand the problem. >=20 > Perhaps you can say that "it is expected that ...", but not placing a = formal requirement. >=20 > This comment also applies to bullet point 2 in the same Section 9.2, = regarding the To header field. Same response. >=20 >=20 >=20 > - Section 9.2, bullet point 10. The text reads: >=20 > A SDP offer SHOULD be included in the INVITE. If voice is > supported the offer MUST include the G.711 codec, see > Section 14. >=20 > Honestly, this is an unrealistic requirement. G.711 is well known for = its bandwidth consumption. Due to this, as far as I know, there is no = cellular network in the world that support or uses G.711 either in = circuit-switched or VoIP. I don't think this draft is going to change = the current status quo. Actually, none has ever got to standardize a = single codec for an application. Due to this, protocols like SIP/SDP = support an codec negotiation mechanism in the format of the SDP offer = answer. >=20 > Other considerations: >=20 > The requirement is nod needed, because in the absence of it, SDP offer = answer will get to negotiate to a single codec for the emergency call. >=20 > This requirement falls into the category of national or supranational = regulation. There will be organisms which will dictate minimum or = recommended support in terms of codecs, and this regulation will be = above the requirements in this document. >=20 > My recommendation is to delete this requirement. >=20 > I also noticed that this requirement is also repeated in Section 14, = Requirement AD-73. The recommendation is also to delete such = requirement. >=20 > Also, req ED-77 in Section 14 tries to do the same with a video codec. = The recommendation is still the same. This has been discussed before. The goal is to be able to have any = device, anywhere, be able to complete an emergency call. To make that = work, you have to have at least one common codec. It's not something a = local regulation could fix: when you get off a plane, your softclient on = your VoIP service provider, must be able to complete an emergency call = where you are. The alternative is to have the document have a requirement on PSAPs to = implement a relatively long list of codecs, and then have each device = implement at least one of those. That would be quite difficult to make = such a list, and even if you did, some service would have a problem. >=20 >=20 >=20 > - Section 12, the text reads: >=20 > Dropping of the old call MUST only > occur if the user is attempting to hang up >=20 > But the previous sentence says: >=20 > If in the interval, an incoming call is received from > the domain of the PSAP, the device MUST drop the old call and alert > for the (new) incoming call. >=20 > So, we have two scenarios for dropping an old call: > 1) the user is attempting to hung up > 2) an incoming call is received from the PSAP >=20 > Therefore, I disagree with the "MUST only occur" of the first = sentence. Please rephrase the text to avoid contradictions. Is see your point. In SIP, hang up requires the complete BYE = transaction, and you can be in the middle of that transaction when the = new call arrives. The problem is the word "drop". What we are = attempting to say is that even though you are in the middle of that = transaction, you have to abandon it, and accept the new call. So I need = a better word for "drop". >=20 >=20 >=20 >=20 >=20 > Nits: >=20 > - Expands acronyms at first occurrence. This includes: PSAP, PIDF, = PIDF-LO, HELD, LCP, and LoST. the terminology sections says: This document uses terms from [RFC3261], [RFC5012] and = [I-D.ietf-ecrit-framework]. I thought that would be enough. I can expand the acronyms here. >=20 > - Section 9.2, first bullet point > s/tree, If/tree. If >=20 > - Section 9.2, second bullet point > s/not find a a Router/not find a Router >=20 > - Section 11 > s/and the Referred-by: header/and the Referred-by header Thanks, I'll fix these >=20 >=20 > BR, >=20 > Miguel >=20 >=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain