From fmenard@xittel.net Thu Jun 17 09:21:26 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7B328C111 for ; Thu, 17 Jun 2010 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.815 X-Spam-Level: *** X-Spam-Status: No, score=3.815 tagged_above=-999 required=5 tests=[BAYES_99=3.5, SARE_MILLIONSOF=0.315] 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 Pn6zSCIeV7JL for ; Thu, 17 Jun 2010 09:21:25 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 6734428C0F8 for ; Thu, 17 Jun 2010 09:21:25 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1OPHqL-0001eh-GP for ecrit@ietf.org; Thu, 17 Jun 2010 12:21:29 -0400 Received: from [205.151.16.4] (helo=[192.168.2.64]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from ) id 1OPHqL-0004PI-46 for ecrit@ietf.org; Thu, 17 Jun 2010 12:21:29 -0400 From: Francois Menard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2010 12:21:28 -0400 Message-Id: To: ecrit Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Ecrit] CRTC says no to mandatory implementation of Location Determination Platforms in Canada X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 16:21:26 -0000 Well, looks like the efforts of Canadian incumbent telephone companies = to force their architecture for location determination platforms have = failed. Ci2 was Canadian NENA i2 whereby the telephone companies, as a the = managers of the 9-1-1 infrastructure, would control databases of all = public IP addresses in case 9-1-1 calls are made from Internet = customers.=20 I think I'll have to create a wikipedia entry for Ci2 (in the past = tense). The decision is here:=20 http://www.crtc.gc.ca/eng/archive/2010/2010-387.htm 12. The Commission notes that no parties indicated that Ci2 or a = similar nomadic VoIP E9-1-1 service has been implemented in other = countries. The Commission therefore considers that the proposed Ci2 = solution is untested and that actual experience with respect to the = feasibility and costs of implementing such a solution does not exist. 13. The Commission also notes that all parties agreed that the = long-term goal in the evolution of the 9-1-1 network is to migrate = customers to NG9-1-1. Further, the Commission notes that Ci2 = implementation is expected to take at least two years and that, = similarly, the deployment of NG9-1-1 is expected in a few years. The = Commission considers that future solutions based on NG9-1-1 would = support nomadic VoIP service by using location-aware devices to = determine a subscriber=92s location, which would make it unnecessary for = ASPs to implement a location-determining platform in their networks. 14. The Commission considers that NG9-1-1 offers several benefits = that will likely result in a technologically advanced solution: it is = based on international standards; it introduces improved technologies = for location detection; and it provides access for multiple = communications devices and technologies, on both wireline and wireless = networks. 15. The Commission notes that access to nomadic VoIP services is = migrating from wireline to wireless high-speed Internet access through = the use of wireless devices such as cellphones. However, for technical = reasons, Ci2 cannot be used to determine the location of a 9-1-1 caller = when the nomadic VoIP service subscriber is using a wireless connection. 16. In light of the above, the Commission considers that by the time = Ci2 would be implemented, it is likely that it will have become outdated = as a result of technological changes and market developments such as the = introduction of NG9-1-1. 17. All parties generally agreed that there are currently fewer than = 200,000 nomadic VoIP service subscribers in Canada and that the expected = demand for this service has not materialized, despite previous = projections that there would be millions of subscribers. We can now focus our energy on Next-Generation 9-1-1 in Canada. What a scare this was. It took from September 2006, until June 2010, = for the CRTC to reach the conclusions it did. And its also scary to remember that Canada proceeded to forbearing from = regulating local telephone services rates on the basis that nomadic VoIP = would be huge. The CRTC says that there is in 2010, less than 200K subs of nomadic VoIP = in Canada and that therefore it is not worth it to implement a temporary = solution until Next-Generation 9-1-1 is implemented. -=3DFrancois=3D- From thompson@ieee.org Sun Jun 20 07:36:19 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575F43A692D for ; Sun, 20 Jun 2010 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.498 X-Spam-Level: X-Spam-Status: No, score=-96.498 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 3zGtq-W+Ce8i for ; Sun, 20 Jun 2010 07:36:18 -0700 (PDT) Received: from smtp104.prem.mail.ac4.yahoo.com (smtp104.prem.mail.ac4.yahoo.com [76.13.13.43]) by core3.amsl.com (Postfix) with SMTP id 326B53A68B3 for ; Sun, 20 Jun 2010 07:36:18 -0700 (PDT) Received: (qmail 75426 invoked from network); 20 Jun 2010 14:36:16 -0000 Received: from geoff-thompsons-macbook-2.local (thompson@71.51.25.146 with plain) by smtp104.prem.mail.ac4.yahoo.com with SMTP; 20 Jun 2010 07:36:16 -0700 PDT X-Yahoo-SMTP: QyU90.qswBBpdAOL14e1mfwUogr5DY5wzs_aWTD7HWypLbttNQmnq7k- X-YMail-OSG: wwcSZKUVM1kIzbR96sKpAJNGmh77.i0BRZPw4ccGRCy0yPi EkPlp5yOwStMRCy1EFZgLcC_zjQfYLTBibSawZxgliB7FZT5q3W4PBV07WxW 0BfF.taQKBnsTX9Y1ktNhhUHOJKkKv_CaW6PvxrRx2AULPzSFpkHcerOQUuT KBZ8a2S4XV1KS72tkhkZ2u1N6QAe0KwWaTgDkdZzlT.b4_rcRn7bC6tQp4q6 s X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C1E275F.1050009@ieee.org> Date: Sun, 20 Jun 2010 07:36:15 -0700 From: Geoff Thompson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="------------070907040109010001090302" Subject: [Ecrit] Comment on CRTC 9-1-1 decision (Ecrit Digest, Vol 65, Issue 1) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: thompson@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 14:36:19 -0000 This is a multi-part message in MIME format. --------------070907040109010001090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to Francois for forwarding the meat of the CRTC decision. (See: Ecrit Digest, Vol 65, Issue 1) I don't argue the outcome of the Canadian decision. I do argue with the overall validity of one of their points. I believe: "13. The Commission also notes that all parties agreed that the long-term goal in the evolution of the 9-1-1 network is to migrate customers to NG9-1-1. Further, the Commission notes that Ci2 implementation is expected to take at least two years and that, similarly, the deployment of NG9-1-1 is expected in a few years. The Commission considers that future solutions based on NG9-1-1 would support nomadic VoIP service by using location-aware devices to determine a subscriber's location, which would make it unnecessary for ASPs to implement a location-determining platform in their networks." is not "true enough" to be the basis of policy. While it may be true for virtually all hardware devices whose primary purpose is VoIP, it is unlikely to be "true enough" (or reliable enough) for all platforms that can host VoIP software. The question then becomes whether it is "worthwhile enough" to require network endpoints (or near endpoints) to be location-aware versus (conversely) try to train the public not to use that class of system for emergency calls. That would also, obviously, include making sure that regulators go along with this decision on an eyes-wide-open basis. Disclosure I am the chair of the IEEE 802.23 Working Group. The basis for the existence of the current 802.23 project is that the Layer 1/2 network will be required to be able to provide reliable location information in a VoIP or similar Citizen-to-Authority emergency call environment. Geoff Thompson --------------070907040109010001090302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Thanks to Francois for forwarding the meat of the CRTC decision.
(See: Ecrit Digest, Vol 65, Issue 1)

I don't argue the outcome of the Canadian decision.
I do argue with the overall validity of one of their points.
I believe:
"13. The Commission also notes that all parties agreed that the long-term goal in the evolution of the 9-1-1 network is to migrate customers to NG9-1-1. Further, the Commission notes that Ci2 implementation is expected to take at least two years and that, similarly, the deployment of NG9-1-1 is expected in a few years. The Commission considers that future solutions based on NG9-1-1 would support nomadic VoIP service by using location-aware devices to determine a subscriber's location, which would make it unnecessary for ASPs to implement a location-determining platform in their networks."
is not "true enough" to be the basis of policy.

While it may be true for virtually all hardware devices whose primary purpose is VoIP, it is unlikely to be "true enough" (or reliable enough) for all platforms that can host VoIP software. The question then becomes whether it is "worthwhile enough" to require network endpoints (or near endpoints) to be location-aware versus (conversely) try to train the public not to use that class of system for emergency calls. That would also, obviously, include making sure that regulators go along with this decision on an eyes-wide-open basis.

Disclosure
I am the chair of the IEEE 802.23 Working Group. The basis for the existence of the current 802.23 project is that the Layer 1/2 network will be required to be able to provide reliable location information in a VoIP or similar Citizen-to-Authority emergency call environment.

Geoff Thompson
--------------070907040109010001090302-- From bernard_aboba@hotmail.com Sun Jun 20 12:09:32 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4C33A690D for ; Sun, 20 Jun 2010 12:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.075 X-Spam-Level: ** X-Spam-Status: No, score=2.075 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtH3eRmU44UP for ; Sun, 20 Jun 2010 12:09:31 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by core3.amsl.com (Postfix) with ESMTP id A56973A68A5 for ; Sun, 20 Jun 2010 12:09:31 -0700 (PDT) Received: from BLU137-W16 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Jun 2010 12:09:38 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_539b4c13-7b19-4ed0-ad88-e923fd1b8019_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 20 Jun 2010 12:09:38 -0700 Importance: Normal In-Reply-To: <4C1E275F.1050009@ieee.org> References: <4C1E275F.1050009@ieee.org> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2010 19:09:38.0544 (UTC) FILETIME=[21120700:01CB10AC] Subject: Re: [Ecrit] Comment on CRTC 9-1-1 decision X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 19:09:33 -0000 --_539b4c13-7b19-4ed0-ad88-e923fd1b8019_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not sure how things work in Canada=2C but in the US=2C regulation of e= mergency services support within Multiline Telephone Systems (MLTS) has evo= lved separately from requirements for consumer emergency services support. = Although the FCC has set rules relating to 9-1-1 support (see http://www.ne= na.org/government-affairs/FCC-911-rules) it has not yet issued rules relati= ng to support of location in MLTS=2C although regulations exist at the stat= e level (see http://www.nena.org/mlts-pbx/state-legislation). HR 4829 (see= http://www.nena.org/government-affairs/pending-legislation) would have the= FCC initiate a proposed rule making on the issue of location support in ML= TS=2C introducing nationwide requirements for location support in MLTS for = the first time.=20 Since the regulation of MLTS has evolved separately from consumer emergency= services regulation=2C I would not necessarily conclude that requirements = will evolve in synchrony. As a result=2C a decision not to require support= for nomadic VOIP in consumer scenarios may not necessarily imply an equiva= lent stance for MLTS. =20 However=2C I'd argue that MLTS state legislation as well as the NENA MLTS m= odel legislation (see http://www.nena.org/standards/technical/data/mlts-mod= el-legislation-2009 ) is not well adapted to nomadic VOIP scenarios involvi= ng wireless hard or softphones. In general=2C wireless handset location de= termination yields a geospatial location and uncertainty=2C which in MLTS l= ocation scenarios may span several floors (and in extreme cases=2C more tha= n one building)=2C making it difficult to satisfy the legislative requireme= nts for resolution at the building/floor level for buildings larger than a = certain size.=20 = --_539b4c13-7b19-4ed0-ad88-e923fd1b8019_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not sure how things work in Canada=2C but in the US=2C regulation of e= mergency services support within Multiline Telephone Systems (MLTS) has evo= lved separately from requirements for consumer emergency services support. = Although the FCC has set rules relating to 9-1-1 support (see http://www.ne= na.org/government-affairs/FCC-911-rules) it has not yet issued rules relati= ng to support of location in MLTS=2C although regulations exist at the stat= e level (see http://www.nena.org/mlts-pbx/state-legislation). =3B HR 48= 29 (see http://www.nena.org/government-affairs/pending-legislation) would h= ave the FCC initiate a proposed rule making on the issue of location suppor= t in MLTS=2C introducing nationwide requirements for location support in ML= TS for the first time.

Since the regulation of MLTS has evolved sep= arately from consumer emergency services regulation=2C I would not necessar= ily conclude that requirements will evolve in synchrony. =3B As a resul= t=2C a decision not to require support for nomadic VOIP in consumer scenari= os may not necessarily imply an equivalent stance for MLTS. =3B
However=2C I'd argue that MLTS state legislation as well as the NENA MLTS = model legislation (see http://www.nena.org/standards/technical/data/mlts-mo= del-legislation-2009 ) is not well adapted to nomadic VOIP scenarios involv= ing wireless hard or softphones. =3B In general=2C wireless handset loc= ation determination yields a geospatial location and uncertainty=2C which i= n MLTS location scenarios may span several floors (and in extreme cases=2C = more than one building)=2C making it difficult to satisfy the legislative r= equirements for resolution at the building/floor level for buildings larger= than a certain size.
= --_539b4c13-7b19-4ed0-ad88-e923fd1b8019_-- From RjS@nostrum.com Tue Jun 22 11:03:37 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41233A67F8 for ; Tue, 22 Jun 2010 11:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs4a8uTbd8ar for ; Tue, 22 Jun 2010 11:03:36 -0700 (PDT) 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 A0BC93A67EC for ; Tue, 22 Jun 2010 11:03:35 -0700 (PDT) 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 o5MI3eHc055603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 Jun 2010 13:03:40 -0500 (CDT) (envelope-from RjS@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 13:03:40 -0500 References: To: ecrit@ietf.org Message-Id: <4820138A-ABED-4A24-A63D-CC23388BD54C@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Ecrit] Fwd: phonebcp initial comments 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 Jun 2010 18:03:38 -0000 (resending from an address that won't land in the moderator queue - = chairs - please delete the version that's stuck there) I'm in the middle of reviewing ecrit-phonebcp in preparation for=20 taking it through the rest of the process. I'd like to start discussing the comments and questions I've found so far. These are in document = order. Introduction (nits): Consider a reference and expand the first occurance of SIP in the = introduction. Missing close paren after AN- in the introduction's 1st paragraph ED-2 may not be sufficiently specified. Did you intend to include = devices like the Tandberg Fieldview or one-way SIP paging/announcement devices? SP-2 (nit) "This" at the beginnning of the second sentence is = potentially ambiguous. The second sentence isn't really part of the requirement - = it's a consideration for other parts of the system.=20 Does ED-11/SP-9 include the counseling service or was it intended to = only apply to the sos service? ED-14/INT-3/AN-3 how is suitable determined? Can any guidance be = provided? ED-15/INT-4/AN-4 Why is override in quotes? AN-6/INT-5 Can the document explain why 650 m^2 was chosen? AN-7/INT-6 The requirement to preserve ay access network provided = location mechanism (not just location) through intermediate devices is hard to extract from the existing text. ED-16/INT-7 Is there a reference to point to (or text to include) that = explains the choice of 100m and 95% confidence? AN-9 Does "do not support" here mean do not implement or do not use? ED-12/INT-12 I'm not sure what the second sentence is trying to say. Is it this?: When devices are deployed in access networks that support interface-specific location discovery mechanisms such as LLDP-MED... AN-13/INT-14 (nit) suggest s/meeting this BCP/satisfying the = requirements in this BCP/ ED-22/INT-15 Can you keep trying LCPs after you find the first one that succeeds? (The requirement currently says "can be used") ED-24 (nit) There are two ranges listed here that could be collapsed=20 (12-21,21-31). Is this just an artifact of editing, or is there a typo? ED-25 It's not clear whether no response is received means transport, = http, or HELD failure. Does the retry mechanic specified here make sense in = the first two cases? In the third, doesn't HELD provide some retry behavior based on its error codes? How does this requirement interact with that? ED-30/INT-23 (nit) "roam" may have connotations of changing networks to = some readers. I think you meant "change location"? ED-31/INT-24 (nit) I suggest replacing "If the device can detect it has = moved", with "If the device detects a state change that might indicate = having moved". ED-32/AN-18 is "MUST be provided" here intended to convey must use or = only must implement? ED-38 How was 10 seconds chosen? ED-39/SP16 - Is this requirement trying to point to Rule 3 in section 3 = of 5491 or something else?=20 SP-17 Should this requirement talk about random choices the way ED-40 = does? ED-41/SP-20 Is this requirement on the generation or verification of = location object (I suspect it's generation, in which case the requirement might = be better written as "MUST be created with" rather than "MUST contain" ED-??/SP-?? : This indicates additional review of the document is = needed.=20 ED-42/SP-21 This needs more context (Perhaps it should start out with = "When there are multiple Geolocation header field values provided"?) SP-22 This requirement is only talking about the initial INVITE and not = really the entire call, correct? Can it be rewritten to focus on that message? ED-46 Is the requirement here to not use S/MIME at all, or to ensure = that if it is used that these bits also appear in the clear. ED-47/SP-24 This is awkwardly phrased (in a way that doesn't use MUST correctly). Right now the only way I can interpret this is "Either TLS = or IPSEC MUST be used to protect location (but see Section 9.1)." If that's the = intent, can the phrase be rewritten this way? ED-48 What are you trying to describe with "HTTP get" in this = requirement? ED-51 Where is the specification of looking for LoST servers in SRV (can this requirement add a reference?). Nit: s/it's/its/. ED-52 looks like a restatement of part of this requirement. Can they be combined? AN-26 Is this requirement intended to mean the access network's DHCP = servers MUST implement the LoST discovery option, or that the access network = must use the option? How does this relate to the requirement in AN-27? ED-58 This requirement says MAY, but ED-65 point 12 says SHOULD. ED-60/SP-31 I suggest replacing "specified" with "used". This = requirement needs to be restructured similar to ED-47/SP-24.=20 ED-62/SP-33 RFC5626 doesn't discuss persistent TLS between proxies. This requirement should be more clearly scoped to connections when one = element is the end device. ED-63/AN-28 Again, suggest s/specified/used/.=20 ED-64/AN-29 Suggest being explicit: When TLS session establishement with = the HELD server fails, ED-65 3 and 4 Why does this need to restate fundamental SIP requirements = (like having a =46rom and Via header field)? Nit: header-> header field = throughout the document ED-63 5: The Route header should have exactly the bits that LoST = returned. It doesn't make sense to add an ;lr if one wasn't already there. Is the = second half of this requirement accurate (will there never be Route headers for = other reasons, such as Service-Route)? ED-64 15: Is this requirement trying to point to Accept-Contact with a "language" parameter? Accept-Language and Caller Preferences aren't = related. SP-34 1: What does "as above" point to? ED-66/SP-35: How was 30 minutes chosen? ED-65 says "several minutes"=20 ED-67/SP-38: This needs expansion/clarification. If the intent is to = insist that an endpoint accept the REFER and issue an INVITE, "MUST = support" is insufficient. Where you say transaction, I think you mean = request. Does this requirement apply only to REFER requests received in = this dialog, or is it intended to also apply to REFER requests = out-of-dialog, but associated with this dialog using the Target-Dialog = extension? ED-68 Is there a reason to not clean up the cruft before publication (I = understand not wanting the numbers to move around much while the working = group was developing the document). ED-79 This requirement makes 5194 a normative down-reference=20 =09 ED-80 should this point to 3984bis? ED-81 Where are the *.test URNs defined/registered? The restatement of requirements in the appendix is dangerous from a = document maintenance point of view. There are already some (minor) = inconsistencies that I found with a hackish python script - this may not = be all of them: ED-9 : Endpoints SHOULD be able to have home dial strings provisioned = by configuration. Endpoints SHOULD be able to have home dial strings provisioned. ED-60 : TLS MUST be specified when attempting to signal an emergency = call with SIP. IPSEC is an acceptable alternative. TLS MUST be specified when attempting to signal an emergency = call. IPSEC is an acceptable alternative. ED-81 : ... and a 404 (Not Found) MUST be returned ... ... and a 404 (Not found) MUST be returned ... ED-82 : (appendix is missing punctuation at end) SP-8 : Service providers MAY provide home dial strings by = configuration. Service providers MAY provision home dial strings in devices. SP-31 : TLS MUST be specified when attempting to signal an emergency = call with SIP. IPSEC is an acceptable alternative. TLS MUST be specified when attempting to signal an emergency = call. IPSEC is an acceptable alternative. AN-11 : ... personnal area ... ... personal area ... Only seen once ED-?? A location with a method of "derived" MUST NOT be used unless no = other location is available. SP-?? A location with a method of "derived" MUST NOT be used unless no = other location is available. From bernard_aboba@hotmail.com Tue Jun 22 12:19:22 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D07B3A68ED for ; Tue, 22 Jun 2010 12:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLUG93Vp8EFx for ; Tue, 22 Jun 2010 12:19:20 -0700 (PDT) Received: from blu0-omc4-s17.blu0.hotmail.com (blu0-omc4-s17.blu0.hotmail.com [65.55.111.156]) by core3.amsl.com (Postfix) with ESMTP id C8E913A68D8 for ; Tue, 22 Jun 2010 12:19:20 -0700 (PDT) Received: from BLU137-W31 ([65.55.111.137]) by blu0-omc4-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 12:19:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_978f9064-69b5-4c2b-a562-81d479788822_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: , Date: Tue, 22 Jun 2010 12:19:28 -0700 Importance: Normal In-Reply-To: <4820138A-ABED-4A24-A63D-CC23388BD54C@nostrum.com> References: , <4820138A-ABED-4A24-A63D-CC23388BD54C@nostrum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2010 19:19:28.0707 (UTC) FILETIME=[D5A94130:01CB123F] Subject: Re: [Ecrit] Fwd: phonebcp initial comments 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 Jun 2010 19:19:22 -0000 --_978f9064-69b5-4c2b-a562-81d479788822_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > ED-16/INT-7 Is there a reference to point to (or text to include) that ex= plains > the choice of 100m and 95% confidence? I'm assuming that this was chosen to correspond to WLAN scenario mentioned = in the previous section. However=2C the 100m figure represents the distance at which a 1 Mbps 802.11 frame can be expected to propagate wi= thin a maximum acceptable Frame Error Rate (FER). However=2C if higher fra= me error rates can be tolerated (such as in Beacon reception)=2C then the d= istance for 95 percent confidence can be greater (or alternatively=2C the c= onfidence would be lower at 100m). As an example=2C in a plane at 3000 m= =2C it is still possible to receive=20 and decode Beacons emitted from the homes below=2C albeit with a high FER. = Also in practice if triangulation is not used=2C there will be a dependenc= y on the roaming algorithms of WLAN chipsets=3B "sticky" implementations co= uld make it difficult to deliver an accuracy of 100m with 95% confidence. = =20 Given this =2Cthe reality is that the accuracy that is achievable will depe= nd on the location technology used=2C and whether the determination is made= by the end-system (Section 6.2.3) or the network (Section 6.2.4). The FC= C Wireless Phase II requirements make these kind of distinctions: Wireless phones relying on network-based technology must provide Public Saf= ety Answering Points (PSAP) with reports on their locations within 100=20 meters of accuracy for 67 percent of calls=2C and within 300 meters for 95 percent of calls=2C by Sept. 11=2C 2012. Phones=20 installed with GPS chips=2C meanwhile=2C must provide PSAPs with=20 reports on their locations within 50 meters of accuracy for 67 percent=20 of calls=2C and within 100 meters for 95 percent of calls=2C by the same=20 date. The FCC also specified certain benchmarks to measure the carriers' progress=2C such as meeting the location accuracy requirements in at=20 least 75 percent of PSAPs a carrier serves by 2010. = --_978f9064-69b5-4c2b-a562-81d479788822_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B ED-16/INT-7 Is there a reference to point to (or text to include) th= at explains
>=3B the choice of 100m and 95% confidence?

I'm ass= uming that this was chosen to correspond to WLAN scenario mentioned in the = previous section. However=2C the 100m figure represents
the distance at = which a 1 Mbps 802.11 frame can be expected to propagate within a maximum a= cceptable Frame Error Rate (FER). =3B However=2C if higher frame error = rates can be tolerated (such as in Beacon reception)=2C then the distance f= or 95 percent confidence can be greater (or alternatively=2C the confidence= would be lower at 100m). =3B As an example=2C in a plane at 3000 m=2C = it is still possible to receive=20 and decode Beacons emitted from the homes below=2C albeit with a high FER.&= nbsp=3B Also in practice if triangulation is not used=2C there will be a de= pendency on the roaming algorithms of WLAN chipsets=3B "sticky" implementat= ions could make it difficult to deliver an accuracy of 100m with 95% confid= ence. =3B

Given this =2Cthe reality is that the accuracy that i= s achievable will depend on the location technology used=2C and whether the= determination is made by the end-system (Section 6.2.3) or the network (Se= ction 6.2.4). =3B =3B The FCC Wireless Phase II requirements make t= hese kind of distinctions:

Wireless phones relying on network-based technology must provide Public Safety Answering Points (PSAP) with reports on their locations within 100=20 meters of accuracy for 67 percent of calls=2C and within 300 meters for 95 percent of calls=2C by Sept. 11=2C 2012. Phones=20 installed with GPS chips=2C meanwhile=2C must pro= vide PSAPs with=20 reports on their locations within 50 meters of accuracy for 67 percent=20 of calls=2C and within 100 meters for 95 percent of calls=2C by the same=20 date. The FCC also specified certain benchmarks to measure the carriers' progress=2C such as meeting the location accuracy requirements in at=20 least 75 percent of PSAPs a carrier serves by 2010.
= --_978f9064-69b5-4c2b-a562-81d479788822_-- From hannes.tschofenig@nsn.com Tue Jun 22 12:21:22 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CB928C0F3 for ; Tue, 22 Jun 2010 12:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iFxtLuMwP7y for ; Tue, 22 Jun 2010 12:21:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D57D028C0DD for ; Tue, 22 Jun 2010 12:21:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5MJLKR1023266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jun 2010 21:21:20 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5MJLK8L015336; Tue, 22 Jun 2010 21:21:20 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 21:21:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1240.17EB613B" Date: Tue, 22 Jun 2010 22:21:16 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450286984D@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: phonebcp initial comments Thread-Index: AcsSP9qBdR3p/aTGQg2WTbirTH3WNQAACMfw References: , <4820138A-ABED-4A24-A63D-CC23388BD54C@nostrum.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Bernard Aboba" , , X-OriginalArrivalTime: 22 Jun 2010 19:21:20.0266 (UTC) FILETIME=[1827CEA0:01CB1240] Subject: Re: [Ecrit] Fwd: phonebcp initial comments 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 Jun 2010 19:21:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1240.17EB613B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I always argued that these numbers should be removed from the document since they have nothing to do with the protocol functionality itself but largely refer to the what regulators decide they find useful (even though they have no way to verify it later on).=20 =20 Ciao Hannes =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: Tuesday, June 22, 2010 10:19 PM To: rjs@nostrum.com; ecrit@ietf.org Subject: Re: [Ecrit] Fwd: phonebcp initial comments =09 =09 > ED-16/INT-7 Is there a reference to point to (or text to include) that explains > the choice of 100m and 95% confidence? =09 I'm assuming that this was chosen to correspond to WLAN scenario mentioned in the previous section. However, the 100m figure represents the distance at which a 1 Mbps 802.11 frame can be expected to propagate within a maximum acceptable Frame Error Rate (FER). However, if higher frame error rates can be tolerated (such as in Beacon reception), then the distance for 95 percent confidence can be greater (or alternatively, the confidence would be lower at 100m). As an example, in a plane at 3000 m, it is still possible to receive and decode Beacons emitted from the homes below, albeit with a high FER. Also in practice if triangulation is not used, there will be a dependency on the roaming algorithms of WLAN chipsets; "sticky" implementations could make it difficult to deliver an accuracy of 100m with 95% confidence. =20 =09 Given this ,the reality is that the accuracy that is achievable will depend on the location technology used, and whether the determination is made by the end-system (Section 6.2.3) or the network (Section 6.2.4). The FCC Wireless Phase II requirements make these kind of distinctions: =09 Wireless phones relying on network-based technology must provide Public Safety Answering Points (PSAP) with reports on their locations within 100 meters of accuracy for 67 percent of calls, and within 300 meters for 95 percent of calls, by Sept. 11, 2012. Phones installed with GPS chips , meanwhile, must provide PSAPs with reports on their locations within 50 meters of accuracy for 67 percent of calls, and within 100 meters for 95 percent of calls, by the same date. The FCC also specified certain benchmarks to measure the carriers' progress, such as meeting the location accuracy requirements in at least 75 percent of PSAPs a carrier serves by 2010. =09 ------_=_NextPart_001_01CB1240.17EB613B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I always=20 argued that these numbers should be removed from the document since they = have=20 nothing to do with the protocol functionality itself but largely refer = to the=20 what regulators decide they find useful (even though they have no way to = verify=20 it later on).
 
Ciao
Hannes
 

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Bernard=20 Aboba
Sent: Tuesday, June 22, 2010 10:19 PM
To:=20 rjs@nostrum.com; ecrit@ietf.org
Subject: Re: [Ecrit] Fwd: = phonebcp=20 initial comments

> ED-16/INT-7 Is there a reference to point to (or text = to=20 include) that explains
> the choice of 100m and 95%=20 confidence?

I'm assuming that this was chosen to correspond to = WLAN=20 scenario mentioned in the previous section. However, the 100m figure=20 represents
the distance at which a 1 Mbps 802.11 frame can be = expected to=20 propagate within a maximum acceptable Frame Error Rate (FER).  = However,=20 if higher frame error rates can be tolerated (such as in Beacon = reception),=20 then the distance for 95 percent confidence can be greater (or = alternatively,=20 the confidence would be lower at 100m).  As an example, in a = plane at=20 3000 m, it is still possible to receive and decode Beacons emitted = from the=20 homes below, albeit with a high FER.  Also in practice if = triangulation=20 is not used, there will be a dependency on the roaming algorithms of = WLAN=20 chipsets; "sticky" implementations could make it difficult to deliver = an=20 accuracy of 100m with 95% confidence. 

Given this ,the = reality is=20 that the accuracy that is achievable will depend on the location = technology=20 used, and whether the determination is made by the end-system (Section = 6.2.3)=20 or the network (Section 6.2.4).   The FCC Wireless Phase II=20 requirements make these kind of distinctions:

Wireless phones = relying=20 on network-based technology must provide Public = Safety=20 Answering Points (PSAP) with reports on their locations within 100 = meters of=20 accuracy for 67 percent of calls, and within 300 meters for 95 percent = of=20 calls, by Sept. 11, 2012. Phones installed with GPS chips, meanwhile, must provide PSAPs with = reports on=20 their locations within 50 meters of accuracy for 67 percent of calls, = and=20 within 100 meters for 95 percent of calls, by the same date. The FCC = also=20 specified certain benchmarks to measure the carriers' progress, such = as=20 meeting the location accuracy requirements in at least 75 percent of = PSAPs a=20 carrier serves by 2010.
------_=_NextPart_001_01CB1240.17EB613B-- From rbarnes@bbn.com Tue Jun 22 17:01:36 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50FE28C12A for ; Tue, 22 Jun 2010 17:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JzNiTLX9IKl for ; Tue, 22 Jun 2010 17:01:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 457CA28C126 for ; Tue, 22 Jun 2010 17:01:35 -0700 (PDT) Received: from [128.89.255.12] (port=50056 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ORDPR-000BqR-CH for ecrit@ietf.org; Tue, 22 Jun 2010 20:01:42 -0400 Message-Id: <1DFB3317-0513-4CB8-BB42-97B385B7782B@bbn.com> From: "Richard L. Barnes" To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-7-443874161 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Jun 2010 20:01:41 -0400 References: <20100621214909.D25A428C13B@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [Ecrit] Fwd: Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 00:01:36 -0000 --Apple-Mail-7-443874161 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit In case people haven't heard the call for NOMCOM volunteers... Begin forwarded message: > From: NomCom Chair > Date: June 21, 2010 5:49:08 PM EDT > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers > > Hi all, > > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are > considering > volunteering please do so very soon. > > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. > > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve > as a > voting member and have not received a confirmation email from me, > please > re-submit and bring to my attention right away! > > However, we need many more volunteers. You have until 17:00 PDT > (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better > if you > volunteer as early as possible. The more volunteers, the better > chance we > have of choosing a random yet representative cross section of the IETF > pouplation. > > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: > IETF-73, > IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are > willing to > forgo appointment to any of the positions for which the nominating > committee is responsible, please volunteer. > > The 10 nominating committee members are selected randomly from a > pool of > volunteers. The details of the operation of nomcom may be found in > RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ > > The lists of open positions and people whose terms end in March 2011 > and > thus the positions for which the nominating committee is responsible > are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ > > The 29 volunteers who have thus far been qualified by the secretariat > are: > > Fred Baker, Cisco Systems > > Stephan Wenger, Vidyo, Inc. > > Marc Blanchet, Viagenie > > Lixia Zhang, UCLA > > John Drake, Juniper Networks > > Ole Troan, Cisco > > Jiankang Yao, CNNIC > > Wassim Haddad, Ericsson > > Yi Zhao, Huawei USA > > Teemu Savolainen, Nokia > > Jouni Korhonen, Nokia Siemens Networks > > Mehmet Ersue, Nokia Siemens Networks > > Christian Schmidt, Nokia Siemens Networks > > Stephen Hanna, Juniper Networks > > Suresh Krishnan, Ericsson > > Eric Gray, Ericsson > > David Sinicrope, Ericsson > > Jan Melen, Ericsson > > Richard Barnes, BBN Technologies > > Hugo Salgado Hernandez, NIC Chile > > Ning Zong, Huawei Technologies > > Qin Wu, Huawei Technologies > > Karen Seo, BBN Technologies > > Haibin Song, Huawei Technologies > > Susan Hares, Huawei Technologies > > Tony Hansen. AT&T Labs > > Fuqing Huang, Huawei Technologies Co., Ltd. > > Huub van Helvoort, Huawei Technologies > > Miya Kohno, Juniper Networks > > The primary activity for this nomcom will begin just prior to > IETF-78 in > Maastricht and should be completed in early January 2011. The > nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be > weekly > conference calls to ensure progress. Thus, being a nomcom member does > require some time commitment. > > While, there is no requirement in RFC 3777 that a participant attend > IETF > meetings while serving on nomcom, please consider that during the IETF > meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting > locations - > Maastricht at the end of July and Beijing in November. > > If you are not yet sure you would like to volunteer, please consider > that > nomcom members play a very important role in shaping the leadership > of the > IETF. Ensuring the leadership of the IETF is fair and balanced and > comprised of those who can lead the IETF in the right direction is an > important responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. > > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: > > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer > > Please include the following information in the body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > > // typically what goes in the Company field > // in the IETF Registration Form > > [] > // > > // For confirmation if selected > > Please expect an email response from me within 3 days stating > whether or > not you are qualified. If you don't receive a response, please re- > send > your email with the tag "Duplicate:" added to the subject line. > > Thank you and I hope to hear from you, > > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-7-443874161 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable In case people haven't heard = the call for NOMCOM volunteers...

Begin forwarded = message:

From: NomCom Chair <nomcom-chair@ietf.org>=
Date: June 21, 2010 5:49:08 PM = EDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: Nomcom 2010-2011: Second Call for = Volunteers 

Hi all, =

This is the Second call for Volunteers for the 2010-11 nomcom. =  We are
just about halfway through the volunteer period so if = you are considering
volunteering please do so very soon.

I am = pleased to report that we have 29 volunteers thus far = whose
qualifications have been confirmed by the secretariat. I have = notified
each of these volunteers by email.  

If you = volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as = a
voting member and have not received a confirmation email from me, = please
re-submit and bring to my attention right = away!

However, we need many more volunteers.  You have until = 17:00 PDT (24:00
UTC) on July 8, 2010 to volunteer for nomcom but it = is much better if you
volunteer as early as possible.  The more = volunteers, the better chance we
have of choosing a random yet = representative cross section of the IETF
pouplation. =   

As a reminder, volunteers must have attended 3 of = the past 5 IETF
meetings - per RFC 3777, which means 3 of the = following meetings: IETF-73,
IETF-74, IETF-75, IETF-76 and IETF-77. =  If you qualify, and are willing to
forgo appointment to any of = the positions for which the nominating
committee is responsible, = please volunteer.  

The 10 nominating committee members are = selected randomly from a pool of
volunteers.  The details of the = operation of nomcom may be found in RFC
3777.  The process on = how to volunteer for nomcom is in the initial
announcement:  https://datatracker= .ietf.org/ann/nomcom/2330/

The lists of open positions and = people whose terms end in March 2011 and
thus the positions for which = the nominating committee is responsible are
summarized in the initial = announcement:
https://datatracker= .ietf.org/ann/nomcom/2330/

The 29 volunteers who have thus = far been qualified by the secretariat
are:

Fred Baker, Cisco = Systems

Stephan Wenger, Vidyo, Inc.

Marc Blanchet, = Viagenie

Lixia Zhang, UCLA

John Drake, Juniper = Networks

Ole Troan, Cisco

Jiankang Yao, = CNNIC

Wassim Haddad, Ericsson

Yi Zhao, Huawei = USA

Teemu Savolainen, Nokia

Jouni Korhonen, Nokia Siemens = Networks

Mehmet Ersue, Nokia Siemens Networks

Christian = Schmidt, Nokia Siemens Networks

Stephen Hanna, Juniper = Networks

Suresh Krishnan, Ericsson

Eric Gray, = Ericsson

David Sinicrope, Ericsson

Jan Melen, = Ericsson

Richard Barnes, BBN Technologies

Hugo Salgado = Hernandez, NIC Chile

Ning Zong, Huawei Technologies

Qin = Wu, Huawei Technologies

Karen Seo, BBN Technologies

Haibin = Song, Huawei Technologies

Susan Hares, Huawei = Technologies

Tony Hansen. AT&T Labs

Fuqing Huang, = Huawei Technologies Co., Ltd.

Huub van Helvoort, Huawei = Technologies

Miya Kohno, Juniper Networks

The primary = activity for this nomcom will begin just prior to IETF-78 = in
Maastricht and should be completed in early January 2011. =  The nomcom will
be collecting requirements from the community, = as well as talking to
candidates and to community members about = candidates. There will be weekly
conference calls to ensure progress. = Thus, being a nomcom member does
require some time commitment. =  

While, there is no requirement in RFC 3777 that a = participant attend IETF
meetings while serving on nomcom, please = consider that during the IETF
meetings, people that do not attend = would be expected to remotely
participate during the day in the time = zones of the meeting locations -
Maastricht at the end of July and = Beijing in November.

If you are not yet sure you would like to = volunteer, please consider that
nomcom members play a very important = role in shaping the leadership of the
IETF.  Ensuring the = leadership of the IETF is fair and balanced and
comprised of those = who can lead the IETF in the right direction is an
important = responsibility that rests on the IETF participants at = large.
Volunteering for the nomcom is a good way of contributing in = that
direction.

Please volunteer by sending an email = before:
17:00 PDT (24:00 UTC) July 8, 2010 as follows:

To: nomcom-chair@ietf.org
Subject= : Nomcom 2010-11 Volunteer

Please include the following = information in the body:

<Your Full Name>  // As you = enter in the IETF Registration Form,
=             &n= bsp;    // First/Given name followed by Last/Family = Name

<Current Primary Affiliation>
=             &n= bsp;    // typically what goes in the Company = field
=             &n= bsp;    // in the IETF Registration Form =

[<all email addresses used to Register for the past 5 IETF = meetings>]
<Preferred email address> =  //

<Telephone number> =         // For confirmation if = selected

Please expect an email response from me within 3 days = stating whether or
not you are qualified.  If you don't receive = a response, please re-send
your email with the tag "Duplicate:" added = to the subject line.

Thank you and I hope to hear from = you,

Thomas Walsh
Chair, Nomcom 2010-11
Email: nomcom-chair@ietf.org

_______________________________________________
IETF-Announce = mailing list
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-7-443874161-- From mlinsner@cisco.com Fri Jun 25 13:00:00 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A693A67F8 for ; Fri, 25 Jun 2010 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjZwiFOWvLz4 for ; Fri, 25 Jun 2010 12:59:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 005D73A6774 for ; Fri, 25 Jun 2010 12:59:58 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,483,1272844800"; d="scan'208";a="125669839" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jun 2010 20:00:07 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5PK02Sp020527; Fri, 25 Jun 2010 20:00:04 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Fri, 25 Jun 2010 15:59:56 -0400 From: Marc Linsner To: James Polk Message-ID: Thread-Topic: Transformations Draft Thread-Index: AcsUoPuu8QfMq00F5kSYdYgl6U3gLg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ecrit Subject: [Ecrit] Transformations Draft 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, 25 Jun 2010 20:00:00 -0000 James, Due to the current ECRIT charter, the ECRIT WG chairs have decided that your draft, draft-polk-ecrit-lost-transformations-urn-01, is best served if you submit/introduce it to the DISPATCH WG. This doesn't prevent ECRIT from taking on this work in the future, but DISPATCH will decided the best path forward for this draft. Thanks, Marc Linsner & Richard Barnes From mlinsner@cisco.com Fri Jun 25 13:04:45 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F217B3A68AC for ; Fri, 25 Jun 2010 13:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aox6Qf7WhY3h for ; Fri, 25 Jun 2010 13:04:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id BCAB33A6855 for ; Fri, 25 Jun 2010 13:04:43 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAI+oJExAaHtegWdsb2JhbACfQRUBARYiIqgFmkuFIQSQfg X-IronPort-AV: E=Sophos;i="4.53,483,1272844800"; d="scan'208";a="8639368" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 25 Jun 2010 19:23:27 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5PK4gJR008437; Fri, 25 Jun 2010 20:04:43 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Fri, 25 Jun 2010 16:04:35 -0400 From: Marc Linsner To: , , , , Message-ID: Thread-Topic: Emergency Text Messaging using SIP MESSAGE Thread-Index: AcsUoaH6/DU0BM+o0kyKocPhNWBKPQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ecrit Subject: [Ecrit] Emergency Text Messaging using SIP MESSAGE 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, 25 Jun 2010 20:04:45 -0000 Authors, Due to the current ECRIT charter, the ECRIT WG chairs have decided that your draft, draft-kim-ecrit-text-00, is best served if you submit/introduce it to the DISPATCH WG. This doesn't prevent ECRIT from taking on this work in the future, but DISPATCH will decided the best path forward for this draft. Thanks, Marc Linsner & Richard Barnes From mlinsner@cisco.com Fri Jun 25 13:16:04 2010 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F023A6855 for ; Fri, 25 Jun 2010 13:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foN7OaD2qv8f for ; Fri, 25 Jun 2010 13:16:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ABE0B3A6939 for ; Fri, 25 Jun 2010 13:16:00 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJurJEyrRN+K/2dsb2JhbACfQ3GndZpLhSEEkH4 X-IronPort-AV: E=Sophos;i="4.53,483,1272844800"; d="scan'208";a="550335202" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2010 20:16:08 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5PKG1mw014602; Fri, 25 Jun 2010 20:16:03 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Fri, 25 Jun 2010 16:15:49 -0400 From: Marc Linsner To: , , , Message-ID: Thread-Topic: Civic Location Format Extension Thread-Index: AcsUozO2b130fdgaJ0aO5dI43cszpQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: ecrit Subject: [Ecrit] Civic Location Format Extension 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, 25 Jun 2010 20:16:04 -0000 Authors, Due to the current ECRIT charter, the ECRIT WG chairs have decided that your draft, draft-george-ecrit-lamp-post-02, is best served if you submit/introduce it to the DISPATCH WG or possibly the GEOPRIV WG. This doesn't prevent ECRIT from taking on this work in the future, but DISPATCH or GEOPRIC will decided the best path forward for this draft. Thanks, Marc Linsner & Richard Barnes