From ecrit-bounces@ietf.org Sat Nov 1 13:15:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A363A69A3; Sat, 1 Nov 2008 13:15:15 -0700 (PDT) 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 5EC713A69A3 for ; Sat, 1 Nov 2008 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.989 X-Spam-Level: X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, SARE_SUB_OBFU_Q1=0.227, 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 uhnsxs0xvzLu for ; Sat, 1 Nov 2008 13:15:13 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 708093A68F4 for ; Sat, 1 Nov 2008 13:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1225570512; x=1257106512; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<00c501c939f9$4378a5f0$ca69f1d0$@net> |References:=20=0D=0A=20<018201c939d1$a9dc3960$fd 94ac20$@net>=0D=0A=20<569CC9EB-681E-408B-89E1-3E1A4AD2384 1@cs.columbia.edu>=0D=0A=20<00c501c939f9$4378a5f0$ca69f1d 0$@net>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-flag:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Fr i,=2031=20Oct=202008=2020:27:25=20-0700|To:=20Brian=20Ros en=20,=0D=0A=20=20=20=20=20=20=20=20"' Henning=20Schulzrinne'"=0D=0A=09,=0D =0A=20=20=20=20=20=20=20=20"'ECRIT'"=20 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=0D=0A=20draft-rosen-ecrit-prema ture-disconnect-rqmts-00.txt|CC:=20"'Tschofenig,=20Hannes =20(NSN=20-=20FI/Espoo)'"=20 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,542 0"=3B=20a=3D"11594296"; bh=hxYyZ0RxhgQwspbHo02d7GztdIzY73iOrQFJeFHMq+0=; b=ysPllYH34utTgYDODTKeLP2nY3+OliTMwJuWjyrpUeXGCIqUjZzsTMbY FLjzgNpVS8WnkztSj8P1doofCACoVWFknXRRznUrnaBh1+0hVhTf8thDd mP9QfkWeMP3DQ25o0UVdL94N4thiQ1U8a3dIY9BqmU1WqUNHva9O5EAQk A=; X-IronPort-AV: E=McAfee;i="5100,188,5420"; a="11594296" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2008 13:15:11 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA1KFBte014690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Nov 2008 13:15:11 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA1KF6pT016364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 Nov 2008 13:15:06 -0700 (PDT) Received: from nasanexhub04.na.qualcomm.com (129.46.134.222) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sat, 1 Nov 2008 13:15:06 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sat, 1 Nov 2008 13:15:05 -0700 Received: from [10.240.23.94] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 1 Nov 2008 13:15:05 -0700 Message-ID: In-Reply-To: <00c501c939f9$4378a5f0$ca69f1d0$@net> References: <018201c939d1$a9dc3960$fd94ac20$@net> <569CC9EB-681E-408B-89E1-3E1A4AD23841@cs.columbia.edu> <00c501c939f9$4378a5f0$ca69f1d0$@net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 31 Oct 2008 20:27:25 -0700 To: Brian Rosen , "'Henning Schulzrinne'" , "'ECRIT'" From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 3:05 PM -0400 10/29/08, Brian Rosen wrote: > While I'm sympathetic to the generalized notion that users retain control, > I'm persuaded by people who actually have experience that it actually works > better to have the PSAP in control. Obviously, we should pay attention to actual experience in handling emergency calls, since this is valuable input, but, presumably, such experience has been with POTS, and specifically, circuit-switched networks, dumb handsets with no UI to speak of, a familiar handset-and-switchhook mechanism, etc. So, I think we may need to put more effort into extrapolating the important aspects of the user experience of the caller and the call-taker, rather than attempting to emulate the call (or signalling) behavior. It seems to me that in the case of many SIP devices, it would be better to put as much of this functionality in the UI as possible, rather than into signalling. I'm not a human factors expert, so I can't say what UI would be most comprehensible in an emergency, or best able to steer panicked callers into not terminating a call, while allowing those stuck in a queue or who otherwise really want to disconnect, to do so. (But then, we don't do such UI detail here anyway.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- For best results, be sure to double clutch when you paradigm shift. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 2 10:59:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64A53A6ADC; Sun, 2 Nov 2008 10:59:38 -0800 (PST) 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 57D3F3A6AFB for ; Sun, 2 Nov 2008 10:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 POC-+W6comA6 for ; Sun, 2 Nov 2008 10:59:36 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 909773A67F8 for ; Sun, 2 Nov 2008 10:59:36 -0800 (PST) Received: from [192.168.0.61] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mA2IxUVk004435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 2 Nov 2008 13:59:32 -0500 (EST) Message-Id: <8389473F-5CCD-40BA-928F-FE4AA0243EA7@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 2 Nov 2008 13:59:30 -0500 X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Subject: [Ecrit] phone-BCP: LoST server configuration 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Working through the unauthenticated case, I think the following needs to be better addressed in the phone-BCP: Assume you have no VSP; this leaves only DHCP (RFC 5223) as a way for the UA to obtain LoST server information. Thus, an ISP has two choices in order for this to work: - Provide a DHCP entry pointing to a LoST server, not necessarily operated by itself. - Have an outbound proxy that can recognize emergency calls and perform a LoST resolution. (This isn't as good, as that makes dial string recognition on the UA harder.) I don't see any other alternatives if we want to support this model, given that manual configuration is not a real option. The current BCP doesn't quite seem to address the case where all attempts to locate a LoST server fail, as far as I can tell. Henning Btw, AN-26 and SP-25 are missing periods at the end of the sentence... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 2 16:55:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D52928C151; Sun, 2 Nov 2008 16:55:19 -0800 (PST) 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 E41E428C162 for ; Sun, 2 Nov 2008 16:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 0t0YLcEpjBHo for ; Sun, 2 Nov 2008 16:55:16 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 031093A6A7C for ; Sun, 2 Nov 2008 16:55:15 -0800 (PST) Received: from [192.168.0.61] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mA30t9Se018934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 2 Nov 2008 19:55:11 -0500 (EST) Message-Id: <23B6F840-55C7-47D2-80BE-B43B09F6B63B@cs.columbia.edu> From: Henning Schulzrinne To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 2 Nov 2008 19:55:09 -0500 References: X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] draft-ietf-ecrit-lost-sync-00.txt: Text Proposal 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks, Hannes. I've updated the document based on the text provided, but making some minor changes: - in line with RFC 5222, the requests don't have ...Request in the name; - the element now can only contain the parameters that are not specified in the elements, to avoid needless duplication and override conditions; - allow the "forbidden" error, in case a node tries to update something it is not allowed to; - the deletion mechanism is fleshed out a bit more. The version that will be submitted tomorrow is at http://www.cs.columbia.edu/sip/draft/lost-sync/draft-ietf-ecrit-lost-sync-01.html Last-minute comments would be most helpful. Henning On Oct 14, 2008, at 6:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I crafted an initial proposal for the text in the draft. > > ---------------- > > 3. Distributing Mappings via and > > > When a LoST node obtains new information that is of interest to its > peers, it pushes the new mappings to its peers. This information > might arrive through non-LoST means, such as a manual addition to > the > local mappings database, or through another LoST node, via a > request or a described later. > > Each peer keeps track of which peer it has exchanged which mapping > elements with. Mapping elements are identified, as described in > Section 5.1 of RFC 5222, by the 'source', 'sourceID' and > 'lastUpdated' parameters. A mapping is considered the > same if these three attributes match. Nodes never push the same > information to the same peer twice. > > To delete a mapping, the content of the mapping is left empty. The > node can delete the mapping from its internal mapping database, but > has to remember which peers it has distributed this update to. > > Processing a message may lead to a successful > response in the form of a or in an > message to be returned. Only > the following errors defined in RFC 5222 are re-used: > > - badRequest > - internalError > - serverTimeout > > Neither the nor the messages are utilized > by this specification. > > The semantic of these errors is described in Section 13.1 of RFC > 5222. > > If the set of nodes that are synchronizing their data does not > form a > tree, it is possible that the same information arrives through > several other nodes. This is unavoidable, but generally only > imposes > a modest overhead. (It would be possible to create a spanning tree > in the same fashion as IP multicast, but the complexity does not > seem > warranted, giving the relatively low volume of data.) > > A newly received mapping M' replaces an existing one M* if the > following > conditions hold: > (1) M'.source equals M*.source (case insensitive comparison) > (2) M'.sourceID' equals M*.sourceID (case insensitive comparison) > (3) M'.lastUpdated greater than M*.lastUpdated > > Consider the following example shown in Figure 1. Image a LoST node > that > obtained two new mappings identified as follows: > > * source="authoritative.example" > sourceId="7e3f40b098c711dbb6060800200c9a66" > lastUpdated="2008-11-26T01:00:00Z" > * source="authoritative.example" > sourceId="7e3f40b098c711dbb606011111111111" > lastUpdated="2008-11-01T01:00:00Z" > > These two mappings have to be added to the peer's mapping database. > > Additionally, it determines that the following mapping has to be > deleted: > > * source="nj.us.example" sourceId="123" > lastUpdated="2008-11-01T01:00:00Z" > > Figure 1 shows the corresponding message: > > > xmlns="urn:ietf:params:xml:ns:lost1" > xmlns:p2="http://www.opengis.net/gml"> > > > > sourceId="7e3f40b098c711dbb6060800200c9a66" > lastUpdated="2008-11-26T01:00:00Z" > expires="2009-12-26T01:00:00Z"> > Leonia Police Department > > urn:service:sos.police > profile="urn:ietf:params:lost:location-profile:basic-civic"> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > US > NJ > Leonia > 07605 > > > sip:police@leonianj.example.org > 911 > > > lastUpdated="2008-11-01T01:00:00Z" > source="authoritative.example" > sourceId="7e3f40b098c711dbb606011111111111"> > New York City Police Department > > urn:service:sos.police > > > > > 37.775 -122.4194 > 37.555 -122.4194 > 37.555 -122.4264 > 37.775 -122.4264 > 37.775 -122.4194 > > > > > sip:nypd@example.com > xmpp:nypd@example.com > 911 > > > lastUpdated="2008-11-01T01:00:00Z" > expires="2008-11-01T01:00:00Z"/> > > > > > Figure 1: pushMappingsRequest Example > > In response the peer performs the necessary operation and updates its > mapping database. > In particular, it will check whether the fields are understood and > contain values that > are understood. In our case a positive response is returned as shown > in > Figure 2: > > > > > Figure 2: pushMappingsResponse Example > > 4. Requesting Mappings via and > > > Instead of pushing mappings to another LoST node a LoST client can > get list of mappings identified by elements. When a server > does not return a mapping as requested then there may be two reasons > for this: > > 1) the mapping is not available at that server > > 2) the client has the current mapping and hence it does not need to > be > resent. > > A LoST node wanting to synchronize its mapping store > with another node issues a , containing an > enumeration of the current mapping sources, source identifiers and > lastUpdated in the elements. The recipient of the request > compares that > list to its own list of mappings. It then returns an unordered set > of mappings that are more recent than the ones identified in the > . > > The querier can limit the scope of the returned mappings returned by > using > the 'source', 'sourceId', and 'lastUpdated' attributes. > If the 'source' attribute is specified, only > mappings with that particular source attribute are considered. > Similarly, the 'sourceId' attribute restricts mappings to those > matching the attribute. If 'sourceId' is specified, the 'source' > attribute also needs to be provided, since the 'sourceId' attribute > is only defined for a particular source. Similarly, if > 'lastUpdated' > is specified, 'source' and 'sourceId' need to be specified as well. > In other words, a querier cannot ask for all mappings last updated > today regardless of source, for example. While the 'source' and the > 'sourceId' attributes are checked for (case insensitive) equality > the value in the 'lastUpdated' attribute is compared with the > matching > mappings and if a fresher mapping exists then it is returned. > elements that do not match any of the locally available mappings > in the database are silently ignored. > > Processing a message may lead to a successful > response in the form of a or in an > message to be returned. Only > the following errors defined in RFC 5222 are re-used: > > - badRequest > - internalError > - serverTimeout > > Neither the nor the messages are utilized > by this specification. > > > The following example illustrates the usage of the > > and messages. Figure 3 shows a LoST node > requesting a specific mapping for source="authoritative.bar.example" > and > sourceId="7e3f40b098c711dbb6060800200c9a66" that is fresher than > "2006-11-01T01:00:00Z". Additionally, all mappings that match > source="authoritative.foo.example" are requested. > > > > sourceId="7e3f40b098c711dbb6060800200c9a66" > lastUpdated="2006-11-01T01:00:00Z"/> > > > > Figure 3: Example > > The response is shown in Figure 4. A more recent mapping was available > with the > identification of source="authoritative.bar.example" and > sourceId="7e3f40b098c711dbb6060800200c9a66". Only one mapping that > matched source="authoritative.foo.example" was found and returned. > > > xmlns="urn:ietf:params:xml:ns:lost1" > xmlns:p2="http://www.opengis.net/gml"> > > > > sourceId="7e3f40b098c711dbb6060800200c9a66" > lastUpdated="2008-11-26T01:00:00Z" > expires="2009-12-26T01:00:00Z"> > Leonia Police Department > > urn:service:sos.police > profile="urn:ietf:params:lost:location-profile:basic-civic"> > xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> > US > NJ > Leonia > 07605 > > > sip:police@leonianj2.example.org > 911 > > > lastUpdated="2008-11-01T01:00:00Z" > source="authoritative.foo.example" > sourceId="7e3f40b098c711dbb606011111111111"> > New York City Police Department > > urn:service:sos.police > > > > > 37.775 -122.4194 > 37.555 -122.4194 > 37.555 -122.4264 > 37.775 -122.4264 > 37.775 -122.4194 > > > > > sip:nypd@example.com > xmpp:nypd@example.com > 911 > > > > > > > Figure 4: Example > > > 5. Relax NG Schema > > > > xmlns="http://relaxng.org/ns/structure/1.0" > xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" > datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> > > > > > > Location-to-Service Translation (LoST) > Synchronization Protocol > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 6. Security Considerations > > The LoST security considerations are discussed in [2]. The > operations described in this document involve mutually-trusting LoST > nodes. These nodes need to authenticate each other. > Nodes implementing LoST MUST implement mutual authentication > based on certificates . > > > 7. IANA Considerations > > No content type registration is needed for this specification. > The application/lost+xml MIME type is used. > > 7.1. LoST Sync Relax NG Schema Registration > > URI: urn:ietf:params:xml:ns:lost-sync1 > > Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne > (hgs@cs.columbia.edu). > > Relax NG Schema: The Relax NG schema to be registered is contained > in Section 5. Its first line is > > > > and its last line is > > > > 7.2. LoST Synchronization Namespace Registration > > URI: urn:ietf:params:xml:ns:lost-sync1 > Registrant Contact: IETF ECRIT Working Group, Henning Schulzrinne > (hgs@cs.columbia.edu). > XML: > > BEGIN > > "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> > > > content="text/html;charset=iso-8859-1"/> > LoST Synchronization Namespace > > >

Namespace for LoST server synchronization

>

urn:ietf:params:xml:ns:lost-sync1

>

See RFCXXXX > [NOTE TO IANA/RFC-EDITOR: > Please replace XXXX with the RFC number of this > specification.].

> > > END > _______________________________________________ > 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 ecrit-bounces@ietf.org Mon Nov 3 11:00:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2213228C1ED; Mon, 3 Nov 2008 11:00:06 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DFCAB3A6BBA; Mon, 3 Nov 2008 11:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103190001.DFCAB3A6BBA@core3.amsl.com> Date: Mon, 3 Nov 2008 11:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-01.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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Servers Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-01.txt Pages : 13 Date : 2008-11-03 The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs. This document defines a set of LoST extensions that allow LoST servers to synchronize their lists of mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03105032.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Nov 3 11:28:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1AB3A6A9B; Mon, 3 Nov 2008 11:28:18 -0800 (PST) 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 9927C3A67F3 for ; Mon, 3 Nov 2008 11:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 YrSXYimImEST for ; Mon, 3 Nov 2008 11:28:16 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CC8DE3A6846 for ; Mon, 3 Nov 2008 11:28:15 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mA3JS8lw002719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Nov 2008 14:28:10 -0500 (EST) Message-Id: <204C2D4B-FF00-4782-B0B3-01D56FDA512C@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 14:28:17 -0500 X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] draft-ietf-ecrit-lost-sync-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org draft-ietf-ecrit-lost-sync-01 has been submitted. I think it addresses most of the open issues and is reasonably complete. I'd like to see whether this is ready to be moved along to WGLC soon. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 3 17:00:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2081928C4AF; Mon, 3 Nov 2008 17:00:04 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9093428C298; Mon, 3 Nov 2008 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081104010001.9093428C298@core3.amsl.com> Date: Mon, 3 Nov 2008 17:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-06.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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-06.txt Pages : 45 Date : 2008-11-03 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03164918.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Nov 3 17:10:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070BE28C4DB; Mon, 3 Nov 2008 17:10:32 -0800 (PST) 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 638D128C4DB for ; Mon, 3 Nov 2008 17:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 i0NMLI4265JH for ; Mon, 3 Nov 2008 17:10:29 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 66C573A689F for ; Mon, 3 Nov 2008 17:10:29 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KxAQt-00005B-DD for ecrit@ietf.org; Mon, 03 Nov 2008 19:10:11 -0600 From: "Brian Rosen" To: "'ECRIT'" Date: Mon, 3 Nov 2008 20:10:17 -0500 Message-ID: <055501c93e1a$1b93c270$52bb4750$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack+DXJOjyUvmY9JSdujd6wLQV/VAAAC3LBg Content-language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [Ecrit] FW: New Version Notification for draft-rosen-ecrit-premature-disconnect-rqmts-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a new version of this draft available I addressed Keith's comments on clearly differentiating the humans from the UAs. I added text on when abandoned call starts I added text in PD-3 to clarify when it applies, and what it does/doesn't imply I added text in PD-5 to clarify it doesn't apply for multi-lines, and that there should be an override I added text in PD-6 to clarify was is/isn't implied, and defined "rapidly" I added text in AC-2 to include when abandoned call starts As this is still an individual submission, I did not change authors :) If it is accepted as a working group item, the chairs may choose an editor. Brian -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, November 03, 2008 6:40 PM To: br@brianrosen.net Subject: New Version Notification for draft-rosen-ecrit-premature-disconnect-rqmts-01 A new version of I-D, draft-rosen-ecrit-premature-disconnect-rqmts-01.txt has been successfuly submitted by Brian Rosen and posted to the IETF repository. Filename: draft-rosen-ecrit-premature-disconnect-rqmts Revision: 01 Title: Requirements for handling abandoned calls and premature disconnects in emergency calls on the Internet Creation_date: 2008-11-03 WG ID: Independent Submission Number_of_pages: 8 Abstract: The -phonebcp draft currently requires endpoints to disable sending a BYE on an emergency call. Insufficient justification and lack of attention to the entire problem has caused comment on that section of the document. This document attempts to define the problem and the requirements to controlling disconnect on emergency calls. The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 5 12:45:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD703A6A9F; Wed, 5 Nov 2008 12:45:48 -0800 (PST) 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 8C9D23A6A79 for ; Wed, 5 Nov 2008 12:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-0.778, 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 c6GqhtAqUQa8 for ; Wed, 5 Nov 2008 12:45:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 78FFA3A6A9F for ; Wed, 5 Nov 2008 12:45:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA5KjW4c027619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Nov 2008 21:45:32 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA5KjVWB026279 for ; Wed, 5 Nov 2008 21:45:31 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 21:44:44 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 21:44:44 +0100 Content-class: urn:content-classes:message Date: Wed, 5 Nov 2008 22:44:51 +0200 MIME-Version: 1.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Agenda Proposal Thread-Index: Ack/h1lwhvEdV6WITaWaF3arvxqd6w== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 05 Nov 2008 20:44:44.0232 (UTC) FILETIME=[5560EC80:01C93F87] Subject: [Ecrit] Agenda Proposal 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is a proposal for the agenda: http://www.ietf.org/proceedings/08nov/agenda/ecrit.txt Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 6 12:04:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3505B3A6A6D; Thu, 6 Nov 2008 12:04:33 -0800 (PST) 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 4FABE3A68FA for ; Thu, 6 Nov 2008 12:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.277 X-Spam-Level: X-Spam-Status: No, score=-105.277 tagged_above=-999 required=5 tests=[AWL=1.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fq-H7PbRzcYR for ; Thu, 6 Nov 2008 12:04:30 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4E4683A6813 for ; Thu, 6 Nov 2008 12:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1226001868; x=1257537868; h=message-id:in-reply-to:references:x-mailer: x-message-flag:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<073101c9296f$4ddbd110$e9937330$@net> |References:=20=0D=0A =20 =0D=0A=20=0D=0A=20 <073101c9296f$4ddbd110$e9937330$@net>|X-Mailer:=20Eudora =20for=20Mac=20OS=20X|X-message-flag:=20Warning:=20Outloo k=20in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Thu,=206=20Nov=202008=2011:51:59=20-08 00|To:=20Brian=20Rosen=20,=20"'Ted=20H ardie'"=20,=0D=0A=20=20=20=20=20=20 =20=20"'Henning=20Schulzrinne'"=20, =0D=0A=20=20=20=20=20=20=20=20"'Marc=20Linsner'"=0D=0A=09 |From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20IETF=20ECRIT=20De sign=20Team=20on=20Premature=20Call=20=20=0D=0A=20Termina tion|CC:=20"'ECRIT'"=20|MIME-Version:=201 .0|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" =3B=20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5425"=3B=20 a=3D"12167433"; bh=G29fmEfNnbtJGkimtQqzvok/nmiXyML2piRXTJYQeE0=; b=Z+VzHoAs/Bf1kYJka+6VtrK+vyqY6wo7cUam7GrTEcJxhz0CI0Ubd9ci tK/+6R0PTdeZHRCORZ4k6ziYv1zltMnzxDSEZf/vCNKB7EGwxRKgQ95iT feGXqzF2nnRCZ2L140kTMBU7icU62QxhvDZg59UxI49/GUwj871bW/+qP A=; X-IronPort-AV: E=McAfee;i="5300,2777,5425"; a="12167433" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2008 12:03:42 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6K3g9d001803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 12:03:42 -0800 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mA6K3fT8011497 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Nov 2008 12:03:42 -0800 Received: from nasanexhub05.na.qualcomm.com (129.46.134.219) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 6 Nov 2008 12:03:42 -0800 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 6 Nov 2008 12:03:41 -0800 Received: from loud.qualcomm.com (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 6 Nov 2008 12:03:39 -0800 Message-ID: In-Reply-To: <073101c9296f$4ddbd110$e9937330$@net> References: <073101c9296f$4ddbd110$e9937330$@net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 6 Nov 2008 11:51:59 -0800 To: Brian Rosen , "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Marc Linsner'" From: Randall Gellens MIME-Version: 1.0 X-Random-Sig-Tag: 1.0b28 Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 1:57 PM -0400 10/8/08, Brian Rosen wrote: > Sure, UI is important here. Some text on multiline might be appropriate > that is all about UI and But the IETF problem is the signaling: no one is > arguing that it is sometimes the right thing to let the user disconnect. So > it's not an absolute, "don't send BYE" or disable the button on the UI. > There is negotiation of the feature. I think the issue of PSAP control over termination is both signalling and UI. It can't be UI-only, because it needs to be optionally invoked by the PSAP. Presumably, PSAPs only want to invoke it when the call is being handled by a call taker, not when it's in a call queue or IVR, so there definitely needs to be signalling. Also, the PSAP probably needs to be able to initiate the signalling regardless of whether it is the called or calling party. Consider situations where someone places a call, and the PSAP needs to call back for whatever reason (and there are multiple possible reasons why the PSAP might need to call back, even in the presence of this feature). Given this, it probably makes sense that control over call termination be negotiated by SIP signalling that can be sent during the call by either end. Presumably, the user's device would have some criteria for accepting such a request to cede termination control (since you'd want this to be accepted when made by a PSAP but not when made by a telemarketer). Once the user's device accepted such a request, presumably it would not send a BYE, and the UI would indicate the situation to the user, hopefully taking full advantage of the UI richness afforded by modern devices. Presumably, a PSAP wanting to invoke the feature would make the request when the call taker came on the line, thus avoiding problems with IVRs and call queues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 6 12:17:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0573A6813; Thu, 6 Nov 2008 12:17:16 -0800 (PST) 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 A3EB13A6813 for ; Thu, 6 Nov 2008 12:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 pRCOxeSLrjCg for ; Thu, 6 Nov 2008 12:17:13 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A693F3A67E3 for ; Thu, 6 Nov 2008 12:17:13 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KyBH6-0002Jn-OI; Thu, 06 Nov 2008 14:16:20 -0600 From: "Brian Rosen" To: "'Randall Gellens'" , "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <073101c9296f$4ddbd110$e9937330$@net> In-Reply-To: Date: Thu, 6 Nov 2008 15:16:17 -0500 Message-ID: <03d101c9404c$8a8899b0$9f99cd10$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclASsE0mpFKELNjR4CHUkwGuirmXgAAaRsw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Seems fairly reasonable. I think it's acceptable to be "offer by UAC, accept by UAS". I don't think you need the reverse. Brian -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com] Sent: Thursday, November 06, 2008 2:52 PM To: Brian Rosen; 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner' Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination At 1:57 PM -0400 10/8/08, Brian Rosen wrote: > Sure, UI is important here. Some text on multiline might be appropriate > that is all about UI and But the IETF problem is the signaling: no one is > arguing that it is sometimes the right thing to let the user disconnect. So > it's not an absolute, "don't send BYE" or disable the button on the UI. > There is negotiation of the feature. I think the issue of PSAP control over termination is both signalling and UI. It can't be UI-only, because it needs to be optionally invoked by the PSAP. Presumably, PSAPs only want to invoke it when the call is being handled by a call taker, not when it's in a call queue or IVR, so there definitely needs to be signalling. Also, the PSAP probably needs to be able to initiate the signalling regardless of whether it is the called or calling party. Consider situations where someone places a call, and the PSAP needs to call back for whatever reason (and there are multiple possible reasons why the PSAP might need to call back, even in the presence of this feature). Given this, it probably makes sense that control over call termination be negotiated by SIP signalling that can be sent during the call by either end. Presumably, the user's device would have some criteria for accepting such a request to cede termination control (since you'd want this to be accepted when made by a PSAP but not when made by a telemarketer). Once the user's device accepted such a request, presumably it would not send a BYE, and the UI would indicate the situation to the user, hopefully taking full advantage of the UI richness afforded by modern devices. Presumably, a PSAP wanting to invoke the feature would make the request when the call taker came on the line, thus avoiding problems with IVRs and call queues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 8 13:28:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713263A69D3; Sat, 8 Nov 2008 13:28:51 -0800 (PST) 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 BF6FF3A69D3 for ; Sat, 8 Nov 2008 13:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 8T6tgwyyyJyG for ; Sat, 8 Nov 2008 13:28:49 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A8D8A3A6916 for ; Sat, 8 Nov 2008 13:28:49 -0800 (PST) Received: from [192.168.0.48] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mA8LSCMc024955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Nov 2008 16:28:34 -0500 (EST) Message-Id: <8CCBE056-C585-40E9-B656-CFCB0114871E@cs.columbia.edu> From: Henning Schulzrinne To: Randall Gellens In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 8 Nov 2008 16:28:00 -0500 References: <073101c9296f$4ddbd110$e9937330$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think there's a subtle difference between "accidental" and "premature" call termination. The former is easy to define: the caller accidentally disconnected, either because of hitting the wrong button or some technical problem, and would have preferred to stay on line. The second is harder to define, since both sides may have a different opinion as to whether the disconnect is "premature". Accidental disconnects are also premature, but not the other way around. The difference is the set where the PSAP wants to continue to talk, but the caller doesn't. We can prevent accidental disconnects largely with UI features, such as requiring user confirmation for hanging up. I think we can also prevent most legitimate premature terminations of the "caller doesn't realize the call taker wants to continue to talk, but has no objection" with appropriate UI design. A simple modal dialogue with "Please wait until the emergency call taker disconnects. Do you really want to terminate the call now?" before sending the BYE will presumably deal with most cases. The correct behavior depends a bit on the device. For example, an iPhone has different possibilities than a traditional place-receiver- on-hook phone (although that type of phone could conceivably switch to speakerphone mode until the user confirms the disconnect, with some kind of alerting to prevent eavesdropping). None of this requires more than recognizing that this is an emergency call. This is tricky for two cases: proxy-recognized calls and return calls. Henning On Nov 6, 2008, at 2:51 PM, Randall Gellens wrote: > At 1:57 PM -0400 10/8/08, Brian Rosen wrote: > >> Sure, UI is important here. Some text on multiline might be >> appropriate >> that is all about UI and But the IETF problem is the signaling: no >> one is >> arguing that it is sometimes the right thing to let the user >> disconnect. So >> it's not an absolute, "don't send BYE" or disable the button on the >> UI. >> There is negotiation of the feature. > > I think the issue of PSAP control over termination is both > signalling and UI. It can't be UI-only, because it needs to be > optionally invoked by the PSAP. Presumably, PSAPs only want to > invoke it when the call is being handled by a call taker, not when > it's in a call queue or IVR, so there definitely needs to be > signalling. Also, the PSAP probably needs to be able to initiate > the signalling regardless of whether it is the called or calling > party. Consider situations where someone places a call, and the > PSAP needs to call back for whatever reason (and there are multiple > possible reasons why the PSAP might need to call back, even in the > presence of this feature). > > Given this, it probably makes sense that control over call > termination be negotiated by SIP signalling that can be sent during > the call by either end. Presumably, the user's device would have > some criteria for accepting such a request to cede termination > control (since you'd want this to be accepted when made by a PSAP > but not when made by a telemarketer). Once the user's device > accepted such a request, presumably it would not send a BYE, and the > UI would indicate the situation to the user, hopefully taking full > advantage of the UI richness afforded by modern devices. > Presumably, a PSAP wanting to invoke the feature would make the > request when the call taker came on the line, thus avoiding problems > with IVRs and call queues. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself > only > -------------- Randomly-selected tag: --------------- > Procedures! Of course, that's what you'd use with a *sophisticated* > machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 10 00:45:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7DC3A69E2; Mon, 10 Nov 2008 00:45:09 -0800 (PST) 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 A0F0C3A69A6 for ; Mon, 10 Nov 2008 00:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 ehg800eM4V+T for ; Mon, 10 Nov 2008 00:45:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3E38E3A687A for ; Mon, 10 Nov 2008 00:45:03 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2008 08:45:00 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp008) with SMTP; 10 Nov 2008 09:45:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mjNE/297mVFNzEA5cwZ6E53Xs55zarOF60e0EFW 4CkyYrm7vBkWRa From: "Hannes Tschofenig" To: "ECRIT" Date: Mon, 10 Nov 2008 10:45:00 +0200 Message-ID: <00a801c94310$9e64be70$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclA5HssBEjSbwIiREWpHw2qZgjOzACLA8rg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: [Ecrit] FW: Publish Request - draft-ietf-ecrit-location-hiding-req-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI, Marc submitted the publication request for draft-ietf-ecrit-location-hiding-req-01. Ciao Hannes ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: 07 November, 2008 16:24 To: jon.peterson@neustar.biz; iesg-secretary@ietf.org Cc: Hannes Tschofenig Subject: Publish Request - draft-ietf-ecrit-location-hiding-req-01 I am requesting to publish draft-ietf-ecrit-location-hiding-req-01 PROTO WRITEUP for draft-ietf-ecrit-location-hiding-req-01.txt ============================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (mlinsner@cisco.com). The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document received a lot of reviews within the group. It was created after long and controversial discussions around feedback obtained from network operators about deploying the IETF emergency services architecture. There are no concerns about the depth and the breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) The topic of location hiding was controversal and kept ECRIT and GEOPRIV participants busy for a while. Key working group members have expressed a lot of concerns but seem to be fine with the resulting requirements document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists but there are not actions for IANA since this is a requirements document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain formal languages. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for "Location Hiding: Problem Statement and Requirements" (draft-ietf-ecrit-location-hiding-req-01.txt) Technical Summary The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has been reviewed by ECRIT working group members and feedback was provided by participants from various emergency services workshops. Personnel Marc Linsner is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 10 13:13:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9C63A68FA; Mon, 10 Nov 2008 13:13:51 -0800 (PST) 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 CC32F3A68FA for ; Mon, 10 Nov 2008 13:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 GM8W9Vdx5lOv for ; Mon, 10 Nov 2008 13:13:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E7A483A68AB for ; Mon, 10 Nov 2008 13:13:46 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2008 21:13:42 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp008) with SMTP; 10 Nov 2008 22:13:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SuLVBHYjShA27Bp2BAKdQvAfjrH4rBhl591I4ic 7LIk0qu2CCUKc9 From: "Hannes Tschofenig" To: "ECRIT" Date: Mon, 10 Nov 2008 23:13:42 +0200 Message-ID: <004c01c94379$36449d60$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclDeTUyZFcqLT7cSSCxUDZpPsI1CA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, thanks for the draft update. The document is much better than the previous version. I still have a few questions regarding Section 1.2. "Abandoned Call": The text is written in such a way that one gets the impression that a regular callback cannot be used for two reasons: A) No callback information is available (most likely only because of uninitialized emergency calls). B) The callback message from the PSAP does not reach the caller (because of call forwarding, etc.). For (A) we are working on solutions that allows the emergency caller to still have a temporary contact info and, at the same time, we try to get rid of uninitialized emergency calls. For (B) we work on solutions to allow calls from the PSAP to the UAC to specially marked to prevent these things from happening. This is good news: In some sense we are working on solutions in this problem space already. Now, the idea of "keeping" information of the abandoned could be OK once the SIP exchange is complete. This is also how it is defined. Still, in a real-world environment I still expect problems. For example, I suspect that some entities along the SIP signalig path will perform some actions when they see a BYE (sent as part of the call being abandoned). (Is it correct that the caller "stopped" the call using a BYE?) For example, an SBC might clean up resources, free allocated NAT bindings, and close opened firewall pinholes. As such, even if the PSAP suddenly sends packets (based on the state it kept alive) then these packets will be dropped on the floor. Additionally, depending on how long it takes the call taker to "contact" the emergency caller it is possible that NAT bindings / packet filters at stateful packet filtering firewalls already got removed (since they time out rather quickly) based on the lack of data packets being continously sent. It could be possible that things do not work too well in many real-world cases. Am I on the wrong track here? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 10 14:15:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAC73A6AA3; Mon, 10 Nov 2008 14:15:09 -0800 (PST) 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 BE82528C1C0 for ; Mon, 10 Nov 2008 14:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 VBCP13Berjxn for ; Mon, 10 Nov 2008 14:15:07 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D01EA3A6A82 for ; Mon, 10 Nov 2008 14:15:07 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kzf27-0007mT-Rj; Mon, 10 Nov 2008 16:14:56 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <004c01c94379$36449d60$0201a8c0@nsnintra.net> In-Reply-To: <004c01c94379$36449d60$0201a8c0@nsnintra.net> Date: Mon, 10 Nov 2008 17:15:00 -0500 Message-ID: <0a3301c94381$c77dea90$5679bfb0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclDeTUyZFcqLT7cSSCxUDZpPsI1CAAA3iXg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think the problems of call back are larger than the problems of keeping the call up, if that's what you mean. However, the requirement is rapid reconnect in the face of some congestion. If you can get that with call back, then you can meet the requirements. I highly doubt that its reasonably possible to do that, but maybe we can. I think that things like losing the media sessions, and the effect that has on call establishment is hard to fix. Consider a 3 second delay: the user hangs up. The phone immediately alerts. The user picks up. 3 second delay before the call taker can speak. Bad. That's why it says around 1 second ("rapid"). It' pretty tough, especially in congestion, to get <1 sec new call (call back) establishment. It could be done if priority treatment was given to the call along the path. That seams really hard. It seems easier to not drop the calls or the media sessions for the tens of seconds it might take to try to get the original caller back on the line. The call taker is going to move on after a while and drop the call. I really don't understand the discussion about networks making better use of resources by allowing the call to drop and then reconnecting it. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, November 10, 2008 4:14 PM To: ECRIT Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01.txt Hi Brian, thanks for the draft update. The document is much better than the previous version. I still have a few questions regarding Section 1.2. "Abandoned Call": The text is written in such a way that one gets the impression that a regular callback cannot be used for two reasons: A) No callback information is available (most likely only because of uninitialized emergency calls). B) The callback message from the PSAP does not reach the caller (because of call forwarding, etc.). For (A) we are working on solutions that allows the emergency caller to still have a temporary contact info and, at the same time, we try to get rid of uninitialized emergency calls. For (B) we work on solutions to allow calls from the PSAP to the UAC to specially marked to prevent these things from happening. This is good news: In some sense we are working on solutions in this problem space already. Now, the idea of "keeping" information of the abandoned could be OK once the SIP exchange is complete. This is also how it is defined. Still, in a real-world environment I still expect problems. For example, I suspect that some entities along the SIP signalig path will perform some actions when they see a BYE (sent as part of the call being abandoned). (Is it correct that the caller "stopped" the call using a BYE?) For example, an SBC might clean up resources, free allocated NAT bindings, and close opened firewall pinholes. As such, even if the PSAP suddenly sends packets (based on the state it kept alive) then these packets will be dropped on the floor. Additionally, depending on how long it takes the call taker to "contact" the emergency caller it is possible that NAT bindings / packet filters at stateful packet filtering firewalls already got removed (since they time out rather quickly) based on the lack of data packets being continously sent. It could be possible that things do not work too well in many real-world cases. Am I on the wrong track here? Ciao Hannes _______________________________________________ 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 ecrit-bounces@ietf.org Tue Nov 11 07:09:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D323D3A6B2A; Tue, 11 Nov 2008 07:09:43 -0800 (PST) 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 C88B63A6B26 for ; Tue, 11 Nov 2008 07:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_50=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 N6BRucGwcd6H for ; Tue, 11 Nov 2008 07:09:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E5E8D3A6840 for ; Tue, 11 Nov 2008 07:09:41 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2008 15:09:35 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp024) with SMTP; 11 Nov 2008 16:09:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+35hUhGu233pqhH8obgKw4QvBJW/82cYFg4g1wE+ XM8rqhK77csI71 From: "Hannes Tschofenig" To: "ECRIT" , "GEOPRIV" Date: Tue, 11 Nov 2008 17:09:34 +0200 Message-ID: <00d601c9440f$81f38c30$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclED4E5YM/mraRySVy5qz+fqXbkng== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.89 Subject: [Ecrit] Code Sprint 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If you are planning to participate at the code sprint this Saturday please drop me a mail. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 11 22:20:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180133A68E7; Tue, 11 Nov 2008 22:20:07 -0800 (PST) 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 2A5B03A68E7 for ; Tue, 11 Nov 2008 22:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, 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 a5-bVGTQcgZc for ; Tue, 11 Nov 2008 22:20:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9327C3A687E for ; Tue, 11 Nov 2008 22:20:04 -0800 (PST) Received: (qmail invoked by alias); 12 Nov 2008 06:20:04 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp049) with SMTP; 12 Nov 2008 07:20:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19VZvhIg/lVLjcWjgmW8C15cQBfQSWefSQ7xiW2Fa QLT0g5+Jl9PKE4 From: "Hannes Tschofenig" To: "ECRIT" Date: Wed, 12 Nov 2008 08:20:03 +0200 Message-ID: <014e01c9448e$b3a01f30$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclEIk7lygZQ1Yj+RA2mjbByHGHc4wAZtnHA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: [Ecrit] FW: Audio Streaming - IETF 73 November 16-21, 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At the next IETF ECRIT session we are also going to discuss the design team work. At a recent NENA phone conference I learned that a number of NENA members cannot join the IETF meeting and hence I suggest to make use of the remote participation facilities. Joel, as you can see in the attachment below, provides audio streaming support. As a backup we might also utilize Skype. Marc, maybe you can run Webex for us so that everyone else can see the slides? Jabber support is also available. The room is xmpp:ecrit@jabber.ietf.org and instructions for how to join it can, for example, be found here: http://www.emergency-services-coordination.info/2008Oct/chat-room.html You can already connect now to the room and test it. Ciao Hannes >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Joel Jaeggli >Sent: 11 November, 2008 19:21 >To: IETF Discussion >Subject: Audio Streaming - IETF 73 November 16-21, 2008 > >Greetings, > >All 8 parallel tracks will be broadcast starting with the >commencement of working group sessions on Monday, November 17, >2008 at 0900 CST and continue until Friday the 21st at 1130 >CST. Additionally it is our intention to broadcast the IEPG >meeting occurring on Sunday the 26th starting at 1000 CST. > >Because I have been asked several times in the past, note that >if you wish to use the rooms that are being recorded for >impromptu meeting during unscheduled sessions or lunch breaks >that you can invite remote participants to tune in to the >appropriate stream. Recording cannot be guaranteed for >unscheduled sessions. Conversely, it should never be assumed >that recording or observation is not occurring on open >microphones, they are after all connected to the Internet. > >The links for streaming sources and the schedule (shortly) >will be available thanks to the continued support of the >Network Startup Resource Center in their traditional location: > >http://videolab.uoregon.edu/events/ietf/ > >Regards >Joel Jaeggli > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 12 05:48:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C873A6958; Wed, 12 Nov 2008 05:48:00 -0800 (PST) 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 DF1FE3A6958 for ; Wed, 12 Nov 2008 05:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKtPiCc5c5na for ; Wed, 12 Nov 2008 05:47:57 -0800 (PST) Received: from mail177.messagelabs.com (mail177.messagelabs.com [85.158.138.99]) by core3.amsl.com (Postfix) with ESMTP id 708763A68FF for ; Wed, 12 Nov 2008 05:47:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-6.tower-177.messagelabs.com!1226497662!13556658!13 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 15264 invoked from network); 12 Nov 2008 13:47:53 -0000 Received: from dm1c8f.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-6.tower-177.messagelabs.com with RC4-SHA encrypted SMTP; 12 Nov 2008 13:47:53 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Wed, 12 Nov 2008 08:47:37 -0500 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Wed, 12 Nov 2008 08:47:36 -0500 From: To: , Date: Wed, 12 Nov 2008 08:47:35 -0500 Thread-Topic: [Ecrit] FW: Audio Streaming - IETF 73 November 16-21, 2008 Thread-Index: AclEIk7lygZQ1Yj+RA2mjbByHGHc4wAZtnHAABDD27A= Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2638483BE5@MBX02.bell.corp.bce.ca> References: <014e01c9448e$b3a01f30$0201a8c0@nsnintra.net> In-Reply-To: <014e01c9448e$b3a01f30$0201a8c0@nsnintra.net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ecrit] FW: Audio Streaming - IETF 73 November 16-21, 2008 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, Unfortunately, it will be impossible for me to attend, even remotely, the e= crit meeting at ietf73. Hopefully, other NENA members will be able to. Thanks for accommodating us. Guy -----Message d'origine----- De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de H= annes Tschofenig Envoy=E9 : 12 novembre 2008 01:20 =C0 : ECRIT Objet : [Ecrit] FW: Audio Streaming - IETF 73 November 16-21, 2008 At the next IETF ECRIT session we are also going to discuss the design team work. At a recent NENA phone conference I learned that a number of NENA members cannot join the IETF meeting and hence I suggest to make use of the remote participation facilities. Joel, as you can see in the attachment below, provides audio streaming support. As a backup we might also utilize Skype. Marc, maybe you can run Webex for us so that everyone else can see the slides? Jabber support is also available. The room is xmpp:ecrit@jabber.ietf.org and instructions for how to join it can, for example, be found here: http://www.emergency-services-coordination.info/2008Oct/chat-room.html You can already connect now to the room and test it. Ciao Hannes >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Joel Jaeggli >Sent: 11 November, 2008 19:21 >To: IETF Discussion >Subject: Audio Streaming - IETF 73 November 16-21, 2008 > >Greetings, > >All 8 parallel tracks will be broadcast starting with the >commencement of working group sessions on Monday, November 17, >2008 at 0900 CST and continue until Friday the 21st at 1130 >CST. Additionally it is our intention to broadcast the IEPG >meeting occurring on Sunday the 26th starting at 1000 CST. > >Because I have been asked several times in the past, note that >if you wish to use the rooms that are being recorded for >impromptu meeting during unscheduled sessions or lunch breaks >that you can invite remote participants to tune in to the >appropriate stream. Recording cannot be guaranteed for >unscheduled sessions. Conversely, it should never be assumed >that recording or observation is not occurring on open >microphones, they are after all connected to the Internet. > >The links for streaming sources and the schedule (shortly) >will be available thanks to the continued support of the >Network Startup Resource Center in their traditional location: > >http://videolab.uoregon.edu/events/ietf/ > >Regards >Joel Jaeggli > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ 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 ecrit-bounces@ietf.org Wed Nov 12 07:07:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C063A68DC; Wed, 12 Nov 2008 07:07:18 -0800 (PST) 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 53DA83A67F0 for ; Wed, 12 Nov 2008 07:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 e4Wx6X5k3eLS for ; Wed, 12 Nov 2008 07:07:16 -0800 (PST) Received: from mail177.messagelabs.com (mail177.messagelabs.com [85.158.138.99]) by core3.amsl.com (Postfix) with ESMTP id 285F83A68DC for ; Wed, 12 Nov 2008 07:07:16 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-13.tower-177.messagelabs.com!1226502140!7835582!95 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [206.47.0.173] Received: (qmail 30774 invoked from network); 12 Nov 2008 15:05:55 -0000 Received: from dm1c8f.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-13.tower-177.messagelabs.com with RC4-SHA encrypted SMTP; 12 Nov 2008 15:05:55 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.1.278.0; Wed, 12 Nov 2008 10:05:48 -0500 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Wed, 12 Nov 2008 10:05:47 -0500 From: To: Date: Wed, 12 Nov 2008 10:05:46 -0500 Thread-Topic: NENA i2.5 Review of draft-rosen-ecrit-premature-disconnect-rqmts-01 Thread-Index: Ack+DXJOjyUvmY9JSdujd6wLQV/VAAAC3LBgAa4d4BA= Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2638483CB9@MBX02.bell.corp.bce.ca> References: <055501c93e1a$1b93c270$52bb4750$@net> In-Reply-To: <055501c93e1a$1b93c270$52bb4750$@net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Ecrit] NENA i2.5 Review of draft-rosen-ecrit-premature-disconnect-rqmts-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Dear ECRIT, The NENA i2.5 Working Group has recently reviewed the new version of the draft and supports it albeit the following changes. In order to align with the NENA i2.5 requirements, we propose that PD-2 and PD-4 be modified as follows: "PD-2 It must be possible for the call taker to know when the caller has attempted to prematurely disconnect and conversely, when a caller attempts to reconnect after having previously attempted to disconnect." This change is necessary to capture the capability for the call taker to know when a caller is attempting to reconnect. "PD-4 When PD-1 is enforced, the call taker must be able to cause alerting at the UAC in situations where the caller has attempted to prematurely disconnect from the emergency call or, when the caller has gone silent without having disconnected. Rationale: The caller may believe they have disconnected or is unable to speak. The ability to alert is needed to encourage the caller, or someone is its surroundings, to reconnect with the call taker." This change is necessary to capture the capability for the call taker to cause alerting at the UAC when the caller is deemed to be still connected but is not verbally responding. Thanks, Guy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 14 17:51:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178063A6A67; Fri, 14 Nov 2008 17:51:59 -0800 (PST) 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 72B7C3A6AA9 for ; Fri, 14 Nov 2008 17:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui+3m4rzbwjR for ; Fri, 14 Nov 2008 17:51:56 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF0F03A6A57 for ; Fri, 14 Nov 2008 17:51:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,607,1220227200"; d="scan'208";a="195184491" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Nov 2008 01:51:57 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAF1pvEX020756 for ; Fri, 14 Nov 2008 17:51:57 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id mAF1puJP000816 for ; Sat, 15 Nov 2008 01:51:56 GMT Message-Id: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> From: Cullen Jennings To: ECRIT Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 18:51:50 -0700 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=202; t=1226713917; x=1227577917; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20What's=20up=20with=20draft-patel-ecrit-sos-para meter |Sender:=20; bh=57GUopxw2PqbCYmBqlgEOtvXqRinHeThNhDMTzHoNlQ=; b=QSzDtl3NPWqjShvMg5fLJsdtLiZrtwYpP3L/xPjDlcqUZPpnboqV+bF4jd hxLuoHu97N/awthl6M7oTDmeIK27VdikZ8KPhnXLiKHaRdubKQfEqPtv5NeZ tA896v/hp+; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I was hoping to see more discussion of this draft on the list. Do folks love it, hate it, think it's done, want to use something else, not understand the problem, whatever? Thoughts? Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 15 05:43:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8103A68A5; Sat, 15 Nov 2008 05:43:32 -0800 (PST) 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 ED4EB3A682C for ; Sat, 15 Nov 2008 05:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-RkC7n-dgJa for ; Sat, 15 Nov 2008 05:43:30 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 16DCA3A6784 for ; Sat, 15 Nov 2008 05:43:29 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAFDhOO01616; Sat, 15 Nov 2008 13:43:24 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 Nov 2008 13:43:20 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com> In-Reply-To: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Thread-Index: AclGxMQ89nLdobMqT2CYMRkhriCI4gAYsu8Q References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> From: "Milan Patel" To: "Cullen Jennings" , "ECRIT" Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Cullen, Thanks for encouraging further discussion on this draft. Currently, it aligns with the proposed use of this URI parameter in 3GPP. During last week's 3GPP meeting, further requests were made for folks to provide their comments on the ECRIT mailing list. Keith will present the draft on my behalf at IETF73. Best regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 15 November 2008 01:52 To: ECRIT Subject: [Ecrit] What's up with draft-patel-ecrit-sos-parameter I was hoping to see more discussion of this draft on the list. Do folks love it, hate it, think it's done, want to use something else, not understand the problem, whatever? Thoughts? Cullen _______________________________________________ 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 ecrit-bounces@ietf.org Sat Nov 15 11:27:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7677E3A67D1; Sat, 15 Nov 2008 11:27:09 -0800 (PST) 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 5CDA13A67D1 for ; Sat, 15 Nov 2008 11:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 NjTB4LHcHnYT for ; Sat, 15 Nov 2008 11:27:07 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 686833A6403 for ; Sat, 15 Nov 2008 11:27:07 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L1QnJ-0008Do-I2; Sat, 15 Nov 2008 13:26:57 -0600 From: "Brian Rosen" To: "'Milan Patel'" , "'Cullen Jennings'" , "'ECRIT'" References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> <0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com> In-Reply-To: <0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com> Date: Sat, 15 Nov 2008 14:27:00 -0500 Message-ID: <005301c94758$23c7a370$6b56ea50$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclGxMQ89nLdobMqT2CYMRkhriCI4gAYsu8QAAvKf2A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have discussed this with Milan. I agree that we need SOMETHING to mark an emergency registration. A parameter on a URI may be the best way to do that, or something else may be appropriate. In our discussion, I think I convinced him that the service URN can stay on the call until it gets to the UAS, even if that was a gateway, and thus is a sufficient marking for the call. Again, I think I convinced Milan that having a URI parameter doesn't fix the problem of a UAC that doesn't recognize a call as an emergency call. If it could recognize the parameter, it could follow phonebcp to determine what is an emergency call, etc. Call backs need a separately chartered item. I don't think we're going to end up with a URI parameter to mark a call back, but I won't prejudice what comes out of that work. Requirements first I would say. Net net, 3GPP needs an emergency registration. Other networks may have similar needs. We need a way to mark an emergency registration. A parameter is one way. Is that the best way? If it is, this work should go ahead with that single purpose. If not, this work should die, and something else should take its place. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Milan Patel Sent: Saturday, November 15, 2008 8:43 AM To: Cullen Jennings; ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Hi Cullen, Thanks for encouraging further discussion on this draft. Currently, it aligns with the proposed use of this URI parameter in 3GPP. During last week's 3GPP meeting, further requests were made for folks to provide their comments on the ECRIT mailing list. Keith will present the draft on my behalf at IETF73. Best regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 15 November 2008 01:52 To: ECRIT Subject: [Ecrit] What's up with draft-patel-ecrit-sos-parameter I was hoping to see more discussion of this draft on the list. Do folks love it, hate it, think it's done, want to use something else, not understand the problem, whatever? Thoughts? Cullen _______________________________________________ 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 ecrit-bounces@ietf.org Sat Nov 15 12:06:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF253A68DC; Sat, 15 Nov 2008 12:06:34 -0800 (PST) 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 E8C433A68DC for ; Sat, 15 Nov 2008 12:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 8xpxNWHgiF4x for ; Sat, 15 Nov 2008 12:06:33 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 2E8CC3A6882 for ; Sat, 15 Nov 2008 12:06:33 -0800 (PST) Received: from [192.168.0.61] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAFK6KHq002505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Nov 2008 15:06:21 -0500 (EST) Message-Id: <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <005301c94758$23c7a370$6b56ea50$@net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 15:06:20 -0500 References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> <0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com> <005301c94758$23c7a370$6b56ea50$@net> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: 'ECRIT' Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Does the emergency registration use the same authentication credentials as the regular registration? Besides being for call backs, what else is different? On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: > > > Net net, 3GPP needs an emergency registration. Other networks may > have > similar needs. We need a way to mark an emergency registration. A > parameter is one way. Is that the best way? If it is, this work > should go > ahead with that single purpose. If not, this work should die, and > something > else should take its place. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Nov 15 23:15:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809AA28C110; Sat, 15 Nov 2008 23:15:44 -0800 (PST) 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 9676B3A68ED for ; Sat, 15 Nov 2008 23:15:43 -0800 (PST) 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 C+H435GviFP5 for ; Sat, 15 Nov 2008 23:15:42 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8EF2E3A6878 for ; Sat, 15 Nov 2008 23:15:42 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAG7FUA3005886; Sun, 16 Nov 2008 01:15:33 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Nov 2008 01:15:31 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Nov 2008 08:15:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Nov 2008 08:11:51 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> In-Reply-To: <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Thread-Index: AclHXauVRLIJnv/5RSiZfsD+0n8ZxgAXE2cw References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> From: "DRAGE, Keith \(Keith\)" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 16 Nov 2008 07:15:28.0625 (UTC) FILETIME=[1A868610:01C947BB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In IMS - Authentication is the same. - The emergency registration does not use the service route extension. - The emergency registration does not create a temporary GRUU. - The emergency registraion cannot be deregistered by the user. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Henning Schulzrinne > Sent: Saturday, November 15, 2008 8:06 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > > Does the emergency registration use the same authentication > credentials as the regular registration? Besides being for > call backs, what else is different? > > On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: > > > > > > Net net, 3GPP needs an emergency registration. Other networks may > > have similar needs. We need a way to mark an emergency > registration. > > A parameter is one way. Is that the best way? If it is, this work > > should go ahead with that single purpose. If not, this work should > > die, and something else should take its place. > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Sun Nov 16 08:21:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2D03A6783; Sun, 16 Nov 2008 08:21:36 -0800 (PST) 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 3319D3A6783 for ; Sun, 16 Nov 2008 08:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 nWNZxhLswQAY for ; Sun, 16 Nov 2008 08:21:34 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 397973A6782 for ; Sun, 16 Nov 2008 08:21:34 -0800 (PST) Received: from [192.168.0.61] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAGGLRor003667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Nov 2008 11:21:28 -0500 (EST) Message-Id: From: Henning Schulzrinne To: "DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 16 Nov 2008 11:21:27 -0500 References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Is the registration request sent to the same registrar as the regular registration? I don't quite understand how this differs from a UAC perspective. The registration doesn't really return any data to the UAC, and the registrar can already keep whatever information it wants, i.e., not de- register. The draft is not too helpful here: "emergency registration is necessary to inform the registrar that the contact address and AOR being registered is to be used for emergency calls, and roaming and barring restrictions should not be applied for the registered AOR." Why would a UA submit a different AOR and contact address for the emergency registration? I think conflating the call marking [REQ2] with the registration marking [REQ1] just adds confusion to the discussion, as they seem to be orthogonal issues. It is not clear that the same solution is appropriate in all cases, so this seems to be a case of reverse- engineering the requirements from a solution. Henning On Nov 16, 2008, at 2:11 AM, DRAGE, Keith (Keith) wrote: > In IMS > > - Authentication is the same. > > - The emergency registration does not use the service route > extension. > > - The emergency registration does not create a temporary GRUU. > > - The emergency registraion cannot be deregistered by the user. > > regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Henning Schulzrinne >> Sent: Saturday, November 15, 2008 8:06 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter >> >> Does the emergency registration use the same authentication >> credentials as the regular registration? Besides being for >> call backs, what else is different? >> >> On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: >>> >>> >>> Net net, 3GPP needs an emergency registration. Other networks may >>> have similar needs. We need a way to mark an emergency >> registration. >>> A parameter is one way. Is that the best way? If it is, this work >>> should go ahead with that single purpose. If not, this work should >>> die, and something else should take its place. >>> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Sun Nov 16 10:29:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADEE73A683E; Sun, 16 Nov 2008 10:29:28 -0800 (PST) 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 73CF43A683E for ; Sun, 16 Nov 2008 10:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RHwf9dem0g9I for ; Sun, 16 Nov 2008 10:29:26 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7DB313A63EB for ; Sun, 16 Nov 2008 10:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1226860166; x=1258396166; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<005301c94758$23c7a370$6b 56ea50$@net>|References:=20<31236E68-C73F-4B81-AAE7-231C2 09374A0@cisco.com>=0D=0A=20<0913B6CD18F370498CD65864CF254 E90075F8C5B@zharhxm1.corp.nortel.com>=0D=0A=20<005301c947 58$23c7a370$6b56ea50$@net>|Date:=20Sun,=2016=20Nov=202008 =2010:29:21=20-0800|To:=20Brian=20Rosen=20,=20"'Milan=20Patel'"=20,=0D=0A =20=20=20=20=20=20=20=20"'Cullen=20Jennings'"=20,=20"'ECRIT'"=20|From:=20Ted=20H ardie=20|Subject:=20Re:=20[Ecrit]=20 What's=20up=20with=20draft-patel-ecrit-sos-parameter |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5435"=3B=20 a=3D"13144462"; bh=TSHvTODhQkNjUoI2IKJIMc8zOcYwCq88HkZq55tMjg0=; b=enJ22fe4gohFuit+iDB/7Nv9aeDBltr8P8OCur245l2IIKQoVrLIvO3T BgHsPPQKYXyjFf/3CBdyJkWSAmFwRHF25PTUU9B2dQrm+Y7k3339Jj2wP 8EE8whkET7DXlRye3VmgcMd0pryc2YlaIr4CVcsewJTYtjgSk6NnUYyFa w=; X-IronPort-AV: E=McAfee;i="5300,2777,5435"; a="13144462" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2008 10:29:26 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAGITPQL024067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Nov 2008 10:29:26 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAGITN3w004195 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 16 Nov 2008 10:29:25 -0800 (PST) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 10:29:22 -0800 Received: from [10.240.15.39] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Sun, 16 Nov 2008 10:29:21 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <005301c94758$23c7a370$6b56ea50$@net> References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com> <0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com> <005301c94758$23c7a370$6b56ea50$@net> Date: Sun, 16 Nov 2008 10:29:21 -0800 To: Brian Rosen , "'Milan Patel'" , "'Cullen Jennings'" , "'ECRIT'" From: Ted Hardie Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > >Net net, 3GPP needs an emergency registration. Other networks may have >similar needs. We need a way to mark an emergency registration. A >parameter is one way. Is that the best way? If it is, this work should go >ahead with that single purpose. If not, this work should die, and something >else should take its place. > >Brian I think the fastest way to move forward at this point is to charter this document as a working group item. That will get 3gpp on the right track (and I believe that there are other tracks...). Once there, if we discover that the current method proposed needs adjustment, we can do so. But absent a working group draft and an agreement to work on it, we're likely to see different parts of the system go different ways. This seems like a reasonable document to start from, at least to me. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 16 11:18:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2357D3A6904; Sun, 16 Nov 2008 11:18:37 -0800 (PST) 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 1D8FF3A6904 for ; Sun, 16 Nov 2008 11:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_34=0.6] 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 wxIdCbuVLvr6 for ; Sun, 16 Nov 2008 11:18:34 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 785B93A67AA for ; Sun, 16 Nov 2008 11:18:32 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2008 19:18:30 -0000 Received: from unknown (EHLO 4FIL42860) [130.129.31.217] by mail.gmx.net (mp015) with SMTP; 16 Nov 2008 20:18:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fOypDHS6f21q2S7IXXvTWBa7uGpHvmWjbiIARYk N10qlQCAmWkWMz From: "Hannes Tschofenig" To: "'ECRIT'" Date: Sun, 16 Nov 2008 21:18:18 +0200 Message-ID: <000101c94820$184cf5e0$17ac1cac@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclIAboklpVbiNRNQSK7nR9O9ivDgQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: [Ecrit] PhoneBCP & Element Mapping 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org When we worked on the text in Section 5.4 of http://tools.ietf.org/html/rfc5222#section-5.4 " 5.4. The Mapped Service: The Element The mandatory element identifies the service for which this mapping applies. Two cases need to be distinguished when the LoST server sets the element in the response message: 1. If the requested service, identified by the service URN [9] in the element of the request, exists for the location indicated, then the LoST server copies the service URN from the request into the element. 2. If, however, the requested service, identified by the service URN [9] in the element in the request, does not exist for the location indicated, the server either can return a (Section 13.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request. " We had a discussion at that time on what information to provide about mapping of requests for Service URNs that a certain jurisdiction may or may not implement. We decided that we would provide a generic text aout the element in LoST, as we see from the text above. And, we would provide more details in the Phone BCP on how this would be done in the emergency services environment. I had problems finding something in PhoneBCP. Did I miss it or did we loose the stuff? We discussed this quite extensively on the list a while ago (pointers to the discussions welcome). So, I believe there needs to be some information about what happens in the following cases: 1) Request with a Service URN comes in (e.g. sos.police) and the specific jurisdiction only provides support for sos without sub-services. We need to provide some text saying that there should not be a error be returned but instead a mapping takes place and the used serviceURN is then returned in the response. 2) Request with a Service URN comes in (e.g., sos) and a specific jurisdiction implements sub-services. (sos.police, sos.fire, ...). This case is less common these days as there are emergency numbers like 1-1-2 and 9-1-1. Does this make sense or am I jet lagged? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 17 05:11:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E294F3A6403; Mon, 17 Nov 2008 05:11:34 -0800 (PST) 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 08FB53A680A for ; Mon, 17 Nov 2008 05:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtV+KtLKUfKY for ; Mon, 17 Nov 2008 05:11:33 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DB56A3A6403 for ; Mon, 17 Nov 2008 05:11:32 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mAHD8JM02304; Mon, 17 Nov 2008 13:08:19 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 13:11:18 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Thread-Index: AclIB2g6bZgtWIShSuurw5ARfewQkQAlYpXg References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> From: "Milan Patel" To: "Henning Schulzrinne" , "DRAGE, Keith (Keith)" Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning The registration request is sent to the same registrar as the regular registration - all registration occurs with the home network. Registration allows the UAC to get a tel-URI for use in emergency calls. This is required so that the emergency caller can be contacted (via call back) in the case where the PSAP is located in the PSTN. Additionally, during call-back, the Serving-CSCF has knowledge of the route towards the emergency caller. If a particular AOR was registered, it is possible to ensure that special handling is applied for this AOR - suppress network based services and barring restrictions. In the Internet Draft, I didn't want to go into all the requirements of registration since these are covered in 3GPP TS 23.167 (which is a normative reference). 3GPP requirements mandate that barred identities can be used to initiate emergency calls. Roaming resitrctions on any identities registered during emergency call initiation must be lifted so these identities can be used when initiating an emergency call when roaming. Registration at the time of emergency call initiation allows these requirements to be fulfilled. Emergency Registration, while roaming, forces the UE to register via register via a local proxy so that a local Emergency-CSCF can be reached. Existing registrations may have resulted in the UE attached to a home proxy, thus a local E-CSCF cannot be reached. Regards, Milan -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: 16 November 2008 16:21 To: DRAGE, Keith (Keith) Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Is the registration request sent to the same registrar as the regular registration? I don't quite understand how this differs from a UAC perspective. The registration doesn't really return any data to the UAC, and the registrar can already keep whatever information it wants, i.e., not de- register. The draft is not too helpful here: "emergency registration is necessary to inform the registrar that the contact address and AOR being registered is to be used for emergency calls, and roaming and barring restrictions should not be applied for the registered AOR." Why would a UA submit a different AOR and contact address for the emergency registration? I think conflating the call marking [REQ2] with the registration marking [REQ1] just adds confusion to the discussion, as they seem to be orthogonal issues. It is not clear that the same solution is appropriate in all cases, so this seems to be a case of reverse- engineering the requirements from a solution. Henning On Nov 16, 2008, at 2:11 AM, DRAGE, Keith (Keith) wrote: > In IMS > > - Authentication is the same. > > - The emergency registration does not use the service route > extension. > > - The emergency registration does not create a temporary GRUU. > > - The emergency registraion cannot be deregistered by the user. > > regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of Henning Schulzrinne >> Sent: Saturday, November 15, 2008 8:06 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter >> >> Does the emergency registration use the same authentication >> credentials as the regular registration? Besides being for call >> backs, what else is different? >> >> On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: >>> >>> >>> Net net, 3GPP needs an emergency registration. Other networks may >>> have similar needs. We need a way to mark an emergency >> registration. >>> A parameter is one way. Is that the best way? If it is, this work >>> should go ahead with that single purpose. If not, this work should >>> die, and something else should take its place. >>> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Mon Nov 17 08:03:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5119628C114; Mon, 17 Nov 2008 08:03:20 -0800 (PST) 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 728843A6A3B for ; Mon, 17 Nov 2008 08:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=-0.316, 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 TOLkZoP0yTKN for ; Mon, 17 Nov 2008 08:03:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id BC3D93A6A3A for ; Mon, 17 Nov 2008 08:03:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAHG3B4u026789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Nov 2008 17:03:11 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAHG3AD4031245 for ; Mon, 17 Nov 2008 17:03:11 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 17:02:13 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 17:02:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 18:02:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unauthenticated ES Work from EMU Thread-Index: AclIislkztktkQlRRJecpLwmwZCYYw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 17 Nov 2008 16:02:13.0643 (UTC) FILETIME=[DAFF4DB0:01C948CD] Subject: [Ecrit] Unauthenticated ES Work from EMU 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I just attended the EMU meeting and noticed that there is a document in the group that addresses issues raised by the IEEE about unauthenticated emergency services (submitted via a liaison statement). Here is the document and the respective section: http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-01#section-3.5 3.5. Emergency Services Authentication When wireless VOIP service is provided, some regulations require any user to be able to gain access to the network to make an emergency telephone call. To avoid eavesdropping on this call, it's best to negotiate link layer security as with any other authentication. Therefore, the tunnel method SHOULD allow anonymous peers or server- only authentication, but still derive keys that can be used for link layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client. Forgoing authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link layer security. This also reminds me to check with Wimax and IEEE about this topic in relationship to the draft http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access- 04.txt This document got recently updated and now contains new terminology. Your feedback would be valuable. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 17 10:34:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C5B3A68AC; Mon, 17 Nov 2008 10:34:50 -0800 (PST) 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 2547E3A68AC for ; Mon, 17 Nov 2008 10:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_34=0.6] 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 Ll7uUmJUkVIf for ; Mon, 17 Nov 2008 10:34:48 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3A4C13A6835 for ; Mon, 17 Nov 2008 10:34:48 -0800 (PST) Received: from [130.129.95.3] (helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L28vm-0005Nv-Ef; Mon, 17 Nov 2008 12:34:39 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <000101c94820$184cf5e0$17ac1cac@nsnintra.net> In-Reply-To: <000101c94820$184cf5e0$17ac1cac@nsnintra.net> Date: Mon, 17 Nov 2008 07:32:07 -0500 Message-ID: <027101c948b0$8259ffb0$870dff10$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclIAboklpVbiNRNQSK7nR9O9ivDgQAo4bhQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] PhoneBCP & Element Mapping 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think this may be up to the jurisdiction. Rather than specifying behavior in -phonebcp, I'd rather just allow the LoST server to have a mapping for every defined service in sos, which might very well all be the same. I could see some text in -framework which says this. The latter case (request .sos in a country that doesn't have a single call center) really ought to be specified, one way or another, what that jurisdiction wishes to be. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, November 16, 2008 2:18 PM To: 'ECRIT' Subject: [Ecrit] PhoneBCP & Element Mapping When we worked on the text in Section 5.4 of http://tools.ietf.org/html/rfc5222#section-5.4 " 5.4. The Mapped Service: The Element The mandatory element identifies the service for which this mapping applies. Two cases need to be distinguished when the LoST server sets the element in the response message: 1. If the requested service, identified by the service URN [9] in the element of the request, exists for the location indicated, then the LoST server copies the service URN from the request into the element. 2. If, however, the requested service, identified by the service URN [9] in the element in the request, does not exist for the location indicated, the server either can return a (Section 13.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request. " We had a discussion at that time on what information to provide about mapping of requests for Service URNs that a certain jurisdiction may or may not implement. We decided that we would provide a generic text aout the element in LoST, as we see from the text above. And, we would provide more details in the Phone BCP on how this would be done in the emergency services environment. I had problems finding something in PhoneBCP. Did I miss it or did we loose the stuff? We discussed this quite extensively on the list a while ago (pointers to the discussions welcome). So, I believe there needs to be some information about what happens in the following cases: 1) Request with a Service URN comes in (e.g. sos.police) and the specific jurisdiction only provides support for sos without sub-services. We need to provide some text saying that there should not be a error be returned but instead a mapping takes place and the used serviceURN is then returned in the response. 2) Request with a Service URN comes in (e.g., sos) and a specific jurisdiction implements sub-services. (sos.police, sos.fire, ...). This case is less common these days as there are emergency numbers like 1-1-2 and 9-1-1. Does this make sense or am I jet lagged? Ciao Hannes _______________________________________________ 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 ecrit-bounces@ietf.org Mon Nov 17 14:38:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3E83A6A83; Mon, 17 Nov 2008 14:38:27 -0800 (PST) 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 22C583A6A83 for ; Mon, 17 Nov 2008 14:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.003 X-Spam-Level: X-Spam-Status: No, score=-5.003 tagged_above=-999 required=5 tests=[AWL=1.596, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg7QNHsYEHeG for ; Mon, 17 Nov 2008 14:38:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 26AFA3A6A7D for ; Mon, 17 Nov 2008 14:38:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAHMcNh5017657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Nov 2008 23:38:23 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAHMcKMe024648 for ; Mon, 17 Nov 2008 23:38:23 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 23:37:47 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 23:37:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 00:37:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides, Please! Thread-Index: AclIwg3gsbrDZOpSSde/L2vp6qHqZw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 17 Nov 2008 22:37:47.0159 (UTC) FILETIME=[1D467270:01C94905] Subject: [Ecrit] Slides, Please! 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Please make sure that you send your slides to Roger so that he can upload them Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 18 08:11:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2269A3A6A66; Tue, 18 Nov 2008 08:11:20 -0800 (PST) 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 38D5728C14F for ; Tue, 18 Nov 2008 08:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 vsMfP4CTTxAb for ; Tue, 18 Nov 2008 08:11:17 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id E2BA83A6808 for ; Tue, 18 Nov 2008 08:11:16 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAIGBAXQ004617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2008 11:11:10 -0500 (EST) Message-Id: <0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu> From: Henning Schulzrinne To: Milan Patel In-Reply-To: <0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 11:11:10 -0500 References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> <0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My general question is whether we need special mechanisms for REGISTER, as we have enough complexity already. (I won't go into the INVITE case for now, as that seems to be a more complicated issue and raises a significant number of fraud prevent issues unless there is no incentive for non-emergency parties to add a "sos".) There seem to be two REGISTER cases: - "Normal" user (not barred from roaming, lacking authentication, ...): As far as I can tell, the device doesn't do anything different and wouldn't know about including special Contact headers in any event. The draft doesn't really specify what happens in that case, as it seems to focus far too much on syntax and not on behavior. Your note seems to indicate that the registrar returns some kind of special (tel) URI that the UA should use as a contact in the call. The draft says "will be included in the Contact header" - but not by whom. If we really want special Contact URIs that the caller should use only in emergency INVITEs, it may make sense to think about parameters *for that Contact URI*. For example, the 'user' parameter may well be suitable for that purpose. In any event, this doesn't require a separate registration, as this special URI could just be returned along with the others, thus reducing the registration signaling load by half. - "Restricted" user: This presumably leads to the whole discussion about unauthenticated calls, subject of a different draft. Henning On Nov 17, 2008, at 8:11 AM, Milan Patel wrote: > Hi Henning > > The registration request is sent to the same registrar as the regular > registration - all registration occurs with the home network. > > Registration allows the UAC to get a tel-URI for use in emergency > calls. > This is required so that the emergency caller can be contacted (via > call > back) in the case where the PSAP is located in the PSTN. Additionally, > during call-back, the Serving-CSCF has knowledge of the route towards > the emergency caller. If a particular AOR was registered, it is > possible > to ensure that special handling is applied for this AOR - suppress > network based services and barring restrictions. In the Internet > Draft, > I didn't want to go into all the requirements of registration since > these are covered in 3GPP TS 23.167 (which is a normative reference). > > 3GPP requirements mandate that barred identities can be used to > initiate > emergency calls. Roaming resitrctions on any identities registered > during emergency call initiation must be lifted so these identities > can > be used when initiating an emergency call when roaming. > Registration at > the time of emergency call initiation allows these requirements to be > fulfilled. Emergency Registration, while roaming, forces the UE to > register via register via a local proxy so that a local Emergency-CSCF > can be reached. Existing registrations may have resulted in the UE > attached to a home proxy, thus a local E-CSCF cannot be reached. > > Regards, > Milan > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: 16 November 2008 16:21 > To: DRAGE, Keith (Keith) > Cc: ECRIT > Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > > Is the registration request sent to the same registrar as the regular > registration? > > I don't quite understand how this differs from a UAC perspective. The > registration doesn't really return any data to the UAC, and the > registrar can already keep whatever information it wants, i.e., not > de- > register. > > The draft is not too helpful here: "emergency registration is > necessary > to inform the registrar that the contact address and AOR being > registered is to be used for emergency calls, and roaming and barring > restrictions should not be applied for the registered AOR." > > Why would a UA submit a different AOR and contact address for the > emergency registration? > > I think conflating the call marking [REQ2] with the registration > marking > [REQ1] just adds confusion to the discussion, as they seem to be > orthogonal issues. It is not clear that the same solution is > appropriate > in all cases, so this seems to be a case of reverse- engineering the > requirements from a solution. > > Henning > > On Nov 16, 2008, at 2:11 AM, DRAGE, Keith (Keith) wrote: > >> In IMS >> >> - Authentication is the same. >> >> - The emergency registration does not use the service route >> extension. >> >> - The emergency registration does not create a temporary GRUU. >> >> - The emergency registraion cannot be deregistered by the user. >> >> regards >> >> Keith >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Henning Schulzrinne >>> Sent: Saturday, November 15, 2008 8:06 PM >>> To: Brian Rosen >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter >>> >>> Does the emergency registration use the same authentication >>> credentials as the regular registration? Besides being for call >>> backs, what else is different? >>> >>> On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: >>>> >>>> >>>> Net net, 3GPP needs an emergency registration. Other networks may >>>> have similar needs. We need a way to mark an emergency >>> registration. >>>> A parameter is one way. Is that the best way? If it is, this work >>>> should go ahead with that single purpose. If not, this work should >>>> die, and something else should take its place. >>>> >>> _______________________________________________ >>> 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 ecrit-bounces@ietf.org Tue Nov 18 09:38:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FD528C1C2; Tue, 18 Nov 2008 09:38:43 -0800 (PST) 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 0519828C13D for ; Tue, 18 Nov 2008 09:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtZhq1IYJFch for ; Tue, 18 Nov 2008 09:38:40 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7871F28C1AC for ; Tue, 18 Nov 2008 09:38:40 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id mAIHZQN14050; Tue, 18 Nov 2008 17:35:26 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 17:38:30 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> In-Reply-To: <0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] What's up with draft-patel-ecrit-sos-parameter Thread-Index: AclJmFs/O7CJu9b1RT6DwDcEiCFvUQACERlw References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> <0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com> <0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu> From: "Milan Patel" To: "Henning Schulzrinne" Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Henning, Firstly, your previous email you asked: Why not just have the normal registration be accepted for emergency calls only, without the parameter? This is perfectly OK when the user is not roaming. At least in 3GPP, the addition of "sos" in the INVITE's contact header can be associated with the sos URN in the Request-URI. But let's concentrate on the REGISTER request for now in this email. I'll deal with the restricted case first: if you do not have sufficient credentials to register with the network, you can't register, so yes, this is similar to the unauthenticated access. In this case, we are using Equipment identity to identify the user, but doesn't help in the call-back case. Since the user is not registered at an S-CSCF, there is no way the call can be routed back to the user. Normal user: if the user isn't roaming, and registered as one normally does. The UE registers with a SIP URI. In the P-Associated-URI in the 200 (OK) to the REGISTER, the UE receives all the identities implicitly registered by the UE, including a tel-URI. In the event of an emergency, the user may use any of these identities when initiating an emergency call. Now in the case when the user wasn't registered, or was roaming (regardless of being registered or not), and has sufficient credentials to be authenticated by the network, the user makes an emergency call - the UE registers with the network. It needs to tell the registrar this registration is due to an emergency call, please don't barr my identities, or restrict me from roaming. Do I need to provide further explanation in the draft on the conditions for emergency registration? Isn't it sufficient to refer out to 3GPP TS 23.167? Cheers, Milan -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: 18 November 2008 16:11 To: Patel, Milan (MOP:EP10) Cc: DRAGE, Keith (Keith); ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter My general question is whether we need special mechanisms for REGISTER, as we have enough complexity already. (I won't go into the INVITE case for now, as that seems to be a more complicated issue and raises a significant number of fraud prevent issues unless there is no incentive for non-emergency parties to add a "sos".) There seem to be two REGISTER cases: - "Normal" user (not barred from roaming, lacking authentication, ...): As far as I can tell, the device doesn't do anything different and wouldn't know about including special Contact headers in any event. The draft doesn't really specify what happens in that case, as it seems to focus far too much on syntax and not on behavior. Your note seems to indicate that the registrar returns some kind of special (tel) URI that the UA should use as a contact in the call. The draft says "will be included in the Contact header" - but not by whom. If we really want special Contact URIs that the caller should use only in emergency INVITEs, it may make sense to think about parameters *for that Contact URI*. For example, the 'user' parameter may well be suitable for that purpose. In any event, this doesn't require a separate registration, as this special URI could just be returned along with the others, thus reducing the registration signaling load by half. - "Restricted" user: This presumably leads to the whole discussion about unauthenticated calls, subject of a different draft. Henning On Nov 17, 2008, at 8:11 AM, Milan Patel wrote: > Hi Henning > > The registration request is sent to the same registrar as the regular > registration - all registration occurs with the home network. > > Registration allows the UAC to get a tel-URI for use in emergency > calls. > This is required so that the emergency caller can be contacted (via > call > back) in the case where the PSAP is located in the PSTN. Additionally, > during call-back, the Serving-CSCF has knowledge of the route towards > the emergency caller. If a particular AOR was registered, it is > possible to ensure that special handling is applied for this AOR - > suppress network based services and barring restrictions. In the > Internet Draft, I didn't want to go into all the requirements of > registration since these are covered in 3GPP TS 23.167 (which is a > normative reference). > > 3GPP requirements mandate that barred identities can be used to > initiate emergency calls. Roaming resitrctions on any identities > registered during emergency call initiation must be lifted so these > identities can > be used when initiating an emergency call when roaming. > Registration at > the time of emergency call initiation allows these requirements to be > fulfilled. Emergency Registration, while roaming, forces the UE to > register via register via a local proxy so that a local Emergency-CSCF > can be reached. Existing registrations may have resulted in the UE > attached to a home proxy, thus a local E-CSCF cannot be reached. > > Regards, > Milan > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: 16 November 2008 16:21 > To: DRAGE, Keith (Keith) > Cc: ECRIT > Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter > > Is the registration request sent to the same registrar as the regular > registration? > > I don't quite understand how this differs from a UAC perspective. The > registration doesn't really return any data to the UAC, and the > registrar can already keep whatever information it wants, i.e., not > de- > register. > > The draft is not too helpful here: "emergency registration is > necessary to inform the registrar that the contact address and AOR > being registered is to be used for emergency calls, and roaming and > barring restrictions should not be applied for the registered AOR." > > Why would a UA submit a different AOR and contact address for the > emergency registration? > > I think conflating the call marking [REQ2] with the registration > marking [REQ1] just adds confusion to the discussion, as they seem to > be orthogonal issues. It is not clear that the same solution is > appropriate in all cases, so this seems to be a case of reverse- > engineering the requirements from a solution. > > Henning > > On Nov 16, 2008, at 2:11 AM, DRAGE, Keith (Keith) wrote: > >> In IMS >> >> - Authentication is the same. >> >> - The emergency registration does not use the service route >> extension. >> >> - The emergency registration does not create a temporary GRUU. >> >> - The emergency registraion cannot be deregistered by the user. >> >> regards >> >> Keith >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Henning Schulzrinne >>> Sent: Saturday, November 15, 2008 8:06 PM >>> To: Brian Rosen >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter >>> >>> Does the emergency registration use the same authentication >>> credentials as the regular registration? Besides being for call >>> backs, what else is different? >>> >>> On Nov 15, 2008, at 2:27 PM, Brian Rosen wrote: >>>> >>>> >>>> Net net, 3GPP needs an emergency registration. Other networks may >>>> have similar needs. We need a way to mark an emergency >>> registration. >>>> A parameter is one way. Is that the best way? If it is, this work >>>> should go ahead with that single purpose. If not, this work should >>>> die, and something else should take its place. >>>> >>> _______________________________________________ >>> 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 ecrit-bounces@ietf.org Tue Nov 18 11:42:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6485A28C1FE; Tue, 18 Nov 2008 11:42:19 -0800 (PST) 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 6153C28C1F0 for ; Tue, 18 Nov 2008 11:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 6yVIIt05yA7s for ; Tue, 18 Nov 2008 11:42:17 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 54D053A677C for ; Tue, 18 Nov 2008 11:42:17 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAIJffvw025348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2008 14:41:41 -0500 (EST) Message-Id: <039FDECD-29A7-4A57-A759-CC3A61E19EB7@cs.columbia.edu> From: Henning Schulzrinne To: Milan Patel In-Reply-To: <0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 14:41:40 -0500 References: <31236E68-C73F-4B81-AAE7-231C209374A0@cisco.com><0913B6CD18F370498CD65864CF254E90075F8C5B@zharhxm1.corp.nortel.com><005301c94758$23c7a370$6b56ea50$@net> <2D9E2E27-7E18-4EB4-83A2-AABEA45D26DC@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180024D92E3@DEEXC1U01.de.lucent.com> <0913B6CD18F370498CD65864CF254E900763513B@zharhxm1.corp.nortel.com> <0671D971-1FA1-4024-951E-4DC75555C8FD@cs.columbia.edu> <0913B6CD18F370498CD65864CF254E90076A4850@zharhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Milan, thanks for your explanation. I think it raises a larger issue: You seem to treat this as a 3GPP-specific issue, i.e., something that only should be used in the 3GPP case. For example, the P-Associated-URI facility is not something available outside that context. In general, I consider it a bad idea to have deployment-specific SIP variants, even more so in the emergency calling case. The goal should be that any SIP terminal can place emergency calls, rather than creating non- compatible versions of SIP based on access networks. Maybe we should have this larger-issue first before worrying about parameter syntax. Henning On Nov 18, 2008, at 12:38 PM, Milan Patel wrote: > Hi Henning, > > Firstly, your previous email you asked: > Why not just have the normal registration be accepted for emergency > calls only, without the parameter? > This is perfectly OK when the user is not roaming. > > At least in 3GPP, the addition of "sos" in the INVITE's contact header > can be associated with the sos URN in the Request-URI. But let's > concentrate on the REGISTER request for now in this email. > > I'll deal with the restricted case first: if you do not have > sufficient > credentials to register with the network, you can't register, so yes, > this is similar to the unauthenticated access. In this case, we are > using Equipment identity to identify the user, but doesn't help in the > call-back case. Since the user is not registered at an S-CSCF, there > is > no way the call can be routed back to the user. > > Normal user: if the user isn't roaming, and registered as one normally > does. The UE registers with a SIP URI. In the P-Associated-URI in the > 200 (OK) to the REGISTER, the UE receives all the identities > implicitly > registered by the UE, including a tel-URI. In the event of an > emergency, > the user may use any of these identities when initiating an emergency > call. > > Now in the case when the user wasn't registered, or was roaming > (regardless of being registered or not), and has sufficient > credentials > to be authenticated by the network, the user makes an emergency call - > the UE registers with the network. It needs to tell the registrar this > registration is due to an emergency call, please don't barr my > identities, or restrict me from roaming. > > Do I need to provide further explanation in the draft on the > conditions > for emergency registration? Isn't it sufficient to refer out to 3GPP > TS > 23.167? > > Cheers, > Milan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 18 12:33:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF1F3A6895; Tue, 18 Nov 2008 12:33:04 -0800 (PST) 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 80E6A3A6895 for ; Tue, 18 Nov 2008 12:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=-0.723, 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 I6tkYHdv3q-T for ; Tue, 18 Nov 2008 12:33:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7E1083A67D1 for ; Tue, 18 Nov 2008 12:33:02 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAIKWxnH025842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Nov 2008 21:32:59 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIKWuqJ026755 for ; Tue, 18 Nov 2008 21:32:59 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 21:32:58 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 21:32:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:29:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? Thread-Index: AclJeV041iNev00MQ1uylIhf5+ZtsQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 20:32:58.0241 (UTC) FILETIME=[D7F1FF10:01C949BC] Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have read the document and I still have a hard time understanding the value of the work. There is no need to mark emergency calls beyond the marking we have with the Service URN document Calls between PSAPs and from a PSAP to a first responder the Service URN is not used. You could, if you think it is useful, use the existing Resource Priority header there. So, why do we need this? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 18 12:40:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BBE3A6AAD; Tue, 18 Nov 2008 12:40:08 -0800 (PST) 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 C2B663A6809 for ; Tue, 18 Nov 2008 12:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 QBb1b-FYEsrP for ; Tue, 18 Nov 2008 12:40:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 396C53A6AAD for ; Tue, 18 Nov 2008 12:40:04 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAIKdtvi017930; Tue, 18 Nov 2008 14:40:01 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 14:39:55 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 21:39:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 21:39:52 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D97B6@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Usefulness? Thread-Index: AclJeV041iNev00MQ1uylIhf5+ZtsQARAyCg References: From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 20:39:53.0240 (UTC) FILETIME=[CF4DD180:01C949BD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You should mark a call appropriate to the functions it need to perform. If you want an emergency call to pass through special queues or whatever in SIP entities, then it should be marked with the appropriate header for doing that, which is the Resource-Priority header. Some administrations want to do this with emergency calls. This would seem to be entirely consistent with the views put forward in draft-ietf-sipping-service-identification, for example, whereas your one indicator does everything, does not. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, November 18, 2008 8:30 PM > To: ECRIT > Subject: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace --Usefulness? > > I have read the document and I still have a hard time > understanding the value of the work. > > There is no need to mark emergency calls beyond the marking > we have with the Service URN document Calls between PSAPs > and from a PSAP to a first responder the Service URN is not > used. You could, if you think it is useful, use the existing > Resource Priority header there. > > So, why do we need this? > > Ciao > Hannes > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Nov 18 13:00:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0BF3A6B28; Tue, 18 Nov 2008 13:00:19 -0800 (PST) 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 AB86D3A6B2F; Tue, 18 Nov 2008 13:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLt8VHbDP579; Tue, 18 Nov 2008 13:00:16 -0800 (PST) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id 7F2243A6B25; Tue, 18 Nov 2008 13:00:16 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-145.messagelabs.com!1227042010!4671972!6 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 24682 invoked from network); 18 Nov 2008 21:00:14 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-145.messagelabs.com with AES256-SHA encrypted SMTP; 18 Nov 2008 21:00:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAIL07ca002414; Tue, 18 Nov 2008 16:00:13 -0500 In-Reply-To: To: "Tschofenig, Hannes (NSN - FI/Espoo)" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 18 Nov 2008 16:00:05 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/18/2008 04:02:45 PM, Serialize complete at 11/18/2008 04:02:45 PM Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? 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: , Content-Type: multipart/mixed; boundary="===============1282821786==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1282821786== Content-Type: multipart/alternative; boundary="=_alternative 00735DD185257505_=" This is a multipart message in MIME format. --=_alternative 00735DD185257505_= Content-Type: text/plain; charset="US-ASCII" Which "existing Resource Priority header" are you proposing to use? The dsn, and drsn namespaces are not intended for use outside the US DoD networks, and only provide (preemption based) priority over calls with the same namespace, but a different value. The q735 namespace, while not restricted to the US DoD is similarly based on a "closed group preemption", which is not appropriate to this situation. The ets and wps namespaces are intended for the "Next Generation" versions of Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS). Both of these are intended to support National Security and Emergency Preparedness, and explicitly exclude "911-type" calls. As I noted earlier, I have some real concerns about some of the text in this ID. But I support the concept of an RPH namespace for ecrit-related calls/sessions. Janet ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > I have read the document and I still have a hard time understanding the > value of the work. > > There is no need to mark emergency calls beyond the marking we have with > the Service URN document > Calls between PSAPs and from a PSAP to a first responder the Service > URN is not used. You could, if you think it is useful, use the existing > Resource Priority header there. > > So, why do we need this? > > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 00735DD185257505_= Content-Type: text/html; charset="US-ASCII"


Which "existing Resource Priority header" are you proposing to use?  

The dsn, and drsn namespaces are not intended for use outside the US DoD networks, and only provide (preemption based) priority over calls with the same namespace, but a different value.

The q735 namespace, while not restricted to the US DoD is similarly based on a "closed group preemption", which is not appropriate to this situation.

The ets and wps namespaces are intended for the "Next Generation" versions of Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS).  Both of these are intended to support National Security and Emergency Preparedness, and explicitly exclude "911-type" calls.

As I noted earlier, I have some real concerns about some of the text in this ID.  But I support the concept of an RPH namespace for ecrit-related calls/sessions.

Janet

ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM:

> I have read the document and I still have a hard time understanding the
> value of the work.
>
> There is no need to mark emergency calls beyond the marking we have with
> the Service URN document
> Calls between PSAPs  and from a PSAP to a first responder the Service
> URN is not used. You could, if you think it is useful, use the existing
> Resource Priority header there.
>
> So, why do we need this?
>
> Ciao
> Hannes
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
 --=_alternative 00735DD185257505_=-- --===============1282821786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1282821786==-- From ecrit-bounces@ietf.org Tue Nov 18 13:01:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757233A6B35; Tue, 18 Nov 2008 13:01:08 -0800 (PST) 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 B17383A6B35 for ; Tue, 18 Nov 2008 13:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-0.678, 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 unVK44WhjgjR for ; Tue, 18 Nov 2008 13:01:06 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id A32DC3A682A for ; Tue, 18 Nov 2008 13:01:05 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAIKWxjb025794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Nov 2008 21:32:59 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIKWsP2026703 for ; Tue, 18 Nov 2008 21:32:58 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 21:32:58 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 21:32:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:29:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 20:32:57.0694 (UTC) FILETIME=[D79E87E0:01C949BC] Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have reviewed this document and I believe the scope has changed to what we agreed in previous ECRIT meetings. I believe that the document must not provide mechanisms for * PSAP callbacks * end hosts attaching a marking I believe that the document should only talk about how to use this marking inside an emergency services network. Other mechanisms are overlapping with other techniques and raise security issues. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 18 13:29:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1053A6A73; Tue, 18 Nov 2008 13:29:51 -0800 (PST) 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 81D8E3A6809; Tue, 18 Nov 2008 13:29:50 -0800 (PST) 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 OxF5SEK1a5Tc; Tue, 18 Nov 2008 13:29:49 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 70F333A6A73; Tue, 18 Nov 2008 13:29:48 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAILTgd7020528; Tue, 18 Nov 2008 15:29:42 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 15:29:42 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 22:29:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:29:38 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? Thread-Index: AclJwKyfICLLbK3CQcmXEFjOBu/FTwAA7N/A References: From: "DRAGE, Keith \(Keith\)" To: "Janet P Gunn" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" X-OriginalArrivalTime: 18 Nov 2008 21:29:39.0877 (UTC) FILETIME=[C37A7550:01C949C4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Type: multipart/mixed; boundary="===============0966940363==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0966940363== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C949C4.C32E55CD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C949C4.C32E55CD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is only one Resource-Priority header field, that defined in RFC 4412. =20 Different handling is determined by the namespace within the header. =20 The requirements for handling emergency calls in terms of priority are different from any other existing namespace, so it needs a new namespace. =20 That is a "priority" namespace rather than a "preemption" one. =20 Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Tuesday, November 18, 2008 9:00 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: ECRIT; ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? =09 =09 =09 =09 Which "existing Resource Priority header" are you proposing to use? =20 =09 The dsn, and drsn namespaces are not intended for use outside the US DoD networks, and only provide (preemption based) priority over calls with the same namespace, but a different value.=20 =09 The q735 namespace, while not restricted to the US DoD is similarly based on a "closed group preemption", which is not appropriate to this situation.=20 =09 The ets and wps namespaces are intended for the "Next Generation" versions of Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS). Both of these are intended to support National Security and Emergency Preparedness, and explicitly exclude "911-type" calls.=20 =09 As I noted earlier, I have some real concerns about some of the text in this ID. But I support the concept of an RPH namespace for ecrit-related calls/sessions.=20 =09 Janet=20 =09 ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: =09 > I have read the document and I still have a hard time understanding the > value of the work.=20 >=20 > There is no need to mark emergency calls beyond the marking we have with > the Service URN document=20 > Calls between PSAPs and from a PSAP to a first responder the Service > URN is not used. You could, if you think it is useful, use the existing > Resource Priority header there.=20 >=20 > So, why do we need this?=20 >=20 > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit =09 ------_=_NextPart_001_01C949C4.C32E55CD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is only one Resource-Priority header = field, that=20 defined in RFC 4412.
 
Different handling is determined by the = namespace within=20 the header.
 
The requirements for handling emergency calls = in terms of=20 priority are different from any other existing namespace, so it needs a = new=20 namespace.
 
That is a "priority" namespace rather than a = "preemption"=20 one.
 
Keith

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P=20 Gunn
Sent: Tuesday, November 18, 2008 9:00 PM
To:=20 Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ECRIT;=20 ecrit-bounces@ietf.org
Subject: Re: [Ecrit]=20 draft-ietf-ecrit-local-emergency-rph-namespace--=20 Usefulness?




Which = "existing Resource=20 Priority header" are you proposing to use?  

The dsn, and drsn namespaces are not = intended for use=20 outside the US DoD networks, and only provide (preemption based) = priority over=20 calls with the same namespace, but a different value. =

The q735 namespace, while not restricted to = the US DoD=20 is similarly based on a "closed group preemption", which is not = appropriate to=20 this situation.

The = ets and wps=20 namespaces are intended for the "Next Generation" versions of = Government=20 Emergency Telecommunications Service (GETS) and Wireless Priority = Service=20 (WPS).  Both of these are intended to support National Security = and=20 Emergency Preparedness, and explicitly exclude "911-type" = calls.=20

As I noted earlier, I have = some real=20 concerns about some of the text in this ID.  But I support the = concept of=20 an RPH namespace for ecrit-related calls/sessions. =

Janet

ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 = PM:

>=20 I have read the document and I still have a hard time understanding=20 the
> value of the work.
>
> There is no need to = mark=20 emergency calls beyond the marking we have with
> the Service = URN=20 document
> Calls between PSAPs  and from a PSAP to a first = responder the Service
> URN is not used. You could, if you think = it is=20 useful, use the existing
> Resource Priority header there. =
>=20
> So, why do we need this?
>
> Ciao
>=20 Hannes
> _______________________________________________
> = Ecrit=20 mailing list
> Ecrit@ietf.org
>=20 = https://www.ietf.org/mailman/listinfo/ecrit
<= /BODY> ------_=_NextPart_001_01C949C4.C32E55CD-- --===============0966940363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0966940363==-- From ecrit-bounces@ietf.org Tue Nov 18 13:33:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928ED28C271; Tue, 18 Nov 2008 13:33:06 -0800 (PST) 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 4B79328C271; Tue, 18 Nov 2008 13:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=-0.638, 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 1zRVMX8FMq1V; Tue, 18 Nov 2008 13:33:04 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D5F523A68C4; Tue, 18 Nov 2008 13:33:03 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAILWs6i019146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 22:32:54 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAILWnK5029194; Tue, 18 Nov 2008 22:32:53 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:32:52 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:32:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 23:31:14 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? Thread-Index: AclJwKyfICLLbK3CQcmXEFjOBu/FTwAA7N/AABCf7dA= References: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Janet P Gunn" X-OriginalArrivalTime: 18 Nov 2008 21:32:51.0704 (UTC) FILETIME=[35D0EF80:01C949C5] Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If it has a totally different meaning does it make sense to put it in the RPH namespace? ________________________________ From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: 18 November, 2008 23:30 To: Janet P Gunn; Tschofenig, Hannes (NSN - FI/Espoo) Cc: ECRIT; ecrit-bounces@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? There is only one Resource-Priority header field, that defined in RFC 4412. Different handling is determined by the namespace within the header. The requirements for handling emergency calls in terms of priority are different from any other existing namespace, so it needs a new namespace. That is a "priority" namespace rather than a "preemption" one. Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Tuesday, November 18, 2008 9:00 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: ECRIT; ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? Which "existing Resource Priority header" are you proposing to use? The dsn, and drsn namespaces are not intended for use outside the US DoD networks, and only provide (preemption based) priority over calls with the same namespace, but a different value. The q735 namespace, while not restricted to the US DoD is similarly based on a "closed group preemption", which is not appropriate to this situation. The ets and wps namespaces are intended for the "Next Generation" versions of Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS). Both of these are intended to support National Security and Emergency Preparedness, and explicitly exclude "911-type" calls. As I noted earlier, I have some real concerns about some of the text in this ID. But I support the concept of an RPH namespace for ecrit-related calls/sessions. Janet ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > I have read the document and I still have a hard time understanding the > value of the work. > > There is no need to mark emergency calls beyond the marking we have with > the Service URN document > Calls between PSAPs and from a PSAP to a first responder the Service > URN is not used. You could, if you think it is useful, use the existing > Resource Priority header there. > > So, why do we need this? > > Ciao > Hannes > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Nov 18 13:33:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D203528C277; Tue, 18 Nov 2008 13:33:08 -0800 (PST) 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 542E628C27C; Tue, 18 Nov 2008 13:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=1.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjnwZMncCY9P; Tue, 18 Nov 2008 13:33:06 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CD8A43A685C; Tue, 18 Nov 2008 13:33:05 -0800 (PST) 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 mAILX1Zb002905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 22:33:01 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAILX0XH029889; Tue, 18 Nov 2008 22:33:01 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:33:00 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 22:32:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 23:32:52 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? Thread-Index: AclJwKdyVM1tgOnQR1isge1gbW1S6QAPqywQ References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Janet P Gunn" X-OriginalArrivalTime: 18 Nov 2008 21:32:59.0688 (UTC) FILETIME=[3A933280:01C949C5] Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I wonder why the specific usage has been tied into the RPH usage. After all, they are just tokens and in the US DoD networks they would have defined their special meaning for them. ________________________________ From: ext Janet P Gunn [mailto:jgunn6@csc.com] Sent: 18 November, 2008 23:00 To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: ECRIT; ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? Which "existing Resource Priority header" are you proposing to use? The dsn, and drsn namespaces are not intended for use outside the US DoD networks, and only provide (preemption based) priority over calls with the same namespace, but a different value. The q735 namespace, while not restricted to the US DoD is similarly based on a "closed group preemption", which is not appropriate to this situation. The ets and wps namespaces are intended for the "Next Generation" versions of Government Emergency Telecommunications Service (GETS) and Wireless Priority Service (WPS). Both of these are intended to support National Security and Emergency Preparedness, and explicitly exclude "911-type" calls. As I noted earlier, I have some real concerns about some of the text in this ID. But I support the concept of an RPH namespace for ecrit-related calls/sessions. Janet ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > I have read the document and I still have a hard time understanding the > value of the work. > > There is no need to mark emergency calls beyond the marking we have with > the Service URN document > Calls between PSAPs and from a PSAP to a first responder the Service > URN is not used. You could, if you think it is useful, use the existing > Resource Priority header there. > > So, why do we need this? > > Ciao > Hannes > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Nov 18 13:42:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A332D3A6B1F; Tue, 18 Nov 2008 13:42:15 -0800 (PST) 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 E565B3A6923; Tue, 18 Nov 2008 13:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NE8mojmXk3Cp; Tue, 18 Nov 2008 13:42:14 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E24C03A6885; Tue, 18 Nov 2008 13:42:13 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAILg7ZF027556; Tue, 18 Nov 2008 15:42:07 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 15:42:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 22:42:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 22:42:03 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D97BB@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? Thread-Index: AclJwKyfICLLbK3CQcmXEFjOBu/FTwAA7N/AABCf7dAAEDFaoA== References: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "Janet P Gunn" X-OriginalArrivalTime: 18 Nov 2008 21:42:04.0872 (UTC) FILETIME=[7F87AC80:01C949C6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The Resource-Priority header was defined to have multiple namespaces. You define your prioritisation requirements by defining the namespace, i.e. it is a name of your template. So yes, it makes absolute sense to use the Resource-Priority header for exactly the functions for which it was defined. regards Keith > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Tuesday, November 18, 2008 9:31 PM > To: DRAGE, Keith (Keith); Janet P Gunn > Cc: ECRIT; ecrit-bounces@ietf.org > Subject: RE: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > > If it has a totally different meaning does it make sense to > put it in the RPH namespace? > > > > ________________________________ > > From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 18 November, 2008 23:30 > To: Janet P Gunn; Tschofenig, Hannes (NSN - FI/Espoo) > Cc: ECRIT; ecrit-bounces@ietf.org > Subject: RE: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > > > There is only one Resource-Priority header field, that > defined in RFC 4412. > > Different handling is determined by the namespace > within the header. > > The requirements for handling emergency calls in terms > of priority are different from any other existing namespace, > so it needs a new namespace. > > That is a "priority" namespace rather than a "preemption" one. > > Keith > > > ________________________________ > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn > Sent: Tuesday, November 18, 2008 9:00 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: ECRIT; ecrit-bounces@ietf.org > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > > > > > > Which "existing Resource Priority header" are you > proposing to use? > > The dsn, and drsn namespaces are not intended > for use outside the US DoD networks, and only provide > (preemption based) priority over calls with the same > namespace, but a different value. > > The q735 namespace, while not restricted to the > US DoD is similarly based on a "closed group preemption", > which is not appropriate to this situation. > > The ets and wps namespaces are intended for the > "Next Generation" versions of Government Emergency > Telecommunications Service > (GETS) and Wireless Priority Service (WPS). Both of these > are intended to support National Security and Emergency > Preparedness, and explicitly exclude "911-type" calls. > > As I noted earlier, I have some real concerns > about some of the text in this ID. But I support the concept > of an RPH namespace for ecrit-related calls/sessions. > > Janet > > ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > > > I have read the document and I still have a > hard time understanding the > > value of the work. > > > > There is no need to mark emergency calls > beyond the marking we have with > > the Service URN document > > Calls between PSAPs and from a PSAP to a > first responder the Service > > URN is not used. You could, if you think it > is useful, use the existing > > Resource Priority header there. > > > > So, why do we need this? > > > > Ciao > > Hannes > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Tue Nov 18 13:51:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFD928C0E8; Tue, 18 Nov 2008 13:51:23 -0800 (PST) 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 8365F28C0E8; Tue, 18 Nov 2008 13:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2qAJSpBlIZp; Tue, 18 Nov 2008 13:51:21 -0800 (PST) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id 3E6E83A6B1F; Tue, 18 Nov 2008 13:51:21 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-64.messagelabs.com!1227045077!89698001!2 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 20472 invoked from network); 18 Nov 2008 21:51:19 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-5.tower-64.messagelabs.com with AES256-SHA encrypted SMTP; 18 Nov 2008 21:51:19 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAILpH8s002082; Tue, 18 Nov 2008 16:51:19 -0500 In-Reply-To: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith \(Keith\)" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 18 Nov 2008 16:51:14 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/18/2008 04:53:50 PM, Serialize complete at 11/18/2008 04:53:50 PM Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Type: multipart/mixed; boundary="===============0664516224==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0664516224== Content-Type: multipart/alternative; boundary="=_alternative 00780C1285257505_=" This is a multipart message in MIME format. --=_alternative 00780C1285257505_= Content-Type: text/plain; charset="US-ASCII" Yes that is what I meant. Use the same HEADER, but need a new NAMESPACE. Janet "DRAGE, Keith \(Keith\)" wrote on 11/18/2008 04:29:38 PM: > There is only one Resource-Priority header field, that defined in RFC 4412. > > Different handling is determined by the namespace within the header. > > The requirements for handling emergency calls in terms of priority > are different from any other existing namespace, so it needs a new namespace. > > That is a "priority" namespace rather than a "preemption" one. > > Keith > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Janet P Gunn > Sent: Tuesday, November 18, 2008 9:00 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: ECRIT; ecrit-bounces@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph- > namespace-- Usefulness? > > > > Which "existing Resource Priority header" are you proposing to use? > > The dsn, and drsn namespaces are not intended for use outside the US > DoD networks, and only provide (preemption based) priority over > calls with the same namespace, but a different value. > > The q735 namespace, while not restricted to the US DoD is similarly > based on a "closed group preemption", which is not appropriate to > this situation. > > The ets and wps namespaces are intended for the "Next Generation" > versions of Government Emergency Telecommunications Service (GETS) > and Wireless Priority Service (WPS). Both of these are intended to > support National Security and Emergency Preparedness, and explicitly > exclude "911-type" calls. > > As I noted earlier, I have some real concerns about some of the text > in this ID. But I support the concept of an RPH namespace for > ecrit-related calls/sessions. > > Janet > > ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > > > I have read the document and I still have a hard time understanding the > > value of the work. > > > > There is no need to mark emergency calls beyond the marking we have with > > the Service URN document > > Calls between PSAPs and from a PSAP to a first responder the Service > > URN is not used. You could, if you think it is useful, use the existing > > Resource Priority header there. > > > > So, why do we need this? > > > > Ciao > > Hannes > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 00780C1285257505_= Content-Type: text/html; charset="US-ASCII"

Yes that is what I meant.  Use the same HEADER, but need  a new NAMESPACE.

Janet

"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> wrote on 11/18/2008 04:29:38 PM:

> There is only one Resource-Priority header field, that defined in RFC 4412.
>  
> Different handling is determined by the namespace within the header.
>  
> The requirements for handling emergency calls in terms of priority
> are different from any other existing namespace, so it needs a new namespace.
>  
> That is a "priority" namespace rather than a "preemption" one.
>  
> Keith
>
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Janet P Gunn
> Sent: Tuesday, November 18, 2008 9:00 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: ECRIT; ecrit-bounces@ietf.org
> Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-
> namespace-- Usefulness?
>
>
>
> Which "existing Resource Priority header" are you proposing to use?  
>
> The dsn, and drsn namespaces are not intended for use outside the US
> DoD networks, and only provide (preemption based) priority over
> calls with the same namespace, but a different value.
>
> The q735 namespace, while not restricted to the US DoD is similarly
> based on a "closed group preemption", which is not appropriate to
> this situation.
>
> The ets and wps namespaces are intended for the "Next Generation"
> versions of Government Emergency Telecommunications Service (GETS)
> and Wireless Priority Service (WPS).  Both of these are intended to
> support National Security and Emergency Preparedness, and explicitly
> exclude "911-type" calls.
>
> As I noted earlier, I have some real concerns about some of the text
> in this ID.  But I support the concept of an RPH namespace for
> ecrit-related calls/sessions.
>
> Janet
>
> ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM:
>
> > I have read the document and I still have a hard time understanding the
> > value of the work.
> >
> > There is no need to mark emergency calls beyond the marking we have with
> > the Service URN document
> > Calls between PSAPs  and from a PSAP to a first responder the Service
> > URN is not used. You could, if you think it is useful, use the existing
> > Resource Priority header there.
> >
> > So, why do we need this?
> >
> > Ciao
> > Hannes
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 00780C1285257505_=-- --===============0664516224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0664516224==-- From ecrit-bounces@ietf.org Tue Nov 18 14:02:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39FEB28C272; Tue, 18 Nov 2008 14:02:06 -0800 (PST) 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 7150928C272 for ; Tue, 18 Nov 2008 14:02:05 -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=[AWL=0.300, 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 JK9lAmcju3Aa for ; Tue, 18 Nov 2008 14:02:04 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9CF8328C26A for ; Tue, 18 Nov 2008 14:02:04 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2Ydv-0005kZ-EE; Tue, 18 Nov 2008 16:01:55 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: In-Reply-To: Date: Tue, 18 Nov 2008 17:01:58 -0500 Message-ID: <07c801c949c9$490e7c30$db2b7490$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't see a problem here. I think it's perfectly reasonable for an endpoint or proxy outside an emergency services IP network to mark a call needing resource priority. The policing and behavior of proxy servers or UASs in the presence of such a marking is beyond the scope, but limiting the marking to emergency services networks is unwarranted. Further, differentiating between an incoming emergency call and a call back seems wise. It may be the case that there is minimal if any resource priority for such calls in some networks, where in others, it may be that there is some explicit priority of incoming vs outgoing. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Tuesday, November 18, 2008 3:30 PM To: ECRIT Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect I have reviewed this document and I believe the scope has changed to what we agreed in previous ECRIT meetings. I believe that the document must not provide mechanisms for * PSAP callbacks * end hosts attaching a marking I believe that the document should only talk about how to use this marking inside an emergency services network. Other mechanisms are overlapping with other techniques and raise security issues. Ciao Hannes _______________________________________________ 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 ecrit-bounces@ietf.org Tue Nov 18 14:07:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DCD3A685C; Tue, 18 Nov 2008 14:07:29 -0800 (PST) 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 EC9D13A68B5; Tue, 18 Nov 2008 14:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvTqk8JIqoZS; Tue, 18 Nov 2008 14:07:27 -0800 (PST) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id D99313A677E; Tue, 18 Nov 2008 14:07:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-64.messagelabs.com!1227046043!84929907!3 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 14041 invoked from network); 18 Nov 2008 22:07:25 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-4.tower-64.messagelabs.com with AES256-SHA encrypted SMTP; 18 Nov 2008 22:07:25 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAIM7MTl024136; Tue, 18 Nov 2008 17:07:25 -0500 In-Reply-To: To: "Tschofenig, Hannes (NSN - FI/Espoo)" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 18 Nov 2008 17:07:20 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/18/2008 05:09:56 PM, Serialize complete at 11/18/2008 05:09:56 PM Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? 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: , Content-Type: multipart/mixed; boundary="===============0393053029==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0393053029== Content-Type: multipart/alternative; boundary="=_alternative 0079857F85257505_=" This is a multipart message in MIME format. --=_alternative 0079857F85257505_= Content-Type: text/plain; charset="US-ASCII" It is entirely possible that a "DoD" call could originate on one DoD network, and terminate on another DoD network, but traverse a non-DOD network in between. The "DoD-related" namespace needs to be preserved, but ignored, by the traversed networks. I would be acted on only by the originating and terminating DoD networks. This would not be possible if the intervening network were using the same namespace for a completely different purpose. This behavior IS spelled out in 4412. Janet "Tschofenig, Hannes (NSN - FI/Espoo)" wrote on 11/18/2008 04:32:52 PM: > I wonder why the specific usage has been tied into the RPH usage. > After all, they are just tokens and in the US DoD networks they would > have defined their special meaning for them. > > > > ________________________________ > > From: ext Janet P Gunn [mailto:jgunn6@csc.com] > Sent: 18 November, 2008 23:00 > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: ECRIT; ecrit-bounces@ietf.org > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? > > > > > > Which "existing Resource Priority header" are you proposing to > use? > > The dsn, and drsn namespaces are not intended for use outside > the US DoD networks, and only provide (preemption based) priority over > calls with the same namespace, but a different value. > > The q735 namespace, while not restricted to the US DoD is > similarly based on a "closed group preemption", which is not appropriate > to this situation. > > The ets and wps namespaces are intended for the "Next > Generation" versions of Government Emergency Telecommunications Service > (GETS) and Wireless Priority Service (WPS). Both of these are intended > to support National Security and Emergency Preparedness, and explicitly > exclude "911-type" calls. > > As I noted earlier, I have some real concerns about some of the > text in this ID. But I support the concept of an RPH namespace for > ecrit-related calls/sessions. > > Janet > > ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > > > I have read the document and I still have a hard time > understanding the > > value of the work. > > > > There is no need to mark emergency calls beyond the marking we > have with > > the Service URN document > > Calls between PSAPs and from a PSAP to a first responder the > Service > > URN is not used. You could, if you think it is useful, use the > existing > > Resource Priority header there. > > > > So, why do we need this? > > > > Ciao > > Hannes > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > --=_alternative 0079857F85257505_= Content-Type: text/html; charset="US-ASCII"

It is entirely possible that a "DoD" call could originate on one DoD network, and terminate on another DoD network, but traverse a non-DOD network in between.

The "DoD-related" namespace needs to be preserved, but ignored, by the traversed networks. I would be acted on only by the originating and terminating DoD networks.  This would not be possible if the intervening network were using the same namespace for a completely different purpose.

This behavior IS spelled out in 4412.

Janet

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote on 11/18/2008 04:32:52 PM:

> I wonder why the specific usage has been tied into the RPH usage.
> After all, they are just tokens and in the US DoD networks they would
> have defined their special meaning for them.
>
>  
>
> ________________________________
>
>    From: ext Janet P Gunn [mailto:jgunn6@csc.com]
>    Sent: 18 November, 2008 23:00
>    To: Tschofenig, Hannes (NSN - FI/Espoo)
>    Cc: ECRIT; ecrit-bounces@ietf.org
>    Subject: Re: [Ecrit]
> draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness?
>    
>    
>
>    
>    
>    Which "existing Resource Priority header" are you proposing to
> use?  
>    
>    The dsn, and drsn namespaces are not intended for use outside
> the US DoD networks, and only provide (preemption based) priority over
> calls with the same namespace, but a different value.
>    
>    The q735 namespace, while not restricted to the US DoD is
> similarly based on a "closed group preemption", which is not appropriate
> to this situation.
>    
>    The ets and wps namespaces are intended for the "Next
> Generation" versions of Government Emergency Telecommunications Service
> (GETS) and Wireless Priority Service (WPS).  Both of these are intended
> to support National Security and Emergency Preparedness, and explicitly
> exclude "911-type" calls.
>    
>    As I noted earlier, I have some real concerns about some of the
> text in this ID.  But I support the concept of an RPH namespace for
> ecrit-related calls/sessions.
>    
>    Janet
>    
>    ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM:
>    
>    > I have read the document and I still have a hard time
> understanding the
>    > value of the work.
>    >
>    > There is no need to mark emergency calls beyond the marking we
> have with
>    > the Service URN document
>    > Calls between PSAPs  and from a PSAP to a first responder the
> Service
>    > URN is not used. You could, if you think it is useful, use the
> existing
>    > Resource Priority header there.
>    >
>    > So, why do we need this?
>    >
>    > Ciao
>    > Hannes
>    > _______________________________________________
>    > Ecrit mailing list
>    > Ecrit@ietf.org
>    > https://www.ietf.org/mailman/listinfo/ecrit
>    
>
--=_alternative 0079857F85257505_=-- --===============0393053029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0393053029==-- From ecrit-bounces@ietf.org Tue Nov 18 14:07:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A175F3A6B22; Tue, 18 Nov 2008 14:07:29 -0800 (PST) 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 6E1B63A677E for ; Tue, 18 Nov 2008 14:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 JvhuSPu1MW6M for ; Tue, 18 Nov 2008 14:07:27 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 865D63A685C for ; Tue, 18 Nov 2008 14:07:26 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mAIM8qeE005338; Tue, 18 Nov 2008 16:08:53 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 16:07:21 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 23:07:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 23:07:18 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> In-Reply-To: <07c801c949c9$490e7c30$db2b7490$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQAABAgeA= References: <07c801c949c9$490e7c30$db2b7490$@net> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:07:19.0487 (UTC) FILETIME=[064F94F0:01C949CA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian is correct. But I was under the impression that people wanted to do the callback stuff later. So I do envisage the current proposal only for the citizen to authority emergency call. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Tuesday, November 18, 2008 10:02 PM > To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > > I don't see a problem here. > > I think it's perfectly reasonable for an endpoint or proxy > outside an emergency services IP network to mark a call > needing resource priority. The policing and behavior of > proxy servers or UASs in the presence of such a marking is > beyond the scope, but limiting the marking to emergency > services networks is unwarranted. > > Further, differentiating between an incoming emergency call > and a call back seems wise. It may be the case that there is > minimal if any resource priority for such calls in some > networks, where in others, it may be that there is some > explicit priority of incoming vs outgoing. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, November 18, 2008 3:30 PM > To: ECRIT > Subject: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > I have reviewed this document and I believe the scope has > changed to what we agreed in previous ECRIT meetings. > > I believe that the document must not provide mechanisms for > * PSAP callbacks > * end hosts attaching a marking > > I believe that the document should only talk about how to use > this marking inside an emergency services network. > Other mechanisms are overlapping with other techniques and > raise security issues. > > Ciao > Hannes > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Nov 18 14:10:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8C23A68B5; Tue, 18 Nov 2008 14:10:40 -0800 (PST) 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 B28303A68B5 for ; Tue, 18 Nov 2008 14:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[AWL=1.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+YcJsOKJIyY for ; Tue, 18 Nov 2008 14:10:37 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 33B563A685C for ; Tue, 18 Nov 2008 14:10:37 -0800 (PST) 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 mAIMAWew010896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 23:10:32 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMATKW012087; Tue, 18 Nov 2008 23:10:32 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:10:30 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:10:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:10:28 +0200 Message-ID: In-Reply-To: <07c801c949c9$490e7c30$db2b7490$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQABBivcA= References: <07c801c949c9$490e7c30$db2b7490$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:10:29.0679 (UTC) FILETIME=[77AC93F0:01C949CA] Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org >I don't see a problem here. > >I think it's perfectly reasonable for an endpoint or proxy >outside an emergency services IP network to mark a call >needing resource priority. The policing and behavior of proxy >servers or UASs in the presence of such a marking is beyond >the scope, but limiting the marking to emergency services >networks is unwarranted. The problem with this approach is that you have TWO (2) different ways to mark an emergency call == NOT GOOD > >Further, differentiating between an incoming emergency call >and a call back seems wise. BUT: We have an alternative way to mark a call from a PSAP towards the UA. >It may be the case that there is >minimal if any resource priority for such calls in some >networks, where in others, it may be that there is some >explicit priority of incoming vs outgoing. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, November 18, 2008 3:30 PM >To: ECRIT >Subject: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > >I have reviewed this document and I believe the scope has >changed to what we agreed in previous ECRIT meetings. > >I believe that the document must not provide mechanisms for >* PSAP callbacks >* end hosts attaching a marking > >I believe that the document should only talk about how to use >this marking inside an emergency services network. >Other mechanisms are overlapping with other techniques and >raise security issues. > >Ciao >Hannes > > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Nov 18 14:11:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0715528C287; Tue, 18 Nov 2008 14:11:04 -0800 (PST) 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 AD15E28C286; Tue, 18 Nov 2008 14:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=1.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRGkFIjeO45b; Tue, 18 Nov 2008 14:10:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 91A3528C280; Tue, 18 Nov 2008 14:10:57 -0800 (PST) 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 mAIMAo7Z011104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 23:10:50 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMAn2p012272; Tue, 18 Nov 2008 23:10:50 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:09:05 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:09:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:09:03 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180024D97BB@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? Thread-Index: AclJwKyfICLLbK3CQcmXEFjOBu/FTwAA7N/AABCf7dAAEDFaoAAwJ1wg References: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180024D97BB@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Janet P Gunn" X-OriginalArrivalTime: 18 Nov 2008 22:09:04.0697 (UTC) FILETIME=[45055A90:01C949CA] Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, you believe that folks are going to use this to mark calls from PSAPs to first responders? >From a PSAP to a PSAP (in case of call forwarding) one could still use the Service URN? >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 18 November, 2008 23:42 >To: Tschofenig, Hannes (NSN - FI/Espoo); Janet P Gunn >Cc: ECRIT; ecrit-bounces@ietf.org >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > >The Resource-Priority header was defined to have multiple namespaces. >You define your prioritisation requirements by defining the >namespace, i.e. it is a name of your template. > >So yes, it makes absolute sense to use the Resource-Priority >header for exactly the functions for which it was defined. > >regards > >Keith > >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Tuesday, November 18, 2008 9:31 PM >> To: DRAGE, Keith (Keith); Janet P Gunn >> Cc: ECRIT; ecrit-bounces@ietf.org >> Subject: RE: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? >> >> If it has a totally different meaning does it make sense to >put it in >> the RPH namespace? >> >> >> >> ________________________________ >> >> From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> >> Sent: 18 November, 2008 23:30 >> To: Janet P Gunn; Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: ECRIT; ecrit-bounces@ietf.org >> Subject: RE: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? >> >> >> There is only one Resource-Priority header field, that >defined in RFC >> 4412. >> >> Different handling is determined by the namespace >within the header. >> >> The requirements for handling emergency calls in terms >of priority >> are different from any other existing namespace, so it needs a new >> namespace. >> >> That is a "priority" namespace rather than a "preemption" one. >> >> Keith >> >> >> ________________________________ >> >> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn >> Sent: Tuesday, November 18, 2008 9:00 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: ECRIT; ecrit-bounces@ietf.org >> Subject: Re: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? >> >> >> >> >> >> Which "existing Resource Priority header" are you >> proposing to use? >> >> The dsn, and drsn namespaces are not intended >for use outside the US >> DoD networks, and only provide (preemption based) priority >over calls >> with the same namespace, but a different value. >> >> The q735 namespace, while not restricted to the >US DoD is similarly >> based on a "closed group preemption", which is not >appropriate to this >> situation. >> >> The ets and wps namespaces are intended for the >"Next Generation" >> versions of Government Emergency Telecommunications Service >> (GETS) and Wireless Priority Service (WPS). Both of these are >> intended to support National Security and Emergency >Preparedness, and >> explicitly exclude "911-type" calls. >> >> As I noted earlier, I have some real concerns >about some of the text >> in this ID. But I support the concept of an RPH namespace for >> ecrit-related calls/sessions. >> >> Janet >> >> ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: >> >> > I have read the document and I still have a hard time >> understanding the >> > value of the work. >> > >> > There is no need to mark emergency calls >beyond the marking we >> have with >> > the Service URN document >> > Calls between PSAPs and from a PSAP to a >first responder the >> Service >> > URN is not used. You could, if you think it >is useful, use the >> existing >> > Resource Priority header there. >> > >> > So, why do we need this? >> > >> > Ciao >> > Hannes >> > _______________________________________________ >> > 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 ecrit-bounces@ietf.org Tue Nov 18 14:15:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D75B28C290; Tue, 18 Nov 2008 14:15:33 -0800 (PST) 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 421A028C28F for ; Tue, 18 Nov 2008 14:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=1.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4M3Ro-PJfyD for ; Tue, 18 Nov 2008 14:15:24 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8998328C290 for ; Tue, 18 Nov 2008 14:15:23 -0800 (PST) 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 mAIMFG5l015021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 23:15:16 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMFG9X017348; Tue, 18 Nov 2008 23:15:16 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:14:09 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:14:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:14:07 +0200 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQAABAgeAAEJaV0A== References: <07c801c949c9$490e7c30$db2b7490$@net> <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext DRAGE, Keith (Keith)" , "Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:14:09.0337 (UTC) FILETIME=[FA99BA90:01C949CA] Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There is a proposal for making a call back in http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt When we set the scope for draft-ietf-ecrit-local-emergency-rph-namespace there was no mentioning of a call-back mechanism. The group seemed to be OK about using this inside the emergency services infrastructure but there was critique when used outside. Ciao Hannes >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: 19 November, 2008 00:07 >To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >Brian is correct. > >But I was under the impression that people wanted to do the >callback stuff later. So I do envisage the current proposal >only for the citizen to authority emergency call. > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Tuesday, November 18, 2008 10:02 PM >> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> Subject: Re: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect >> >> I don't see a problem here. >> >> I think it's perfectly reasonable for an endpoint or proxy >outside an >> emergency services IP network to mark a call needing resource >> priority. The policing and behavior of proxy servers or UASs in the >> presence of such a marking is beyond the scope, but limiting the >> marking to emergency services networks is unwarranted. >> >> Further, differentiating between an incoming emergency call >and a call >> back seems wise. It may be the case that there is minimal if any >> resource priority for such calls in some networks, where in >others, it >> may be that there is some explicit priority of incoming vs outgoing. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, November 18, 2008 3:30 PM >> To: ECRIT >> Subject: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >> >> I have reviewed this document and I believe the scope has changed to >> what we agreed in previous ECRIT meetings. >> >> I believe that the document must not provide mechanisms for >> * PSAP callbacks >> * end hosts attaching a marking >> >> I believe that the document should only talk about how to use this >> marking inside an emergency services network. >> Other mechanisms are overlapping with other techniques and raise >> security issues. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Tue Nov 18 14:16:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1560628C28F; Tue, 18 Nov 2008 14:16:37 -0800 (PST) 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 8112B28C296 for ; Tue, 18 Nov 2008 14:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FLGrx70azNIi for ; Tue, 18 Nov 2008 14:16:34 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D62F23A68A0 for ; Tue, 18 Nov 2008 14:16:16 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAIMGDbT026108; Tue, 18 Nov 2008 16:16:13 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 16:16:13 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 23:16:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 23:16:10 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180024D97CB@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQABBivcAAD+sGIA== References: <07c801c949c9$490e7c30$db2b7490$@net> From: "DRAGE, Keith \(Keith\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:16:11.0218 (UTC) FILETIME=[433F4B20:01C949CB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Incorrect. You have a way of marking that you want an emergency call to be given particular priority. You have a way of marking that you want an emergency call to be sent to a PSAP. etc. What you are hinting at is that you believe emergency calls behave entirely according to a single indicator, which defines a profile of characteristics that is followed by entity in the path from sender to destination. That in my view is a declaritive service definition in my understanding of http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identific ation-03.txt and therefore entirely the wrong way to go. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, November 18, 2008 10:10 PM > To: ext Brian Rosen; ECRIT > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > > > >I don't see a problem here. > > > >I think it's perfectly reasonable for an endpoint or proxy > outside an > >emergency services IP network to mark a call needing > resource priority. > >The policing and behavior of proxy servers or UASs in the > presence of > >such a marking is beyond the scope, but limiting the marking to > >emergency services networks is unwarranted. > > The problem with this approach is that you have TWO (2) > different ways to mark an emergency call == NOT GOOD > > > > > > > >Further, differentiating between an incoming emergency call > and a call > >back seems wise. > > BUT: We have an alternative way to mark a call from a PSAP > towards the UA. > > > > >It may be the case that there is > >minimal if any resource priority for such calls in some > networks, where > >in others, it may be that there is some explicit priority of > incoming > >vs outgoing. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf > >Of Tschofenig, Hannes (NSN - FI/Espoo) > >Sent: Tuesday, November 18, 2008 3:30 PM > >To: ECRIT > >Subject: [Ecrit] > >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > > >I have reviewed this document and I believe the scope has changed to > >what we agreed in previous ECRIT meetings. > > > >I believe that the document must not provide mechanisms for > >* PSAP callbacks > >* end hosts attaching a marking > > > >I believe that the document should only talk about how to use this > >marking inside an emergency services network. > >Other mechanisms are overlapping with other techniques and raise > >security issues. > > > >Ciao > >Hannes > > > > > >_______________________________________________ > >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 ecrit-bounces@ietf.org Tue Nov 18 14:17:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D420F28C290; Tue, 18 Nov 2008 14:17:59 -0800 (PST) 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 ED52E28C28F for ; Tue, 18 Nov 2008 14:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 adw20zGWdw1i for ; Tue, 18 Nov 2008 14:17:58 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0E35F28C284 for ; Tue, 18 Nov 2008 14:17:58 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2YtH-000322-MH; Tue, 18 Nov 2008 16:17:49 -0600 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <07c801c949c9$490e7c30$db2b7490$@net> <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> Date: Tue, 18 Nov 2008 17:14:47 -0500 Message-ID: <07db01c949cb$140c9f10$3c25dd30$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQAABAgeAAAD61EA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If indeed a ecrit us chartered to do call backs, and this draft goes forward, I would have no problem in having this draft define the namespace (and thus a registry for values in that namespace), and then having the call back work add a new value in the registry, thus removing the call back value from this document. Brian -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Tuesday, November 18, 2008 5:07 PM To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect Brian is correct. But I was under the impression that people wanted to do the callback stuff later. So I do envisage the current proposal only for the citizen to authority emergency call. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Tuesday, November 18, 2008 10:02 PM > To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > > I don't see a problem here. > > I think it's perfectly reasonable for an endpoint or proxy > outside an emergency services IP network to mark a call > needing resource priority. The policing and behavior of > proxy servers or UASs in the presence of such a marking is > beyond the scope, but limiting the marking to emergency > services networks is unwarranted. > > Further, differentiating between an incoming emergency call > and a call back seems wise. It may be the case that there is > minimal if any resource priority for such calls in some > networks, where in others, it may be that there is some > explicit priority of incoming vs outgoing. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, November 18, 2008 3:30 PM > To: ECRIT > Subject: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > I have reviewed this document and I believe the scope has > changed to what we agreed in previous ECRIT meetings. > > I believe that the document must not provide mechanisms for > * PSAP callbacks > * end hosts attaching a marking > > I believe that the document should only talk about how to use > this marking inside an emergency services network. > Other mechanisms are overlapping with other techniques and > raise security issues. > > Ciao > Hannes > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Tue Nov 18 14:21:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E2628C27F; Tue, 18 Nov 2008 14:21:10 -0800 (PST) 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 55E3628C27F for ; Tue, 18 Nov 2008 14:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 eTjBT+9WGTZy for ; Tue, 18 Nov 2008 14:21:05 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 6E81E3A68A0 for ; Tue, 18 Nov 2008 14:21:05 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2YwK-0004m5-Mi; Tue, 18 Nov 2008 16:20:56 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <07c801c949c9$490e7c30$db2b7490$@net> In-Reply-To: Date: Tue, 18 Nov 2008 17:17:56 -0500 Message-ID: <07e201c949cb$83d828a0$8b8879e0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQABBivcAAD82u8A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The service URN is a ROUTING marking The RPH is a (SIP) RESOURCE marking They do different things. It may even make sense to have one marking without the other in some circumstances, although the generic 1-1-2 type emergency call would likely have both. Brian -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, November 18, 2008 5:10 PM To: ext Brian Rosen; ECRIT Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >I don't see a problem here. > >I think it's perfectly reasonable for an endpoint or proxy >outside an emergency services IP network to mark a call >needing resource priority. The policing and behavior of proxy >servers or UASs in the presence of such a marking is beyond >the scope, but limiting the marking to emergency services >networks is unwarranted. The problem with this approach is that you have TWO (2) different ways to mark an emergency call == NOT GOOD > >Further, differentiating between an incoming emergency call >and a call back seems wise. BUT: We have an alternative way to mark a call from a PSAP towards the UA. >It may be the case that there is >minimal if any resource priority for such calls in some >networks, where in others, it may be that there is some >explicit priority of incoming vs outgoing. > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >Sent: Tuesday, November 18, 2008 3:30 PM >To: ECRIT >Subject: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > >I have reviewed this document and I believe the scope has >changed to what we agreed in previous ECRIT meetings. > >I believe that the document must not provide mechanisms for >* PSAP callbacks >* end hosts attaching a marking > >I believe that the document should only talk about how to use >this marking inside an emergency services network. >Other mechanisms are overlapping with other techniques and >raise security issues. > >Ciao >Hannes > > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Nov 18 14:37:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED633A68F5; Tue, 18 Nov 2008 14:37:43 -0800 (PST) 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 538DC3A67AB for ; Tue, 18 Nov 2008 14:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 peiM5CtPf9V5 for ; Tue, 18 Nov 2008 14:37:37 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 84CCE3A68F5 for ; Tue, 18 Nov 2008 14:37:37 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMbW8a017214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 23:37:32 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMbPT9011398; Tue, 18 Nov 2008 23:37:32 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:37:31 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:37:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:37:29 +0200 Message-ID: In-Reply-To: <07e201c949cb$83d828a0$8b8879e0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQABBivcAAD82u8AAvpLfQ References: <07c801c949c9$490e7c30$db2b7490$@net> <07e201c949cb$83d828a0$8b8879e0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:37:30.0996 (UTC) FILETIME=[3E0DEB40:01C949CE] Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org They are different only on a philosophical sense. A SIP UA should not have to implement two mechanisms for such a philosophical difference. The RPH marking can also be used to influence routing decisions (like anything can be used todo that) >The service URN is a ROUTING marking >The RPH is a (SIP) RESOURCE marking > >They do different things. It may even make sense to have one >marking without the other in some circumstances, although the >generic 1-1-2 type emergency call would likely have both. > >Brian > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo) >[mailto:hannes.tschofenig@nsn.com] > >Sent: Tuesday, November 18, 2008 5:10 PM >To: ext Brian Rosen; ECRIT >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > >>I don't see a problem here. >> >>I think it's perfectly reasonable for an endpoint or proxy outside an >>emergency services IP network to mark a call needing resource >priority. >>The policing and behavior of proxy servers or UASs in the presence of >>such a marking is beyond the scope, but limiting the marking to >>emergency services networks is unwarranted. > >The problem with this approach is that you have TWO (2) >different ways to mark an emergency call == NOT GOOD > > > > >> >>Further, differentiating between an incoming emergency call >and a call >>back seems wise. > >BUT: We have an alternative way to mark a call from a PSAP >towards the UA. > > > >>It may be the case that there is >>minimal if any resource priority for such calls in some >networks, where >>in others, it may be that there is some explicit priority of incoming >>vs outgoing. >> >>Brian >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Tschofenig, Hannes (NSN - FI/Espoo) >>Sent: Tuesday, November 18, 2008 3:30 PM >>To: ECRIT >>Subject: [Ecrit] >>draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >> >>I have reviewed this document and I believe the scope has changed to >>what we agreed in previous ECRIT meetings. >> >>I believe that the document must not provide mechanisms for >>* PSAP callbacks >>* end hosts attaching a marking >> >>I believe that the document should only talk about how to use this >>marking inside an emergency services network. >>Other mechanisms are overlapping with other techniques and raise >>security issues. >> >>Ciao >>Hannes >> >> >>_______________________________________________ >>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 ecrit-bounces@ietf.org Tue Nov 18 14:42:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEBB3A68EF; Tue, 18 Nov 2008 14:42:27 -0800 (PST) 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 627F428C146 for ; Tue, 18 Nov 2008 14:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.418 X-Spam-Level: X-Spam-Status: No, score=-5.418 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zPCQbH1RzBN for ; Tue, 18 Nov 2008 14:42:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 32D7928C133 for ; Tue, 18 Nov 2008 14:42:26 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMgJAn008437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 23:42:19 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAIMgH5c014474; Tue, 18 Nov 2008 23:42:19 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:39:19 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 23:39:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:39:17 +0200 Message-ID: In-Reply-To: <07db01c949cb$140c9f10$3c25dd30$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect Thread-Index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQAABAgeAAAD61EAAP4lcA References: <07c801c949c9$490e7c30$db2b7490$@net> <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> <07db01c949cb$140c9f10$3c25dd30$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Rosen" , "DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 18 Nov 2008 22:39:18.0852 (UTC) FILETIME=[7E577040:01C949CE] Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What do you think about the approach taken in http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt with regard to a call back procedure? >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 19 November, 2008 00:15 >To: 'DRAGE, Keith (Keith)'; Tschofenig, Hannes (NSN - >FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >If indeed a ecrit us chartered to do call backs, and this >draft goes forward, I would have no problem in having this >draft define the namespace (and thus a registry for values in >that namespace), and then having the call back work add a new >value in the registry, thus removing the call back value from >this document. > >Brian > >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: Tuesday, November 18, 2008 5:07 PM >To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >Brian is correct. > >But I was under the impression that people wanted to do the >callback stuff later. So I do envisage the current proposal >only for the citizen to authority emergency call. > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Tuesday, November 18, 2008 10:02 PM >> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> Subject: Re: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect >> >> I don't see a problem here. >> >> I think it's perfectly reasonable for an endpoint or proxy >outside an >> emergency services IP network to mark a call needing resource >> priority. The policing and behavior of proxy servers or UASs in the >> presence of such a marking is beyond the scope, but limiting the >> marking to emergency services networks is unwarranted. >> >> Further, differentiating between an incoming emergency call >and a call >> back seems wise. It may be the case that there is minimal if any >> resource priority for such calls in some networks, where in >others, it >> may be that there is some explicit priority of incoming vs outgoing. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, November 18, 2008 3:30 PM >> To: ECRIT >> Subject: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >> >> I have reviewed this document and I believe the scope has changed to >> what we agreed in previous ECRIT meetings. >> >> I believe that the document must not provide mechanisms for >> * PSAP callbacks >> * end hosts attaching a marking >> >> I believe that the document should only talk about how to use this >> marking inside an emergency services network. >> Other mechanisms are overlapping with other techniques and raise >> security issues. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Tue Nov 18 14:46:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CDB3A6B41; Tue, 18 Nov 2008 14:46:37 -0800 (PST) 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 878603A6B41 for ; Tue, 18 Nov 2008 14:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pkhRtBokBoM for ; Tue, 18 Nov 2008 14:46:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A17473A6B44 for ; Tue, 18 Nov 2008 14:46:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220227200"; d="scan'208";a="28308726" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Nov 2008 22:46:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAIMkQdw025226; Tue, 18 Nov 2008 17:46:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAIMkQ1a023452; Tue, 18 Nov 2008 22:46:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 17:46:26 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.211]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 17:46:25 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2008 16:46:25 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 18 Nov 2008 22:46:25.0855 (UTC) FILETIME=[7CDAECF0:01C949CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=816; t=1227048386; x=1227912386; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace=20--=0A=20=20Scope=20incorrect |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22EC RIT=22=20; bh=9iSd52G1RbQaXyypN9RSSQHT5NetIQeC2HrII/HoNNg=; b=YhB/BQ47yz5ol3o3yvn/LS7f39U2RTDtl+7lBoJBamXfKJ3peWHTuB8e5y qw5yL0x4L+q9hRgIOZv3sUrlA/X2whaKDRcMVLocTs88Bxr34FWhodx61k+1 Z255YFZrjW; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:29 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >I have reviewed this document and I believe the scope has changed to >what we agreed in previous ECRIT meetings. > >I believe that the document must not provide mechanisms for >* PSAP callbacks >* end hosts attaching a marking > >I believe that the document should only talk about how to use this >marking inside an emergency services network. Hannes - is all this said with your WG chair hat on, or as an individual contributor? >Other mechanisms are overlapping with other techniques and raise >security issues. what other overlapping mechanisms exist within SIP? >Ciao >Hannes > > >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Nov 18 14:51:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57D83A6B34; Tue, 18 Nov 2008 14:51:49 -0800 (PST) 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 2D3DF3A6B34 for ; Tue, 18 Nov 2008 14:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIUB6Hy8h3Vv for ; Tue, 18 Nov 2008 14:51:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2D0D63A6B29 for ; Tue, 18 Nov 2008 14:51:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220227200"; d="scan'208";a="28309219" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Nov 2008 22:51:47 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAIMpliK008165; Tue, 18 Nov 2008 17:51:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAIMplaq024778; Tue, 18 Nov 2008 22:51:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 17:51:46 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.211]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 17:51:46 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2008 16:51:45 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ECRIT" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 18 Nov 2008 22:51:46.0636 (UTC) FILETIME=[3C0E38C0:01C949D0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1212; t=1227048707; x=1227912707; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace=20--=0A=20=20Usefulness? |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22EC RIT=22=20; bh=GJGOHKWCtE6ad+XUa0H5aUeCa7w69PCu+LqzMhm3DJY=; b=M3NXQnAXwhpzKKsJ9DT56wknElMo2X3yWfqR1CjYu8QLWw6CxfFo6chOIw CdC48Srw/X2i2u6/+dzv8MNXkm9g3S0a8HYIpd04R9XDm6hoQwgqwiW9CvAI cBWN0jNrE4; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:29 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >I have read the document and I still have a hard time understanding the >value of the work. Is this comment said with your WG chair hat on or as an individual contributor? >There is no need to mark emergency calls beyond the marking we have with >the Service URN document. So, do you want SIP entities to use another resource mechanism ONLY WHEN AN EMERGENCY CALL IS MADE, or do you want SIP to only use one mechanism, which is defined by RFC 4412, and updated with this ID's namespace? > >Calls between PSAPs and from a PSAP to a first responder the Service >URN is not used. You could, if you think it is useful, use the existing >Resource Priority header there. Hannes - the existing Resource Priority header spec (RFC 4412) does *not* define a namespace for emergency services. This ID defines *the* new namespace for use within emergency calling. It doesn't exist anywhere else. >So, why do we need this? see the paragraph above for the why. >Ciao >Hannes >_______________________________________________ >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 ecrit-bounces@ietf.org Tue Nov 18 14:53:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1A828C226; Tue, 18 Nov 2008 14:53:48 -0800 (PST) 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 EFA6928C226 for ; Tue, 18 Nov 2008 14:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 tNgrDDQJkKOB for ; Tue, 18 Nov 2008 14:53:46 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BC81628C1F8 for ; Tue, 18 Nov 2008 14:53:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2ZRw-0005lr-MP; Tue, 18 Nov 2008 16:53:36 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ECRIT'" References: <07c801c949c9$490e7c30$db2b7490$@net> <07e201c949cb$83d828a0$8b8879e0$@net> In-Reply-To: Date: Tue, 18 Nov 2008 17:53:37 -0500 Message-ID: <07fe01c949d0$7ffad520$7ff07f60$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQABBivcAAD82u8AAvpLfQAE4vyzA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Could I ask if there are others on the list who have the same objections that Hannes has? We have gone around this loop several times. Brian -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, November 18, 2008 5:37 PM To: ext Brian Rosen; ECRIT Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect They are different only on a philosophical sense. A SIP UA should not have to implement two mechanisms for such a philosophical difference. The RPH marking can also be used to influence routing decisions (like anything can be used todo that) >The service URN is a ROUTING marking >The RPH is a (SIP) RESOURCE marking > >They do different things. It may even make sense to have one >marking without the other in some circumstances, although the >generic 1-1-2 type emergency call would likely have both. > >Brian > >-----Original Message----- >From: Tschofenig, Hannes (NSN - FI/Espoo) >[mailto:hannes.tschofenig@nsn.com] > >Sent: Tuesday, November 18, 2008 5:10 PM >To: ext Brian Rosen; ECRIT >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > >>I don't see a problem here. >> >>I think it's perfectly reasonable for an endpoint or proxy outside an >>emergency services IP network to mark a call needing resource >priority. >>The policing and behavior of proxy servers or UASs in the presence of >>such a marking is beyond the scope, but limiting the marking to >>emergency services networks is unwarranted. > >The problem with this approach is that you have TWO (2) >different ways to mark an emergency call == NOT GOOD > > > > >> >>Further, differentiating between an incoming emergency call >and a call >>back seems wise. > >BUT: We have an alternative way to mark a call from a PSAP >towards the UA. > > > >>It may be the case that there is >>minimal if any resource priority for such calls in some >networks, where >>in others, it may be that there is some explicit priority of incoming >>vs outgoing. >> >>Brian >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >>Of Tschofenig, Hannes (NSN - FI/Espoo) >>Sent: Tuesday, November 18, 2008 3:30 PM >>To: ECRIT >>Subject: [Ecrit] >>draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >> >>I have reviewed this document and I believe the scope has changed to >>what we agreed in previous ECRIT meetings. >> >>I believe that the document must not provide mechanisms for >>* PSAP callbacks >>* end hosts attaching a marking >> >>I believe that the document should only talk about how to use this >>marking inside an emergency services network. >>Other mechanisms are overlapping with other techniques and raise >>security issues. >> >>Ciao >>Hannes >> >> >>_______________________________________________ >>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 ecrit-bounces@ietf.org Tue Nov 18 15:03:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D308C3A6869; Tue, 18 Nov 2008 15:03:45 -0800 (PST) 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 183683A6869; Tue, 18 Nov 2008 15:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+AAktPuEbcu; Tue, 18 Nov 2008 15:03:44 -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 BEE583A6819; Tue, 18 Nov 2008 15:03:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220227200"; d="scan'208";a="28276340" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Nov 2008 23:03:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAIN3gqE032073; Tue, 18 Nov 2008 18:03:42 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAIN3gsR027817; Tue, 18 Nov 2008 23:03:42 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 18:03:42 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.211]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 18:03:42 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Nov 2008 17:03:41 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext DRAGE, Keith (Keith)" , "Janet P Gunn" From: "James M. Polk" In-Reply-To: References: <5D1A7985295922448D5550C94DE29180024D97B8@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180024D97BB@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 18 Nov 2008 23:03:42.0296 (UTC) FILETIME=[E69F4580:01C949D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5257; t=1227049422; x=1227913422; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=0A=20=20draft-ietf-ecrit-local- emergency-rph-namespace--=09Usefulness? |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22ex t=20DRAGE,=20Keith=20(Keith)=22=20 ,=0A=20=20=20=20=20=20=20=20=22Janet=20P=20Gunn=22=20; bh=r1JD08chVhxLflBrjw0BBQDE8gFrGY5/bi38SCE4Ve8=; b=r0xv1CqLWy8QMftBk4Se0PqdR9IEyz9Atn2aszUvBofDLhFRUXqmlh6RHd TOMNGcd+ZzhUK4fl8IXTptvXQ/NfGJb0J+eQIkFyNbKvZcbOmNd76klDWeG1 STVbINo+5H; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes You really are comparing apples to oranges (or boats), *and* you are adding mechanisms that are needed to be coded for, instead of reducing the number of mechanisms that need to be accounted for. James At 04:09 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >So, you believe that folks are going to use this to mark calls from >PSAPs to first responders? > From a PSAP to a PSAP (in case of call forwarding) one could still use >the Service URN? > > > > >-----Original Message----- > >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 18 November, 2008 23:42 > >To: Tschofenig, Hannes (NSN - FI/Espoo); Janet P Gunn > >Cc: ECRIT; ecrit-bounces@ietf.org > >Subject: RE: [Ecrit] > >draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > > > >The Resource-Priority header was defined to have multiple namespaces. > >You define your prioritisation requirements by defining the > >namespace, i.e. it is a name of your template. > > > >So yes, it makes absolute sense to use the Resource-Priority > >header for exactly the functions for which it was defined. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: Tschofenig, Hannes (NSN - FI/Espoo) > >> [mailto:hannes.tschofenig@nsn.com] > >> Sent: Tuesday, November 18, 2008 9:31 PM > >> To: DRAGE, Keith (Keith); Janet P Gunn > >> Cc: ECRIT; ecrit-bounces@ietf.org > >> Subject: RE: [Ecrit] > >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > >> > >> If it has a totally different meaning does it make sense to > >put it in > >> the RPH namespace? > >> > >> > >> > >> ________________________________ > >> > >> From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> > >> Sent: 18 November, 2008 23:30 > >> To: Janet P Gunn; Tschofenig, Hannes (NSN - FI/Espoo) > >> Cc: ECRIT; ecrit-bounces@ietf.org > >> Subject: RE: [Ecrit] > >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > >> > >> > >> There is only one Resource-Priority header field, that > >defined in RFC > >> 4412. > >> > >> Different handling is determined by the namespace > >within the header. > >> > >> The requirements for handling emergency calls in terms > >of priority > >> are different from any other existing namespace, so it needs a new > >> namespace. > >> > >> That is a "priority" namespace rather than a "preemption" one. > >> > >> Keith > >> > >> > >> ________________________________ > >> > >> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn > >> Sent: Tuesday, November 18, 2008 9:00 PM > >> To: Tschofenig, Hannes (NSN - FI/Espoo) > >> Cc: ECRIT; ecrit-bounces@ietf.org > >> Subject: Re: [Ecrit] > >> draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness? > >> > >> > >> > >> > >> > >> Which "existing Resource Priority header" are you > >> proposing to use? > >> > >> The dsn, and drsn namespaces are not intended > >for use outside the US > >> DoD networks, and only provide (preemption based) priority > >over calls > >> with the same namespace, but a different value. > >> > >> The q735 namespace, while not restricted to the > >US DoD is similarly > >> based on a "closed group preemption", which is not > >appropriate to this > >> situation. > >> > >> The ets and wps namespaces are intended for the > >"Next Generation" > >> versions of Government Emergency Telecommunications Service > >> (GETS) and Wireless Priority Service (WPS). Both of these are > >> intended to support National Security and Emergency > >Preparedness, and > >> explicitly exclude "911-type" calls. > >> > >> As I noted earlier, I have some real concerns > >about some of the text > >> in this ID. But I support the concept of an RPH namespace for > >> ecrit-related calls/sessions. > >> > >> Janet > >> > >> ecrit-bounces@ietf.org wrote on 11/18/2008 03:29:57 PM: > >> > >> > I have read the document and I still have a hard time > >> understanding the > >> > value of the work. > >> > > >> > There is no need to mark emergency calls > >beyond the marking we > >> have with > >> > the Service URN document > >> > Calls between PSAPs and from a PSAP to a > >first responder the > >> Service > >> > URN is not used. You could, if you think it > >is useful, use the > >> existing > >> > Resource Priority header there. > >> > > >> > So, why do we need this? > >> > > >> > Ciao > >> > Hannes > >> > _______________________________________________ > >> > 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 ecrit-bounces@ietf.org Tue Nov 18 15:03:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCA728C24E; Tue, 18 Nov 2008 15:03:51 -0800 (PST) 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 ADE8E28C24E for ; Tue, 18 Nov 2008 15:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 EkGD3mWCS1Li for ; Tue, 18 Nov 2008 15:03:48 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B846A28C21A for ; Tue, 18 Nov 2008 15:03:48 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2Zbe-0006F0-KC; Tue, 18 Nov 2008 17:03:38 -0600 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'DRAGE, Keith \(Keith\)'" , "'ECRIT'" References: <07c801c949c9$490e7c30$db2b7490$@net> <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> <07db01c949cb$140c9f10$3c25dd30$@net> In-Reply-To: Date: Tue, 18 Nov 2008 18:03:43 -0500 Message-ID: <080501c949d1$e952f3d0$bbf8db70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclJeVffUpTlGiwWSa2SoR0SQUkfZQAT3GsQAABAgeAAAD61EAAP4lcAAA4qMpA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The whole subject needs a requirements doc and a mechanism. I don't think this is going to be the right mechanism, but we'll see. Charter Then Requirements Then mechanism Right, Mr. Co-Chair? Brian -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, November 18, 2008 5:39 PM To: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect What do you think about the approach taken in http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt with regard to a call back procedure? >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: 19 November, 2008 00:15 >To: 'DRAGE, Keith (Keith)'; Tschofenig, Hannes (NSN - >FI/Espoo); 'ECRIT' >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >If indeed a ecrit us chartered to do call backs, and this >draft goes forward, I would have no problem in having this >draft define the namespace (and thus a registry for values in >that namespace), and then having the call back work add a new >value in the registry, thus removing the call back value from >this document. > >Brian > >-----Original Message----- >From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >Sent: Tuesday, November 18, 2008 5:07 PM >To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT >Subject: RE: [Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >Brian is correct. > >But I was under the impression that people wanted to do the >callback stuff later. So I do envisage the current proposal >only for the citizen to authority emergency call. > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Brian Rosen >> Sent: Tuesday, November 18, 2008 10:02 PM >> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' >> Subject: Re: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect >> >> I don't see a problem here. >> >> I think it's perfectly reasonable for an endpoint or proxy >outside an >> emergency services IP network to mark a call needing resource >> priority. The policing and behavior of proxy servers or UASs in the >> presence of such a marking is beyond the scope, but limiting the >> marking to emergency services networks is unwarranted. >> >> Further, differentiating between an incoming emergency call >and a call >> back seems wise. It may be the case that there is minimal if any >> resource priority for such calls in some networks, where in >others, it >> may be that there is some explicit priority of incoming vs outgoing. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Tuesday, November 18, 2008 3:30 PM >> To: ECRIT >> Subject: [Ecrit] >> draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect >> >> I have reviewed this document and I believe the scope has changed to >> what we agreed in previous ECRIT meetings. >> >> I believe that the document must not provide mechanisms for >> * PSAP callbacks >> * end hosts attaching a marking >> >> I believe that the document should only talk about how to use this >> marking inside an emergency services network. >> Other mechanisms are overlapping with other techniques and raise >> security issues. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Tue Nov 18 15:21:21 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB2F3A6B39; Tue, 18 Nov 2008 15:21:21 -0800 (PST) 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 4DF0A3A6B34; Tue, 18 Nov 2008 15:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 9QCjEgtaFRhd; Tue, 18 Nov 2008 15:21:17 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 355FD3A6945; Tue, 18 Nov 2008 15:21:17 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-85.messagelabs.com!1227050474!43670086!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 12467 invoked from network); 18 Nov 2008 23:21:15 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 18 Nov 2008 23:21:15 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAINLBHn008763; Tue, 18 Nov 2008 18:21:14 -0500 In-Reply-To: To: "'ECRIT'" , ecrit-bounces@ietf.org, "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 18 Nov 2008 18:21:07 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/18/2008 06:23:45 PM, Serialize complete at 11/18/2008 06:23:45 PM Subject: [Ecrit] earlier comments Re: draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============1166550740==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1166550740== Content-Type: multipart/alternative; boundary="=_alternative 0080475885257505_=" This is a multipart message in MIME format. --=_alternative 0080475885257505_= Content-Type: text/plain; charset="US-ASCII" Since we are now actively talking about this document, I am resending my earlier comments. I expect they were missed because everyone was in the middle of meeting the ID dead line. Janet ecrit-bounces@ietf.org wrote on 10/27/2008 11:45:43 PM: > > I apologize for not tracking this as closely as I meant to, as these > comments apply to earlier versions as well. > > > This sentence at the end of sec 1 doesn't quite work. > "This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just > of those from citizens to PSAPs." (no clear antecedent for "those") > > Perhaps > "This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not > just for calls or sessions > from citizens to PSAPs." > > Section 2 says > "This document updates the behaviors of the SIP Resource Priority > header, defined in [RFC4412], during the treatment options > surrounding this new "esnet" namespace only. The usage of the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." > > I don't see this as an "update of the behavior of 4412". Neither > the ets namespace not the wps > namespace have a "normal" or "routine" call level. Every use of the > wps and ets namespaces will > have priority over calls without RPH. > > You say "This > namespace, therefore, MAY be overwritten or deleted, contrary to the > rules of RFC 4412 [RFC4412]." > > It is not clear to me why this is "contrary to the rules of 4412". > It is certainly anticipated > that other RPH will be overwritten or deleted, when the UAS > understands the namespace. > > 4412 says "Existing implementations of RFC 3261 that do not participate in the > resource priority mechanism follow the normal rules of RFC 3261, > Section 8.2.2: "If a UAS does not understand a header field in a > request (that is, the header field is not defined in this > specification or in any supported extension), the server MUST ignore > that header field and continue processing the message". " > > But I do not see anywhere that is says that a UAS that DOES > understand the namespace is > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > that "the UAC > MAY attempt a subsequent request with the same or different resource > value." This certainly implies the ability to overwrite or > delete an RPH namespace. > > (See also, for instance the PTSC SAC document on the use of the ets > and wps namespaces) > > Immediately following these statements, you give 3 options- > "These proxies in the service provider > MAY either > > o accept the existing RPH value with "esnet" in it, if one is > present, and grant relative preferential treatment to the request > when forwarding it to the ESINet. > > o replace any existing RPH value, if one is present, and insert an > "esnet" namespace and give relative preferential treatment to the > request when forwarding it to the ESINet. > > o insert an "esnet" namespace in a new RPH and give relative > preferential treatment to the request when forwarding the SIP > request towards the ESINet." > > Why do you exclude the possibility of adding the esnet RPH value > without "replacing" an existing RPH value? > > Finally, there is another point that needs to be made clear. At > least one person has contacted me expressing concern that this ID > implied that the esnet namespace would have priority over other > namespaces (in particular wps and ets). I assured him that this was > not the case, that there was nothing prevent the expected behavior - > that the ets and wps namespaces would be prioritized ahead of esnet > in GETS Service Provider networks. > > However, since the question has already arisen, it would be a good > idea to clarify this, perhaps in section 3, where you discuss the > other namespaces. In particular, it needs to be made clear in > section 3.2 that, even if "the local jurisdiction preferred to > preempt normal calls in lieu of > completing emergency calls. ", esnet calls will NOT preempt wps > or ets calls. > > By the way, I think you mean "the local jurisdiction preferred to > preempt normal calls in order to complete emergency calls. " - not > "in lieu of". Or perhaps "the local jurisdiction preferred to > preempt normal calls in lieu of dropping emergency calls. " > > In fact, it is not clear to me that 4412 permits a call with an RPH > (e.g., esnet) to preempt a "normal" call (with no RPH namespace). > Section 4.7.2.1 of 4412 says > "4.7.2.1. User Agent Servers and Preemption Algorithm > > A UAS compliant with this specification MUST terminate a session > established with a valid namespace and lower-priority value in favor > of a new session set up with a valid namespace and higher relative > priority value, unless local policy has some form of call-waiting > capability enabled. " > > It doesn't say anything about preempting a call with no RPH > > Thanks > > Janet > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the > use of e-mail for such purpose. > > > "James M. Polk" > Sent by: ecrit-bounces@ietf.org > 10/27/2008 08:32 PM > > To > > "'ECRIT'" > > cc > > Subject > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > ECRIT WG > > Here is a update to a ID I think is pretty near done, given that this > is merely an IANA registration ID of an existing mechanism. > > Comments are wanted > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Emergency Context Resolution with > >Internet Technologies Working Group of the IETF. > > > > > > Title : IANA Registering a SIP Resource Priority > > Header Namespace for Local Emergency Communications > > Author(s) : J. Polk > > Filename : > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > Pages : 9 > > Date : 2008-10-27 > > > >This document creates and IANA registers the new Session Initiation > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > >local emergency usage to a public safety answering point (PSAP), > >between PSAPs, and between a PSAP and first responders and their > >organizations. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > emergency-rph-namespace-00.txt > > > > > > > > emergency-rph-namespace-00.txt> > > _______________________________________________ > 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 --=_alternative 0080475885257505_= Content-Type: text/html; charset="US-ASCII"


Since we are now actively talking about this document, I am resending my earlier comments.  I expect they were missed because everyone was in the middle of meeting the ID dead line.

Janet

ecrit-bounces@ietf.org wrote on 10/27/2008 11:45:43 PM:

>
> I apologize for not tracking this as closely as I meant to, as these
> comments apply to  earlier versions as well.
>
>
> This sentence at the end of sec 1 doesn't quite work.
> "This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not just
>    of those from citizens to PSAPs." (no clear antecedent for "those")
>
> Perhaps
> "This document IANA registers the "esnet"
>    RPH namespace for use within emergency services networks, not
> just for calls or sessions
>     from citizens to PSAPs."
>
> Section 2 says
>  "This document updates the behaviors of the SIP Resource Priority
>    header, defined in [RFC4412], during the treatment options
>    surrounding this new "esnet" namespace only. The usage of the
>    "esnet" namespace does not have a normal, or routine call level.  
>    Every use of this namespace will be in times of an emergency, where
>    at least one end of the signaling is with a local emergency
>    organization."
>
> I don't see this as an "update of the behavior of 4412".  Neither
> the ets namespace not the wps
> namespace have a "normal" or "routine" call level.  Every use of the
> wps and ets namespaces will
> have priority over calls without RPH.
>
> You say "This
>    namespace, therefore, MAY be overwritten or deleted, contrary to the
>    rules of RFC 4412 [RFC4412]."
>
> It is not clear to me why this is "contrary to the rules of 4412".  
> It is certainly anticipated
> that other RPH will be overwritten or deleted, when the UAS
> understands the namespace.
>
> 4412 says "Existing implementations of RFC 3261 that do not participate in the
>    resource priority mechanism follow the normal rules of RFC 3261,
>    Section 8.2.2: "If a UAS does not understand a header field in a
>    request (that is, the header field is not defined in this
>    specification or in any supported extension), the server MUST ignore
>    that header field and continue processing the message". "
>
> But I do not see anywhere that is says that a UAS that DOES
> understand the namespace is
> forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says
> that "the UAC
>    MAY attempt a subsequent request with the same or different resource
>    value."  This certainly implies the ability to overwrite or
> delete an RPH namespace.  
>
> (See also, for instance the PTSC SAC document on the use of the ets
> and wps namespaces)
>
> Immediately following these statements, you give 3 options-
> "These proxies in the service provider
>    MAY either
>
>    o  accept the existing RPH value with "esnet" in it, if one is
>       present, and grant relative preferential treatment to the request
>       when forwarding it to the ESINet.
>
>    o  replace any existing RPH value, if one is present, and insert an
>       "esnet" namespace and give relative preferential treatment to the
>       request when forwarding it to the ESINet.
>
>    o  insert an "esnet" namespace in a new RPH and give relative
>       preferential treatment to the request when forwarding the SIP
>       request towards the ESINet."
>
> Why do you exclude the possibility of adding the esnet RPH value
> without "replacing" an existing RPH value?
>
> Finally, there is another point that  needs to be made clear.  At
> least one person has contacted me expressing concern that this ID
> implied that the esnet namespace would  have priority over other
> namespaces (in particular wps and ets).  I assured him that this was
> not the case, that there was nothing prevent the expected behavior -
> that the ets and wps namespaces would be prioritized ahead of esnet
> in GETS Service Provider networks.
>
> However, since the question has already arisen, it would be a good
> idea to clarify  this, perhaps in  section 3, where you discuss  the
> other namespaces.  In particular, it needs to be made clear in
> section 3.2  that, even if  "the   local jurisdiction preferred to
> preempt normal calls in lieu of
>    completing emergency calls. ", esnet calls will NOT preempt wps
> or ets calls.
>
> By the way, I think you mean "the   local jurisdiction preferred to
> preempt normal calls in order to complete emergency calls. "  - not
> "in lieu of".  Or perhaps "the   local jurisdiction preferred to
> preempt normal calls in lieu of  dropping emergency calls. "
>
> In fact, it is not clear to me that 4412 permits a call with an RPH
> (e.g., esnet)  to preempt a "normal" call (with no RPH namespace).  
> Section 4.7.2.1 of 4412 says
> "4.7.2.1.  User Agent Servers and Preemption Algorithm
>
>    A UAS compliant with this specification MUST terminate a session
>    established with a valid namespace and lower-priority value in favor
>    of a new session set up with a valid namespace and higher relative
>    priority value, unless local policy has some form of call-waiting
>    capability enabled. "
>
> It doesn't say anything about preempting a call with no RPH
>
> Thanks
>
> Janet
>
>
>
>
>
>
> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind
> CSC to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the
> use of e-mail for such purpose.
>

>
> "James M. Polk" <jmpolk@cisco.com>
> Sent by: ecrit-bounces@ietf.org
> 10/27/2008 08:32 PM
>
> To
>
> "'ECRIT'" <ecrit@ietf.org>
>
> cc
>
> Subject
>
> [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
>
>
>
>
> ECRIT WG
>
> Here is a update to a ID I think is pretty near done, given that this
> is merely an IANA registration ID of an existing mechanism.
>
> Comments are wanted
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Emergency Context Resolution with
> >Internet Technologies Working Group of the IETF.
> >
> >
> >         Title           : IANA Registering a SIP Resource Priority
> > Header Namespace for Local Emergency Communications
> >         Author(s)       : J. Polk
> >         Filename        :
> > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
> >         Pages           : 9
> >         Date            : 2008-10-27
> >
> >This document creates and IANA registers the new Session Initiation
> >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> >local emergency usage to a public safety answering point (PSAP),
> >between PSAPs, and between a PSAP and first responders and their
> >organizations.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt
> >
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt>
>
> _______________________________________________
> 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
 --=_alternative 0080475885257505_=-- --===============1166550740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1166550740==-- From ecrit-bounces@ietf.org Wed Nov 19 09:03:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80DE3A6B9D; Wed, 19 Nov 2008 09:03:33 -0800 (PST) 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 BAEDA3A6972 for ; Wed, 19 Nov 2008 09:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REaNVo86lUQk for ; Wed, 19 Nov 2008 09:03:31 -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 AEC253A6805 for ; Wed, 19 Nov 2008 09:03:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,632,1220227200"; d="scan'208";a="28358577" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2008 17:03:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAJH3UNe026963; Wed, 19 Nov 2008 12:03:30 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJH3UUG019632; Wed, 19 Nov 2008 17:03:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:03:30 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.218.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:03:29 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Nov 2008 11:03:28 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Brian Rosen" , "ECRIT" From: "James M. Polk" In-Reply-To: References: <07c801c949c9$490e7c30$db2b7490$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 19 Nov 2008 17:03:29.0826 (UTC) FILETIME=[BEFFD020:01C94A68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2198; t=1227114210; x=1227978210; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace=20--=0A=20=20Scope=09incorrect |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22ex t=20Brian=20Rosen=22=20,=20=22ECRIT=22=20 ; bh=AWPdFC/7xI4KlOOdntELYH1SWEYmZ1TBbBJJskwcseI=; b=l7qC0mRzYJN8YGrABSZVh0EfnREM7Ti4jF4nhRXLhjQELNDiCZZCw5PS66 uWXp5TOfEN8jwZYPvpebEVyRMoUa94DD12+dH6SUllbAaJ5H6WCbNSRHyvcb mDXnlD7nfT; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:10 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >I don't see a problem here. > > > >I think it's perfectly reasonable for an endpoint or proxy > >outside an emergency services IP network to mark a call > >needing resource priority. The policing and behavior of proxy > >servers or UASs in the presence of such a marking is beyond > >the scope, but limiting the marking to emergency services > >networks is unwarranted. > >The problem with this approach is that you have TWO (2) different ways >to mark an emergency call == NOT GOOD no no no.... you are suggesting using TWO mechanisms to accomplish resource priority ==> which is NOT GOOD. > > > > > > > >Further, differentiating between an incoming emergency call > >and a call back seems wise. > >BUT: We have an alternative way to mark a call from a PSAP towards the >UA. > > > > >It may be the case that there is > >minimal if any resource priority for such calls in some > >networks, where in others, it may be that there is some > >explicit priority of incoming vs outgoing. > > > >Brian > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >Sent: Tuesday, November 18, 2008 3:30 PM > >To: ECRIT > >Subject: [Ecrit] > >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > > >I have reviewed this document and I believe the scope has > >changed to what we agreed in previous ECRIT meetings. > > > >I believe that the document must not provide mechanisms for > >* PSAP callbacks > >* end hosts attaching a marking > > > >I believe that the document should only talk about how to use > >this marking inside an emergency services network. > >Other mechanisms are overlapping with other techniques and > >raise security issues. > > > >Ciao > >Hannes > > > > > >_______________________________________________ > >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 ecrit-bounces@ietf.org Wed Nov 19 09:07:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECBB3A6805; Wed, 19 Nov 2008 09:07:17 -0800 (PST) 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 C3C2E3A6805 for ; Wed, 19 Nov 2008 09:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R40M7+TZB0iG for ; Wed, 19 Nov 2008 09:07:14 -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 8220B3A67F9 for ; Wed, 19 Nov 2008 09:07:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,632,1220227200"; d="scan'208";a="28358969" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2008 17:07:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAJH7DVn015910; Wed, 19 Nov 2008 12:07:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJH7Dup020614; Wed, 19 Nov 2008 17:07:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:07:12 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.218.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:07:12 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Nov 2008 11:07:10 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext DRAGE, Keith (Keith)" , "Brian Rosen" , "ECRIT" From: "James M. Polk" In-Reply-To: References: <07c801c949c9$490e7c30$db2b7490$@net> <5D1A7985295922448D5550C94DE29180024D97BF@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 19 Nov 2008 17:07:12.0498 (UTC) FILETIME=[43B8DD20:01C94A69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3701; t=1227114433; x=1227978433; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace=0A=20=20--Scope=09incorrect |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 ,=0A=20=20=20=20=20=20=20=20=22ex t=20DRAGE,=20Keith=20(Keith)=22=20 ,=0A=20=20=20=20=20=20=20=20=22Brian=20Rosen=22=20,=20=22ECRIT=22=20; bh=RycDU3v7f3SmSuC84cBZA3sNG2GxlEuWvXl8p3+YqYw=; b=nIdd567KuZfNZQlxi/FtL//F7734U3p2EKK+ZnaoqoEz/U//z5EeiBm8Eu 7cnG/TrQ76nJRAvAFwOryHUTI5FpAIWGgR7VzW7ZdGAXUggcMYv9f6OVJNIl euIiL46iS/; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:14 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >There is a proposal for making a call back in >http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt > >When we set the scope for >draft-ietf-ecrit-local-emergency-rph-namespace there was no mentioning >of a call-back mechanism. > >The group seemed to be OK about using this inside the emergency services >infrastructure but there was critique when used outside. To be accurate, there was critique when the UAC (i.e., the phone) *set* the Resource-Priority header - yes. There are SPs that want to have the ability to have a relationship with PSAPs in such a way to have the SPs do the Resource-Priority header insertion. the document is currently consistent with this view. >Ciao >Hannes > > >-----Original Message----- > >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 19 November, 2008 00:07 > >To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT > >Subject: RE: [Ecrit] > >draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > > > >Brian is correct. > > > >But I was under the impression that people wanted to do the > >callback stuff later. So I do envisage the current proposal > >only for the citizen to authority emergency call. > > > >Keith > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Brian Rosen > >> Sent: Tuesday, November 18, 2008 10:02 PM > >> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT' > >> Subject: Re: [Ecrit] > >> draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect > >> > >> I don't see a problem here. > >> > >> I think it's perfectly reasonable for an endpoint or proxy > >outside an > >> emergency services IP network to mark a call needing resource > >> priority. The policing and behavior of proxy servers or UASs in the > >> presence of such a marking is beyond the scope, but limiting the > >> marking to emergency services networks is unwarranted. > >> > >> Further, differentiating between an incoming emergency call > >and a call > >> back seems wise. It may be the case that there is minimal if any > >> resource priority for such calls in some networks, where in > >others, it > >> may be that there is some explicit priority of incoming vs outgoing. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of Tschofenig, Hannes (NSN - FI/Espoo) > >> Sent: Tuesday, November 18, 2008 3:30 PM > >> To: ECRIT > >> Subject: [Ecrit] > >> draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > >> > >> I have reviewed this document and I believe the scope has changed to > >> what we agreed in previous ECRIT meetings. > >> > >> I believe that the document must not provide mechanisms for > >> * PSAP callbacks > >> * end hosts attaching a marking > >> > >> I believe that the document should only talk about how to use this > >> marking inside an emergency services network. > >> Other mechanisms are overlapping with other techniques and raise > >> security issues. > >> > >> Ciao > >> Hannes > >> > >> > >> _______________________________________________ > >> 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 ecrit-bounces@ietf.org Wed Nov 19 09:10:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DC33A6AEA; Wed, 19 Nov 2008 09:10:46 -0800 (PST) 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 2C61E3A681D for ; Wed, 19 Nov 2008 09:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLQ9CM6d9Yvi for ; Wed, 19 Nov 2008 09:10:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 928103A67F9 for ; Wed, 19 Nov 2008 09:10:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,632,1220227200"; d="scan'208";a="197720192" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2008 17:10:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAJHAhmS028330; Wed, 19 Nov 2008 09:10:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAJHAhWh000150; Wed, 19 Nov 2008 17:10:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:10:43 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.218.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 12:10:42 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Nov 2008 11:10:41 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Brian Rosen" , "ECRIT" From: "James M. Polk" In-Reply-To: References: <07c801c949c9$490e7c30$db2b7490$@net> <07e201c949cb$83d828a0$8b8879e0$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 19 Nov 2008 17:10:42.0748 (UTC) FILETIME=[C10A77C0:01C94A69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3237; t=1227114643; x=1227978643; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace=20--=0A=20=20Scope=09incorrect |Sender:=20; bh=L2fZjaMK2zTZkGWldL/kXNZWLhhjZa7jahv32eJuozM=; b=TmukrH9hhVbVo4A6nJuMTJY/HX0/rRauqPDa7Ea9tI/SKFoOrED9X0F2So mzUt7GVwWcet8ylUxeSNDzh9nqNnSF2guYtpq0T+DRGZw1B4D4IHonvQuNbe 7+peaS0iSU; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 04:37 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >They are different only on a philosophical sense. > >A SIP UA should not have to Hannes - the existing document *never* says a UA has to implement anything at all. The doc doesn't even suggest a UA SHOULD implement anything at all. I think you are confusing things. >implement two mechanisms for such a >philosophical difference. > >The RPH marking can also be used to influence routing decisions (like >anything can be used todo that) > > >The service URN is a ROUTING marking > >The RPH is a (SIP) RESOURCE marking > > > >They do different things. It may even make sense to have one > >marking without the other in some circumstances, although the > >generic 1-1-2 type emergency call would likely have both. > > > >Brian > > > >-----Original Message----- > >From: Tschofenig, Hannes (NSN - FI/Espoo) > >[mailto:hannes.tschofenig@nsn.com] > > > >Sent: Tuesday, November 18, 2008 5:10 PM > >To: ext Brian Rosen; ECRIT > >Subject: RE: [Ecrit] > >draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > > > > > >>I don't see a problem here. > >> > >>I think it's perfectly reasonable for an endpoint or proxy outside an > >>emergency services IP network to mark a call needing resource > >priority. > >>The policing and behavior of proxy servers or UASs in the presence of > >>such a marking is beyond the scope, but limiting the marking to > >>emergency services networks is unwarranted. > > > >The problem with this approach is that you have TWO (2) > >different ways to mark an emergency call == NOT GOOD > > > > > > > > > >> > >>Further, differentiating between an incoming emergency call > >and a call > >>back seems wise. > > > >BUT: We have an alternative way to mark a call from a PSAP > >towards the UA. > > > > > > > >>It may be the case that there is > >>minimal if any resource priority for such calls in some > >networks, where > >>in others, it may be that there is some explicit priority of incoming > >>vs outgoing. > >> > >>Brian > >> > >>-----Original Message----- > >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >>Of Tschofenig, Hannes (NSN - FI/Espoo) > >>Sent: Tuesday, November 18, 2008 3:30 PM > >>To: ECRIT > >>Subject: [Ecrit] > >>draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect > >> > >>I have reviewed this document and I believe the scope has changed to > >>what we agreed in previous ECRIT meetings. > >> > >>I believe that the document must not provide mechanisms for > >>* PSAP callbacks > >>* end hosts attaching a marking > >> > >>I believe that the document should only talk about how to use this > >>marking inside an emergency services network. > >>Other mechanisms are overlapping with other techniques and raise > >>security issues. > >> > >>Ciao > >>Hannes > >> > >> > >>_______________________________________________ > >>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 ecrit-bounces@ietf.org Wed Nov 19 10:20:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D443A6BB1; Wed, 19 Nov 2008 10:20:11 -0800 (PST) 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 60BB03A6866 for ; Wed, 19 Nov 2008 10:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 K+pZ1JMGEhiV for ; Wed, 19 Nov 2008 10:20:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2478E3A6BB2 for ; Wed, 19 Nov 2008 10:20:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAJIK59K017007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Nov 2008 19:20:05 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAJIK4Ku011803 for ; Wed, 19 Nov 2008 19:20:05 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 19:19:51 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 19:19:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 20:19:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote Participation at the ECRIT Meeting Thread-Index: AclKF1ggzMd7nt63TuahECumtdEvMQAGMErg From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 19 Nov 2008 18:19:51.0164 (UTC) FILETIME=[69B083C0:01C94A73] Subject: [Ecrit] Remote Participation at the ECRIT Meeting 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Based on the fact that some folks are not in Minneapolis to participate at the IETF#73 ECRIT meeting I would like to remind you about the remote participation facilities. * Agenda: http://www3.ietf.org/proceedings/08nov/agenda/ecrit.txt Slides: https://datatracker.ietf.org/meeting/73/materials.html * Audio Streaming Information can be found here: http://www.ietf.org/mail-archive/web/ietf/current/msg53997.html * Jabber Room Room: ecrit@jabber.ietf.org An example on how to get started with Jabber can be found here: http://www.emergency-services-coordination.info/2008Oct/chat-room.html * Conference Bridge We are also going to setup a conference bridge and maybe using Webex (see Jabber room before the meeting for more info). Here is the bridge info: Number: +1 (712) 432-1100 PIN: 292812# Please join the meeting. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 19 22:48:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F3D3A6849; Wed, 19 Nov 2008 22:48:38 -0800 (PST) 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 08D943A6849 for ; Wed, 19 Nov 2008 22:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIgFR9mekxPy for ; Wed, 19 Nov 2008 22:48:36 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1CDD43A680D for ; Wed, 19 Nov 2008 22:48:34 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAK6m3Tj016945; Thu, 20 Nov 2008 08:48:28 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 08:48:25 +0200 Received: from esebe111.NOE.Nokia.com ([172.21.143.154]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 08:48:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 08:48:23 +0200 Message-ID: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location Protocols in Phone BCP Thread-Index: AclJfA21/Ob3kGogT9aCDh5wV8pxHABVkjVg References: From: To: X-OriginalArrivalTime: 20 Nov 2008 06:48:25.0528 (UTC) FILETIME=[FCBC9380:01C94ADB] X-Nokia-AV: Clean Cc: marc.linsner@cisco.com, hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: multipart/mixed; boundary="===============0059930675==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0059930675== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94ADB.FC88AFD9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94ADB.FC88AFD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was requested to send my observations regarding this requirement: ED-21/INT-12 Devices MUST support all of: DHCP location options [RFC4776] and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. =20 I believe we should come up with a list of LCPs which are likely to be supported in devices in a not so distant future. Since I have no seen or heard about LLDP support yet, at least that should be replaced with what is mostly used today (OMA SUPL) and the 802.11 mechanism, with the condition that this MUST only be supported if there is a wifi interface available on the device. - Gabor =20 ________________________________ From: ext Tschofenig, Hannes Sent: Tuesday, November 18, 2008 12:49 PM To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com Subject: Location Protocols in Phone BCP =20 Gabor,=20 Could you please raise your question about location protocols in Phone BCP mentioned at ESW5 in the ECRIT WG session again?=20 Ciao Hannes=20 ------_=_NextPart_001_01C94ADB.FC88AFD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Location Protocols in Phone BCP

I was requested to send my = observations regarding this requirement:

  ED-21/INT-12 Devices MUST support all =
of: DHCP location options
   [RFC4776] and [RFC3825], =
HELD
   =
[I-D.ietf-geopriv-http-location-delivery] and LLDP-MED =
[LLDP-MED].
 

I believe we should come up with a = list of LCPs which are likely to be supported in devices in a not so distant = future. Since I have no seen or heard about LLDP support yet, at least that = should be replaced with what is mostly used today (OMA SUPL) and the 802.11 = mechanism, with the condition that this MUST only be supported if there is a wifi interface available on the device.

- = Gabor

 

From: ext = Tschofenig, Hannes

Sent: = Tuesday, November 18, 2008 12:49 PM
To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com
Subject: Location = Protocols in Phone BCP

 

Gabor,

Could you please raise your question about location protocols in Phone BCP = mentioned at ESW5 in the ECRIT WG session again?

Ciao
Hannes

------_=_NextPart_001_01C94ADB.FC88AFD9-- --===============0059930675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0059930675==-- From ecrit-bounces@ietf.org Thu Nov 20 00:09:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEC63A6957; Thu, 20 Nov 2008 00:09:02 -0800 (PST) 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 8C0283A6957 for ; Thu, 20 Nov 2008 00:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 lXBEmMK+TtDh for ; Thu, 20 Nov 2008 00:08:59 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 985073A682D for ; Thu, 20 Nov 2008 00:08:59 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_02_26_37 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 02:26:37 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 02:08:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 02:05:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location Protocols in Phone BCP Thread-Index: AclJfA21/Ob3kGogT9aCDh5wV8pxHABVkjVgAAUfExc= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> From: "Winterbottom, James" To: , X-OriginalArrivalTime: 20 Nov 2008 08:08:57.0449 (UTC) FILETIME=[3CC93590:01C94AE7] Cc: hannes.tschofenig@nsn.com, marc.linsner@cisco.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Gabor, The list of LCPs in the phone BCP is a must support list, and is access-type agnostic. I am curious that you say that SUPL is a MUST support given that: a) it requires a home network in order to operate b) it simply doesn't work for DSL or Cable c) it is questionable whether it is really deployable for WiFi networks Can you perhaps describe how it fits into the general Internet model? Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com Sent: Thu 11/20/2008 12:48 AM To: ecrit@ietf.org Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP I was requested to send my observations regarding this requirement: ED-21/INT-12 Devices MUST support all of: DHCP location options [RFC4776] and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. I believe we should come up with a list of LCPs which are likely to be supported in devices in a not so distant future. Since I have no seen or heard about LLDP support yet, at least that should be replaced with what is mostly used today (OMA SUPL) and the 802.11 mechanism, with the condition that this MUST only be supported if there is a wifi interface available on the device. - Gabor ________________________________ From: ext Tschofenig, Hannes Sent: Tuesday, November 18, 2008 12:49 PM To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com Subject: Location Protocols in Phone BCP Gabor, Could you please raise your question about location protocols in Phone BCP mentioned at ESW5 in the ECRIT WG session again? Ciao Hannes ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 06:26:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C823A686A; Thu, 20 Nov 2008 06:26:24 -0800 (PST) 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 47CA53A686A for ; Thu, 20 Nov 2008 06:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjbtNwxU3t4c for ; Thu, 20 Nov 2008 06:26:20 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B2B753A67FA for ; Thu, 20 Nov 2008 06:26:19 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAKEQ3Z4017158; Thu, 20 Nov 2008 16:26:10 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 16:26:10 +0200 Received: from esebe111.NOE.Nokia.com ([172.21.143.154]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 16:26:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 16:26:08 +0200 Message-ID: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclJfA21/Ob3kGogT9aCDh5wV8pxHABVkjVgAAUfExcADI1hQA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 20 Nov 2008 14:26:10.0172 (UTC) FILETIME=[EEF0ABC0:01C94B1B] X-Nokia-AV: Clean Cc: hannes.tschofenig@nsn.com, marc.linsner@cisco.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, Is the intent to list the LCPs which are access-type agnostic but not supported anywhere, or instead have a list of LCPs which are highly probable to produce the intended result? There are restrictions everywhere, things come at a cost even in the general Internet model. The reality is that most of the devices with internet access have a home network already. - Gabor >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Thursday, November 20, 2008 12:06 AM >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >Hi Gabor, > >The list of LCPs in the phone BCP is a must support list, and is access- >type agnostic. >I am curious that you say that SUPL is a MUST support given that: >a) it requires a home network in order to operate >b) it simply doesn't work for DSL or Cable >c) it is questionable whether it is really deployable for WiFi networks > >Can you perhaps describe how it fits into the general Internet model? > >Cheers >James > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >Sent: Thu 11/20/2008 12:48 AM >To: ecrit@ietf.org >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >I was requested to send my observations regarding this requirement: > > ED-21/INT-12 Devices MUST support all of: DHCP location options > [RFC4776] and [RFC3825], HELD > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. > > >I believe we should come up with a list of LCPs which are likely to be >supported in devices in a not so distant future. Since I have no seen or >heard about LLDP support yet, at least that should be replaced with what >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >condition that this MUST only be supported if there is a wifi interface >available on the device. > >- Gabor > > > >________________________________ > >From: ext Tschofenig, Hannes > >Sent: Tuesday, November 18, 2008 12:49 PM >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >Subject: Location Protocols in Phone BCP > > > >Gabor, > >Could you please raise your question about location protocols in Phone >BCP mentioned at ESW5 in the ECRIT WG session again? > >Ciao >Hannes > > >----------------------------------------------------------------------- -- >----------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >----------------------------------------------------------------------- -- >----------------------- >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 06:38:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5936F3A6998; Thu, 20 Nov 2008 06:38:34 -0800 (PST) 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 C5E6628C1F1 for ; Thu, 20 Nov 2008 06:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KCSfc2WqjbTq for ; Thu, 20 Nov 2008 06:38:32 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D3A233A6998 for ; Thu, 20 Nov 2008 06:38:32 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3Afm-0002ZJ-Kp; Thu, 20 Nov 2008 08:38:22 -0600 From: "Brian Rosen" To: , , References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> In-Reply-To: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> Date: Thu, 20 Nov 2008 09:38:22 -0500 Message-ID: <00ff01c94b1d$a5d11e50$f1735af0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclJfA21/Ob3kGogT9aCDh5wV8pxHABVkjVgAAUfExcADI1hQAAA9kBA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: marc.linsner@cisco.com, hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem with SUPL is that the majority of networks where SUPL would be available have a proxy (E-CSCF) insert location. It also has an incompatible location representation, and an incompatible privacy model. That makes it very hard to interwork with any of the rest of the IETF work. I will say this. For quite some time, the IETF has been trying to interest OMA into cooperation on location so that we have interoperability at the protocol, location representation and privacy levels. So far, that has not happened. If, as part of a comprehensive agreement to accomplish such a goal, SUPL became one of the LCPs, I would not object. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, November 20, 2008 9:26 AM To: James.Winterbottom@andrew.com; ecrit@ietf.org Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com Subject: Re: [Ecrit] Location Protocols in Phone BCP Hi, Is the intent to list the LCPs which are access-type agnostic but not supported anywhere, or instead have a list of LCPs which are highly probable to produce the intended result? There are restrictions everywhere, things come at a cost even in the general Internet model. The reality is that most of the devices with internet access have a home network already. - Gabor >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Thursday, November 20, 2008 12:06 AM >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >Hi Gabor, > >The list of LCPs in the phone BCP is a must support list, and is access- >type agnostic. >I am curious that you say that SUPL is a MUST support given that: >a) it requires a home network in order to operate >b) it simply doesn't work for DSL or Cable >c) it is questionable whether it is really deployable for WiFi networks > >Can you perhaps describe how it fits into the general Internet model? > >Cheers >James > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >Sent: Thu 11/20/2008 12:48 AM >To: ecrit@ietf.org >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >I was requested to send my observations regarding this requirement: > > ED-21/INT-12 Devices MUST support all of: DHCP location options > [RFC4776] and [RFC3825], HELD > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. > > >I believe we should come up with a list of LCPs which are likely to be >supported in devices in a not so distant future. Since I have no seen or >heard about LLDP support yet, at least that should be replaced with what >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >condition that this MUST only be supported if there is a wifi interface >available on the device. > >- Gabor > > > >________________________________ > >From: ext Tschofenig, Hannes > >Sent: Tuesday, November 18, 2008 12:49 PM >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >Subject: Location Protocols in Phone BCP > > > >Gabor, > >Could you please raise your question about location protocols in Phone >BCP mentioned at ESW5 in the ECRIT WG session again? > >Ciao >Hannes > > >----------------------------------------------------------------------- -- >----------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >----------------------------------------------------------------------- -- >----------------------- >[mf2] _______________________________________________ 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 ecrit-bounces@ietf.org Thu Nov 20 07:10:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFC13A67FA; Thu, 20 Nov 2008 07:10:53 -0800 (PST) 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 8A5DA3A6867 for ; Thu, 20 Nov 2008 07:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GRuWiS5u6+oB for ; Thu, 20 Nov 2008 07:10:50 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 34CD73A67DB for ; Thu, 20 Nov 2008 07:10:50 -0800 (PST) Received: from [128.89.255.100] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3BB4-0004GY-BG; Thu, 20 Nov 2008 10:10:42 -0500 Message-ID: <49257DF1.2000205@bbn.com> Date: Thu, 20 Nov 2008 09:10:41 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Brian Rosen References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> In-Reply-To: <00ff01c94b1d$a5d11e50$f1735af0$@net> Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think we need to pull up a level. It's not reasonable for an RFC to try to list all of the location protocols out there, if for no other reason than that it will rapidly become obsolete. Instead, we should say something like the following: " INT-12 Devices MUST support the DHCP location options [RFC4776] and [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices SHOULD support all location protocols supported at lower layers by their interfaces (e.g., LLDP-MED [LLDP-MED]). " Brian Rosen wrote: > The problem with SUPL is that the majority of networks where SUPL would be > available have a proxy (E-CSCF) insert location. It also has an > incompatible location representation, and an incompatible privacy model. > That makes it very hard to interwork with any of the rest of the IETF work. > > I will say this. For quite some time, the IETF has been trying to interest > OMA into cooperation on location so that we have interoperability at the > protocol, location representation and privacy levels. So far, that has not > happened. If, as part of a comprehensive agreement to accomplish such a > goal, SUPL became one of the LCPs, I would not object. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Thursday, November 20, 2008 9:26 AM > To: James.Winterbottom@andrew.com; ecrit@ietf.org > Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Hi, > > Is the intent to list the LCPs which are access-type agnostic but not > supported anywhere, or instead have a list of LCPs which are highly > probable to produce the intended result? > > There are restrictions everywhere, things come at a cost even in the > general Internet model. The reality is that most of the devices with > internet access have a home network already. > > - Gabor > > > >-----Original Message----- > >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > >Sent: Thursday, November 20, 2008 12:06 AM > >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > >Hi Gabor, > > > >The list of LCPs in the phone BCP is a must support list, and is > access- > >type agnostic. > >I am curious that you say that SUPL is a MUST support given that: > >a) it requires a home network in order to operate > >b) it simply doesn't work for DSL or Cable > >c) it is questionable whether it is really deployable for WiFi > networks > > > >Can you perhaps describe how it fits into the general Internet model? > > > >Cheers > >James > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >Sent: Thu 11/20/2008 12:48 AM > >To: ecrit@ietf.org > >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >I was requested to send my observations regarding this requirement: > > > > ED-21/INT-12 Devices MUST support all of: DHCP location options > > [RFC4776] and [RFC3825], HELD > > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. > > > > > >I believe we should come up with a list of LCPs which are likely to > be > >supported in devices in a not so distant future. Since I have no seen > or > >heard about LLDP support yet, at least that should be replaced with > what > >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the > >condition that this MUST only be supported if there is a wifi > interface > >available on the device. > > > >- Gabor > > > > > > > >________________________________ > > > >From: ext Tschofenig, Hannes > > > >Sent: Tuesday, November 18, 2008 12:49 PM > >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >Subject: Location Protocols in Phone BCP > > > > > > > >Gabor, > > > >Could you please raise your question about location protocols in > Phone > >BCP mentioned at ESW5 in the ECRIT WG session again? > > > >Ciao > >Hannes > > > > > >> ----------------------------------------------------------------------- > -- > >----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >> ----------------------------------------------------------------------- > -- > >----------------------- > >[mf2] > > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Nov 20 07:25:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78CC3A6867; Thu, 20 Nov 2008 07:25:03 -0800 (PST) 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 34D473A69DA for ; Thu, 20 Nov 2008 07:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHvpOH-oPM4W for ; Thu, 20 Nov 2008 07:25:00 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 473F33A6867 for ; Thu, 20 Nov 2008 07:24:57 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAKFOaUu016343; Thu, 20 Nov 2008 09:24:52 -0600 (CST) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 09:22:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 09:22:49 -0600 Message-ID: <7D096A439A3D0D48A3D10872022CFD090359D22F@ILEXC1U02.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re:Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 thread-index: AclLI9lJJ75xS6j8TWa8SRYgyo9IDg== From: "GOLDMAN, STUART O \(STUART\)" To: "Janet P Gunn" X-OriginalArrivalTime: 20 Nov 2008 15:22:50.0954 (UTC) FILETIME=[D9F6D2A0:01C94B23] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============1431068433==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1431068433== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94B23.D9CC7969" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94B23.D9CC7969 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Janet, =20 With regard to you e-mail below, did you intend that esnet could be at the same level of priority as ETS & WPS, or that ETS & WPS need to be at an even higher priority than esnet? =20 =20 =20 Stuart Goldman Alcatel-Lucent=20 Stuart.Goldman@alcatel-lucent.com +1 602 493 8438 +1 480 414 1260 mobile P please save a tree by not printing this e-mail. =20 =20 =20 Janet P Gunn/FED/CSC@CSC=20 Sent by: ecrit-bounces@ietf.org=20 10/27/2008 11:45 PM=20 =20 To "James M. Polk" =20 cc "'ECRIT'" , ecrit-bounces@ietf.org=20 Subject Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 =20 =20 =20 =20 I apologize for not tracking this as closely as I meant to, as these comments apply to earlier versions as well.=20 This sentence at the end of sec 1 doesn't quite work.=20 "This document IANA registers the "esnet"=20 RPH namespace for use within emergency services networks, not just=20 of those from citizens to PSAPs." (no clear antecedent for "those")=20 Perhaps=20 "This document IANA registers the "esnet"=20 RPH namespace for use within emergency services networks, not just for calls or sessions=20 from citizens to PSAPs."=20 Section 2 says=20 "This document updates the behaviors of the SIP Resource Priority=20 header, defined in [RFC4412], during the treatment options=20 surrounding this new "esnet" namespace only. The usage of the=20 "esnet" namespace does not have a normal, or routine call level. =20 Every use of this namespace will be in times of an emergency, where=20 at least one end of the signaling is with a local emergency=20 organization."=20 I don't see this as an "update of the behavior of 4412". Neither the ets namespace not the wps=20 namespace have a "normal" or "routine" call level. Every use of the wps and ets namespaces will=20 have priority over calls without RPH.=20 You say "This=20 namespace, therefore, MAY be overwritten or deleted, contrary to the=20 rules of RFC 4412 [RFC4412]."=20 It is not clear to me why this is "contrary to the rules of 4412". It is certainly anticipated=20 that other RPH will be overwritten or deleted, when the UAS understands the namespace.=20 4412 says "Existing implementations of RFC 3261 that do not participate in the=20 resource priority mechanism follow the normal rules of RFC 3261,=20 Section 8.2.2: "If a UAS does not understand a header field in a=20 request (that is, the header field is not defined in this=20 specification or in any supported extension), the server MUST ignore=20 that header field and continue processing the message". "=20 But I do not see anywhere that is says that a UAS that DOES understand the namespace is=20 forbidden from deleting it. For instance, sec 4.7.1 of 4412 says that "the UAC=20 MAY attempt a subsequent request with the same or different resource=20 value." This certainly implies the ability to overwrite or delete an RPH namespace. =20 (See also, for instance the PTSC SAC document on the use of the ets and wps namespaces)=20 Immediately following these statements, you give 3 options-=20 "These proxies in the service provider=20 MAY either=20 o accept the existing RPH value with "esnet" in it, if one is=20 present, and grant relative preferential treatment to the request=20 when forwarding it to the ESINet.=20 o replace any existing RPH value, if one is present, and insert an=20 "esnet" namespace and give relative preferential treatment to the=20 request when forwarding it to the ESINet.=20 o insert an "esnet" namespace in a new RPH and give relative=20 preferential treatment to the request when forwarding the SIP=20 request towards the ESINet."=20 Why do you exclude the possibility of adding the esnet RPH value without "replacing" an existing RPH value?=20 Finally, there is another point that needs to be made clear. At least one person has contacted me expressing concern that this ID implied that the esnet namespace would have priority over other namespaces (in particular wps and ets). I assured him that this was not the case, that there was nothing prevent the expected behavior - that the ets and wps namespaces would be prioritized ahead of esnet in GETS Service Provider networks.=20 However, since the question has already arisen, it would be a good idea to clarify this, perhaps in section 3, where you discuss the other namespaces. In particular, it needs to be made clear in section 3.2 that, even if "the local jurisdiction preferred to preempt normal calls in lieu of=20 completing emergency calls. ", esnet calls will NOT preempt wps or ets calls.=20 By the way, I think you mean "the local jurisdiction preferred to preempt normal calls in order to complete emergency calls. " - not "in lieu of". Or perhaps "the local jurisdiction preferred to preempt normal calls in lieu of dropping emergency calls. "=20 In fact, it is not clear to me that 4412 permits a call with an RPH (e.g., esnet) to preempt a "normal" call (with no RPH namespace). Section 4.7.2.1 of 4412 says=20 "4.7.2.1. User Agent Servers and Preemption Algorithm=20 A UAS compliant with this specification MUST terminate a session=20 established with a valid namespace and lower-priority value in favor=20 of a new session set up with a valid namespace and higher relative=20 priority value, unless local policy has some form of call-waiting=20 capability enabled. "=20 It doesn't say anything about preempting a call with no RPH=20 Thanks=20 Janet=20 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.=20 NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.=20 "James M. Polk" =20 Sent by: ecrit-bounces@ietf.org=20 10/27/2008 08:32 PM=20 =20 =20 To "'ECRIT'" =20 cc =20 Subject [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 =20 =20 =20 =20 ECRIT WG Here is a update to a ID I think is pretty near done, given that this=20 is merely an IANA registration ID of an existing mechanism. Comments are wanted >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. >This draft is a work item of the Emergency Context Resolution with=20 >Internet Technologies Working Group of the IETF. > > > Title : IANA Registering a SIP Resource Priority=20 > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename :=20 > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > Pages : 9 > Date : 2008-10-27 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rp h-namespace-00.txt > > > > _______________________________________________ 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 =20 =20 Stuart Goldman Alcatel-Lucent=20 Stuart.Goldman@alcatel-lucent.com +1 602 493 8438 +1 480 414 1260 mobile P please save a tree by not printing this e-mail. =20 =20 =20 ------_=_NextPart_001_01C94B23.D9CC7969 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Janet,

 

With regard to you e-mail below, did = you intend that esnet could be at the same level of priority as ETS & = WPS,  or that ETS & WPS need to be at an even higher priority than = esnet?

 

 

 

Stuart Goldman

Alcatel-Lucent

Stuart.Goldman@alcatel-lucent.com

+1 602 493 8438

+1 480 414 1260 mobile

P please save a tree by not printing this = e-mail.

 

 

 

Janet P = Gunn/FED/CSC@CSC
Sent by: ecrit-bounces@ietf.org

10/27/2008 11:45 PM

 

To

"James M. Polk" <jmpolk@cisco.com>

cc

"'ECRIT'" = <ecrit@ietf.org>, ecrit-bounces@ietf.org

Subject

Re: [Ecrit] = draft-ietf-ecrit-local-emergency-rph-namespace-00


 

 

 

 






I apologize for not tracking this as closely as I meant to, as these = comments apply to  earlier versions as well.


This sentence at the end of sec 1 doesn't quite work. =
"This document IANA registers the "esnet" =
 RPH namespace for use within emergency services networks, not just =
 of those from citizens to PSAPs." (no clear antecedent for "those")

Perhaps
"This document IANA registers the "esnet" =
 RPH namespace for use within emergency services networks, not just = for calls or sessions
  from citizens to PSAPs."

Section 2 says
"This document updates the behaviors of the SIP Resource Priority =
 header, defined in [RFC4412], during the treatment options
 surrounding this new "esnet" namespace only. The usage = of the
 "esnet" namespace does not have a normal, or routine = call level.  
 Every use of this namespace will be in times of an emergency, = where
 at least one end of the signaling is with a local emergency
 organization."

I don't see this as an "update of the behavior of 4412".  Neither the ets namespace not the wps
namespace have a "normal" or "routine" call level.  Every use of the wps and ets namespaces will
have priority over calls without RPH.

You say "This
 namespace, therefore, MAY be overwritten or deleted, contrary to = the
 rules of RFC 4412 [RFC4412]."

It is not clear to me why this is "contrary to the rules of = 4412".  It is certainly anticipated
that other RPH will be overwritten or deleted, when the UAS understands = the namespace.

4412 says "Existing implementations of RFC 3261 that do not = participate in the
 resource priority mechanism follow the normal rules of RFC = 3261,
 Section 8.2.2: "If a UAS does not understand a header field = in a
 request (that is, the header field is not defined in = this
 specification or in any supported extension), the server MUST = ignore
 that header field and continue processing the message". = "

But I do not see anywhere that is says that a UAS that DOES understand = the namespace is
forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says = that "the UAC
 MAY attempt a subsequent request with the same or different = resource
 value."  This certainly implies the ability to overwrite = or delete an RPH namespace.  

(See also, for instance the PTSC SAC document on the use of the ets and = wps namespaces)

Immediately following these statements, you give 3 = options-
"These proxies in the service provider
 MAY either

 o  accept the existing RPH value with "esnet" in = it, if one is
    present, and grant relative preferential treatment to the = request
    when forwarding it to the ESINet.

 o  replace any existing RPH value, if one is present, and = insert an
    "esnet" namespace and give relative preferential treatment to the
    request when forwarding it to the ESINet. =

 o  insert an "esnet" namespace in a new RPH and = give relative
    preferential treatment to the request when forwarding the = SIP
    request towards the ESINet."

Why do you exclude the possibility of adding the esnet RPH value without "replacing" an existing RPH value?

Finally, there is another point that  needs to be made clear. =  At least one person has contacted me expressing concern that this ID = implied that the esnet namespace would  have priority over other namespaces (in particular wps and ets).  I assured him that this was not the case, = that there was nothing prevent the expected behavior - that the ets and wps = namespaces would be prioritized ahead of esnet in GETS Service Provider = networks.

However, since the question has already arisen, it would be a good idea = to clarify  this, perhaps in  section 3, where you discuss =  the other namespaces.  In particular, it needs to be made clear in = section 3.2  that, even if  "the   local jurisdiction preferred = to preempt normal calls in lieu of
 completing emergency calls. ", esnet calls will NOT preempt = wps or ets calls.

By the way, I think you mean "the   local jurisdiction = preferred to preempt normal calls in order to complete emergency calls. " =  - not "in lieu of".  Or perhaps "the   local = jurisdiction preferred to preempt normal calls in lieu of  dropping emergency = calls. "

In fact, it is not clear to me that 4412 permits a call with an RPH = (e.g., esnet)  to preempt a "normal" call (with no RPH = namespace).  Section 4.7.2.1 of 4412 says
"4.7.2.1.  User Agent Servers and Preemption = Algorithm

 A UAS compliant with this specification MUST terminate a = session
 established with a valid namespace and lower-priority value in = favor
 of a new session set up with a valid namespace and higher = relative
 priority value, unless local policy has some form of = call-waiting
 capability enabled. "

It doesn't say anything about preempting a call with no = RPH

Thanks

Janet






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

"James M. = Polk" <jmpolk@cisco.com>
Sent by: ecrit-bounces@ietf.org

10/27/2008 08:32 PM

 

 

To

"'ECRIT'" = <ecrit@ietf.org>

cc

 

Subject

[Ecrit] = draft-ietf-ecrit-local-emergency-rph-namespace-00


 

 

 

 






ECRIT WG

Here is a update to a ID I think is pretty near done, given that this =
is merely an IANA registration ID of an existing mechanism.

Comments are wanted

>A New Internet-Draft is available from the on-line Internet-Drafts =
>directories.
>This draft is a work item of the Emergency Context Resolution with =
>Internet Technologies Working Group of the IETF.
>
>
>         Title         =   : IANA Registering a SIP Resource Priority
> Header Namespace for Local Emergency Communications
>         Author(s)       : J. = Polk
>         Filename        : =
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
>         Pages         =   : 9
>         Date            : 2008-10-27
>
>This document creates and IANA registers the new Session = Initiation
>Protocol (SIP) Resource Priority header (RPH) namespace = "esnet" for
>local emergency usage to a public safety answering point (PSAP),
>between PSAPs, and between a PSAP and first responders and their
>organizations.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-= rph-namespace-00.txt
>
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergen= cy-rph-namespace-00.txt>

_______________________________________________
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 =

 

 

Stuart Goldman

Alcatel-Lucent

Stuart.Goldman@alcatel-lucent.com

+1 602 493 8438

+1 480 414 1260 mobile

P please save a tree by not printing this = e-mail.

 

 

 

------_=_NextPart_001_01C94B23.D9CC7969-- --===============1431068433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1431068433==-- From ecrit-bounces@ietf.org Thu Nov 20 07:30:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41ED33A6800; Thu, 20 Nov 2008 07:30:03 -0800 (PST) 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 053733A6800 for ; Thu, 20 Nov 2008 07:30:02 -0800 (PST) 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 Iq99PyZA50du for ; Thu, 20 Nov 2008 07:30:00 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 97B963A67B5 for ; Thu, 20 Nov 2008 07:30:00 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3BTe-0005iX-KC; Thu, 20 Nov 2008 09:29:55 -0600 From: "Brian Rosen" To: "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> In-Reply-To: <49257DF1.2000205@bbn.com> Date: Thu, 20 Nov 2008 10:29:54 -0500 Message-ID: <011b01c94b24$d8d78a80$8a869f80$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLIiiqk7bMMCeMRjmQ9io0lnt01QAAY2Ag Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have been over this several times before. You can't get interoperability that way. If there are exactly two LCPs all UAs must implement, and any number of optional ones, then every network has to implement at least one of those two LCPs, and any number of optional ones. That means that "any number of optional ones" is useless for both parties. If the network can limit UAs to ONLY those that implement one of the optional protocols, then it works, but in practice, it is usually impossible to do that. My example is the wired, Ethernet connected phone in an RV traveling down the road with wireless data card in a router. These EXIST, now. Brian -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Thursday, November 20, 2008 10:11 AM To: Brian Rosen Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP I think we need to pull up a level. It's not reasonable for an RFC to try to list all of the location protocols out there, if for no other reason than that it will rapidly become obsolete. Instead, we should say something like the following: " INT-12 Devices MUST support the DHCP location options [RFC4776] and [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices SHOULD support all location protocols supported at lower layers by their interfaces (e.g., LLDP-MED [LLDP-MED]). " Brian Rosen wrote: > The problem with SUPL is that the majority of networks where SUPL would be > available have a proxy (E-CSCF) insert location. It also has an > incompatible location representation, and an incompatible privacy model. > That makes it very hard to interwork with any of the rest of the IETF work. > > I will say this. For quite some time, the IETF has been trying to interest > OMA into cooperation on location so that we have interoperability at the > protocol, location representation and privacy levels. So far, that has not > happened. If, as part of a comprehensive agreement to accomplish such a > goal, SUPL became one of the LCPs, I would not object. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Thursday, November 20, 2008 9:26 AM > To: James.Winterbottom@andrew.com; ecrit@ietf.org > Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Hi, > > Is the intent to list the LCPs which are access-type agnostic but not > supported anywhere, or instead have a list of LCPs which are highly > probable to produce the intended result? > > There are restrictions everywhere, things come at a cost even in the > general Internet model. The reality is that most of the devices with > internet access have a home network already. > > - Gabor > > > >-----Original Message----- > >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > >Sent: Thursday, November 20, 2008 12:06 AM > >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > >Hi Gabor, > > > >The list of LCPs in the phone BCP is a must support list, and is > access- > >type agnostic. > >I am curious that you say that SUPL is a MUST support given that: > >a) it requires a home network in order to operate > >b) it simply doesn't work for DSL or Cable > >c) it is questionable whether it is really deployable for WiFi > networks > > > >Can you perhaps describe how it fits into the general Internet model? > > > >Cheers > >James > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >Sent: Thu 11/20/2008 12:48 AM > >To: ecrit@ietf.org > >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >I was requested to send my observations regarding this requirement: > > > > ED-21/INT-12 Devices MUST support all of: DHCP location options > > [RFC4776] and [RFC3825], HELD > > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. > > > > > >I believe we should come up with a list of LCPs which are likely to > be > >supported in devices in a not so distant future. Since I have no seen > or > >heard about LLDP support yet, at least that should be replaced with > what > >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the > >condition that this MUST only be supported if there is a wifi > interface > >available on the device. > > > >- Gabor > > > > > > > >________________________________ > > > >From: ext Tschofenig, Hannes > > > >Sent: Tuesday, November 18, 2008 12:49 PM > >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >Subject: Location Protocols in Phone BCP > > > > > > > >Gabor, > > > >Could you please raise your question about location protocols in > Phone > >BCP mentioned at ESW5 in the ECRIT WG session again? > > > >Ciao > >Hannes > > > > > >> ----------------------------------------------------------------------- > -- > >----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >> ----------------------------------------------------------------------- > -- > >----------------------- > >[mf2] > > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Nov 20 08:00:05 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8BB128C20D; Thu, 20 Nov 2008 08:00:05 -0800 (PST) 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 83F8428C111 for ; Thu, 20 Nov 2008 08:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+BouuG-aSju for ; Thu, 20 Nov 2008 08:00:00 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 4A0343A695F for ; Thu, 20 Nov 2008 08:00:00 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-85.messagelabs.com!1227196781!3771851!9 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 3337 invoked from network); 20 Nov 2008 15:59:57 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 15:59:57 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAKFxfxd032234 for ; Thu, 20 Nov 2008 10:59:56 -0500 In-Reply-To: <7D096A439A3D0D48A3D10872022CFD090359D22F@ILEXC1U02.ndc.lucent.com> To: "GOLDMAN, STUART O \(STUART\)" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 20 Nov 2008 10:59:52 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/20/2008 11:02:27 AM, Serialize complete at 11/20/2008 11:02:27 AM Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============1840743966==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1840743966== Content-Type: multipart/alternative; boundary="=_alternative 0057E11A85257507_=" This is a multipart message in MIME format. --=_alternative 0057E11A85257507_= Content-Type: text/plain; charset="US-ASCII" Stu, I intended to say that the esnet namespace needs to be at a LOWER priority than the ets and wps namespaces, in any network that recognizes ets and wps as described in 10.5 and 10.6 of RFC4412. Janet "GOLDMAN, STUART O \(STUART\)" wrote on 11/20/2008 10:22:49 AM: > Janet, > > With regard to you e-mail below, did you intend that esnet could be > at the same level of priority as ETS & WPS, or that ETS & WPS need > to be at an even higher priority than esnet? > > > > Stuart Goldman > Alcatel-Lucent > Stuart.Goldman@alcatel-lucent.com > +1 602 493 8438 > +1 480 414 1260 mobile > P please save a tree by not printing this e-mail. > > > > > Janet P Gunn/FED/CSC@CSC > Sent by: ecrit-bounces@ietf.org > 10/27/2008 11:45 PM > > > > To > > "James M. Polk" > > cc > > "'ECRIT'" , ecrit-bounces@ietf.org > > Subject > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant to, as these > comments apply to earlier versions as well. > > > This sentence at the end of sec 1 doesn't quite work. > "This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just > of those from citizens to PSAPs." (no clear antecedent for "those") > > Perhaps > "This document IANA registers the "esnet" > RPH namespace for use within emergency services networks, not just > for calls or sessions > from citizens to PSAPs." > > Section 2 says > "This document updates the behaviors of the SIP Resource Priority > header, defined in [RFC4412], during the treatment options > surrounding this new "esnet" namespace only. The usage of the > "esnet" namespace does not have a normal, or routine call level. > Every use of this namespace will be in times of an emergency, where > at least one end of the signaling is with a local emergency > organization." > > I don't see this as an "update of the behavior of 4412". Neither > the ets namespace not the wps > namespace have a "normal" or "routine" call level. Every use of the > wps and ets namespaces will > have priority over calls without RPH. > > You say "This > namespace, therefore, MAY be overwritten or deleted, contrary to the > rules of RFC 4412 [RFC4412]." > > It is not clear to me why this is "contrary to the rules of 4412". > It is certainly anticipated > that other RPH will be overwritten or deleted, when the UAS > understands the namespace. > > 4412 says "Existing implementations of RFC 3261 that do not participate in the > resource priority mechanism follow the normal rules of RFC 3261, > Section 8.2.2: "If a UAS does not understand a header field in a > request (that is, the header field is not defined in this > specification or in any supported extension), the server MUST ignore > that header field and continue processing the message". " > > But I do not see anywhere that is says that a UAS that DOES > understand the namespace is > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > that "the UAC > MAY attempt a subsequent request with the same or different resource > value." This certainly implies the ability to overwrite or delete > an RPH namespace. > > (See also, for instance the PTSC SAC document on the use of the ets > and wps namespaces) > > Immediately following these statements, you give 3 options- > "These proxies in the service provider > MAY either > > o accept the existing RPH value with "esnet" in it, if one is > present, and grant relative preferential treatment to the request > when forwarding it to the ESINet. > > o replace any existing RPH value, if one is present, and insert an > "esnet" namespace and give relative preferential treatment to the > request when forwarding it to the ESINet. > > o insert an "esnet" namespace in a new RPH and give relative > preferential treatment to the request when forwarding the SIP > request towards the ESINet." > > Why do you exclude the possibility of adding the esnet RPH value > without "replacing" an existing RPH value? > > Finally, there is another point that needs to be made clear. At > least one person has contacted me expressing concern that this ID > implied that the esnet namespace would have priority over other > namespaces (in particular wps and ets). I assured him that this was > not the case, that there was nothing prevent the expected behavior - > that the ets and wps namespaces would be prioritized ahead of esnet > in GETS Service Provider networks. > > However, since the question has already arisen, it would be a good > idea to clarify this, perhaps in section 3, where you discuss the > other namespaces. In particular, it needs to be made clear in > section 3.2 that, even if "the local jurisdiction preferred to > preempt normal calls in lieu of > completing emergency calls. ", esnet calls will NOT preempt wps or ets calls. > > By the way, I think you mean "the local jurisdiction preferred to > preempt normal calls in order to complete emergency calls. " - not > "in lieu of". Or perhaps "the local jurisdiction preferred to > preempt normal calls in lieu of dropping emergency calls. " > > In fact, it is not clear to me that 4412 permits a call with an RPH > (e.g., esnet) to preempt a "normal" call (with no RPH namespace). > Section 4.7.2.1 of 4412 says > "4.7.2.1. User Agent Servers and Preemption Algorithm > > A UAS compliant with this specification MUST terminate a session > established with a valid namespace and lower-priority value in favor > of a new session set up with a valid namespace and higher relative > priority value, unless local policy has some form of call-waiting > capability enabled. " > > It doesn't say anything about preempting a call with no RPH > > Thanks > > Janet > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. > NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the > use of e-mail for such purpose. > > "James M. Polk" > Sent by: ecrit-bounces@ietf.org > 10/27/2008 08:32 PM > > > > > To > > "'ECRIT'" > > cc > > > > Subject > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > ECRIT WG > > Here is a update to a ID I think is pretty near done, given that this > is merely an IANA registration ID of an existing mechanism. > > Comments are wanted > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Emergency Context Resolution with > >Internet Technologies Working Group of the IETF. > > > > > > Title : IANA Registering a SIP Resource Priority > > Header Namespace for Local Emergency Communications > > Author(s) : J. Polk > > Filename : > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > Pages : 9 > > Date : 2008-10-27 > > > >This document creates and IANA registers the new Session Initiation > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > >local emergency usage to a public safety answering point (PSAP), > >between PSAPs, and between a PSAP and first responders and their > >organizations. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > emergency-rph-namespace-00.txt > > > > > > > > emergency-rph-namespace-00.txt> > > _______________________________________________ > 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 > > > Stuart Goldman > Alcatel-Lucent > Stuart.Goldman@alcatel-lucent.com > +1 602 493 8438 > +1 480 414 1260 mobile > P please save a tree by not printing this e-mail. > > > --=_alternative 0057E11A85257507_= Content-Type: text/html; charset="US-ASCII"
Stu,

I intended to say that the esnet namespace needs to be at a LOWER priority  than the ets and wps namespaces, in any network that recognizes ets and wps as described in 10.5 and 10.6 of RFC4412.

Janet

"GOLDMAN, STUART O \(STUART\)" <sgoldman@alcatel-lucent.com> wrote on 11/20/2008 10:22:49 AM:

> Janet,
>  
> With regard to you e-mail below, did you intend that esnet could be
> at the same level of priority as ETS & WPS,  or that ETS & WPS need
> to be at an even higher priority than esnet?
>  
>  
>  
> Stuart Goldman
> Alcatel-Lucent
> Stuart.Goldman@alcatel-lucent.com
> +1 602 493 8438
> +1 480 414 1260 mobile
> P please save a tree by not printing this e-mail.
>  
>  
>  
>
> Janet P Gunn/FED/CSC@CSC
> Sent by: ecrit-bounces@ietf.org
> 10/27/2008 11:45 PM
>
>  
>
> To
>
> "James M. Polk" <jmpolk@cisco.com>
>
> cc
>
> "'ECRIT'" <ecrit@ietf.org>, ecrit-bounces@ietf.org
>
> Subject
>
> Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
>
>
>  
>  
>
>  
>
>  
>
>
>
>
>
>
> I apologize for not tracking this as closely as I meant to, as these
> comments apply to  earlier versions as well.
>
>
> This sentence at the end of sec 1 doesn't quite work.
> "This document IANA registers the "esnet"
>  RPH namespace for use within emergency services networks, not just
>  of those from citizens to PSAPs." (no clear antecedent for "those")
>
> Perhaps
> "This document IANA registers the "esnet"
>  RPH namespace for use within emergency services networks, not just
> for calls or sessions
>   from citizens to PSAPs."
>
> Section 2 says
> "This document updates the behaviors of the SIP Resource Priority
>  header, defined in [RFC4412], during the treatment options
>  surrounding this new "esnet" namespace only. The usage of the
>  "esnet" namespace does not have a normal, or routine call level.  
>  Every use of this namespace will be in times of an emergency, where
>  at least one end of the signaling is with a local emergency
>  organization."
>
> I don't see this as an "update of the behavior of 4412".  Neither
> the ets namespace not the wps
> namespace have a "normal" or "routine" call level.  Every use of the
> wps and ets namespaces will
> have priority over calls without RPH.
>
> You say "This
>  namespace, therefore, MAY be overwritten or deleted, contrary to the
>  rules of RFC 4412 [RFC4412]."
>
> It is not clear to me why this is "contrary to the rules of 4412".  
> It is certainly anticipated
> that other RPH will be overwritten or deleted, when the UAS
> understands the namespace.
>
> 4412 says "Existing implementations of RFC 3261 that do not participate in the
>  resource priority mechanism follow the normal rules of RFC 3261,
>  Section 8.2.2: "If a UAS does not understand a header field in a
>  request (that is, the header field is not defined in this
>  specification or in any supported extension), the server MUST ignore
>  that header field and continue processing the message". "
>
> But I do not see anywhere that is says that a UAS that DOES
> understand the namespace is
> forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says
> that "the UAC
>  MAY attempt a subsequent request with the same or different resource
>  value."  This certainly implies the ability to overwrite or delete
> an RPH namespace.  
>
> (See also, for instance the PTSC SAC document on the use of the ets
> and wps namespaces)
>
> Immediately following these statements, you give 3 options-
> "These proxies in the service provider
>  MAY either
>
>  o  accept the existing RPH value with "esnet" in it, if one is
>     present, and grant relative preferential treatment to the request
>     when forwarding it to the ESINet.
>
>  o  replace any existing RPH value, if one is present, and insert an
>     "esnet" namespace and give relative preferential treatment to the
>     request when forwarding it to the ESINet.
>
>  o  insert an "esnet" namespace in a new RPH and give relative
>     preferential treatment to the request when forwarding the SIP
>     request towards the ESINet."
>
> Why do you exclude the possibility of adding the esnet RPH value
> without "replacing" an existing RPH value?
>
> Finally, there is another point that  needs to be made clear.  At
> least one person has contacted me expressing concern that this ID
> implied that the esnet namespace would  have priority over other
> namespaces (in particular wps and ets).  I assured him that this was
> not the case, that there was nothing prevent the expected behavior -
> that the ets and wps namespaces would be prioritized ahead of esnet
> in GETS Service Provider networks.
>
> However, since the question has already arisen, it would be a good
> idea to clarify  this, perhaps in  section 3, where you discuss  the
> other namespaces.  In particular, it needs to be made clear in
> section 3.2  that, even if  "the   local jurisdiction preferred to
> preempt normal calls in lieu of
>  completing emergency calls. ", esnet calls will NOT preempt wps or ets calls.
>
> By the way, I think you mean "the   local jurisdiction preferred to
> preempt normal calls in order to complete emergency calls. "  - not
> "in lieu of".  Or perhaps "the   local jurisdiction preferred to
> preempt normal calls in lieu of  dropping emergency calls. "
>
> In fact, it is not clear to me that 4412 permits a call with an RPH
> (e.g., esnet)  to preempt a "normal" call (with no RPH namespace).  
> Section 4.7.2.1 of 4412 says
> "4.7.2.1.  User Agent Servers and Preemption Algorithm
>
>  A UAS compliant with this specification MUST terminate a session
>  established with a valid namespace and lower-priority value in favor
>  of a new session set up with a valid namespace and higher relative
>  priority value, unless local policy has some form of call-waiting
>  capability enabled. "
>
> It doesn't say anything about preempting a call with no RPH
>
> Thanks
>
> Janet
>
>
>
>
>
>
> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind
> CSC to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the
> use of e-mail for such purpose.
>
> "James M. Polk" <jmpolk@cisco.com>
> Sent by: ecrit-bounces@ietf.org
> 10/27/2008 08:32 PM
>
>  
>  
>
> To
>
> "'ECRIT'" <ecrit@ietf.org>
>
> cc
>
>  
>
> Subject
>
> [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
>
>
>  
>  
>
>  
>
>  
>
>
>
>
>
>
> ECRIT WG
>
> Here is a update to a ID I think is pretty near done, given that this
> is merely an IANA registration ID of an existing mechanism.
>
> Comments are wanted
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Emergency Context Resolution with
> >Internet Technologies Working Group of the IETF.
> >
> >
> >         Title           : IANA Registering a SIP Resource Priority
> > Header Namespace for Local Emergency Communications
> >         Author(s)       : J. Polk
> >         Filename        :
> > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
> >         Pages           : 9
> >         Date            : 2008-10-27
> >
> >This document creates and IANA registers the new Session Initiation
> >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
> >local emergency usage to a public safety answering point (PSAP),
> >between PSAPs, and between a PSAP and first responders and their
> >organizations.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt
> >
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-namespace-00.txt>
>
> _______________________________________________
> 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
>  
>  
> Stuart Goldman
> Alcatel-Lucent
> Stuart.Goldman@alcatel-lucent.com
> +1 602 493 8438
> +1 480 414 1260 mobile
> P please save a tree by not printing this e-mail.
>  
>  
>   --=_alternative 0057E11A85257507_=-- --===============1840743966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1840743966==-- From ecrit-bounces@ietf.org Thu Nov 20 08:11:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3F53A698C; Thu, 20 Nov 2008 08:11:14 -0800 (PST) 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 8CB5E3A698C for ; Thu, 20 Nov 2008 08:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iYc4SMoHbecq for ; Thu, 20 Nov 2008 08:11:12 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C313B3A6943 for ; Thu, 20 Nov 2008 08:11:11 -0800 (PST) Received: from [128.89.255.106] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3C7T-0005Bd-Af; Thu, 20 Nov 2008 11:11:03 -0500 Message-ID: <49258C15.2070303@bbn.com> Date: Thu, 20 Nov 2008 10:11:01 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Brian Rosen References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> In-Reply-To: <011b01c94b24$d8d78a80$8a869f80$@net> Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The IETF can't (and shouldn't) try to make particular standards for every access technology that's out there. What we can say is that the paradigm for those protocols should be the same as at the IP layer: Clients MUST implement all, networks MUST implement at least one. (This is a little different from the text I sent before, and clearer, I think.) All I'm saying is that we shouldn't try to enumerate all the possible protocols at lower layers, we should just state the general rule. It seems to me that this achieves the same level of interoperability at all layers. --Richard > If there are exactly two LCPs all UAs must implement, and any number of > optional ones, then every network has to implement at least one of those two > LCPs, and any number of optional ones. That means that "any number of > optional ones" is useless for both parties. > If the network can limit UAs to ONLY those that implement one of the > optional protocols, then it works, but in practice, it is usually impossible > to do that. My example is the wired, Ethernet connected phone in an RV > traveling down the road with wireless data card in a router. These EXIST, > now. > > Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 10:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; > marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > I think we need to pull up a level. It's not reasonable for an RFC to > try to list all of the location protocols out there, if for no other > reason than that it will rapidly become obsolete. Instead, we should > say something like the following: > > " > INT-12 Devices MUST support the DHCP location options [RFC4776] and > [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices > SHOULD support all location protocols supported at lower layers by their > interfaces (e.g., LLDP-MED [LLDP-MED]). > " > > > > > Brian Rosen wrote: >> The problem with SUPL is that the majority of networks where SUPL would be >> available have a proxy (E-CSCF) insert location. It also has an >> incompatible location representation, and an incompatible privacy model. >> That makes it very hard to interwork with any of the rest of the IETF > work. >> I will say this. For quite some time, the IETF has been trying to > interest >> OMA into cooperation on location so that we have interoperability at the >> protocol, location representation and privacy levels. So far, that has > not >> happened. If, as part of a comprehensive agreement to accomplish such a >> goal, SUPL became one of the LCPs, I would not object. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Gabor.Bajko@nokia.com >> Sent: Thursday, November 20, 2008 9:26 AM >> To: James.Winterbottom@andrew.com; ecrit@ietf.org >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> Hi, >> >> Is the intent to list the LCPs which are access-type agnostic but not >> supported anywhere, or instead have a list of LCPs which are highly >> probable to produce the intended result? >> >> There are restrictions everywhere, things come at a cost even in the >> general Internet model. The reality is that most of the devices with >> internet access have a home network already. >> >> - Gabor >> >> >> >-----Original Message----- >> >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> >Sent: Thursday, November 20, 2008 12:06 AM >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >> > >> >Hi Gabor, >> > >> >The list of LCPs in the phone BCP is a must support list, and is >> access- >> >type agnostic. >> >I am curious that you say that SUPL is a MUST support given that: >> >a) it requires a home network in order to operate >> >b) it simply doesn't work for DSL or Cable >> >c) it is questionable whether it is really deployable for WiFi >> networks >> > >> >Can you perhaps describe how it fits into the general Internet model? >> > >> >Cheers >> >James >> > >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >> >Sent: Thu 11/20/2008 12:48 AM >> >To: ecrit@ietf.org >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >> > >> >I was requested to send my observations regarding this requirement: >> > >> > ED-21/INT-12 Devices MUST support all of: DHCP location options >> > [RFC4776] and [RFC3825], HELD >> > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. >> > >> > >> >I believe we should come up with a list of LCPs which are likely to >> be >> >supported in devices in a not so distant future. Since I have no seen >> or >> >heard about LLDP support yet, at least that should be replaced with >> what >> >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >> >condition that this MUST only be supported if there is a wifi >> interface >> >available on the device. >> > >> >- Gabor >> > >> > >> > >> >________________________________ >> > >> >From: ext Tschofenig, Hannes >> > >> >Sent: Tuesday, November 18, 2008 12:49 PM >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >> >Subject: Location Protocols in Phone BCP >> > >> > >> > >> >Gabor, >> > >> >Could you please raise your question about location protocols in >> Phone >> >BCP mentioned at ESW5 in the ECRIT WG session again? >> > >> >Ciao >> >Hannes >> > >> > >> >>> ----------------------------------------------------------------------- >> -- >> >----------------------- >> >This message is for the designated recipient only and may >> >contain privileged, proprietary, or otherwise private information. >> >If you have received it in error, please notify the sender >> >immediately and delete the original. Any unauthorized use of >> >this email is prohibited. >> >>> ----------------------------------------------------------------------- >> -- >> >----------------------- >> >[mf2] >> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Thu Nov 20 08:16:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6FC3A698C; Thu, 20 Nov 2008 08:16:47 -0800 (PST) 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 ACAE63A698C for ; Thu, 20 Nov 2008 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wA4ee79t8Ur5 for ; Thu, 20 Nov 2008 08:16:44 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3BB143A6980 for ; Thu, 20 Nov 2008 08:16:44 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3CCr-00011D-FX; Thu, 20 Nov 2008 10:16:37 -0600 From: "Brian Rosen" To: "'Janet P Gunn'" , "'GOLDMAN, STUART O \(STUART\)'" References: <7D096A439A3D0D48A3D10872022CFD090359D22F@ILEXC1U02.ndc.lucent.com> In-Reply-To: Date: Thu, 20 Nov 2008 11:16:39 -0500 Message-ID: <015301c94b2b$60155ee0$20401ca0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKUkpF0vf9MMORIuko725aI68oAAASrzQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org A suggestion was made to me that we should define two namespaces. One would be used in public networks, and generally would be used to request resource priority for citizen to authority and possibly authority to citizen calls. This would have lower priority than ETS/WPS. The other would be for use within emergency services IP networks. It would be unlikely that ETS/WPS would be used within those networks, but if it was, some values within the namespace would need higher priority that ETS/WPS. For example, a message which was an incident commanders =93evacuate=94 mess= age would be higher than a ETS/WPS traffic. On the other hand, a citizen to authority emergency call would have lower priority. I would be happier with one namespace and more values in that namespace for all of this, but I was advised that two namespaces was a better choice. Brian From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Thursday, November 20, 2008 11:00 AM To: GOLDMAN, STUART O (STUART) Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 Stu, = I intended to say that the esnet namespace needs to be at a LOWER priority =A0than the ets and wps namespaces, in any network that recognizes ets and = wps as described in 10.5 and 10.6 of RFC4412. = Janet = "GOLDMAN, STUART O \(STUART\)" wrote on 11/20/2008 10:22:49 AM: > Janet, = > =A0 = > With regard to you e-mail below, did you intend that esnet could be = > at the same level of priority as ETS & WPS, =A0or that ETS & WPS need = > to be at an even higher priority than esnet? = > =A0 = > =A0 = > =A0 = > Stuart Goldman = > Alcatel-Lucent = > Stuart.Goldman@alcatel-lucent.com = > +1 602 493 8438 = > +1 480 414 1260 mobile = > P please save a tree by not printing this e-mail. = > =A0 = > =A0 = > =A0 = > = > Janet P Gunn/FED/CSC@CSC = > Sent by: ecrit-bounces@ietf.org = > 10/27/2008 11:45 PM = > = > =A0 = > = > To = > = > "James M. Polk" = > = > cc = > = > "'ECRIT'" , ecrit-bounces@ietf.org = > = > Subject = > = > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 = > = > = > =A0 = > =A0 = > = > =A0 = > = > =A0 = > = > = > = > = > = > = > I apologize for not tracking this as closely as I meant to, as these > comments apply to =A0earlier versions as well. = > = > = > This sentence at the end of sec 1 doesn't quite work. = > "This document IANA registers the "esnet" = > =A0RPH namespace for use within emergency services networks, not just = > =A0of those from citizens to PSAPs." (no clear antecedent for "those") = > = > Perhaps = > "This document IANA registers the "esnet" = > =A0RPH namespace for use within emergency services networks, not just = > for calls or sessions = > =A0 from citizens to PSAPs." = > = > Section 2 says = > "This document updates the behaviors of the SIP Resource Priority = > =A0header, defined in [RFC4412], during the treatment options = > =A0surrounding this new "esnet" namespace only. The usage of the = > =A0"esnet" namespace does not have a normal, or routine call level. =A0 = > =A0Every use of this namespace will be in times of an emergency, where = > =A0at least one end of the signaling is with a local emergency = > =A0organization." = > = > I don't see this as an "update of the behavior of 4412". =A0Neither = > the ets namespace not the wps = > namespace have a "normal" or "routine" call level. =A0Every use of the > wps and ets namespaces will = > have priority over calls without RPH. = > = > You say "This = > =A0namespace, therefore, MAY be overwritten or deleted, contrary to the = > =A0rules of RFC 4412 [RFC4412]." = > = > It is not clear to me why this is "contrary to the rules of 4412". =A0 > It is certainly anticipated = > that other RPH will be overwritten or deleted, when the UAS = > understands the namespace. = > = > 4412 says "Existing implementations of RFC 3261 that do not participate in the > =A0resource priority mechanism follow the normal rules of RFC 3261, = > =A0Section 8.2.2: "If a UAS does not understand a header field in a = > =A0request (that is, the header field is not defined in this = > =A0specification or in any supported extension), the server MUST ignore = > =A0that header field and continue processing the message". " = > = > But I do not see anywhere that is says that a UAS that DOES = > understand the namespace is = > forbidden from deleting it. =A0For instance, sec 4.7.1 of 4412 says = > that "the UAC = > =A0MAY attempt a subsequent request with the same or different resource = > =A0value." =A0This certainly implies the ability to overwrite or delete = > an RPH namespace. =A0 = > = > (See also, for instance the PTSC SAC document on the use of the ets = > and wps namespaces) = > = > Immediately following these statements, you give 3 options- = > "These proxies in the service provider = > =A0MAY either = > = > =A0o =A0accept the existing RPH value with "esnet" in it, if one is = > =A0 =A0 present, and grant relative preferential treatment to the request = > =A0 =A0 when forwarding it to the ESINet. = > = > =A0o =A0replace any existing RPH value, if one is present, and insert an = > =A0 =A0 "esnet" namespace and give relative preferential treatment to the = > =A0 =A0 request when forwarding it to the ESINet. = > = > =A0o =A0insert an "esnet" namespace in a new RPH and give relative = > =A0 =A0 preferential treatment to the request when forwarding the SIP = > =A0 =A0 request towards the ESINet." = > = > Why do you exclude the possibility of adding the esnet RPH value = > without "replacing" an existing RPH value? = > = > Finally, there is another point that =A0needs to be made clear. =A0At = > least one person has contacted me expressing concern that this ID = > implied that the esnet namespace would =A0have priority over other = > namespaces (in particular wps and ets). =A0I assured him that this was > not the case, that there was nothing prevent the expected behavior - > that the ets and wps namespaces would be prioritized ahead of esnet = > in GETS Service Provider networks. = > = > However, since the question has already arisen, it would be a good = > idea to clarify =A0this, perhaps in =A0section 3, where you discuss =A0the > other namespaces. =A0In particular, it needs to be made clear in = > section 3.2 =A0that, even if =A0"the =A0 local jurisdiction preferred to = > preempt normal calls in lieu of = > =A0completing emergency calls. ", esnet calls will NOT preempt wps or ets calls. > = > By the way, I think you mean "the =A0 local jurisdiction preferred to = > preempt normal calls in order to complete emergency calls. " =A0- not = > "in lieu of". =A0Or perhaps "the =A0 local jurisdiction preferred to = > preempt normal calls in lieu of =A0dropping emergency calls. " = > = > In fact, it is not clear to me that 4412 permits a call with an RPH = > (e.g., esnet) =A0to preempt a "normal" call (with no RPH namespace). =A0 > Section 4.7.2.1 of 4412 says = > "4.7.2.1. =A0User Agent Servers and Preemption Algorithm = > = > =A0A UAS compliant with this specification MUST terminate a session = > =A0established with a valid namespace and lower-priority value in favor = > =A0of a new session set up with a valid namespace and higher relative = > =A0priority value, unless local policy has some form of call-waiting = > =A0capability enabled. " = > = > It doesn't say anything about preempting a call with no RPH = > = > Thanks = > = > Janet = > = > = > = > = > = > = > This is a PRIVATE message. If you are not the intended recipient, = > please delete without copying and kindly advise us by e-mail of the = > mistake in delivery. = > NOTE: Regardless of content, this e-mail shall not operate to bind = > CSC to any order or other contract unless pursuant to explicit = > written agreement or government initiative expressly permitting the = > use of e-mail for such purpose. = > = > "James M. Polk" = > Sent by: ecrit-bounces@ietf.org = > 10/27/2008 08:32 PM = > = > =A0 = > =A0 = > = > To = > = > "'ECRIT'" = > = > cc = > = > =A0 = > = > Subject = > = > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 = > = > = > =A0 = > =A0 = > = > =A0 = > = > =A0 = > = > = > = > = > = > = > ECRIT WG > = > Here is a update to a ID I think is pretty near done, given that this = > is merely an IANA registration ID of an existing mechanism. > = > Comments are wanted > = > >A New Internet-Draft is available from the on-line Internet-Drafts = > >directories. > >This draft is a work item of the Emergency Context Resolution with = > >Internet Technologies Working Group of the IETF. > > > > > > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : IANA Registering a SIP Reso= urce Priority = > > Header Namespace for Local Emergency Communications > > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Polk > > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: = > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 > > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2008-10-27 > > > >This document creates and IANA registers the new Session Initiation > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > >local emergency usage to a public safety answering point (PSAP), > >between PSAPs, and between a PSAP and first responders and their > >organizations. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > emergency-rph-namespace-00.txt > > > > > > > > emergency-rph-namespace-00.txt> > = > _______________________________________________ > 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 = > =A0 = > =A0 = > Stuart Goldman = > Alcatel-Lucent = > Stuart.Goldman@alcatel-lucent.com = > +1 602 493 8438 = > +1 480 414 1260 mobile = > P please save a tree by not printing this e-mail. = > =A0 = > =A0 = > =A0 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 08:22:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B3A28C1D0; Thu, 20 Nov 2008 08:22:48 -0800 (PST) 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 0C5D628C1D0 for ; Thu, 20 Nov 2008 08:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NQOeatAsqlre for ; Thu, 20 Nov 2008 08:22:45 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A362028C1BB for ; Thu, 20 Nov 2008 08:22:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3CIg-0001by-9T; Thu, 20 Nov 2008 10:22:39 -0600 From: "Brian Rosen" To: "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> In-Reply-To: <49258C15.2070303@bbn.com> Date: Thu, 20 Nov 2008 11:22:40 -0500 Message-ID: <015401c94b2c$374c6ed0$a5e54c70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's very hard to have L2 specific LCPs. The problem is that the clients are generally not very L2 aware. It's the clients that have the problem. You can do things like interwork an L2 specific LCP to a common LCP so that non L2 aware devices can work, but you have to do that, and usually, that's impractical. Use my example. Suppose that the L2 used SUPL. It's possible for the PC Card that is plugged into the router could implement a SUPL client and a HELD server and interwork SUPL in the GSM system to HELD on the Ethernet so the Ethernet VoIP phone could get location via HELD. Possible, but not practical. There are all sorts of these kinds of problems. That's why L2 specific LCPs don't work. Brian -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Thursday, November 20, 2008 11:11 AM To: Brian Rosen Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP The IETF can't (and shouldn't) try to make particular standards for every access technology that's out there. What we can say is that the paradigm for those protocols should be the same as at the IP layer: Clients MUST implement all, networks MUST implement at least one. (This is a little different from the text I sent before, and clearer, I think.) All I'm saying is that we shouldn't try to enumerate all the possible protocols at lower layers, we should just state the general rule. It seems to me that this achieves the same level of interoperability at all layers. --Richard > If there are exactly two LCPs all UAs must implement, and any number of > optional ones, then every network has to implement at least one of those two > LCPs, and any number of optional ones. That means that "any number of > optional ones" is useless for both parties. > If the network can limit UAs to ONLY those that implement one of the > optional protocols, then it works, but in practice, it is usually impossible > to do that. My example is the wired, Ethernet connected phone in an RV > traveling down the road with wireless data card in a router. These EXIST, > now. > > Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 10:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; > marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > I think we need to pull up a level. It's not reasonable for an RFC to > try to list all of the location protocols out there, if for no other > reason than that it will rapidly become obsolete. Instead, we should > say something like the following: > > " > INT-12 Devices MUST support the DHCP location options [RFC4776] and > [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices > SHOULD support all location protocols supported at lower layers by their > interfaces (e.g., LLDP-MED [LLDP-MED]). > " > > > > > Brian Rosen wrote: >> The problem with SUPL is that the majority of networks where SUPL would be >> available have a proxy (E-CSCF) insert location. It also has an >> incompatible location representation, and an incompatible privacy model. >> That makes it very hard to interwork with any of the rest of the IETF > work. >> I will say this. For quite some time, the IETF has been trying to > interest >> OMA into cooperation on location so that we have interoperability at the >> protocol, location representation and privacy levels. So far, that has > not >> happened. If, as part of a comprehensive agreement to accomplish such a >> goal, SUPL became one of the LCPs, I would not object. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Gabor.Bajko@nokia.com >> Sent: Thursday, November 20, 2008 9:26 AM >> To: James.Winterbottom@andrew.com; ecrit@ietf.org >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> Hi, >> >> Is the intent to list the LCPs which are access-type agnostic but not >> supported anywhere, or instead have a list of LCPs which are highly >> probable to produce the intended result? >> >> There are restrictions everywhere, things come at a cost even in the >> general Internet model. The reality is that most of the devices with >> internet access have a home network already. >> >> - Gabor >> >> >> >-----Original Message----- >> >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> >Sent: Thursday, November 20, 2008 12:06 AM >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >> > >> >Hi Gabor, >> > >> >The list of LCPs in the phone BCP is a must support list, and is >> access- >> >type agnostic. >> >I am curious that you say that SUPL is a MUST support given that: >> >a) it requires a home network in order to operate >> >b) it simply doesn't work for DSL or Cable >> >c) it is questionable whether it is really deployable for WiFi >> networks >> > >> >Can you perhaps describe how it fits into the general Internet model? >> > >> >Cheers >> >James >> > >> > >> >-----Original Message----- >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >> >Sent: Thu 11/20/2008 12:48 AM >> >To: ecrit@ietf.org >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >> > >> >I was requested to send my observations regarding this requirement: >> > >> > ED-21/INT-12 Devices MUST support all of: DHCP location options >> > [RFC4776] and [RFC3825], HELD >> > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. >> > >> > >> >I believe we should come up with a list of LCPs which are likely to >> be >> >supported in devices in a not so distant future. Since I have no seen >> or >> >heard about LLDP support yet, at least that should be replaced with >> what >> >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >> >condition that this MUST only be supported if there is a wifi >> interface >> >available on the device. >> > >> >- Gabor >> > >> > >> > >> >________________________________ >> > >> >From: ext Tschofenig, Hannes >> > >> >Sent: Tuesday, November 18, 2008 12:49 PM >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >> >Subject: Location Protocols in Phone BCP >> > >> > >> > >> >Gabor, >> > >> >Could you please raise your question about location protocols in >> Phone >> >BCP mentioned at ESW5 in the ECRIT WG session again? >> > >> >Ciao >> >Hannes >> > >> > >> >>> ----------------------------------------------------------------------- >> -- >> >----------------------- >> >This message is for the designated recipient only and may >> >contain privileged, proprietary, or otherwise private information. >> >If you have received it in error, please notify the sender >> >immediately and delete the original. Any unauthorized use of >> >this email is prohibited. >> >>> ----------------------------------------------------------------------- >> -- >> >----------------------- >> >[mf2] >> >> _______________________________________________ >> 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 ecrit-bounces@ietf.org Thu Nov 20 08:37:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249E43A68BE; Thu, 20 Nov 2008 08:37:31 -0800 (PST) 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 93D4C28C1CD for ; Thu, 20 Nov 2008 08:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RyHC5BHThso for ; Thu, 20 Nov 2008 08:37:27 -0800 (PST) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with ESMTP id 64C683A67FA for ; Thu, 20 Nov 2008 08:37:27 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-87.messagelabs.com!1227199043!41863287!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 3614 invoked from network); 20 Nov 2008 16:37:23 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 16:37:23 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAKGbMoH022229 for ; Thu, 20 Nov 2008 11:37:22 -0500 In-Reply-To: <015301c94b2b$60155ee0$20401ca0$@net> To: "Brian Rosen" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 20 Nov 2008 11:37:15 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/20/2008 11:39:53 AM, Serialize complete at 11/20/2008 11:39:53 AM Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============1998818205==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1998818205== Content-Type: multipart/alternative; boundary="=_alternative 005B4B4785257507_=" This is a multipart message in MIME format. --=_alternative 005B4B4785257507_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNCkkgbmVlZCB0byB1bmRlcnN0YW5kIHRoaXMgYmV0dGVyLg0KDQpFeGFjdGx5IHdo YXQgYXJlIHRoZSBjb25zdHJhaW50cyBvZiB0aGUgImVtZXJnZW5jeSBzZXJ2aWNlcyBJUCBuZXR3 b3JrIj8gDQpJcyB0aGlzIGEgbmV0d29yayBpbiB3aGljaCBFVkVSWSBjYWxsIHdvdWxkIGhhdmUg dGhlIFJQSCB3aXRoIHRoZSAgZXNuZXQgDQpuYW1lc3BhY2UgKGp1c3QgdmFyeWluZyBwcmlvcml0 eSB2YWx1ZXMpLGFuZCB0aGVyZSB3b3VsZCBiZSBubyAibm9ybWFsIiANCmNhbGxzPyAgT3Igd291 bGQgdGhlaXIgYmUgYSBtaXh0dXJlIG9mIGNhbGxzIHdpdGggYW5kIHdpdGhvdXQgUlBIIHdpdCAN CmVzbmV0Pw0KDQpKYW5ldA0KDQoiQnJpYW4gUm9zZW4iIDxickBicmlhbnJvc2VuLm5ldD4gd3Jv dGUgb24gMTEvMjAvMjAwOCAxMToxNjozOSBBTToNCg0KPiBBIHN1Z2dlc3Rpb24gd2FzIG1hZGUg dG8gbWUgdGhhdCB3ZSBzaG91bGQgZGVmaW5lIHR3byBuYW1lc3BhY2VzLg0KPiANCj4gT25lIHdv dWxkIGJlIHVzZWQgaW4gcHVibGljIG5ldHdvcmtzLCBhbmQgZ2VuZXJhbGx5IHdvdWxkIGJlIHVz ZWQgdG8gDQpyZXF1ZXN0DQo+IHJlc291cmNlIHByaW9yaXR5IGZvciBjaXRpemVuIHRvIGF1dGhv cml0eSBhbmQgcG9zc2libHkgYXV0aG9yaXR5IHRvIA0KY2l0aXplbg0KPiBjYWxscy4gIFRoaXMg d291bGQgaGF2ZSBsb3dlciBwcmlvcml0eSB0aGFuIEVUUy9XUFMuDQo+IA0KPiBUaGUgb3RoZXIg d291bGQgYmUgZm9yIHVzZSB3aXRoaW4gZW1lcmdlbmN5IHNlcnZpY2VzIElQIG5ldHdvcmtzLiAg SXQgDQp3b3VsZA0KPiBiZSB1bmxpa2VseSB0aGF0IEVUUy9XUFMgd291bGQgYmUgdXNlZCB3aXRo aW4gdGhvc2UgbmV0d29ya3MsIGJ1dCBpZiBpdCANCndhcywNCj4gc29tZSB2YWx1ZXMgd2l0aGlu IHRoZSBuYW1lc3BhY2Ugd291bGQgbmVlZCBoaWdoZXIgcHJpb3JpdHkgdGhhdCANCkVUUy9XUFMu DQo+IEZvciBleGFtcGxlLCBhIG1lc3NhZ2Ugd2hpY2ggd2FzIGFuIGluY2lkZW50IGNvbW1hbmRl cnMg4oCcZXZhY3VhdGXigJ0gDQptZXNzYWdlDQo+IHdvdWxkIGJlIGhpZ2hlciB0aGFuIGEgRVRT L1dQUyB0cmFmZmljLiAgT24gdGhlIG90aGVyIGhhbmQsIGEgY2l0aXplbiB0bw0KPiBhdXRob3Jp dHkgZW1lcmdlbmN5IGNhbGwgd291bGQgaGF2ZSBsb3dlciBwcmlvcml0eS4NCj4gDQo+IEkgd291 bGQgYmUgaGFwcGllciB3aXRoIG9uZSBuYW1lc3BhY2UgYW5kIG1vcmUgdmFsdWVzIGluIHRoYXQg bmFtZXNwYWNlIA0KZm9yDQo+IGFsbCBvZiB0aGlzLCBidXQgSSB3YXMgYWR2aXNlZCB0aGF0IHR3 byBuYW1lc3BhY2VzIHdhcyBhIGJldHRlciBjaG9pY2UuDQo+IA0KPiBCcmlhbg0KPiANCj4gRnJv bTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiANCk9mDQo+IEphbmV0IFAgR3Vubg0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1i ZXIgMjAsIDIwMDggMTE6MDAgQU0NCj4gVG86IEdPTERNQU4sIFNUVUFSVCBPIChTVFVBUlQpDQo+ IENjOiBFY3JpdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBFY3JpdF0NCj4gZHJh ZnQtaWV0Zi1lY3JpdC1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZS0wMA0KPiANCj4gDQo+ IFN0dSwgDQo+IA0KPiBJIGludGVuZGVkIHRvIHNheSB0aGF0IHRoZSBlc25ldCBuYW1lc3BhY2Ug bmVlZHMgdG8gYmUgYXQgYSBMT1dFUiANCnByaW9yaXR5DQo+ICB0aGFuIHRoZSBldHMgYW5kIHdw cyBuYW1lc3BhY2VzLCBpbiBhbnkgbmV0d29yayB0aGF0IHJlY29nbml6ZXMgZXRzIGFuZCANCndw cw0KPiBhcyBkZXNjcmliZWQgaW4gMTAuNSBhbmQgMTAuNiBvZiBSRkM0NDEyLiANCj4gDQo+IEph bmV0IA0KPiANCj4gIkdPTERNQU4sIFNUVUFSVCBPIFwoU1RVQVJUXCkiIDxzZ29sZG1hbkBhbGNh dGVsLWx1Y2VudC5jb20+IHdyb3RlIG9uDQo+IDExLzIwLzIwMDggMTA6MjI6NDkgQU06DQo+IA0K PiA+IEphbmV0LCANCj4gPiAgIA0KPiA+IFdpdGggcmVnYXJkIHRvIHlvdSBlLW1haWwgYmVsb3cs IGRpZCB5b3UgaW50ZW5kIHRoYXQgZXNuZXQgY291bGQgYmUgDQo+ID4gYXQgdGhlIHNhbWUgbGV2 ZWwgb2YgcHJpb3JpdHkgYXMgRVRTICYgV1BTLCAgb3IgdGhhdCBFVFMgJiBXUFMgbmVlZCANCj4g PiB0byBiZSBhdCBhbiBldmVuIGhpZ2hlciBwcmlvcml0eSB0aGFuIGVzbmV0PyANCj4gPiAgIA0K PiA+ICAgDQo+ID4gICANCj4gPiBTdHVhcnQgR29sZG1hbiANCj4gPiBBbGNhdGVsLUx1Y2VudCAN Cj4gPiBTdHVhcnQuR29sZG1hbkBhbGNhdGVsLWx1Y2VudC5jb20gDQo+ID4gKzEgNjAyIDQ5MyA4 NDM4IA0KPiA+ICsxIDQ4MCA0MTQgMTI2MCBtb2JpbGUgDQo+ID4gUCBwbGVhc2Ugc2F2ZSBhIHRy ZWUgYnkgbm90IHByaW50aW5nIHRoaXMgZS1tYWlsLiANCj4gPiAgIA0KPiA+ICAgDQo+ID4gICAN Cj4gPiANCj4gPiBKYW5ldCBQIEd1bm4vRkVEL0NTQ0BDU0MgDQo+ID4gU2VudCBieTogZWNyaXQt Ym91bmNlc0BpZXRmLm9yZyANCj4gPiAxMC8yNy8yMDA4IDExOjQ1IFBNIA0KPiA+IA0KPiA+ICAg DQo+ID4gDQo+ID4gVG8gDQo+ID4gDQo+ID4gIkphbWVzIE0uIFBvbGsiIDxqbXBvbGtAY2lzY28u Y29tPiANCj4gPiANCj4gPiBjYyANCj4gPiANCj4gPiAiJ0VDUklUJyIgPGVjcml0QGlldGYub3Jn PiwgZWNyaXQtYm91bmNlc0BpZXRmLm9yZyANCj4gPiANCj4gPiBTdWJqZWN0IA0KPiA+IA0KPiA+ IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcmdlbmN5LXJwaC1uYW1lc3Bh Y2UtMDAgDQo+ID4gDQo+ID4gDQo+ID4gICANCj4gPiAgIA0KPiA+IA0KPiA+ICAgDQo+ID4gDQo+ ID4gICANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBJIGFwb2xvZ2l6 ZSBmb3Igbm90IHRyYWNraW5nIHRoaXMgYXMgY2xvc2VseSBhcyBJIG1lYW50IHRvLCBhcyB0aGVz ZQ0KPiA+IGNvbW1lbnRzIGFwcGx5IHRvICBlYXJsaWVyIHZlcnNpb25zIGFzIHdlbGwuIA0KPiA+ IA0KPiA+IA0KPiA+IFRoaXMgc2VudGVuY2UgYXQgdGhlIGVuZCBvZiBzZWMgMSBkb2Vzbid0IHF1 aXRlIHdvcmsuIA0KPiA+ICJUaGlzIGRvY3VtZW50IElBTkEgcmVnaXN0ZXJzIHRoZSAiZXNuZXQi IA0KPiA+ICBSUEggbmFtZXNwYWNlIGZvciB1c2Ugd2l0aGluIGVtZXJnZW5jeSBzZXJ2aWNlcyBu ZXR3b3Jrcywgbm90IGp1c3QgDQo+ID4gIG9mIHRob3NlIGZyb20gY2l0aXplbnMgdG8gUFNBUHMu IiAobm8gY2xlYXIgYW50ZWNlZGVudCBmb3IgInRob3NlIikgDQo+ID4gDQo+ID4gUGVyaGFwcyAN Cj4gPiAiVGhpcyBkb2N1bWVudCBJQU5BIHJlZ2lzdGVycyB0aGUgImVzbmV0IiANCj4gPiAgUlBI IG5hbWVzcGFjZSBmb3IgdXNlIHdpdGhpbiBlbWVyZ2VuY3kgc2VydmljZXMgbmV0d29ya3MsIG5v dCBqdXN0IA0KPiA+IGZvciBjYWxscyBvciBzZXNzaW9ucyANCj4gPiAgIGZyb20gY2l0aXplbnMg dG8gUFNBUHMuIiANCj4gPiANCj4gPiBTZWN0aW9uIDIgc2F5cyANCj4gPiAiVGhpcyBkb2N1bWVu dCB1cGRhdGVzIHRoZSBiZWhhdmlvcnMgb2YgdGhlIFNJUCBSZXNvdXJjZSBQcmlvcml0eSANCj4g PiAgaGVhZGVyLCBkZWZpbmVkIGluIFtSRkM0NDEyXSwgZHVyaW5nIHRoZSB0cmVhdG1lbnQgb3B0 aW9ucyANCj4gPiAgc3Vycm91bmRpbmcgdGhpcyBuZXcgImVzbmV0IiBuYW1lc3BhY2Ugb25seS4g VGhlIHVzYWdlIG9mIHRoZSANCj4gPiAgImVzbmV0IiBuYW1lc3BhY2UgZG9lcyBub3QgaGF2ZSBh IG5vcm1hbCwgb3Igcm91dGluZSBjYWxsIGxldmVsLiAgIA0KPiA+ICBFdmVyeSB1c2Ugb2YgdGhp cyBuYW1lc3BhY2Ugd2lsbCBiZSBpbiB0aW1lcyBvZiBhbiBlbWVyZ2VuY3ksIHdoZXJlIA0KPiA+ ICBhdCBsZWFzdCBvbmUgZW5kIG9mIHRoZSBzaWduYWxpbmcgaXMgd2l0aCBhIGxvY2FsIGVtZXJn ZW5jeSANCj4gPiAgb3JnYW5pemF0aW9uLiIgDQo+ID4gDQo+ID4gSSBkb24ndCBzZWUgdGhpcyBh cyBhbiAidXBkYXRlIG9mIHRoZSBiZWhhdmlvciBvZiA0NDEyIi4gIE5laXRoZXIgDQo+ID4gdGhl IGV0cyBuYW1lc3BhY2Ugbm90IHRoZSB3cHMgDQo+ID4gbmFtZXNwYWNlIGhhdmUgYSAibm9ybWFs IiBvciAicm91dGluZSIgY2FsbCBsZXZlbC4gIEV2ZXJ5IHVzZSBvZiB0aGUNCj4gPiB3cHMgYW5k IGV0cyBuYW1lc3BhY2VzIHdpbGwgDQo+ID4gaGF2ZSBwcmlvcml0eSBvdmVyIGNhbGxzIHdpdGhv dXQgUlBILiANCj4gPiANCj4gPiBZb3Ugc2F5ICJUaGlzIA0KPiA+ICBuYW1lc3BhY2UsIHRoZXJl Zm9yZSwgTUFZIGJlIG92ZXJ3cml0dGVuIG9yIGRlbGV0ZWQsIGNvbnRyYXJ5IHRvIHRoZSANCj4g PiAgcnVsZXMgb2YgUkZDIDQ0MTIgW1JGQzQ0MTJdLiIgDQo+ID4gDQo+ID4gSXQgaXMgbm90IGNs ZWFyIHRvIG1lIHdoeSB0aGlzIGlzICJjb250cmFyeSB0byB0aGUgcnVsZXMgb2YgNDQxMiIuICAN Cj4gPiBJdCBpcyBjZXJ0YWlubHkgYW50aWNpcGF0ZWQgDQo+ID4gdGhhdCBvdGhlciBSUEggd2ls bCBiZSBvdmVyd3JpdHRlbiBvciBkZWxldGVkLCB3aGVuIHRoZSBVQVMgDQo+ID4gdW5kZXJzdGFu ZHMgdGhlIG5hbWVzcGFjZS4gDQo+ID4gDQo+ID4gNDQxMiBzYXlzICJFeGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgb2YgUkZDIDMyNjEgdGhhdCBkbyBub3QgDQpwYXJ0aWNpcGF0ZSBpbg0KPiB0aGUN Cj4gPiAgcmVzb3VyY2UgcHJpb3JpdHkgbWVjaGFuaXNtIGZvbGxvdyB0aGUgbm9ybWFsIHJ1bGVz IG9mIFJGQyAzMjYxLCANCj4gPiAgU2VjdGlvbiA4LjIuMjogIklmIGEgVUFTIGRvZXMgbm90IHVu ZGVyc3RhbmQgYSBoZWFkZXIgZmllbGQgaW4gYSANCj4gPiAgcmVxdWVzdCAodGhhdCBpcywgdGhl IGhlYWRlciBmaWVsZCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzIA0KPiA+ICBzcGVjaWZpY2F0aW9u IG9yIGluIGFueSBzdXBwb3J0ZWQgZXh0ZW5zaW9uKSwgdGhlIHNlcnZlciBNVVNUIGlnbm9yZSAN Cj4gPiAgdGhhdCBoZWFkZXIgZmllbGQgYW5kIGNvbnRpbnVlIHByb2Nlc3NpbmcgdGhlIG1lc3Nh Z2UiLiAiIA0KPiA+IA0KPiA+IEJ1dCBJIGRvIG5vdCBzZWUgYW55d2hlcmUgdGhhdCBpcyBzYXlz IHRoYXQgYSBVQVMgdGhhdCBET0VTIA0KPiA+IHVuZGVyc3RhbmQgdGhlIG5hbWVzcGFjZSBpcyAN Cj4gPiBmb3JiaWRkZW4gZnJvbSBkZWxldGluZyBpdC4gIEZvciBpbnN0YW5jZSwgc2VjIDQuNy4x IG9mIDQ0MTIgc2F5cyANCj4gPiB0aGF0ICJ0aGUgVUFDIA0KPiA+ICBNQVkgYXR0ZW1wdCBhIHN1 YnNlcXVlbnQgcmVxdWVzdCB3aXRoIHRoZSBzYW1lIG9yIGRpZmZlcmVudCByZXNvdXJjZSANCj4g PiAgdmFsdWUuIiAgVGhpcyBjZXJ0YWlubHkgaW1wbGllcyB0aGUgYWJpbGl0eSB0byBvdmVyd3Jp dGUgb3IgZGVsZXRlIA0KPiA+IGFuIFJQSCBuYW1lc3BhY2UuICAgDQo+ID4gDQo+ID4gKFNlZSBh bHNvLCBmb3IgaW5zdGFuY2UgdGhlIFBUU0MgU0FDIGRvY3VtZW50IG9uIHRoZSB1c2Ugb2YgdGhl IGV0cyANCj4gPiBhbmQgd3BzIG5hbWVzcGFjZXMpIA0KPiA+IA0KPiA+IEltbWVkaWF0ZWx5IGZv bGxvd2luZyB0aGVzZSBzdGF0ZW1lbnRzLCB5b3UgZ2l2ZSAzIG9wdGlvbnMtIA0KPiA+ICJUaGVz ZSBwcm94aWVzIGluIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIA0KPiA+ICBNQVkgZWl0aGVyIA0KPiA+ IA0KPiA+ICBvICBhY2NlcHQgdGhlIGV4aXN0aW5nIFJQSCB2YWx1ZSB3aXRoICJlc25ldCIgaW4g aXQsIGlmIG9uZSBpcyANCj4gPiAgICAgcHJlc2VudCwgYW5kIGdyYW50IHJlbGF0aXZlIHByZWZl cmVudGlhbCB0cmVhdG1lbnQgdG8gdGhlIHJlcXVlc3QgDQo+ID4gICAgIHdoZW4gZm9yd2FyZGlu ZyBpdCB0byB0aGUgRVNJTmV0LiANCj4gPiANCj4gPiAgbyAgcmVwbGFjZSBhbnkgZXhpc3Rpbmcg UlBIIHZhbHVlLCBpZiBvbmUgaXMgcHJlc2VudCwgYW5kIGluc2VydCBhbiANCj4gPiAgICAgImVz bmV0IiBuYW1lc3BhY2UgYW5kIGdpdmUgcmVsYXRpdmUgcHJlZmVyZW50aWFsIHRyZWF0bWVudCB0 byB0aGUgDQo+ID4gICAgIHJlcXVlc3Qgd2hlbiBmb3J3YXJkaW5nIGl0IHRvIHRoZSBFU0lOZXQu IA0KPiA+IA0KPiA+ICBvICBpbnNlcnQgYW4gImVzbmV0IiBuYW1lc3BhY2UgaW4gYSBuZXcgUlBI IGFuZCBnaXZlIHJlbGF0aXZlIA0KPiA+ICAgICBwcmVmZXJlbnRpYWwgdHJlYXRtZW50IHRvIHRo ZSByZXF1ZXN0IHdoZW4gZm9yd2FyZGluZyB0aGUgU0lQIA0KPiA+ICAgICByZXF1ZXN0IHRvd2Fy ZHMgdGhlIEVTSU5ldC4iIA0KPiA+IA0KPiA+IFdoeSBkbyB5b3UgZXhjbHVkZSB0aGUgcG9zc2li aWxpdHkgb2YgYWRkaW5nIHRoZSBlc25ldCBSUEggdmFsdWUgDQo+ID4gd2l0aG91dCAicmVwbGFj aW5nIiBhbiBleGlzdGluZyBSUEggdmFsdWU/IA0KPiA+IA0KPiA+IEZpbmFsbHksIHRoZXJlIGlz IGFub3RoZXIgcG9pbnQgdGhhdCAgbmVlZHMgdG8gYmUgbWFkZSBjbGVhci4gIEF0IA0KPiA+IGxl YXN0IG9uZSBwZXJzb24gaGFzIGNvbnRhY3RlZCBtZSBleHByZXNzaW5nIGNvbmNlcm4gdGhhdCB0 aGlzIElEIA0KPiA+IGltcGxpZWQgdGhhdCB0aGUgZXNuZXQgbmFtZXNwYWNlIHdvdWxkICBoYXZl IHByaW9yaXR5IG92ZXIgb3RoZXIgDQo+ID4gbmFtZXNwYWNlcyAoaW4gcGFydGljdWxhciB3cHMg YW5kIGV0cykuICBJIGFzc3VyZWQgaGltIHRoYXQgdGhpcyB3YXMNCj4gPiBub3QgdGhlIGNhc2Us IHRoYXQgdGhlcmUgd2FzIG5vdGhpbmcgcHJldmVudCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgLQ0K PiA+IHRoYXQgdGhlIGV0cyBhbmQgd3BzIG5hbWVzcGFjZXMgd291bGQgYmUgcHJpb3JpdGl6ZWQg YWhlYWQgb2YgZXNuZXQgDQo+ID4gaW4gR0VUUyBTZXJ2aWNlIFByb3ZpZGVyIG5ldHdvcmtzLiAN Cj4gPiANCj4gPiBIb3dldmVyLCBzaW5jZSB0aGUgcXVlc3Rpb24gaGFzIGFscmVhZHkgYXJpc2Vu LCBpdCB3b3VsZCBiZSBhIGdvb2QgDQo+ID4gaWRlYSB0byBjbGFyaWZ5ICB0aGlzLCBwZXJoYXBz IGluICBzZWN0aW9uIDMsIHdoZXJlIHlvdSBkaXNjdXNzICB0aGUNCj4gPiBvdGhlciBuYW1lc3Bh Y2VzLiAgSW4gcGFydGljdWxhciwgaXQgbmVlZHMgdG8gYmUgbWFkZSBjbGVhciBpbiANCj4gPiBz ZWN0aW9uIDMuMiAgdGhhdCwgZXZlbiBpZiAgInRoZSAgIGxvY2FsIGp1cmlzZGljdGlvbiBwcmVm ZXJyZWQgdG8gDQo+ID4gcHJlZW1wdCBub3JtYWwgY2FsbHMgaW4gbGlldSBvZiANCj4gPiAgY29t cGxldGluZyBlbWVyZ2VuY3kgY2FsbHMuICIsIGVzbmV0IGNhbGxzIHdpbGwgTk9UIHByZWVtcHQg d3BzIG9yIA0KZXRzDQo+IGNhbGxzLg0KPiA+IA0KPiA+IEJ5IHRoZSB3YXksIEkgdGhpbmsgeW91 IG1lYW4gInRoZSAgIGxvY2FsIGp1cmlzZGljdGlvbiBwcmVmZXJyZWQgdG8gDQo+ID4gcHJlZW1w dCBub3JtYWwgY2FsbHMgaW4gb3JkZXIgdG8gY29tcGxldGUgZW1lcmdlbmN5IGNhbGxzLiAiICAt IG5vdCANCj4gPiAiaW4gbGlldSBvZiIuICBPciBwZXJoYXBzICJ0aGUgICBsb2NhbCBqdXJpc2Rp Y3Rpb24gcHJlZmVycmVkIHRvIA0KPiA+IHByZWVtcHQgbm9ybWFsIGNhbGxzIGluIGxpZXUgb2Yg IGRyb3BwaW5nIGVtZXJnZW5jeSBjYWxscy4gIiANCj4gPiANCj4gPiBJbiBmYWN0LCBpdCBpcyBu b3QgY2xlYXIgdG8gbWUgdGhhdCA0NDEyIHBlcm1pdHMgYSBjYWxsIHdpdGggYW4gUlBIIA0KPiA+ IChlLmcuLCBlc25ldCkgIHRvIHByZWVtcHQgYSAibm9ybWFsIiBjYWxsICh3aXRoIG5vIFJQSCBu YW1lc3BhY2UpLiAgDQo+ID4gU2VjdGlvbiA0LjcuMi4xIG9mIDQ0MTIgc2F5cyANCj4gPiAiNC43 LjIuMS4gIFVzZXIgQWdlbnQgU2VydmVycyBhbmQgUHJlZW1wdGlvbiBBbGdvcml0aG0gDQo+ID4g DQo+ID4gIEEgVUFTIGNvbXBsaWFudCB3aXRoIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHRlcm1p bmF0ZSBhIHNlc3Npb24gDQo+ID4gIGVzdGFibGlzaGVkIHdpdGggYSB2YWxpZCBuYW1lc3BhY2Ug YW5kIGxvd2VyLXByaW9yaXR5IHZhbHVlIGluIGZhdm9yIA0KPiA+ICBvZiBhIG5ldyBzZXNzaW9u IHNldCB1cCB3aXRoIGEgdmFsaWQgbmFtZXNwYWNlIGFuZCBoaWdoZXIgcmVsYXRpdmUgDQo+ID4g IHByaW9yaXR5IHZhbHVlLCB1bmxlc3MgbG9jYWwgcG9saWN5IGhhcyBzb21lIGZvcm0gb2YgY2Fs bC13YWl0aW5nIA0KPiA+ICBjYXBhYmlsaXR5IGVuYWJsZWQuICIgDQo+ID4gDQo+ID4gSXQgZG9l c24ndCBzYXkgYW55dGhpbmcgYWJvdXQgcHJlZW1wdGluZyBhIGNhbGwgd2l0aCBubyBSUEggDQo+ ID4gDQo+ID4gVGhhbmtzIA0KPiA+IA0KPiA+IEphbmV0IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ IA0KPiA+IA0KPiA+IA0KPiA+IFRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0KPiA+IHBsZWFzZSBkZWxldGUgd2l0aG91dCBj b3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgDQo+ID4gbWlzdGFr ZSBpbiBkZWxpdmVyeS4gDQo+ID4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUt bWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIA0KPiA+IENTQyB0byBhbnkgb3JkZXIgb3Ig b3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IA0KPiA+IHdyaXR0ZW4g YWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0 aGUgDQo+ID4gdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLiANCj4gPiANCj4gPiAiSmFt ZXMgTS4gUG9sayIgPGptcG9sa0BjaXNjby5jb20+IA0KPiA+IFNlbnQgYnk6IGVjcml0LWJvdW5j ZXNAaWV0Zi5vcmcgDQo+ID4gMTAvMjcvMjAwOCAwODozMiBQTSANCj4gPiANCj4gPiAgIA0KPiA+ ICAgDQo+ID4gDQo+ID4gVG8gDQo+ID4gDQo+ID4gIidFQ1JJVCciIDxlY3JpdEBpZXRmLm9yZz4g DQo+ID4gDQo+ID4gY2MgDQo+ID4gDQo+ID4gICANCj4gPiANCj4gPiBTdWJqZWN0IA0KPiA+IA0K PiA+IFtFY3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFj ZS0wMCANCj4gPiANCj4gPiANCj4gPiAgIA0KPiA+ICAgDQo+ID4gDQo+ID4gICANCj4gPiANCj4g PiAgIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEVDUklUIFdHDQo+ ID4gDQo+ID4gSGVyZSBpcyBhIHVwZGF0ZSB0byBhIElEIEkgdGhpbmsgaXMgcHJldHR5IG5lYXIg ZG9uZSwgZ2l2ZW4gdGhhdCB0aGlzIA0KPiA+IGlzIG1lcmVseSBhbiBJQU5BIHJlZ2lzdHJhdGlv biBJRCBvZiBhbiBleGlzdGluZyBtZWNoYW5pc20uDQo+ID4gDQo+ID4gQ29tbWVudHMgYXJlIHdh bnRlZA0KPiA+IA0KPiA+ID5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQo+ID4gPmRpcmVjdG9yaWVzLg0KPiA+ID5UaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9u IHdpdGggDQo+ID4gPkludGVybmV0IFRlY2hub2xvZ2llcyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJ RVRGLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IElBTkEg UmVnaXN0ZXJpbmcgYSBTSVAgUmVzb3VyY2UgUHJpb3JpdHkgDQo+ID4gPiBIZWFkZXIgTmFtZXNw YWNlIGZvciBMb2NhbCBFbWVyZ2VuY3kgQ29tbXVuaWNhdGlvbnMNCj4gPiA+ICAgICAgICAgQXV0 aG9yKHMpICAgICAgIDogSi4gUG9saw0KPiA+ID4gICAgICAgICBGaWxlbmFtZSAgICAgICAgOiAN Cj4gPiA+IGRyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2UtMDAu dHh0DQo+ID4gPiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDkNCj4gPiA+ICAgICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAwOC0xMC0yNw0KPiA+ID4NCj4gPiA+VGhpcyBkb2N1bWVudCBjcmVh dGVzIGFuZCBJQU5BIHJlZ2lzdGVycyB0aGUgbmV3IFNlc3Npb24gSW5pdGlhdGlvbg0KPiA+ID5Q cm90b2NvbCAoU0lQKSBSZXNvdXJjZSBQcmlvcml0eSBoZWFkZXIgKFJQSCkgbmFtZXNwYWNlICJl c25ldCIgZm9yDQo+ID4gPmxvY2FsIGVtZXJnZW5jeSB1c2FnZSB0byBhIHB1YmxpYyBzYWZldHkg YW5zd2VyaW5nIHBvaW50IChQU0FQKSwNCj4gPiA+YmV0d2VlbiBQU0FQcywgYW5kIGJldHdlZW4g YSBQU0FQIGFuZCBmaXJzdCByZXNwb25kZXJzIGFuZCB0aGVpcg0KPiA+ID5vcmdhbml6YXRpb25z Lg0KPiA+ID4NCj4gPiA+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+ID4gPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWNyaXQtbG9jYWwt DQo+ID4gZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2UtMDAudHh0DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPjxmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWNy aXQtbG9jYWwtDQo+ID4gZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2UtMDAudHh0Pg0KPiA+IA0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRWNy aXQgbWFpbGluZyBsaXN0DQo+ID4gRWNyaXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gPiBFY3Jp dEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy aXQgDQo+ID4gICANCj4gPiAgIA0KPiA+IFN0dWFydCBHb2xkbWFuIA0KPiA+IEFsY2F0ZWwtTHVj ZW50IA0KPiA+IFN0dWFydC5Hb2xkbWFuQGFsY2F0ZWwtbHVjZW50LmNvbSANCj4gPiArMSA2MDIg NDkzIDg0MzggDQo+ID4gKzEgNDgwIDQxNCAxMjYwIG1vYmlsZSANCj4gPiBQIHBsZWFzZSBzYXZl IGEgdHJlZSBieSBub3QgcHJpbnRpbmcgdGhpcyBlLW1haWwuIA0KPiA+ICAgDQo+ID4gICANCj4g PiAgDQo+IA0KDQo= --=_alternative 005B4B4785257507_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJyaWFuLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBuZWVkIHRvIHVuZGVyc3RhbmQg dGhpcyBiZXR0ZXIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5FeGFjdGx5IHdoYXQgYXJlIHRoZSBjb25zdHJhaW50cyBvZg0KdGhlICZxdW90O2VtZXJn ZW5jeSBzZXJ2aWNlcyBJUCBuZXR3b3JrJnF1b3Q7PyAmbmJzcDtJcyB0aGlzIGEgbmV0d29yaw0K aW4gd2hpY2ggRVZFUlkgY2FsbCB3b3VsZCBoYXZlIHRoZSBSUEggd2l0aCB0aGUgJm5ic3A7ZXNu ZXQgbmFtZXNwYWNlIChqdXN0DQp2YXJ5aW5nIHByaW9yaXR5IHZhbHVlcyksYW5kIHRoZXJlIHdv dWxkIGJlIG5vICZxdW90O25vcm1hbCZxdW90OyBjYWxscz8NCiZuYnNwO09yIHdvdWxkIHRoZWly IGJlIGEgbWl4dHVyZSBvZiBjYWxscyB3aXRoIGFuZCB3aXRob3V0IFJQSCB3aXQgZXNuZXQ/PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5ldDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZxdW90O0JyaWFuIFJvc2VuJnF1b3Q7ICZs dDtickBicmlhbnJvc2VuLm5ldCZndDsNCndyb3RlIG9uIDExLzIwLzIwMDggMTE6MTY6MzkgQU06 PGJyPg0KPGJyPg0KJmd0OyBBIHN1Z2dlc3Rpb24gd2FzIG1hZGUgdG8gbWUgdGhhdCB3ZSBzaG91 bGQgZGVmaW5lIHR3byBuYW1lc3BhY2VzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbmUgd291bGQg YmUgdXNlZCBpbiBwdWJsaWMgbmV0d29ya3MsIGFuZCBnZW5lcmFsbHkgd291bGQgYmUgdXNlZA0K dG8gcmVxdWVzdDxicj4NCiZndDsgcmVzb3VyY2UgcHJpb3JpdHkgZm9yIGNpdGl6ZW4gdG8gYXV0 aG9yaXR5IGFuZCBwb3NzaWJseSBhdXRob3JpdHkNCnRvIGNpdGl6ZW48YnI+DQomZ3Q7IGNhbGxz LiAmbmJzcDtUaGlzIHdvdWxkIGhhdmUgbG93ZXIgcHJpb3JpdHkgdGhhbiBFVFMvV1BTLjxicj4N CiZndDsgPGJyPg0KJmd0OyBUaGUgb3RoZXIgd291bGQgYmUgZm9yIHVzZSB3aXRoaW4gZW1lcmdl bmN5IHNlcnZpY2VzIElQIG5ldHdvcmtzLg0KJm5ic3A7SXQgd291bGQ8YnI+DQomZ3Q7IGJlIHVu bGlrZWx5IHRoYXQgRVRTL1dQUyB3b3VsZCBiZSB1c2VkIHdpdGhpbiB0aG9zZSBuZXR3b3Jrcywg YnV0DQppZiBpdCB3YXMsPGJyPg0KJmd0OyBzb21lIHZhbHVlcyB3aXRoaW4gdGhlIG5hbWVzcGFj ZSB3b3VsZCBuZWVkIGhpZ2hlciBwcmlvcml0eSB0aGF0IEVUUy9XUFMuPGJyPg0KJmd0OyBGb3Ig ZXhhbXBsZSwgYSBtZXNzYWdlIHdoaWNoIHdhcyBhbiBpbmNpZGVudCBjb21tYW5kZXJzIOKAnGV2 YWN1YXRl4oCdDQptZXNzYWdlPGJyPg0KJmd0OyB3b3VsZCBiZSBoaWdoZXIgdGhhbiBhIEVUUy9X UFMgdHJhZmZpYy4gJm5ic3A7T24gdGhlIG90aGVyIGhhbmQsIGENCmNpdGl6ZW4gdG88YnI+DQom Z3Q7IGF1dGhvcml0eSBlbWVyZ2VuY3kgY2FsbCB3b3VsZCBoYXZlIGxvd2VyIHByaW9yaXR5Ljxi cj4NCiZndDsgPGJyPg0KJmd0OyBJIHdvdWxkIGJlIGhhcHBpZXIgd2l0aCBvbmUgbmFtZXNwYWNl IGFuZCBtb3JlIHZhbHVlcyBpbiB0aGF0IG5hbWVzcGFjZQ0KZm9yPGJyPg0KJmd0OyBhbGwgb2Yg dGhpcywgYnV0IEkgd2FzIGFkdmlzZWQgdGhhdCB0d28gbmFtZXNwYWNlcyB3YXMgYSBiZXR0ZXIg Y2hvaWNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBCcmlhbjxicj4NCiZndDsgPGJyPg0KJmd0OyBG cm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQpPZjxicj4NCiZndDsgSmFuZXQgUCBHdW5uPGJyPg0KJmd0OyBTZW50OiBU aHVyc2RheSwgTm92ZW1iZXIgMjAsIDIwMDggMTE6MDAgQU08YnI+DQomZ3Q7IFRvOiBHT0xETUFO LCBTVFVBUlQgTyAoU1RVQVJUKTxicj4NCiZndDsgQ2M6IEVjcml0QGlldGYub3JnPGJyPg0KJmd0 OyBTdWJqZWN0OiBSZTogW0Vjcml0XSBFY3JpdF08YnI+DQomZ3Q7IGRyYWZ0LWlldGYtZWNyaXQt bG9jYWwtZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2UtMDA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBTdHUsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGludGVuZGVkIHRvIHNheSB0aGF0 IHRoZSBlc25ldCBuYW1lc3BhY2UgbmVlZHMgdG8gYmUgYXQgYSBMT1dFUg0KcHJpb3JpdHk8YnI+ DQomZ3Q7ICZuYnNwO3RoYW4gdGhlIGV0cyBhbmQgd3BzIG5hbWVzcGFjZXMsIGluIGFueSBuZXR3 b3JrIHRoYXQgcmVjb2duaXplcw0KZXRzIGFuZCB3cHM8YnI+DQomZ3Q7IGFzIGRlc2NyaWJlZCBp biAxMC41IGFuZCAxMC42IG9mIFJGQzQ0MTIuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBKYW5ldCA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7R09MRE1BTiwgU1RVQVJUIE8gXChTVFVBUlRcKSZx dW90OyAmbHQ7c2dvbGRtYW5AYWxjYXRlbC1sdWNlbnQuY29tJmd0Ow0Kd3JvdGUgb248YnI+DQom Z3Q7IDExLzIwLzIwMDggMTA6MjI6NDkgQU06PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgSmFu ZXQsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFdpdGggcmVnYXJkIHRv IHlvdSBlLW1haWwgYmVsb3csIGRpZCB5b3UgaW50ZW5kIHRoYXQgZXNuZXQgY291bGQNCmJlIDxi cj4NCiZndDsgJmd0OyBhdCB0aGUgc2FtZSBsZXZlbCBvZiBwcmlvcml0eSBhcyBFVFMgJmFtcDsg V1BTLCAmbmJzcDtvciB0aGF0DQpFVFMgJmFtcDsgV1BTIG5lZWQgPGJyPg0KJmd0OyAmZ3Q7IHRv IGJlIGF0IGFuIGV2ZW4gaGlnaGVyIHByaW9yaXR5IHRoYW4gZXNuZXQ/IDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyBTdHVhcnQgR29sZG1hbiA8YnI+DQomZ3Q7ICZndDsgQWxjYXRlbC1MdWNl bnQgPGJyPg0KJmd0OyAmZ3Q7IFN0dWFydC5Hb2xkbWFuQGFsY2F0ZWwtbHVjZW50LmNvbSA8YnI+ DQomZ3Q7ICZndDsgKzEgNjAyIDQ5MyA4NDM4IDxicj4NCiZndDsgJmd0OyArMSA0ODAgNDE0IDEy NjAgbW9iaWxlIDxicj4NCiZndDsgJmd0OyBQIHBsZWFzZSBzYXZlIGEgdHJlZSBieSBub3QgcHJp bnRpbmcgdGhpcyBlLW1haWwuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgSmFuZXQgUCBHdW5uL0ZFRC9DU0NAQ1NDIDxicj4NCiZndDsgJmd0OyBTZW50IGJ5OiBl Y3JpdC1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgJmd0OyAxMC8yNy8yMDA4IDExOjQ1IFBN IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgVG8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtK YW1lcyBNLiBQb2xrJnF1b3Q7ICZsdDtqbXBvbGtAY2lzY28uY29tJmd0OyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IGNjIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJnF1 b3Q7J0VDUklUJyZxdW90OyAmbHQ7ZWNyaXRAaWV0Zi5vcmcmZ3Q7LCBlY3JpdC1ib3VuY2VzQGll dGYub3JnDQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3QgPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWxvY2Fs LWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwDQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgSSBhcG9sb2dpemUgZm9yIG5vdCB0cmFja2luZyB0aGlzIGFzIGNsb3NlbHkg YXMgSSBtZWFudCB0bywgYXMNCnRoZXNlPGJyPg0KJmd0OyAmZ3Q7IGNvbW1lbnRzIGFwcGx5IHRv ICZuYnNwO2VhcmxpZXIgdmVyc2lvbnMgYXMgd2VsbC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhpcyBzZW50ZW5jZSBhdCB0aGUgZW5kIG9mIHNlYyAx IGRvZXNuJ3QgcXVpdGUgd29yay4gPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O1RoaXMgZG9jdW1lbnQg SUFOQSByZWdpc3RlcnMgdGhlICZxdW90O2VzbmV0JnF1b3Q7IDxicj4NCiZndDsgJmd0OyAmbmJz cDtSUEggbmFtZXNwYWNlIGZvciB1c2Ugd2l0aGluIGVtZXJnZW5jeSBzZXJ2aWNlcyBuZXR3b3Jr cywNCm5vdCBqdXN0IDxicj4NCiZndDsgJmd0OyAmbmJzcDtvZiB0aG9zZSBmcm9tIGNpdGl6ZW5z IHRvIFBTQVBzLiZxdW90OyAobm8gY2xlYXIgYW50ZWNlZGVudA0KZm9yICZxdW90O3Rob3NlJnF1 b3Q7KSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFBlcmhhcHMgPGJyPg0KJmd0OyAm Z3Q7ICZxdW90O1RoaXMgZG9jdW1lbnQgSUFOQSByZWdpc3RlcnMgdGhlICZxdW90O2VzbmV0JnF1 b3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDtSUEggbmFtZXNwYWNlIGZvciB1c2Ugd2l0aGluIGVt ZXJnZW5jeSBzZXJ2aWNlcyBuZXR3b3JrcywNCm5vdCBqdXN0IDxicj4NCiZndDsgJmd0OyBmb3Ig Y2FsbHMgb3Igc2Vzc2lvbnMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBmcm9tIGNpdGl6ZW5zIHRv IFBTQVBzLiZxdW90OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNlY3Rpb24gMiBz YXlzIDxicj4NCiZndDsgJmd0OyAmcXVvdDtUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIGJlaGF2 aW9ycyBvZiB0aGUgU0lQIFJlc291cmNlDQpQcmlvcml0eSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 aGVhZGVyLCBkZWZpbmVkIGluIFtSRkM0NDEyXSwgZHVyaW5nIHRoZSB0cmVhdG1lbnQgb3B0aW9u cw0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO3N1cnJvdW5kaW5nIHRoaXMgbmV3ICZxdW90O2VzbmV0 JnF1b3Q7IG5hbWVzcGFjZSBvbmx5Lg0KVGhlIHVzYWdlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7JnF1b3Q7ZXNuZXQmcXVvdDsgbmFtZXNwYWNlIGRvZXMgbm90IGhhdmUgYSBub3JtYWws IG9yDQpyb3V0aW5lIGNhbGwgbGV2ZWwuICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7RXZl cnkgdXNlIG9mIHRoaXMgbmFtZXNwYWNlIHdpbGwgYmUgaW4gdGltZXMgb2YgYW4gZW1lcmdlbmN5 LA0Kd2hlcmUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO2F0IGxlYXN0IG9uZSBlbmQgb2YgdGhlIHNp Z25hbGluZyBpcyB3aXRoIGEgbG9jYWwgZW1lcmdlbmN5DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 b3JnYW5pemF0aW9uLiZxdW90OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgZG9u J3Qgc2VlIHRoaXMgYXMgYW4gJnF1b3Q7dXBkYXRlIG9mIHRoZSBiZWhhdmlvciBvZiA0NDEyJnF1 b3Q7Lg0KJm5ic3A7TmVpdGhlciA8YnI+DQomZ3Q7ICZndDsgdGhlIGV0cyBuYW1lc3BhY2Ugbm90 IHRoZSB3cHMgPGJyPg0KJmd0OyAmZ3Q7IG5hbWVzcGFjZSBoYXZlIGEgJnF1b3Q7bm9ybWFsJnF1 b3Q7IG9yICZxdW90O3JvdXRpbmUmcXVvdDsgY2FsbA0KbGV2ZWwuICZuYnNwO0V2ZXJ5IHVzZSBv ZiB0aGU8YnI+DQomZ3Q7ICZndDsgd3BzIGFuZCBldHMgbmFtZXNwYWNlcyB3aWxsIDxicj4NCiZn dDsgJmd0OyBoYXZlIHByaW9yaXR5IG92ZXIgY2FsbHMgd2l0aG91dCBSUEguIDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgWW91IHNheSAmcXVvdDtUaGlzIDxicj4NCiZndDsgJmd0OyAm bmJzcDtuYW1lc3BhY2UsIHRoZXJlZm9yZSwgTUFZIGJlIG92ZXJ3cml0dGVuIG9yIGRlbGV0ZWQs IGNvbnRyYXJ5DQp0byB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO3J1bGVzIG9mIFJGQyA0NDEy IFtSRkM0NDEyXS4mcXVvdDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJdCBpcyBu b3QgY2xlYXIgdG8gbWUgd2h5IHRoaXMgaXMgJnF1b3Q7Y29udHJhcnkgdG8gdGhlIHJ1bGVzDQpv ZiA0NDEyJnF1b3Q7LiAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgSXQgaXMgY2VydGFpbmx5IGFudGlj aXBhdGVkIDxicj4NCiZndDsgJmd0OyB0aGF0IG90aGVyIFJQSCB3aWxsIGJlIG92ZXJ3cml0dGVu IG9yIGRlbGV0ZWQsIHdoZW4gdGhlIFVBUyA8YnI+DQomZ3Q7ICZndDsgdW5kZXJzdGFuZHMgdGhl IG5hbWVzcGFjZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA0NDEyIHNheXMgJnF1 b3Q7RXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9mIFJGQyAzMjYxIHRoYXQgZG8NCm5vdCBwYXJ0 aWNpcGF0ZSBpbjxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO3Jlc291cmNlIHBy aW9yaXR5IG1lY2hhbmlzbSBmb2xsb3cgdGhlIG5vcm1hbCBydWxlcyBvZg0KUkZDIDMyNjEsIDxi cj4NCiZndDsgJmd0OyAmbmJzcDtTZWN0aW9uIDguMi4yOiAmcXVvdDtJZiBhIFVBUyBkb2VzIG5v dCB1bmRlcnN0YW5kIGEgaGVhZGVyDQpmaWVsZCBpbiBhIDxicj4NCiZndDsgJmd0OyAmbmJzcDty ZXF1ZXN0ICh0aGF0IGlzLCB0aGUgaGVhZGVyIGZpZWxkIGlzIG5vdCBkZWZpbmVkIGluIHRoaXMN Cjxicj4NCiZndDsgJmd0OyAmbmJzcDtzcGVjaWZpY2F0aW9uIG9yIGluIGFueSBzdXBwb3J0ZWQg ZXh0ZW5zaW9uKSwgdGhlIHNlcnZlcg0KTVVTVCBpZ25vcmUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw O3RoYXQgaGVhZGVyIGZpZWxkIGFuZCBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlJnF1 b3Q7Lg0KJnF1b3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQnV0IEkgZG8gbm90 IHNlZSBhbnl3aGVyZSB0aGF0IGlzIHNheXMgdGhhdCBhIFVBUyB0aGF0IERPRVMgPGJyPg0KJmd0 OyAmZ3Q7IHVuZGVyc3RhbmQgdGhlIG5hbWVzcGFjZSBpcyA8YnI+DQomZ3Q7ICZndDsgZm9yYmlk ZGVuIGZyb20gZGVsZXRpbmcgaXQuICZuYnNwO0ZvciBpbnN0YW5jZSwgc2VjIDQuNy4xIG9mDQo0 NDEyIHNheXMgPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgJnF1b3Q7dGhlIFVBQyA8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7TUFZIGF0dGVtcHQgYSBzdWJzZXF1ZW50IHJlcXVlc3Qgd2l0aCB0aGUgc2FtZSBv ciBkaWZmZXJlbnQNCnJlc291cmNlIDxicj4NCiZndDsgJmd0OyAmbmJzcDt2YWx1ZS4mcXVvdDsg Jm5ic3A7VGhpcyBjZXJ0YWlubHkgaW1wbGllcyB0aGUgYWJpbGl0eSB0bw0Kb3ZlcndyaXRlIG9y IGRlbGV0ZSA8YnI+DQomZ3Q7ICZndDsgYW4gUlBIIG5hbWVzcGFjZS4gJm5ic3A7IDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgKFNlZSBhbHNvLCBmb3IgaW5zdGFuY2UgdGhlIFBUU0Mg U0FDIGRvY3VtZW50IG9uIHRoZSB1c2Ugb2YgdGhlDQpldHMgPGJyPg0KJmd0OyAmZ3Q7IGFuZCB3 cHMgbmFtZXNwYWNlcykgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJbW1lZGlhdGVs eSBmb2xsb3dpbmcgdGhlc2Ugc3RhdGVtZW50cywgeW91IGdpdmUgMyBvcHRpb25zLSA8YnI+DQom Z3Q7ICZndDsgJnF1b3Q7VGhlc2UgcHJveGllcyBpbiB0aGUgc2VydmljZSBwcm92aWRlciA8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7TUFZIGVpdGhlciA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwO28gJm5ic3A7YWNjZXB0IHRoZSBleGlzdGluZyBSUEggdmFsdWUgd2l0aCAmcXVv dDtlc25ldCZxdW90Ow0KaW4gaXQsIGlmIG9uZSBpcyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyBwcmVzZW50LCBhbmQgZ3JhbnQgcmVsYXRpdmUgcHJlZmVyZW50aWFsIHRyZWF0bWVudA0K dG8gdGhlIHJlcXVlc3QgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgd2hlbiBmb3J3YXJk aW5nIGl0IHRvIHRoZSBFU0lOZXQuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7byAmbmJzcDtyZXBsYWNlIGFueSBleGlzdGluZyBSUEggdmFsdWUsIGlmIG9uZSBpcyBwcmVz ZW50LA0KYW5kIGluc2VydCBhbiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtl c25ldCZxdW90OyBuYW1lc3BhY2UgYW5kIGdpdmUgcmVsYXRpdmUgcHJlZmVyZW50aWFsDQp0cmVh dG1lbnQgdG8gdGhlIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHJlcXVlc3Qgd2hlbiBm b3J3YXJkaW5nIGl0IHRvIHRoZSBFU0lOZXQuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7byAmbmJzcDtpbnNlcnQgYW4gJnF1b3Q7ZXNuZXQmcXVvdDsgbmFtZXNwYWNlIGlu IGEgbmV3DQpSUEggYW5kIGdpdmUgcmVsYXRpdmUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgcHJlZmVyZW50aWFsIHRyZWF0bWVudCB0byB0aGUgcmVxdWVzdCB3aGVuIGZvcndhcmRpbmcN CnRoZSBTSVAgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgcmVxdWVzdCB0b3dhcmRzIHRo ZSBFU0lOZXQuJnF1b3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2h5IGRvIHlv dSBleGNsdWRlIHRoZSBwb3NzaWJpbGl0eSBvZiBhZGRpbmcgdGhlIGVzbmV0IFJQSCB2YWx1ZQ0K PGJyPg0KJmd0OyAmZ3Q7IHdpdGhvdXQgJnF1b3Q7cmVwbGFjaW5nJnF1b3Q7IGFuIGV4aXN0aW5n IFJQSCB2YWx1ZT8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBGaW5hbGx5LCB0aGVy ZSBpcyBhbm90aGVyIHBvaW50IHRoYXQgJm5ic3A7bmVlZHMgdG8gYmUgbWFkZSBjbGVhci4NCiZu YnNwO0F0IDxicj4NCiZndDsgJmd0OyBsZWFzdCBvbmUgcGVyc29uIGhhcyBjb250YWN0ZWQgbWUg ZXhwcmVzc2luZyBjb25jZXJuIHRoYXQgdGhpcw0KSUQgPGJyPg0KJmd0OyAmZ3Q7IGltcGxpZWQg dGhhdCB0aGUgZXNuZXQgbmFtZXNwYWNlIHdvdWxkICZuYnNwO2hhdmUgcHJpb3JpdHkgb3Zlcg0K b3RoZXIgPGJyPg0KJmd0OyAmZ3Q7IG5hbWVzcGFjZXMgKGluIHBhcnRpY3VsYXIgd3BzIGFuZCBl dHMpLiAmbmJzcDtJIGFzc3VyZWQgaGltIHRoYXQNCnRoaXMgd2FzPGJyPg0KJmd0OyAmZ3Q7IG5v dCB0aGUgY2FzZSwgdGhhdCB0aGVyZSB3YXMgbm90aGluZyBwcmV2ZW50IHRoZSBleHBlY3RlZCBi ZWhhdmlvcg0KLTxicj4NCiZndDsgJmd0OyB0aGF0IHRoZSBldHMgYW5kIHdwcyBuYW1lc3BhY2Vz IHdvdWxkIGJlIHByaW9yaXRpemVkIGFoZWFkIG9mDQplc25ldCA8YnI+DQomZ3Q7ICZndDsgaW4g R0VUUyBTZXJ2aWNlIFByb3ZpZGVyIG5ldHdvcmtzLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEhvd2V2ZXIsIHNpbmNlIHRoZSBxdWVzdGlvbiBoYXMgYWxyZWFkeSBhcmlzZW4sIGl0 IHdvdWxkIGJlIGENCmdvb2QgPGJyPg0KJmd0OyAmZ3Q7IGlkZWEgdG8gY2xhcmlmeSAmbmJzcDt0 aGlzLCBwZXJoYXBzIGluICZuYnNwO3NlY3Rpb24gMywgd2hlcmUNCnlvdSBkaXNjdXNzICZuYnNw O3RoZTxicj4NCiZndDsgJmd0OyBvdGhlciBuYW1lc3BhY2VzLiAmbmJzcDtJbiBwYXJ0aWN1bGFy LCBpdCBuZWVkcyB0byBiZSBtYWRlIGNsZWFyDQppbiA8YnI+DQomZ3Q7ICZndDsgc2VjdGlvbiAz LjIgJm5ic3A7dGhhdCwgZXZlbiBpZiAmbmJzcDsmcXVvdDt0aGUgJm5ic3A7IGxvY2FsDQpqdXJp c2RpY3Rpb24gcHJlZmVycmVkIHRvIDxicj4NCiZndDsgJmd0OyBwcmVlbXB0IG5vcm1hbCBjYWxs cyBpbiBsaWV1IG9mIDxicj4NCiZndDsgJmd0OyAmbmJzcDtjb21wbGV0aW5nIGVtZXJnZW5jeSBj YWxscy4gJnF1b3Q7LCBlc25ldCBjYWxscyB3aWxsIE5PVA0KcHJlZW1wdCB3cHMgb3IgZXRzPGJy Pg0KJmd0OyBjYWxscy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEJ5IHRoZSB3YXks IEkgdGhpbmsgeW91IG1lYW4gJnF1b3Q7dGhlICZuYnNwOyBsb2NhbCBqdXJpc2RpY3Rpb24NCnBy ZWZlcnJlZCB0byA8YnI+DQomZ3Q7ICZndDsgcHJlZW1wdCBub3JtYWwgY2FsbHMgaW4gb3JkZXIg dG8gY29tcGxldGUgZW1lcmdlbmN5IGNhbGxzLiAmcXVvdDsNCiZuYnNwOy0gbm90IDxicj4NCiZn dDsgJmd0OyAmcXVvdDtpbiBsaWV1IG9mJnF1b3Q7LiAmbmJzcDtPciBwZXJoYXBzICZxdW90O3Ro ZSAmbmJzcDsgbG9jYWwNCmp1cmlzZGljdGlvbiBwcmVmZXJyZWQgdG8gPGJyPg0KJmd0OyAmZ3Q7 IHByZWVtcHQgbm9ybWFsIGNhbGxzIGluIGxpZXUgb2YgJm5ic3A7ZHJvcHBpbmcgZW1lcmdlbmN5 IGNhbGxzLg0KJnF1b3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gZmFjdCwg aXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgNDQxMiBwZXJtaXRzIGEgY2FsbCB3aXRoDQphbiBS UEggPGJyPg0KJmd0OyAmZ3Q7IChlLmcuLCBlc25ldCkgJm5ic3A7dG8gcHJlZW1wdCBhICZxdW90 O25vcm1hbCZxdW90OyBjYWxsICh3aXRoDQpubyBSUEggbmFtZXNwYWNlKS4gJm5ic3A7PGJyPg0K Jmd0OyAmZ3Q7IFNlY3Rpb24gNC43LjIuMSBvZiA0NDEyIHNheXMgPGJyPg0KJmd0OyAmZ3Q7ICZx dW90OzQuNy4yLjEuICZuYnNwO1VzZXIgQWdlbnQgU2VydmVycyBhbmQgUHJlZW1wdGlvbiBBbGdv cml0aG0NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7QSBVQVMgY29tcGxp YW50IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgdGVybWluYXRlDQphIHNlc3Npb24gPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwO2VzdGFibGlzaGVkIHdpdGggYSB2YWxpZCBuYW1lc3BhY2UgYW5k IGxvd2VyLXByaW9yaXR5IHZhbHVlDQppbiBmYXZvciA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7b2Yg YSBuZXcgc2Vzc2lvbiBzZXQgdXAgd2l0aCBhIHZhbGlkIG5hbWVzcGFjZSBhbmQgaGlnaGVyDQpy ZWxhdGl2ZSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7cHJpb3JpdHkgdmFsdWUsIHVubGVzcyBsb2Nh bCBwb2xpY3kgaGFzIHNvbWUgZm9ybSBvZiBjYWxsLXdhaXRpbmcNCjxicj4NCiZndDsgJmd0OyAm bmJzcDtjYXBhYmlsaXR5IGVuYWJsZWQuICZxdW90OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEl0IGRvZXNuJ3Qgc2F5IGFueXRoaW5nIGFib3V0IHByZWVtcHRpbmcgYSBjYWxsIHdp dGggbm8gUlBIIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSmFuZXQgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsDQo8YnI+DQomZ3Q7ICZndDsgcGxl YXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWls DQpvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IG1pc3Rha2UgaW4gZGVsaXZlcnkuIDxicj4NCiZndDsg Jmd0OyBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBv cGVyYXRlIHRvDQpiaW5kIDxicj4NCiZndDsgJmd0OyBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVy IGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdA0KPGJyPg0KJmd0OyAmZ3Q7IHdy aXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0 dGluZw0KdGhlIDxicj4NCiZndDsgJmd0OyB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2Uu IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7SmFtZXMgTS4gUG9sayZxdW90 OyAmbHQ7am1wb2xrQGNpc2NvLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNlbnQgYnk6IGVjcml0 LWJvdW5jZXNAaWV0Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7IDEwLzI3LzIwMDggMDg6MzIgUE0gPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvIDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJnF1b3Q7J0VDUklUJyZxdW90OyAmbHQ7ZWNyaXRAaWV0Zi5vcmcmZ3Q7IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgY2MgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTdWJqZWN0IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWxv Y2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBFQ1JJVCBXRzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGVy ZSBpcyBhIHVwZGF0ZSB0byBhIElEIEkgdGhpbmsgaXMgcHJldHR5IG5lYXIgZG9uZSwgZ2l2ZW4g dGhhdA0KdGhpcyA8YnI+DQomZ3Q7ICZndDsgaXMgbWVyZWx5IGFuIElBTkEgcmVnaXN0cmF0aW9u IElEIG9mIGFuIGV4aXN0aW5nIG1lY2hhbmlzbS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IENvbW1lbnRzIGFyZSB3YW50ZWQ8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDtBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyAm Z3Q7ICZndDtUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBFbWVyZ2VuY3kgQ29udGV4 dCBSZXNvbHV0aW9uDQp3aXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7SW50ZXJuZXQgVGVjaG5vbG9n aWVzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyA6IElBTkEgUmVn aXN0ZXJpbmcgYSBTSVAgUmVzb3VyY2UgUHJpb3JpdHkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGVh ZGVyIE5hbWVzcGFjZSBmb3IgTG9jYWwgRW1lcmdlbmN5IENvbW11bmljYXRpb25zPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcihzKSAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KOiBKLiBQb2xrPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs6IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IGRyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcmdlbmN5LXJwaC1u YW1lc3BhY2UtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDogOTxicj4N CiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzogMjAwOC0xMC0yNzxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYW5kIElB TkEgcmVnaXN0ZXJzIHRoZSBuZXcgU2Vzc2lvbg0KSW5pdGlhdGlvbjxicj4NCiZndDsgJmd0OyAm Z3Q7UHJvdG9jb2wgKFNJUCkgUmVzb3VyY2UgUHJpb3JpdHkgaGVhZGVyIChSUEgpIG5hbWVzcGFj ZSAmcXVvdDtlc25ldCZxdW90Ow0KZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDtsb2NhbCBlbWVyZ2Vu Y3kgdXNhZ2UgdG8gYSBwdWJsaWMgc2FmZXR5IGFuc3dlcmluZyBwb2ludA0KKFBTQVApLDxicj4N CiZndDsgJmd0OyAmZ3Q7YmV0d2VlbiBQU0FQcywgYW5kIGJldHdlZW4gYSBQU0FQIGFuZCBmaXJz dCByZXNwb25kZXJzIGFuZA0KdGhlaXI8YnI+DQomZ3Q7ICZndDsgJmd0O29yZ2FuaXphdGlvbnMu PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0O0EgVVJMIGZvciB0aGlzIElu dGVybmV0LURyYWZ0IGlzOjxicj4NCiZndDsgJmd0OyAmZ3Q7aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1lY3JpdC1sb2NhbC08YnI+DQomZ3Q7ICZndDsgZW1l cmdlbmN5LXJwaC1uYW1lc3BhY2UtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbHQ7ZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVjcml0LWxvY2FsLTxi cj4NCiZndDsgJmd0OyBlbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZS0wMC50eHQmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsgRWNyaXRAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lY3JpdDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBFY3JpdCBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7ICZndDsgRWNyaXRAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFN0dWFydCBHb2xkbWFu IDxicj4NCiZndDsgJmd0OyBBbGNhdGVsLUx1Y2VudCA8YnI+DQomZ3Q7ICZndDsgU3R1YXJ0Lkdv bGRtYW5AYWxjYXRlbC1sdWNlbnQuY29tIDxicj4NCiZndDsgJmd0OyArMSA2MDIgNDkzIDg0Mzgg PGJyPg0KJmd0OyAmZ3Q7ICsxIDQ4MCA0MTQgMTI2MCBtb2JpbGUgPGJyPg0KJmd0OyAmZ3Q7IFAg cGxlYXNlIHNhdmUgYSB0cmVlIGJ5IG5vdCBwcmludGluZyB0aGlzIGUtbWFpbC4gPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJz cDs8YnI+DQomZ3Q7IDxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 005B4B4785257507_=-- --===============1998818205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1998818205==-- From ecrit-bounces@ietf.org Thu Nov 20 09:00:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7BD28C186; Thu, 20 Nov 2008 09:00:59 -0800 (PST) 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 B300528C186 for ; Thu, 20 Nov 2008 09:00:57 -0800 (PST) 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 wH3IQVHFvUkr for ; Thu, 20 Nov 2008 09:00:56 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 02B7E3A6A25 for ; Thu, 20 Nov 2008 09:00:56 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3Ctd-00066U-6y; Thu, 20 Nov 2008 11:00:49 -0600 From: "Brian Rosen" To: "'Janet P Gunn'" References: <015301c94b2b$60155ee0$20401ca0$@net> In-Reply-To: Date: Thu, 20 Nov 2008 12:00:50 -0500 Message-ID: <017a01c94b31$8bfa57d0$a3ef0770$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLLkOCvH4EF1BDRSW3h6LtCMKLfAAAZ2ow Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org QW4g4oCcRW1lcmdlbmN5IFNlcnZpY2VzIElQIE5ldHdvcmvigJ0gaXMgYSBwcml2YXRlIElQIG5l dHdvcmsgdG8gd2hpY2gsIHdlIGhvcGUsIGFsbCBwdWJsaWMgc2FmZXR5IGFnZW5jaWVzIGFyZSBj b25uZWN0ZWQuICBJdCBoYW5kbGVzIGFsbCB0aGUgdHJhZmZpYyBvZiBhIHB1YmxpYyBzYWZldHkg YWdlbmN5LCB3aGljaCB3b3VsZCBpbmNsdWRlIHJvdXRpbmUgYW5kIHByaW9yaXR5IGNpdGl6ZW4g dG8gYXV0aG9yaXR5LCBhdXRob3JpdHkgdG8gYXV0aG9yaXR5IGFuZCBhdXRob3JpdHkgdG8gY2l0 aXplbiB0cmFmZmljLiAgSXTigJlzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB5ZXQgd2hldGhl ciB3ZSBjYW4gcmV1c2UgYSBudW1iZXIgb2YgdGhlIGV4aXN0aW5nIG5hbWUgc3BhY2VzIGFzIHdl bGwgYXMgYSBuZXcgb25lLiAgRm9yIGV4YW1wbGUsIHNvbWUgb2YgdGhlIGFnZW5jeS1hZ2VuY3kg dHJhZmZpYyB3aWxsIHJlcXVpcmUgcHJlLWVtcHRpb24sIGJ1dCB0aGUgZXhpc3RpbmcgTUxQUCBu YW1lc3BhY2UgbWF5IGJlIHF1aXRlIHN1ZmZpY2llbnQuCgpJdCBkb2VzIG9jY3VyIHRvIG1lIHRo YXQgd2UgY291bGQgaGF2ZSBFVFMgYW5kIHBvc3NpYmx5IFdQUyB0cmFmZmljLCBpbiB0aGF0IGlm IHRoZSBub3JtYWwgYWNjZXNzIHRvIHB1YmxpYyBmYWNpbGl0aWVzIHRyYXZlcnNlZCB0aGUgRVNJ bmV0IHRvd2FyZHMgc29tZSBraW5kIG9mIGdhdGV3YXkgdG8gYSBwdWJsaWMgbmV0d29yaywgdGhl biB3ZSB3b3VsZCBlaXRoZXIgaGF2ZSB0byBoYXZlIHRoZSBFVFMvV1BTIHZhbHVlcywgb3IgcmVt YXJrIHRoZW0gYXQgdGhlIGVkZ2UgaWYgYSBjYWxsZXIgaW5zaWRlIHRoZSBFU0luZXQgbmVlZGVk IHRvIGNhbGwgc29tZW9uZSBvdXRzaWRlIHRoZSBFU0luZXQgYW5kIG5lZWRlZCBFVFMvV1BTIHBy aW9yaXR5IHRvIGRvIHNvLiAgIElmIHdlIGNhcnJpZWQgdGhlIHByaW9yaXR5IG1hcmtpbmcgYWNy b3NzIHRoZSBFU0luZXQsIEVUUy9XUFMgd291bGQgYmUgbG93ZXIgcHJpb3JpdHkgdGhhbiBzb21l IG90aGVyIHRyYWZmaWMsIGJ1dCBoaWdoZXIgdGhhbiwgZm9yIGV4YW1wbGUsIGNpdGl6ZW4gdG8g YXV0aG9yaXR5IGVtZXJnZW5jeSBjYWxscy4KCkJyaWFuCgoKCkZyb206IEphbmV0IFAgR3VubiBb bWFpbHRvOmpndW5uNkBjc2MuY29tXSAKU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIwLCAyMDA4 IDExOjM3IEFNClRvOiBCcmlhbiBSb3NlbgpDYzogRWNyaXRAaWV0Zi5vcmc7ICdHT0xETUFOLCBT VFVBUlQgTyAoU1RVQVJUKScKU3ViamVjdDogUkU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1s b2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZS0wMAoKCkJyaWFuLCAKCkkgbmVlZCB0byB1bmRl cnN0YW5kIHRoaXMgYmV0dGVyLiAKCkV4YWN0bHkgd2hhdCBhcmUgdGhlIGNvbnN0cmFpbnRzIG9m IHRoZSAiZW1lcmdlbmN5IHNlcnZpY2VzIElQIG5ldHdvcmsiPyAgSXMgdGhpcyBhIG5ldHdvcmsg aW4gd2hpY2ggRVZFUlkgY2FsbCB3b3VsZCBoYXZlIHRoZSBSUEggd2l0aCB0aGUgIGVzbmV0IG5h bWVzcGFjZSAoanVzdCB2YXJ5aW5nIHByaW9yaXR5IHZhbHVlcyksYW5kIHRoZXJlIHdvdWxkIGJl IG5vICJub3JtYWwiIGNhbGxzPyAgT3Igd291bGQgdGhlaXIgYmUgYSBtaXh0dXJlIG9mIGNhbGxz IHdpdGggYW5kIHdpdGhvdXQgUlBIIHdpdCBlc25ldD8gCgpKYW5ldCAKCiJCcmlhbiBSb3NlbiIg PGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZSBvbiAxMS8yMC8yMDA4IDExOjE2OjM5IEFNOgoKPiBB IHN1Z2dlc3Rpb24gd2FzIG1hZGUgdG8gbWUgdGhhdCB3ZSBzaG91bGQgZGVmaW5lIHR3byBuYW1l c3BhY2VzLgo+IAo+IE9uZSB3b3VsZCBiZSB1c2VkIGluIHB1YmxpYyBuZXR3b3JrcywgYW5kIGdl bmVyYWxseSB3b3VsZCBiZSB1c2VkIHRvIHJlcXVlc3QKPiByZXNvdXJjZSBwcmlvcml0eSBmb3Ig Y2l0aXplbiB0byBhdXRob3JpdHkgYW5kIHBvc3NpYmx5IGF1dGhvcml0eSB0byBjaXRpemVuCj4g Y2FsbHMuICBUaGlzIHdvdWxkIGhhdmUgbG93ZXIgcHJpb3JpdHkgdGhhbiBFVFMvV1BTLgo+IAo+ IFRoZSBvdGhlciB3b3VsZCBiZSBmb3IgdXNlIHdpdGhpbiBlbWVyZ2VuY3kgc2VydmljZXMgSVAg bmV0d29ya3MuICBJdCB3b3VsZAo+IGJlIHVubGlrZWx5IHRoYXQgRVRTL1dQUyB3b3VsZCBiZSB1 c2VkIHdpdGhpbiB0aG9zZSBuZXR3b3JrcywgYnV0IGlmIGl0IHdhcywKPiBzb21lIHZhbHVlcyB3 aXRoaW4gdGhlIG5hbWVzcGFjZSB3b3VsZCBuZWVkIGhpZ2hlciBwcmlvcml0eSB0aGF0IEVUUy9X UFMuCj4gRm9yIGV4YW1wbGUsIGEgbWVzc2FnZSB3aGljaCB3YXMgYW4gaW5jaWRlbnQgY29tbWFu ZGVycyDigJxldmFjdWF0ZeKAnSBtZXNzYWdlCj4gd291bGQgYmUgaGlnaGVyIHRoYW4gYSBFVFMv V1BTIHRyYWZmaWMuICBPbiB0aGUgb3RoZXIgaGFuZCwgYSBjaXRpemVuIHRvCj4gYXV0aG9yaXR5 IGVtZXJnZW5jeSBjYWxsIHdvdWxkIGhhdmUgbG93ZXIgcHJpb3JpdHkuCj4gCj4gSSB3b3VsZCBi ZSBoYXBwaWVyIHdpdGggb25lIG5hbWVzcGFjZSBhbmQgbW9yZSB2YWx1ZXMgaW4gdGhhdCBuYW1l c3BhY2UgZm9yCj4gYWxsIG9mIHRoaXMsIGJ1dCBJIHdhcyBhZHZpc2VkIHRoYXQgdHdvIG5hbWVz cGFjZXMgd2FzIGEgYmV0dGVyIGNob2ljZS4KPiAKPiBCcmlhbgo+IAo+IEZyb206IGVjcml0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YKPiBKYW5ldCBQIEd1bm4KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjAsIDIwMDggMTE6 MDAgQU0KPiBUbzogR09MRE1BTiwgU1RVQVJUIE8gKFNUVUFSVCkKPiBDYzogRWNyaXRAaWV0Zi5v cmcKPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBFY3JpdF0KPiBkcmFmdC1pZXRmLWVjcml0LWxvY2Fs LWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwCj4gCj4gCj4gU3R1LCAKPiAKPiBJIGludGVuZGVk IHRvIHNheSB0aGF0IHRoZSBlc25ldCBuYW1lc3BhY2UgbmVlZHMgdG8gYmUgYXQgYSBMT1dFUiBw cmlvcml0eQo+ICB0aGFuIHRoZSBldHMgYW5kIHdwcyBuYW1lc3BhY2VzLCBpbiBhbnkgbmV0d29y ayB0aGF0IHJlY29nbml6ZXMgZXRzIGFuZCB3cHMKPiBhcyBkZXNjcmliZWQgaW4gMTAuNSBhbmQg MTAuNiBvZiBSRkM0NDEyLiAKPiAKPiBKYW5ldCAKPiAKPiAiR09MRE1BTiwgU1RVQVJUIE8gXChT VFVBUlRcKSIgPHNnb2xkbWFuQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGUgb24KPiAxMS8yMC8y MDA4IDEwOjIyOjQ5IEFNOgo+IAo+ID4gSmFuZXQsIAo+ID4gICAKPiA+IFdpdGggcmVnYXJkIHRv IHlvdSBlLW1haWwgYmVsb3csIGRpZCB5b3UgaW50ZW5kIHRoYXQgZXNuZXQgY291bGQgYmUgCj4g PiBhdCB0aGUgc2FtZSBsZXZlbCBvZiBwcmlvcml0eSBhcyBFVFMgJiBXUFMsICBvciB0aGF0IEVU UyAmIFdQUyBuZWVkIAo+ID4gdG8gYmUgYXQgYW4gZXZlbiBoaWdoZXIgcHJpb3JpdHkgdGhhbiBl c25ldD8gCj4gPiAgIAo+ID4gICAKPiA+ICAgCj4gPiBTdHVhcnQgR29sZG1hbiAKPiA+IEFsY2F0 ZWwtTHVjZW50IAo+ID4gU3R1YXJ0LkdvbGRtYW5AYWxjYXRlbC1sdWNlbnQuY29tIAo+ID4gKzEg NjAyIDQ5MyA4NDM4IAo+ID4gKzEgNDgwIDQxNCAxMjYwIG1vYmlsZSAKPiA+IFAgcGxlYXNlIHNh dmUgYSB0cmVlIGJ5IG5vdCBwcmludGluZyB0aGlzIGUtbWFpbC4gCj4gPiAgIAo+ID4gICAKPiA+ ICAgCj4gPiAKPiA+IEphbmV0IFAgR3Vubi9GRUQvQ1NDQENTQyAKPiA+IFNlbnQgYnk6IGVjcml0 LWJvdW5jZXNAaWV0Zi5vcmcgCj4gPiAxMC8yNy8yMDA4IDExOjQ1IFBNIAo+ID4gCj4gPiAgIAo+ ID4gCj4gPiBUbyAKPiA+IAo+ID4gIkphbWVzIE0uIFBvbGsiIDxqbXBvbGtAY2lzY28uY29tPiAK PiA+IAo+ID4gY2MgCj4gPiAKPiA+ICInRUNSSVQnIiA8ZWNyaXRAaWV0Zi5vcmc+LCBlY3JpdC1i b3VuY2VzQGlldGYub3JnIAo+ID4gCj4gPiBTdWJqZWN0IAo+ID4gCj4gPiBSZTogW0Vjcml0XSBk cmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwIAo+ID4gCj4g PiAKPiA+ICAgCj4gPiAgIAo+ID4gCj4gPiAgIAo+ID4gCj4gPiAgIAo+ID4gCj4gPiAKPiA+IAo+ ID4gCj4gPiAKPiA+IAo+ID4gSSBhcG9sb2dpemUgZm9yIG5vdCB0cmFja2luZyB0aGlzIGFzIGNs b3NlbHkgYXMgSSBtZWFudCB0bywgYXMgdGhlc2UKPiA+IGNvbW1lbnRzIGFwcGx5IHRvICBlYXJs aWVyIHZlcnNpb25zIGFzIHdlbGwuIAo+ID4gCj4gPiAKPiA+IFRoaXMgc2VudGVuY2UgYXQgdGhl IGVuZCBvZiBzZWMgMSBkb2Vzbid0IHF1aXRlIHdvcmsuIAo+ID4gIlRoaXMgZG9jdW1lbnQgSUFO QSByZWdpc3RlcnMgdGhlICJlc25ldCIgCj4gPiAgUlBIIG5hbWVzcGFjZSBmb3IgdXNlIHdpdGhp biBlbWVyZ2VuY3kgc2VydmljZXMgbmV0d29ya3MsIG5vdCBqdXN0IAo+ID4gIG9mIHRob3NlIGZy b20gY2l0aXplbnMgdG8gUFNBUHMuIiAobm8gY2xlYXIgYW50ZWNlZGVudCBmb3IgInRob3NlIikg Cj4gPiAKPiA+IFBlcmhhcHMgCj4gPiAiVGhpcyBkb2N1bWVudCBJQU5BIHJlZ2lzdGVycyB0aGUg ImVzbmV0IiAKPiA+ICBSUEggbmFtZXNwYWNlIGZvciB1c2Ugd2l0aGluIGVtZXJnZW5jeSBzZXJ2 aWNlcyBuZXR3b3Jrcywgbm90IGp1c3QgCj4gPiBmb3IgY2FsbHMgb3Igc2Vzc2lvbnMgCj4gPiAg IGZyb20gY2l0aXplbnMgdG8gUFNBUHMuIiAKPiA+IAo+ID4gU2VjdGlvbiAyIHNheXMgCj4gPiAi VGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBiZWhhdmlvcnMgb2YgdGhlIFNJUCBSZXNvdXJjZSBQ cmlvcml0eSAKPiA+ICBoZWFkZXIsIGRlZmluZWQgaW4gW1JGQzQ0MTJdLCBkdXJpbmcgdGhlIHRy ZWF0bWVudCBvcHRpb25zIAo+ID4gIHN1cnJvdW5kaW5nIHRoaXMgbmV3ICJlc25ldCIgbmFtZXNw YWNlIG9ubHkuIFRoZSB1c2FnZSBvZiB0aGUgCj4gPiAgImVzbmV0IiBuYW1lc3BhY2UgZG9lcyBu b3QgaGF2ZSBhIG5vcm1hbCwgb3Igcm91dGluZSBjYWxsIGxldmVsLiAgIAo+ID4gIEV2ZXJ5IHVz ZSBvZiB0aGlzIG5hbWVzcGFjZSB3aWxsIGJlIGluIHRpbWVzIG9mIGFuIGVtZXJnZW5jeSwgd2hl cmUgCj4gPiAgYXQgbGVhc3Qgb25lIGVuZCBvZiB0aGUgc2lnbmFsaW5nIGlzIHdpdGggYSBsb2Nh bCBlbWVyZ2VuY3kgCj4gPiAgb3JnYW5pemF0aW9uLiIgCj4gPiAKPiA+IEkgZG9uJ3Qgc2VlIHRo aXMgYXMgYW4gInVwZGF0ZSBvZiB0aGUgYmVoYXZpb3Igb2YgNDQxMiIuICBOZWl0aGVyIAo+ID4g dGhlIGV0cyBuYW1lc3BhY2Ugbm90IHRoZSB3cHMgCj4gPiBuYW1lc3BhY2UgaGF2ZSBhICJub3Jt YWwiIG9yICJyb3V0aW5lIiBjYWxsIGxldmVsLiAgRXZlcnkgdXNlIG9mIHRoZQo+ID4gd3BzIGFu ZCBldHMgbmFtZXNwYWNlcyB3aWxsIAo+ID4gaGF2ZSBwcmlvcml0eSBvdmVyIGNhbGxzIHdpdGhv dXQgUlBILiAKPiA+IAo+ID4gWW91IHNheSAiVGhpcyAKPiA+ICBuYW1lc3BhY2UsIHRoZXJlZm9y ZSwgTUFZIGJlIG92ZXJ3cml0dGVuIG9yIGRlbGV0ZWQsIGNvbnRyYXJ5IHRvIHRoZSAKPiA+ICBy dWxlcyBvZiBSRkMgNDQxMiBbUkZDNDQxMl0uIiAKPiA+IAo+ID4gSXQgaXMgbm90IGNsZWFyIHRv IG1lIHdoeSB0aGlzIGlzICJjb250cmFyeSB0byB0aGUgcnVsZXMgb2YgNDQxMiIuICAKPiA+IEl0 IGlzIGNlcnRhaW5seSBhbnRpY2lwYXRlZCAKPiA+IHRoYXQgb3RoZXIgUlBIIHdpbGwgYmUgb3Zl cndyaXR0ZW4gb3IgZGVsZXRlZCwgd2hlbiB0aGUgVUFTIAo+ID4gdW5kZXJzdGFuZHMgdGhlIG5h bWVzcGFjZS4gCj4gPiAKPiA+IDQ0MTIgc2F5cyAiRXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG9m IFJGQyAzMjYxIHRoYXQgZG8gbm90IHBhcnRpY2lwYXRlIGluCj4gdGhlCj4gPiAgcmVzb3VyY2Ug cHJpb3JpdHkgbWVjaGFuaXNtIGZvbGxvdyB0aGUgbm9ybWFsIHJ1bGVzIG9mIFJGQyAzMjYxLCAK PiA+ICBTZWN0aW9uIDguMi4yOiAiSWYgYSBVQVMgZG9lcyBub3QgdW5kZXJzdGFuZCBhIGhlYWRl ciBmaWVsZCBpbiBhIAo+ID4gIHJlcXVlc3QgKHRoYXQgaXMsIHRoZSBoZWFkZXIgZmllbGQgaXMg bm90IGRlZmluZWQgaW4gdGhpcyAKPiA+ICBzcGVjaWZpY2F0aW9uIG9yIGluIGFueSBzdXBwb3J0 ZWQgZXh0ZW5zaW9uKSwgdGhlIHNlcnZlciBNVVNUIGlnbm9yZSAKPiA+ICB0aGF0IGhlYWRlciBm aWVsZCBhbmQgY29udGludWUgcHJvY2Vzc2luZyB0aGUgbWVzc2FnZSIuICIgCj4gPiAKPiA+IEJ1 dCBJIGRvIG5vdCBzZWUgYW55d2hlcmUgdGhhdCBpcyBzYXlzIHRoYXQgYSBVQVMgdGhhdCBET0VT IAo+ID4gdW5kZXJzdGFuZCB0aGUgbmFtZXNwYWNlIGlzIAo+ID4gZm9yYmlkZGVuIGZyb20gZGVs ZXRpbmcgaXQuICBGb3IgaW5zdGFuY2UsIHNlYyA0LjcuMSBvZiA0NDEyIHNheXMgCj4gPiB0aGF0 ICJ0aGUgVUFDIAo+ID4gIE1BWSBhdHRlbXB0IGEgc3Vic2VxdWVudCByZXF1ZXN0IHdpdGggdGhl IHNhbWUgb3IgZGlmZmVyZW50IHJlc291cmNlIAo+ID4gIHZhbHVlLiIgIFRoaXMgY2VydGFpbmx5 IGltcGxpZXMgdGhlIGFiaWxpdHkgdG8gb3ZlcndyaXRlIG9yIGRlbGV0ZSAKPiA+IGFuIFJQSCBu YW1lc3BhY2UuICAgCj4gPiAKPiA+IChTZWUgYWxzbywgZm9yIGluc3RhbmNlIHRoZSBQVFNDIFNB QyBkb2N1bWVudCBvbiB0aGUgdXNlIG9mIHRoZSBldHMgCj4gPiBhbmQgd3BzIG5hbWVzcGFjZXMp IAo+ID4gCj4gPiBJbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlc2Ugc3RhdGVtZW50cywgeW91IGdp dmUgMyBvcHRpb25zLSAKPiA+ICJUaGVzZSBwcm94aWVzIGluIHRoZSBzZXJ2aWNlIHByb3ZpZGVy IAo+ID4gIE1BWSBlaXRoZXIgCj4gPiAKPiA+ICBvICBhY2NlcHQgdGhlIGV4aXN0aW5nIFJQSCB2 YWx1ZSB3aXRoICJlc25ldCIgaW4gaXQsIGlmIG9uZSBpcyAKPiA+ICAgICBwcmVzZW50LCBhbmQg Z3JhbnQgcmVsYXRpdmUgcHJlZmVyZW50aWFsIHRyZWF0bWVudCB0byB0aGUgcmVxdWVzdCAKPiA+ ICAgICB3aGVuIGZvcndhcmRpbmcgaXQgdG8gdGhlIEVTSU5ldC4gCj4gPiAKPiA+ICBvICByZXBs YWNlIGFueSBleGlzdGluZyBSUEggdmFsdWUsIGlmIG9uZSBpcyBwcmVzZW50LCBhbmQgaW5zZXJ0 IGFuIAo+ID4gICAgICJlc25ldCIgbmFtZXNwYWNlIGFuZCBnaXZlIHJlbGF0aXZlIHByZWZlcmVu dGlhbCB0cmVhdG1lbnQgdG8gdGhlIAo+ID4gICAgIHJlcXVlc3Qgd2hlbiBmb3J3YXJkaW5nIGl0 IHRvIHRoZSBFU0lOZXQuIAo+ID4gCj4gPiAgbyAgaW5zZXJ0IGFuICJlc25ldCIgbmFtZXNwYWNl IGluIGEgbmV3IFJQSCBhbmQgZ2l2ZSByZWxhdGl2ZSAKPiA+ICAgICBwcmVmZXJlbnRpYWwgdHJl YXRtZW50IHRvIHRoZSByZXF1ZXN0IHdoZW4gZm9yd2FyZGluZyB0aGUgU0lQIAo+ID4gICAgIHJl cXVlc3QgdG93YXJkcyB0aGUgRVNJTmV0LiIgCj4gPiAKPiA+IFdoeSBkbyB5b3UgZXhjbHVkZSB0 aGUgcG9zc2liaWxpdHkgb2YgYWRkaW5nIHRoZSBlc25ldCBSUEggdmFsdWUgCj4gPiB3aXRob3V0 ICJyZXBsYWNpbmciIGFuIGV4aXN0aW5nIFJQSCB2YWx1ZT8gCj4gPiAKPiA+IEZpbmFsbHksIHRo ZXJlIGlzIGFub3RoZXIgcG9pbnQgdGhhdCAgbmVlZHMgdG8gYmUgbWFkZSBjbGVhci4gIEF0IAo+ ID4gbGVhc3Qgb25lIHBlcnNvbiBoYXMgY29udGFjdGVkIG1lIGV4cHJlc3NpbmcgY29uY2VybiB0 aGF0IHRoaXMgSUQgCj4gPiBpbXBsaWVkIHRoYXQgdGhlIGVzbmV0IG5hbWVzcGFjZSB3b3VsZCAg aGF2ZSBwcmlvcml0eSBvdmVyIG90aGVyIAo+ID4gbmFtZXNwYWNlcyAoaW4gcGFydGljdWxhciB3 cHMgYW5kIGV0cykuICBJIGFzc3VyZWQgaGltIHRoYXQgdGhpcyB3YXMKPiA+IG5vdCB0aGUgY2Fz ZSwgdGhhdCB0aGVyZSB3YXMgbm90aGluZyBwcmV2ZW50IHRoZSBleHBlY3RlZCBiZWhhdmlvciAt Cj4gPiB0aGF0IHRoZSBldHMgYW5kIHdwcyBuYW1lc3BhY2VzIHdvdWxkIGJlIHByaW9yaXRpemVk IGFoZWFkIG9mIGVzbmV0IAo+ID4gaW4gR0VUUyBTZXJ2aWNlIFByb3ZpZGVyIG5ldHdvcmtzLiAK PiA+IAo+ID4gSG93ZXZlciwgc2luY2UgdGhlIHF1ZXN0aW9uIGhhcyBhbHJlYWR5IGFyaXNlbiwg aXQgd291bGQgYmUgYSBnb29kIAo+ID4gaWRlYSB0byBjbGFyaWZ5ICB0aGlzLCBwZXJoYXBzIGlu ICBzZWN0aW9uIDMsIHdoZXJlIHlvdSBkaXNjdXNzICB0aGUKPiA+IG90aGVyIG5hbWVzcGFjZXMu ICBJbiBwYXJ0aWN1bGFyLCBpdCBuZWVkcyB0byBiZSBtYWRlIGNsZWFyIGluIAo+ID4gc2VjdGlv biAzLjIgIHRoYXQsIGV2ZW4gaWYgICJ0aGUgICBsb2NhbCBqdXJpc2RpY3Rpb24gcHJlZmVycmVk IHRvIAo+ID4gcHJlZW1wdCBub3JtYWwgY2FsbHMgaW4gbGlldSBvZiAKPiA+ICBjb21wbGV0aW5n IGVtZXJnZW5jeSBjYWxscy4gIiwgZXNuZXQgY2FsbHMgd2lsbCBOT1QgcHJlZW1wdCB3cHMgb3Ig ZXRzCj4gY2FsbHMuCj4gPiAKPiA+IEJ5IHRoZSB3YXksIEkgdGhpbmsgeW91IG1lYW4gInRoZSAg IGxvY2FsIGp1cmlzZGljdGlvbiBwcmVmZXJyZWQgdG8gCj4gPiBwcmVlbXB0IG5vcm1hbCBjYWxs cyBpbiBvcmRlciB0byBjb21wbGV0ZSBlbWVyZ2VuY3kgY2FsbHMuICIgIC0gbm90IAo+ID4gImlu IGxpZXUgb2YiLiAgT3IgcGVyaGFwcyAidGhlICAgbG9jYWwganVyaXNkaWN0aW9uIHByZWZlcnJl ZCB0byAKPiA+IHByZWVtcHQgbm9ybWFsIGNhbGxzIGluIGxpZXUgb2YgIGRyb3BwaW5nIGVtZXJn ZW5jeSBjYWxscy4gIiAKPiA+IAo+ID4gSW4gZmFjdCwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRo YXQgNDQxMiBwZXJtaXRzIGEgY2FsbCB3aXRoIGFuIFJQSCAKPiA+IChlLmcuLCBlc25ldCkgIHRv IHByZWVtcHQgYSAibm9ybWFsIiBjYWxsICh3aXRoIG5vIFJQSCBuYW1lc3BhY2UpLiAgCj4gPiBT ZWN0aW9uIDQuNy4yLjEgb2YgNDQxMiBzYXlzIAo+ID4gIjQuNy4yLjEuICBVc2VyIEFnZW50IFNl cnZlcnMgYW5kIFByZWVtcHRpb24gQWxnb3JpdGhtIAo+ID4gCj4gPiAgQSBVQVMgY29tcGxpYW50 IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgdGVybWluYXRlIGEgc2Vzc2lvbiAKPiA+ICBl c3RhYmxpc2hlZCB3aXRoIGEgdmFsaWQgbmFtZXNwYWNlIGFuZCBsb3dlci1wcmlvcml0eSB2YWx1 ZSBpbiBmYXZvciAKPiA+ICBvZiBhIG5ldyBzZXNzaW9uIHNldCB1cCB3aXRoIGEgdmFsaWQgbmFt ZXNwYWNlIGFuZCBoaWdoZXIgcmVsYXRpdmUgCj4gPiAgcHJpb3JpdHkgdmFsdWUsIHVubGVzcyBs b2NhbCBwb2xpY3kgaGFzIHNvbWUgZm9ybSBvZiBjYWxsLXdhaXRpbmcgCj4gPiAgY2FwYWJpbGl0 eSBlbmFibGVkLiAiIAo+ID4gCj4gPiBJdCBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCBwcmVl bXB0aW5nIGEgY2FsbCB3aXRoIG5vIFJQSCAKPiA+IAo+ID4gVGhhbmtzIAo+ID4gCj4gPiBKYW5l dCAKPiA+IAo+ID4gCj4gPiAKPiA+IAo+ID4gCj4gPiAKPiA+IFRoaXMgaXMgYSBQUklWQVRFIG1l c3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIAo+ID4gcGxlYXNl IGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9m IHRoZSAKPiA+IG1pc3Rha2UgaW4gZGVsaXZlcnkuIAo+ID4gTk9URTogUmVnYXJkbGVzcyBvZiBj b250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIAo+ID4gQ1NDIHRv IGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQg Cj4gPiB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5 IHBlcm1pdHRpbmcgdGhlIAo+ID4gdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLiAKPiA+ IAo+ID4gIkphbWVzIE0uIFBvbGsiIDxqbXBvbGtAY2lzY28uY29tPiAKPiA+IFNlbnQgYnk6IGVj cml0LWJvdW5jZXNAaWV0Zi5vcmcgCj4gPiAxMC8yNy8yMDA4IDA4OjMyIFBNIAo+ID4gCj4gPiAg IAo+ID4gICAKPiA+IAo+ID4gVG8gCj4gPiAKPiA+ICInRUNSSVQnIiA8ZWNyaXRAaWV0Zi5vcmc+ IAo+ID4gCj4gPiBjYyAKPiA+IAo+ID4gICAKPiA+IAo+ID4gU3ViamVjdCAKPiA+IAo+ID4gW0Vj cml0XSBkcmFmdC1pZXRmLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwIAo+ ID4gCj4gPiAKPiA+ICAgCj4gPiAgIAo+ID4gCj4gPiAgIAo+ID4gCj4gPiAgIAo+ID4gCj4gPiAK PiA+IAo+ID4gCj4gPiAKPiA+IAo+ID4gRUNSSVQgV0cKPiA+IAo+ID4gSGVyZSBpcyBhIHVwZGF0 ZSB0byBhIElEIEkgdGhpbmsgaXMgcHJldHR5IG5lYXIgZG9uZSwgZ2l2ZW4gdGhhdCB0aGlzIAo+ ID4gaXMgbWVyZWx5IGFuIElBTkEgcmVnaXN0cmF0aW9uIElEIG9mIGFuIGV4aXN0aW5nIG1lY2hh bmlzbS4KPiA+IAo+ID4gQ29tbWVudHMgYXJlIHdhbnRlZAo+ID4gCj4gPiA+QSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIAo+ ID4gPmRpcmVjdG9yaWVzLgo+ID4gPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEVt ZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCAKPiA+ID5JbnRlcm5ldCBUZWNobm9sb2dp ZXMgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4KPiA+ID4KPiA+ID4KPiA+ID4gICAgICAgICBU aXRsZSAgICAgICAgICAgOiBJQU5BIFJlZ2lzdGVyaW5nIGEgU0lQIFJlc291cmNlIFByaW9yaXR5 IAo+ID4gPiBIZWFkZXIgTmFtZXNwYWNlIGZvciBMb2NhbCBFbWVyZ2VuY3kgQ29tbXVuaWNhdGlv bnMKPiA+ID4gICAgICAgICBBdXRob3IocykgICAgICAgOiBKLiBQb2xrCj4gPiA+ICAgICAgICAg RmlsZW5hbWUgICAgICAgIDogCj4gPiA+IGRyYWZ0LWlldGYtZWNyaXQtbG9jYWwtZW1lcmdlbmN5 LXJwaC1uYW1lc3BhY2UtMDAudHh0Cj4gPiA+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogOQo+ ID4gPiAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMDgtMTAtMjcKPiA+ID4KPiA+ID5UaGlz IGRvY3VtZW50IGNyZWF0ZXMgYW5kIElBTkEgcmVnaXN0ZXJzIHRoZSBuZXcgU2Vzc2lvbiBJbml0 aWF0aW9uCj4gPiA+UHJvdG9jb2wgKFNJUCkgUmVzb3VyY2UgUHJpb3JpdHkgaGVhZGVyIChSUEgp IG5hbWVzcGFjZSAiZXNuZXQiIGZvcgo+ID4gPmxvY2FsIGVtZXJnZW5jeSB1c2FnZSB0byBhIHB1 YmxpYyBzYWZldHkgYW5zd2VyaW5nIHBvaW50IChQU0FQKSwKPiA+ID5iZXR3ZWVuIFBTQVBzLCBh bmQgYmV0d2VlbiBhIFBTQVAgYW5kIGZpcnN0IHJlc3BvbmRlcnMgYW5kIHRoZWlyCj4gPiA+b3Jn YW5pemF0aW9ucy4KPiA+ID4KPiA+ID5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoK PiA+ID5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVjcml0 LWxvY2FsLQo+ID4gZW1lcmdlbmN5LXJwaC1uYW1lc3BhY2UtMDAudHh0Cj4gPiA+Cj4gPiA+Cj4g PiA+Cj4gPiA+PGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1l Y3JpdC1sb2NhbC0KPiA+IGVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAwLnR4dD4KPiA+IAo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IEVjcml0 IG1haWxpbmcgbGlzdAo+ID4gRWNyaXRAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gPiBFY3JpdCBtYWlsaW5nIGxpc3QKPiA+IEVjcml0QGlldGYu b3JnCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IAo+ID4g ICAKPiA+ICAgCj4gPiBTdHVhcnQgR29sZG1hbiAKPiA+IEFsY2F0ZWwtTHVjZW50IAo+ID4gU3R1 YXJ0LkdvbGRtYW5AYWxjYXRlbC1sdWNlbnQuY29tIAo+ID4gKzEgNjAyIDQ5MyA4NDM4IAo+ID4g KzEgNDgwIDQxNCAxMjYwIG1vYmlsZSAKPiA+IFAgcGxlYXNlIHNhdmUgYSB0cmVlIGJ5IG5vdCBw cmludGluZyB0aGlzIGUtbWFpbC4gCj4gPiAgIAo+ID4gICAKPiA+ICAKPiAKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkVjcml0IG1haWxpbmcgbGlzdApF Y3JpdEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 Cg== From ecrit-bounces@ietf.org Thu Nov 20 09:26:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F683A6943; Thu, 20 Nov 2008 09:26:03 -0800 (PST) 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 DA1343A6943 for ; Thu, 20 Nov 2008 09:26:01 -0800 (PST) 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 M+07+moF2uSf for ; Thu, 20 Nov 2008 09:26:00 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 16FC33A67FA for ; Thu, 20 Nov 2008 09:26:00 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 09:25:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 09:24:45 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533686@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <017a01c94b31$8bfa57d0$a3ef0770$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 Thread-Index: AclLLkOCvH4EF1BDRSW3h6LtCMKLfAAAZ2owAAD5awA= References: <015301c94b2b$60155ee0$20401ca0$@net> <017a01c94b31$8bfa57d0$a3ef0770$@net> From: "Roger Marshall" To: "Brian Rosen" , "Janet P Gunn" Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It seems like we're diverging here. In the ESInet, it seems to me, that the owner/manager of that ESInet will set the priority treatment as they deem fit. Only in the public network arena will real prioritization have a chance to be "standardized". So far what do people say is the ordering? Public net: P1. ets/wps? (PSAPs may not be so eager to agree) P2. esnet P3. Private net (ESInet): (anything they want) Lastly, what kind of prioritization does a government official (a servant of the people) get when they themselves initiate an emergency call? esnet or ets/wps? (In a private ESInet, it may be to their disadvantage to keep the wrong one.) -roger marshall. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 9:01 AM > To: 'Janet P Gunn' > Cc: Ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > An "Emergency Services IP Network" is a private IP network to > which, we hope, all public safety agencies are connected. It > handles all the traffic of a public safety agency, which > would include routine and priority citizen to authority, > authority to authority and authority to citizen traffic. > It's not entirely clear to me yet whether we can reuse a > number of the existing name spaces as well as a new one. For > example, some of the agency-agency traffic will require > pre-emption, but the existing MLPP namespace may be quite sufficient. > > It does occur to me that we could have ETS and possibly WPS > traffic, in that if the normal access to public facilities > traversed the ESInet towards some kind of gateway to a public > network, then we would either have to have the ETS/WPS > values, or remark them at the edge if a caller inside the > ESInet needed to call someone outside the ESInet and needed > ETS/WPS priority to do so. If we carried the priority > marking across the ESInet, ETS/WPS would be lower priority > than some other traffic, but higher than, for example, > citizen to authority emergency calls. > > Brian > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: Thursday, November 20, 2008 11:37 AM > To: Brian Rosen > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > Brian, > > I need to understand this better. > > Exactly what are the constraints of the "emergency services > IP network"? Is this a network in which EVERY call would > have the RPH with the esnet namespace (just varying priority > values),and there would be no "normal" calls? Or would their > be a mixture of calls with and without RPH wit esnet? > > Janet > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > A suggestion was made to me that we should define two namespaces. > > > > One would be used in public networks, and generally would > be used to request > > resource priority for citizen to authority and possibly > authority to citizen > > calls. This would have lower priority than ETS/WPS. > > > > The other would be for use within emergency services IP > networks. It would > > be unlikely that ETS/WPS would be used within those > networks, but if it was, > > some values within the namespace would need higher priority > that ETS/WPS. > > For example, a message which was an incident commanders > "evacuate" message > > would be higher than a ETS/WPS traffic. On the other hand, > a citizen to > > authority emergency call would have lower priority. > > > > I would be happier with one namespace and more values in > that namespace for > > all of this, but I was advised that two namespaces was a > better choice. > > > > Brian > > > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Janet P Gunn > > Sent: Thursday, November 20, 2008 11:00 AM > > To: GOLDMAN, STUART O (STUART) > > Cc: Ecrit@ietf.org > > Subject: Re: [Ecrit] Ecrit] > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > Stu, > > > > I intended to say that the esnet namespace needs to be at a > LOWER priority > > than the ets and wps namespaces, in any network that > recognizes ets and wps > > as described in 10.5 and 10.6 of RFC4412. > > > > Janet > > > > "GOLDMAN, STUART O \(STUART\)" > wrote on > > 11/20/2008 10:22:49 AM: > > > > > Janet, > > > > > > With regard to you e-mail below, did you intend that > esnet could be > > > at the same level of priority as ETS & WPS, or that ETS > & WPS need > > > to be at an even higher priority than esnet? > > > > > > > > > > > > Stuart Goldman > > > Alcatel-Lucent > > > Stuart.Goldman@alcatel-lucent.com > > > +1 602 493 8438 > > > +1 480 414 1260 mobile > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > Sent by: ecrit-bounces@ietf.org > > > 10/27/2008 11:45 PM > > > > > > > > > > > > To > > > > > > "James M. Polk" > > > > > > cc > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > Subject > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > to, as these > > > comments apply to earlier versions as well. > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > "This document IANA registers the "esnet" > > > RPH namespace for use within emergency services > networks, not just > > > of those from citizens to PSAPs." (no clear antecedent > for "those") > > > > > > Perhaps > > > "This document IANA registers the "esnet" > > > RPH namespace for use within emergency services > networks, not just > > > for calls or sessions > > > from citizens to PSAPs." > > > > > > Section 2 says > > > "This document updates the behaviors of the SIP Resource Priority > > > header, defined in [RFC4412], during the treatment options > > > surrounding this new "esnet" namespace only. The usage of the > > > "esnet" namespace does not have a normal, or routine > call level. > > > Every use of this namespace will be in times of an > emergency, where > > > at least one end of the signaling is with a local emergency > > > organization." > > > > > > I don't see this as an "update of the behavior of 4412". Neither > > > the ets namespace not the wps > > > namespace have a "normal" or "routine" call level. Every > use of the > > > wps and ets namespaces will > > > have priority over calls without RPH. > > > > > > You say "This > > > namespace, therefore, MAY be overwritten or deleted, > contrary to the > > > rules of RFC 4412 [RFC4412]." > > > > > > It is not clear to me why this is "contrary to the rules > of 4412". > > > It is certainly anticipated > > > that other RPH will be overwritten or deleted, when the UAS > > > understands the namespace. > > > > > > 4412 says "Existing implementations of RFC 3261 that do > not participate in > > the > > > resource priority mechanism follow the normal rules of RFC 3261, > > > Section 8.2.2: "If a UAS does not understand a header field in a > > > request (that is, the header field is not defined in this > > > specification or in any supported extension), the server > MUST ignore > > > that header field and continue processing the message". " > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > understand the namespace is > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > > that "the UAC > > > MAY attempt a subsequent request with the same or > different resource > > > value." This certainly implies the ability to overwrite > or delete > > > an RPH namespace. > > > > > > (See also, for instance the PTSC SAC document on the use > of the ets > > > and wps namespaces) > > > > > > Immediately following these statements, you give 3 options- > > > "These proxies in the service provider > > > MAY either > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > present, and grant relative preferential treatment to > the request > > > when forwarding it to the ESINet. > > > > > > o replace any existing RPH value, if one is present, > and insert an > > > "esnet" namespace and give relative preferential > treatment to the > > > request when forwarding it to the ESINet. > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > preferential treatment to the request when forwarding the SIP > > > request towards the ESINet." > > > > > > Why do you exclude the possibility of adding the esnet RPH value > > > without "replacing" an existing RPH value? > > > > > > Finally, there is another point that needs to be made clear. At > > > least one person has contacted me expressing concern that this ID > > > implied that the esnet namespace would have priority over other > > > namespaces (in particular wps and ets). I assured him > that this was > > > not the case, that there was nothing prevent the expected > behavior - > > > that the ets and wps namespaces would be prioritized > ahead of esnet > > > in GETS Service Provider networks. > > > > > > However, since the question has already arisen, it would > be a good > > > idea to clarify this, perhaps in section 3, where you > discuss the > > > other namespaces. In particular, it needs to be made clear in > > > section 3.2 that, even if "the local jurisdiction > preferred to > > > preempt normal calls in lieu of > > > completing emergency calls. ", esnet calls will NOT > preempt wps or ets > > calls. > > > > > > By the way, I think you mean "the local jurisdiction > preferred to > > > preempt normal calls in order to complete emergency > calls. " - not > > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > In fact, it is not clear to me that 4412 permits a call > with an RPH > > > (e.g., esnet) to preempt a "normal" call (with no RPH > namespace). > > > Section 4.7.2.1 of 4412 says > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > A UAS compliant with this specification MUST terminate a session > > > established with a valid namespace and lower-priority > value in favor > > > of a new session set up with a valid namespace and > higher relative > > > priority value, unless local policy has some form of > call-waiting > > > capability enabled. " > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > Thanks > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > > please delete without copying and kindly advise us by > e-mail of the > > > mistake in delivery. > > > NOTE: Regardless of content, this e-mail shall not > operate to bind > > > CSC to any order or other contract unless pursuant to explicit > > > written agreement or government initiative expressly > permitting the > > > use of e-mail for such purpose. > > > > > > "James M. Polk" > > > Sent by: ecrit-bounces@ietf.org > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > To > > > > > > "'ECRIT'" > > > > > > cc > > > > > > > > > > > > Subject > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > Here is a update to a ID I think is pretty near done, > given that this > > > is merely an IANA registration ID of an existing mechanism. > > > > > > Comments are wanted > > > > > > >A New Internet-Draft is available from the on-line > Internet-Drafts > > > >directories. > > > >This draft is a work item of the Emergency Context > Resolution with > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > Title : IANA Registering a SIP > Resource Priority > > > > Header Namespace for Local Emergency Communications > > > > Author(s) : J. Polk > > > > Filename : > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > Pages : 9 > > > > Date : 2008-10-27 > > > > > > > >This document creates and IANA registers the new Session > Initiation > > > >Protocol (SIP) Resource Priority header (RPH) namespace > "esnet" for > > > >local emergency usage to a public safety answering point (PSAP), > > > >between PSAPs, and between a PSAP and first responders and their > > > >organizations. > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > _______________________________________________ > > > 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 > > > > > > > > > Stuart Goldman > > > Alcatel-Lucent > > > Stuart.Goldman@alcatel-lucent.com > > > +1 602 493 8438 > > > +1 480 414 1260 mobile > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 11:36:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212763A6ACF; Thu, 20 Nov 2008 11:36:50 -0800 (PST) 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 8FA753A6ACF for ; Thu, 20 Nov 2008 11:36:48 -0800 (PST) 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 5VFPa8LZRUqu for ; Thu, 20 Nov 2008 11:36:47 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id C385A3A6A44 for ; Thu, 20 Nov 2008 11:36:46 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 11:36:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 11:35:33 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <015401c94b2c$374c6ed0$a5e54c70$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> From: "Roger Marshall" To: "Brian Rosen" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If the choice is between preventing, allowing, or requiring PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I would prefer 'require' since *most* of the location-aware 3G compatible handsets/aircards over the next several years will (I predict) have a SUPL stack included. In the same time frame, many of those will also have WiFi support, others will have LTE or WiMAX support as hybrids. SUPL will be common-place. OMA may not be 'Open-Source', it is open-minded, and there is movement afoot to expand OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) w/respect expected proposals such as LocSIP, etc. Over the fairly near-term, I think there will be fewer protocol, location representation, and privacy discontinuities - things that too often get cited - yet are seldom well understood. Let's encourage continued IETF communication with OMA/SUPL - not block its use altogether. This is a case where we need to be inclusive, not exclusive. As to the mobile RV sample case, the solution is also forseeable - especially given that the location of the 3G aircard in the router is good enough for routing. The scenario given needs some integration, but is doable. Given that the aircard acts as a logical SET, with a SUPL stack on board, and a GPS/AGPS chipset inside. This combination *WILL* (I believe) interoperate with a number of end client applications to initiate and complete a location-routed, 3261 style SIP, emergency call through the core, and into an ESInet. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 8:23 AM > To: 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > It's very hard to have L2 specific LCPs. The problem is that > the clients are generally not very L2 aware. It's the > clients that have the problem. > You can do things like interwork an L2 specific LCP to a > common LCP so that non L2 aware devices can work, but you > have to do that, and usually, that's impractical. Use my > example. Suppose that the L2 used SUPL. It's possible for > the PC Card that is plugged into the router could implement a > SUPL client and a HELD server and interwork SUPL in the GSM > system to HELD on the Ethernet so the Ethernet VoIP phone > could get location via HELD. Possible, but not practical. > There are all sorts of these kinds of problems. That's why > L2 specific LCPs don't work. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 11:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > The IETF can't (and shouldn't) try to make particular > standards for every access technology that's out there. What > we can say is that the paradigm for those protocols should be > the same as at the IP layer: > Clients MUST implement all, networks MUST implement at least one. > > (This is a little different from the text I sent before, and > clearer, I > think.) > > All I'm saying is that we shouldn't try to enumerate all the > possible protocols at lower layers, we should just state the > general rule. It seems to me that this achieves the same > level of interoperability at all layers. > > --Richard > > > If there are exactly two LCPs all UAs must implement, and > any number > > of optional ones, then every network has to implement at > least one of > > those > two > > LCPs, and any number of optional ones. That means that > "any number of > > optional ones" is useless for both parties. > > If the network can limit UAs to ONLY those that implement > one of the > > optional protocols, then it works, but in practice, it is usually > impossible > > to do that. My example is the wired, Ethernet connected > phone in an > > RV traveling down the road with wireless data card in a > router. These > > EXIST, now. > > > > Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 10:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I think we need to pull up a level. It's not reasonable > for an RFC to > > try to list all of the location protocols out there, if for > no other > > reason than that it will rapidly become obsolete. Instead, > we should > > say something like the following: > > > > " > > INT-12 Devices MUST support the DHCP location options [RFC4776] and > > [RFC3825] and HELD > [I-D.ietf-geopriv-http-location-delivery]. Devices > > SHOULD support all location protocols supported at lower layers by > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > " > > > > > > > > > > Brian Rosen wrote: > >> The problem with SUPL is that the majority of networks where SUPL > >> would > be > >> available have a proxy (E-CSCF) insert location. It also has an > >> incompatible location representation, and an incompatible > privacy model. > >> That makes it very hard to interwork with any of the rest > of the IETF > > work. > >> I will say this. For quite some time, the IETF has been trying to > > interest > >> OMA into cooperation on location so that we have > interoperability at > >> the protocol, location representation and privacy levels. So far, > >> that has > > not > >> happened. If, as part of a comprehensive agreement to accomplish > >> such a goal, SUPL became one of the LCPs, I would not object. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Gabor.Bajko@nokia.com > >> Sent: Thursday, November 20, 2008 9:26 AM > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > >> Hi, > >> > >> Is the intent to list the LCPs which are access-type > agnostic but not > >> supported anywhere, or instead have a list of LCPs which > are highly > >> probable to produce the intended result? > >> > >> There are restrictions everywhere, things come at a cost > even in the > >> general Internet model. The reality is that most of the > devices with > >> internet access have a home network already. > >> > >> - Gabor > >> > >> > >> >-----Original Message----- > >> >From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > >> >Sent: Thursday, November 20, 2008 12:06 AM > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >> > > >> >Hi Gabor, > >> > > >> >The list of LCPs in the phone BCP is a must support list, and is > >> access- > >> >type agnostic. > >> >I am curious that you say that SUPL is a MUST support > given that: > >> >a) it requires a home network in order to operate > >> >b) it simply doesn't work for DSL or Cable > >> >c) it is questionable whether it is really deployable for WiFi > >> networks > >> > > >> >Can you perhaps describe how it fits into the general > Internet model? > >> > > >> >Cheers > >> >James > >> > > >> > > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >> >Sent: Thu 11/20/2008 12:48 AM > >> >To: ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > > >> >I was requested to send my observations regarding this > requirement: > >> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > location options > >> > [RFC4776] and [RFC3825], HELD > >> > [I-D.ietf-geopriv-http-location-delivery] and > LLDP-MED [LLDP-MED]. > >> > > >> > > >> >I believe we should come up with a list of LCPs which > are likely > >> to be > >> >supported in devices in a not so distant future. Since > I have no > >> seen or > >> >heard about LLDP support yet, at least that should be replaced > >> with what > >> >is mostly used today (OMA SUPL) and the 802.11 > mechanism, with the > >> >condition that this MUST only be supported if there is a wifi > >> interface > >> >available on the device. > >> > > >> >- Gabor > >> > > >> > > >> > > >> >________________________________ > >> > > >> >From: ext Tschofenig, Hannes > >> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >> >Subject: Location Protocols in Phone BCP > >> > > >> > > >> > > >> >Gabor, > >> > > >> >Could you please raise your question about location > protocols in > >> Phone > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > >> > > >> >Ciao > >> >Hannes > >> > > >> > > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >This message is for the designated recipient only and may > >> >contain privileged, proprietary, or otherwise private > information. > >> >If you have received it in error, please notify the sender > >> >immediately and delete the original. Any unauthorized use of > >> >this email is prohibited. > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >[mf2] > >> > >> _______________________________________________ > >> 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 > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 11:46:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87F628C23B; Thu, 20 Nov 2008 11:46:25 -0800 (PST) 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 4208828C23C for ; Thu, 20 Nov 2008 11:46:24 -0800 (PST) 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 XAvxAanSjfIw for ; Thu, 20 Nov 2008 11:46:22 -0800 (PST) Received: from mail1.911.org (mail1.911.org [65.67.130.186]) by core3.amsl.com (Postfix) with ESMTP id 3196428C23A for ; Thu, 20 Nov 2008 11:46:22 -0800 (PST) Received: from ghcmail [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Thu, 20 Nov 2008 13:40:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 13:46:17 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAZxn4A== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> From: "Marc Berryman" To: "Roger Marshall" , "Brian Rosen" , "Richard Barnes" X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2008_11_20_13_40_44 Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger makes a valid and compelling argument, one which I agree with. Marc B -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, November 20, 2008 1:36 PM To: Brian Rosen; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP If the choice is between preventing, allowing, or requiring PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I would prefer 'require' since *most* of the location-aware 3G compatible handsets/aircards over the next several years will (I predict) have a SUPL stack included. In the same time frame, many of those will also have WiFi support, others will have LTE or WiMAX support as hybrids. SUPL will be common-place. OMA may not be 'Open-Source', it is open-minded, and there is movement afoot to expand OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) w/respect expected proposals such as LocSIP, etc. Over the fairly near-term, I think there will be fewer protocol, location representation, and privacy discontinuities - things that too often get cited - yet are seldom well understood. Let's encourage continued IETF communication with OMA/SUPL - not block its use altogether. This is a case where we need to be inclusive, not exclusive. As to the mobile RV sample case, the solution is also forseeable - especially given that the location of the 3G aircard in the router is good enough for routing. The scenario given needs some integration, but is doable. Given that the aircard acts as a logical SET, with a SUPL stack on board, and a GPS/AGPS chipset inside. This combination *WILL* (I believe) interoperate with a number of end client applications to initiate and complete a location-routed, 3261 style SIP, emergency call through the core, and into an ESInet. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 8:23 AM > To: 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > It's very hard to have L2 specific LCPs. The problem is that > the clients are generally not very L2 aware. It's the > clients that have the problem. > You can do things like interwork an L2 specific LCP to a > common LCP so that non L2 aware devices can work, but you > have to do that, and usually, that's impractical. Use my > example. Suppose that the L2 used SUPL. It's possible for > the PC Card that is plugged into the router could implement a > SUPL client and a HELD server and interwork SUPL in the GSM > system to HELD on the Ethernet so the Ethernet VoIP phone > could get location via HELD. Possible, but not practical. > There are all sorts of these kinds of problems. That's why > L2 specific LCPs don't work. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 11:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > The IETF can't (and shouldn't) try to make particular > standards for every access technology that's out there. What > we can say is that the paradigm for those protocols should be > the same as at the IP layer: > Clients MUST implement all, networks MUST implement at least one. > > (This is a little different from the text I sent before, and > clearer, I > think.) > > All I'm saying is that we shouldn't try to enumerate all the > possible protocols at lower layers, we should just state the > general rule. It seems to me that this achieves the same > level of interoperability at all layers. > > --Richard > > > If there are exactly two LCPs all UAs must implement, and > any number > > of optional ones, then every network has to implement at > least one of > > those > two > > LCPs, and any number of optional ones. That means that > "any number of > > optional ones" is useless for both parties. > > If the network can limit UAs to ONLY those that implement > one of the > > optional protocols, then it works, but in practice, it is usually > impossible > > to do that. My example is the wired, Ethernet connected > phone in an > > RV traveling down the road with wireless data card in a > router. These > > EXIST, now. > > > > Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 10:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I think we need to pull up a level. It's not reasonable > for an RFC to > > try to list all of the location protocols out there, if for > no other > > reason than that it will rapidly become obsolete. Instead, > we should > > say something like the following: > > > > " > > INT-12 Devices MUST support the DHCP location options [RFC4776] and > > [RFC3825] and HELD > [I-D.ietf-geopriv-http-location-delivery]. Devices > > SHOULD support all location protocols supported at lower layers by > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > " > > > > > > > > > > Brian Rosen wrote: > >> The problem with SUPL is that the majority of networks where SUPL > >> would > be > >> available have a proxy (E-CSCF) insert location. It also has an > >> incompatible location representation, and an incompatible > privacy model. > >> That makes it very hard to interwork with any of the rest > of the IETF > > work. > >> I will say this. For quite some time, the IETF has been trying to > > interest > >> OMA into cooperation on location so that we have > interoperability at > >> the protocol, location representation and privacy levels. So far, > >> that has > > not > >> happened. If, as part of a comprehensive agreement to accomplish > >> such a goal, SUPL became one of the LCPs, I would not object. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Gabor.Bajko@nokia.com > >> Sent: Thursday, November 20, 2008 9:26 AM > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > >> Hi, > >> > >> Is the intent to list the LCPs which are access-type > agnostic but not > >> supported anywhere, or instead have a list of LCPs which > are highly > >> probable to produce the intended result? > >> > >> There are restrictions everywhere, things come at a cost > even in the > >> general Internet model. The reality is that most of the > devices with > >> internet access have a home network already. > >> > >> - Gabor > >> > >> > >> >-----Original Message----- > >> >From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > >> >Sent: Thursday, November 20, 2008 12:06 AM > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >> > > >> >Hi Gabor, > >> > > >> >The list of LCPs in the phone BCP is a must support list, and is > >> access- > >> >type agnostic. > >> >I am curious that you say that SUPL is a MUST support > given that: > >> >a) it requires a home network in order to operate > >> >b) it simply doesn't work for DSL or Cable > >> >c) it is questionable whether it is really deployable for WiFi > >> networks > >> > > >> >Can you perhaps describe how it fits into the general > Internet model? > >> > > >> >Cheers > >> >James > >> > > >> > > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >> >Sent: Thu 11/20/2008 12:48 AM > >> >To: ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > > >> >I was requested to send my observations regarding this > requirement: > >> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > location options > >> > [RFC4776] and [RFC3825], HELD > >> > [I-D.ietf-geopriv-http-location-delivery] and > LLDP-MED [LLDP-MED]. > >> > > >> > > >> >I believe we should come up with a list of LCPs which > are likely > >> to be > >> >supported in devices in a not so distant future. Since > I have no > >> seen or > >> >heard about LLDP support yet, at least that should be replaced > >> with what > >> >is mostly used today (OMA SUPL) and the 802.11 > mechanism, with the > >> >condition that this MUST only be supported if there is a wifi > >> interface > >> >available on the device. > >> > > >> >- Gabor > >> > > >> > > >> > > >> >________________________________ > >> > > >> >From: ext Tschofenig, Hannes > >> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >> >Subject: Location Protocols in Phone BCP > >> > > >> > > >> > > >> >Gabor, > >> > > >> >Could you please raise your question about location > protocols in > >> Phone > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > >> > > >> >Ciao > >> >Hannes > >> > > >> > > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >This message is for the designated recipient only and may > >> >contain privileged, proprietary, or otherwise private > information. > >> >If you have received it in error, please notify the sender > >> >immediately and delete the original. Any unauthorized use of > >> >this email is prohibited. > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >[mf2] > >> > >> _______________________________________________ > >> 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 > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ 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 ecrit-bounces@ietf.org Thu Nov 20 11:47:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220513A69C9; Thu, 20 Nov 2008 11:47:23 -0800 (PST) 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 5A87C3A69C9 for ; Thu, 20 Nov 2008 11:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg8hrMHnnugv for ; Thu, 20 Nov 2008 11:47:20 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id AEAB83A686D for ; Thu, 20 Nov 2008 11:47:16 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAKJkDZF024445; Thu, 20 Nov 2008 21:46:34 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 21:46:33 +0200 Received: from esebe111.NOE.Nokia.com ([172.21.143.154]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 21:46:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 21:46:30 +0200 Message-ID: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EEE82@esebe111.NOE.Nokia.com> In-Reply-To: <015401c94b2c$374c6ed0$a5e54c70$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAZqe/A= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> From: To: , X-OriginalArrivalTime: 20 Nov 2008 19:46:33.0303 (UTC) FILETIME=[B0D1AE70:01C94B48] X-Nokia-AV: Clean Cc: hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Oh, well. Do you want to have text which accommodates current client implementations or instead set requirements for implementations intended to support functionalities defined in ecrit? Some (most?) of the clients out there do use L2 specific location determination extensively. E.g., my device knows its location (at least roughly) by multiple means, being that A-GPS, 2G/3G cell-id, L7 based on L2 identifiers, etc. Since there is a DHCP client in the device, it wouldn't be a big deal supporting the two location specific options. But are there any DHCP servers out there which could provide me with reliable location while I am on the move? The problem I have is that what is used today is excluded from the draft, but we are including things there which may never be deployed. And it would be a naivity thinking that these LCPs would get deployed because they are included in this draft. - Gabor >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Thursday, November 20, 2008 8:23 AM >To: 'Richard Barnes' >Cc: Bajko Gabor (Nokia-CIC/MtView); James.Winterbottom@andrew.com; >ecrit@ietf.org; marc.linsner@cisco.com; Tschofenig Hannes (NSN - >FI/Espoo) >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >It's very hard to have L2 specific LCPs. The problem is that the clients >are generally not very L2 aware. It's the clients that have the problem. >You can do things like interwork an L2 specific LCP to a common LCP so >that >non L2 aware devices can work, but you have to do that, and usually, >that's >impractical. Use my example. Suppose that the L2 used SUPL. It's >possible >for the PC Card that is plugged into the router could implement a SUPL >client and a HELD server and interwork SUPL in the GSM system to HELD on >the >Ethernet so the Ethernet VoIP phone could get location via HELD. >Possible, >but not practical. There are all sorts of these kinds of problems. >That's >why L2 specific LCPs don't work. > >Brian > >-----Original Message----- >From: Richard Barnes [mailto:rbarnes@bbn.com] >Sent: Thursday, November 20, 2008 11:11 AM >To: Brian Rosen >Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; >marc.linsner@cisco.com; hannes.tschofenig@nsn.com >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >The IETF can't (and shouldn't) try to make particular standards for >every access technology that's out there. What we can say is that the >paradigm for those protocols should be the same as at the IP layer: >Clients MUST implement all, networks MUST implement at least one. > >(This is a little different from the text I sent before, and clearer, I >think.) > >All I'm saying is that we shouldn't try to enumerate all the possible >protocols at lower layers, we should just state the general rule. It >seems to me that this achieves the same level of interoperability at all >layers. > >--Richard > >> If there are exactly two LCPs all UAs must implement, and any number of >> optional ones, then every network has to implement at least one of >those >two >> LCPs, and any number of optional ones. That means that "any number of >> optional ones" is useless for both parties. >> If the network can limit UAs to ONLY those that implement one of the >> optional protocols, then it works, but in practice, it is usually >impossible >> to do that. My example is the wired, Ethernet connected phone in an RV >> traveling down the road with wireless data card in a router. These >EXIST, >> now. >> >> Brian >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, November 20, 2008 10:11 AM >> To: Brian Rosen >> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >ecrit@ietf.org; >> marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> I think we need to pull up a level. It's not reasonable for an RFC to >> try to list all of the location protocols out there, if for no other >> reason than that it will rapidly become obsolete. Instead, we should >> say something like the following: >> >> " >> INT-12 Devices MUST support the DHCP location options [RFC4776] and >> [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices >> SHOULD support all location protocols supported at lower layers by >their >> interfaces (e.g., LLDP-MED [LLDP-MED]). >> " >> >> >> >> >> Brian Rosen wrote: >>> The problem with SUPL is that the majority of networks where SUPL >would >be >>> available have a proxy (E-CSCF) insert location. It also has an >>> incompatible location representation, and an incompatible privacy >model. >>> That makes it very hard to interwork with any of the rest of the IETF >> work. >>> I will say this. For quite some time, the IETF has been trying to >> interest >>> OMA into cooperation on location so that we have interoperability at >the >>> protocol, location representation and privacy levels. So far, that >has >> not >>> happened. If, as part of a comprehensive agreement to accomplish such >a >>> goal, SUPL became one of the LCPs, I would not object. >>> >>> Brian >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of >>> Gabor.Bajko@nokia.com >>> Sent: Thursday, November 20, 2008 9:26 AM >>> To: James.Winterbottom@andrew.com; ecrit@ietf.org >>> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>> Hi, >>> >>> Is the intent to list the LCPs which are access-type agnostic but not >>> supported anywhere, or instead have a list of LCPs which are highly >>> probable to produce the intended result? >>> >>> There are restrictions everywhere, things come at a cost even in the >>> general Internet model. The reality is that most of the devices with >>> internet access have a home network already. >>> >>> - Gabor >>> >>> >>> >-----Original Message----- >>> >From: ext Winterbottom, James >[mailto:James.Winterbottom@andrew.com] >>> >Sent: Thursday, November 20, 2008 12:06 AM >>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>> > >>> >Hi Gabor, >>> > >>> >The list of LCPs in the phone BCP is a must support list, and is >>> access- >>> >type agnostic. >>> >I am curious that you say that SUPL is a MUST support given that: >>> >a) it requires a home network in order to operate >>> >b) it simply doesn't work for DSL or Cable >>> >c) it is questionable whether it is really deployable for WiFi >>> networks >>> > >>> >Can you perhaps describe how it fits into the general Internet >model? >>> > >>> >Cheers >>> >James >>> > >>> > >>> >-----Original Message----- >>> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >>> >Sent: Thu 11/20/2008 12:48 AM >>> >To: ecrit@ietf.org >>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> > >>> >I was requested to send my observations regarding this requirement: >>> > >>> > ED-21/INT-12 Devices MUST support all of: DHCP location options >>> > [RFC4776] and [RFC3825], HELD >>> > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP- >MED]. >>> > >>> > >>> >I believe we should come up with a list of LCPs which are likely to >>> be >>> >supported in devices in a not so distant future. Since I have no >seen >>> or >>> >heard about LLDP support yet, at least that should be replaced with >>> what >>> >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >>> >condition that this MUST only be supported if there is a wifi >>> interface >>> >available on the device. >>> > >>> >- Gabor >>> > >>> > >>> > >>> >________________________________ >>> > >>> >From: ext Tschofenig, Hannes >>> > >>> >Sent: Tuesday, November 18, 2008 12:49 PM >>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>> >Subject: Location Protocols in Phone BCP >>> > >>> > >>> > >>> >Gabor, >>> > >>> >Could you please raise your question about location protocols in >>> Phone >>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>> > >>> >Ciao >>> >Hannes >>> > >>> > >>> >>>> --------------------------------------------------------------------- >-- >>> -- >>> >----------------------- >>> >This message is for the designated recipient only and may >>> >contain privileged, proprietary, or otherwise private information. >>> >If you have received it in error, please notify the sender >>> >immediately and delete the original. Any unauthorized use of >>> >this email is prohibited. >>> >>>> --------------------------------------------------------------------- >-- >>> -- >>> >----------------------- >>> >[mf2] >>> >>> _______________________________________________ >>> 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 ecrit-bounces@ietf.org Thu Nov 20 11:52:08 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E8D28C0FD; Thu, 20 Nov 2008 11:52:08 -0800 (PST) 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 209F43A686D for ; Thu, 20 Nov 2008 11:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 i1A-bFQSOoKn for ; Thu, 20 Nov 2008 11:52:05 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 23CB228C114 for ; Thu, 20 Nov 2008 11:52:05 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3FZD-0003kv-UC; Thu, 20 Nov 2008 13:51:56 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> Date: Thu, 20 Nov 2008 14:51:59 -0500 Message-ID: <01df01c94b49$7573d0f0$605b72d0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYepAA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm not interested in preventing SUPL. The drafts allow others. The problem is, and remains interoperability. The basic LCP "rule" is "endpoints implement all, access networks implement one". That rule provides interoperability. There is nothing you can do with SUPL that is interoperable unless it goes on the list. If you implement SUPL, then the network and the endpoints ALSO need to implement another protocol from the list, or we don't have interoperability. It's possible for the network to implement SUPL and some endpoints implement SUPL and those endpoints will work. Others won't, and that is very bad. There is no short cut. Either SUPL goes on the list, or the network has to implement one of the LCPs on the list. Given the current level of non-interoperability of SUPL with the rest of the LCPs, I oppose adding SUPL to the list at this time. I don't understand your comments on the RV case. The card can implement a SUPL client. Unless it implements a DHCP or HELD server and interworks the SUPL location to the HELD/DHCP protocols, we have a problem. And of course, we can't reasonably get the privacy right doing that, and in some cases we can't interwork the location representation. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Thursday, November 20, 2008 2:36 PM To: Brian Rosen; Richard Barnes Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; marc.linsner@cisco.com; ecrit@ietf.org Subject: RE: [Ecrit] Location Protocols in Phone BCP If the choice is between preventing, allowing, or requiring PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I would prefer 'require' since *most* of the location-aware 3G compatible handsets/aircards over the next several years will (I predict) have a SUPL stack included. In the same time frame, many of those will also have WiFi support, others will have LTE or WiMAX support as hybrids. SUPL will be common-place. OMA may not be 'Open-Source', it is open-minded, and there is movement afoot to expand OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) w/respect expected proposals such as LocSIP, etc. Over the fairly near-term, I think there will be fewer protocol, location representation, and privacy discontinuities - things that too often get cited - yet are seldom well understood. Let's encourage continued IETF communication with OMA/SUPL - not block its use altogether. This is a case where we need to be inclusive, not exclusive. As to the mobile RV sample case, the solution is also forseeable - especially given that the location of the 3G aircard in the router is good enough for routing. The scenario given needs some integration, but is doable. Given that the aircard acts as a logical SET, with a SUPL stack on board, and a GPS/AGPS chipset inside. This combination *WILL* (I believe) interoperate with a number of end client applications to initiate and complete a location-routed, 3261 style SIP, emergency call through the core, and into an ESInet. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 8:23 AM > To: 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > It's very hard to have L2 specific LCPs. The problem is that > the clients are generally not very L2 aware. It's the > clients that have the problem. > You can do things like interwork an L2 specific LCP to a > common LCP so that non L2 aware devices can work, but you > have to do that, and usually, that's impractical. Use my > example. Suppose that the L2 used SUPL. It's possible for > the PC Card that is plugged into the router could implement a > SUPL client and a HELD server and interwork SUPL in the GSM > system to HELD on the Ethernet so the Ethernet VoIP phone > could get location via HELD. Possible, but not practical. > There are all sorts of these kinds of problems. That's why > L2 specific LCPs don't work. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 11:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > The IETF can't (and shouldn't) try to make particular > standards for every access technology that's out there. What > we can say is that the paradigm for those protocols should be > the same as at the IP layer: > Clients MUST implement all, networks MUST implement at least one. > > (This is a little different from the text I sent before, and > clearer, I > think.) > > All I'm saying is that we shouldn't try to enumerate all the > possible protocols at lower layers, we should just state the > general rule. It seems to me that this achieves the same > level of interoperability at all layers. > > --Richard > > > If there are exactly two LCPs all UAs must implement, and > any number > > of optional ones, then every network has to implement at > least one of > > those > two > > LCPs, and any number of optional ones. That means that > "any number of > > optional ones" is useless for both parties. > > If the network can limit UAs to ONLY those that implement > one of the > > optional protocols, then it works, but in practice, it is usually > impossible > > to do that. My example is the wired, Ethernet connected > phone in an > > RV traveling down the road with wireless data card in a > router. These > > EXIST, now. > > > > Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 10:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I think we need to pull up a level. It's not reasonable > for an RFC to > > try to list all of the location protocols out there, if for > no other > > reason than that it will rapidly become obsolete. Instead, > we should > > say something like the following: > > > > " > > INT-12 Devices MUST support the DHCP location options [RFC4776] and > > [RFC3825] and HELD > [I-D.ietf-geopriv-http-location-delivery]. Devices > > SHOULD support all location protocols supported at lower layers by > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > " > > > > > > > > > > Brian Rosen wrote: > >> The problem with SUPL is that the majority of networks where SUPL > >> would > be > >> available have a proxy (E-CSCF) insert location. It also has an > >> incompatible location representation, and an incompatible > privacy model. > >> That makes it very hard to interwork with any of the rest > of the IETF > > work. > >> I will say this. For quite some time, the IETF has been trying to > > interest > >> OMA into cooperation on location so that we have > interoperability at > >> the protocol, location representation and privacy levels. So far, > >> that has > > not > >> happened. If, as part of a comprehensive agreement to accomplish > >> such a goal, SUPL became one of the LCPs, I would not object. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Gabor.Bajko@nokia.com > >> Sent: Thursday, November 20, 2008 9:26 AM > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > >> Hi, > >> > >> Is the intent to list the LCPs which are access-type > agnostic but not > >> supported anywhere, or instead have a list of LCPs which > are highly > >> probable to produce the intended result? > >> > >> There are restrictions everywhere, things come at a cost > even in the > >> general Internet model. The reality is that most of the > devices with > >> internet access have a home network already. > >> > >> - Gabor > >> > >> > >> >-----Original Message----- > >> >From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > >> >Sent: Thursday, November 20, 2008 12:06 AM > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >> > > >> >Hi Gabor, > >> > > >> >The list of LCPs in the phone BCP is a must support list, and is > >> access- > >> >type agnostic. > >> >I am curious that you say that SUPL is a MUST support > given that: > >> >a) it requires a home network in order to operate > >> >b) it simply doesn't work for DSL or Cable > >> >c) it is questionable whether it is really deployable for WiFi > >> networks > >> > > >> >Can you perhaps describe how it fits into the general > Internet model? > >> > > >> >Cheers > >> >James > >> > > >> > > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >> >Sent: Thu 11/20/2008 12:48 AM > >> >To: ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > > >> >I was requested to send my observations regarding this > requirement: > >> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > location options > >> > [RFC4776] and [RFC3825], HELD > >> > [I-D.ietf-geopriv-http-location-delivery] and > LLDP-MED [LLDP-MED]. > >> > > >> > > >> >I believe we should come up with a list of LCPs which > are likely > >> to be > >> >supported in devices in a not so distant future. Since > I have no > >> seen or > >> >heard about LLDP support yet, at least that should be replaced > >> with what > >> >is mostly used today (OMA SUPL) and the 802.11 > mechanism, with the > >> >condition that this MUST only be supported if there is a wifi > >> interface > >> >available on the device. > >> > > >> >- Gabor > >> > > >> > > >> > > >> >________________________________ > >> > > >> >From: ext Tschofenig, Hannes > >> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >> >Subject: Location Protocols in Phone BCP > >> > > >> > > >> > > >> >Gabor, > >> > > >> >Could you please raise your question about location > protocols in > >> Phone > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > >> > > >> >Ciao > >> >Hannes > >> > > >> > > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >This message is for the designated recipient only and may > >> >contain privileged, proprietary, or otherwise private > information. > >> >If you have received it in error, please notify the sender > >> >immediately and delete the original. Any unauthorized use of > >> >this email is prohibited. > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >[mf2] > >> > >> _______________________________________________ > >> 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 > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 11:54:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B39C3A69D8; Thu, 20 Nov 2008 11:54:32 -0800 (PST) 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 AD00E28C0FD for ; Thu, 20 Nov 2008 11:54:30 -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 Mu7II1yIk8Xa for ; Thu, 20 Nov 2008 11:54:29 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id C4DC53A677D for ; Thu, 20 Nov 2008 11:54:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1227210866!27693647!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 15904 invoked from network); 20 Nov 2008 19:54:26 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-10.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 19:54:26 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mAKJsPRO008123; Thu, 20 Nov 2008 14:54:26 -0500 Received: from 01GAF5142010621.AD.BLS.COM ([139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id mAKJsISD008013; Thu, 20 Nov 2008 14:54:20 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Nov 2008 14:54:20 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Nov 2008 14:54:19 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 14:54:15 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP thread-index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4A== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> From: "Stark, Barbara" To: "Roger Marshall" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 20 Nov 2008 19:54:19.0596 (UTC) FILETIME=[C6C058C0:01C94B49] Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I cannot support requiring SUPL in DSL routers, desktop computers (and related operating systems, SIP soft clients), analog terminal adaptors, or other similar devices that are intended for use in a wireline environment. I think that organizations that can drive requirements for devices intended to be use in an environment where SUPL would actually work, should be responsible for having device requirements requiring SUPL. In other words, 3GPP/3GPP2 are absolutely in a position to require SUPL support for devices that operate in an environment where SUPL works. This is a perfect example of the "closed" network that Brian describes somewhere (framework, I think). Phonebcp is about requirements for devices in access environments where the operators of the access environment cannot be assumed to have any control over the type or nature of devices that connect to or through it. Phonebcp needs to continue to have that as its purpose. I agree that nothing in phonebcp should preclude the use of SUPL, or be incompatible with the use of SUPL. And I don't think it does. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, November 20, 2008 2:36 PM To: Brian Rosen; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP If the choice is between preventing, allowing, or requiring PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I would prefer 'require' since *most* of the location-aware 3G compatible handsets/aircards over the next several years will (I predict) have a SUPL stack included. In the same time frame, many of those will also have WiFi support, others will have LTE or WiMAX support as hybrids. SUPL will be common-place. OMA may not be 'Open-Source', it is open-minded, and there is movement afoot to expand OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) w/respect expected proposals such as LocSIP, etc. Over the fairly near-term, I think there will be fewer protocol, location representation, and privacy discontinuities - things that too often get cited - yet are seldom well understood. Let's encourage continued IETF communication with OMA/SUPL - not block its use altogether. This is a case where we need to be inclusive, not exclusive. As to the mobile RV sample case, the solution is also forseeable - especially given that the location of the 3G aircard in the router is good enough for routing. The scenario given needs some integration, but is doable. Given that the aircard acts as a logical SET, with a SUPL stack on board, and a GPS/AGPS chipset inside. This combination *WILL* (I believe) interoperate with a number of end client applications to initiate and complete a location-routed, 3261 style SIP, emergency call through the core, and into an ESInet. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 8:23 AM > To: 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > It's very hard to have L2 specific LCPs. The problem is that > the clients are generally not very L2 aware. It's the > clients that have the problem. > You can do things like interwork an L2 specific LCP to a > common LCP so that non L2 aware devices can work, but you > have to do that, and usually, that's impractical. Use my > example. Suppose that the L2 used SUPL. It's possible for > the PC Card that is plugged into the router could implement a > SUPL client and a HELD server and interwork SUPL in the GSM > system to HELD on the Ethernet so the Ethernet VoIP phone > could get location via HELD. Possible, but not practical. > There are all sorts of these kinds of problems. That's why > L2 specific LCPs don't work. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 11:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > The IETF can't (and shouldn't) try to make particular > standards for every access technology that's out there. What > we can say is that the paradigm for those protocols should be > the same as at the IP layer: > Clients MUST implement all, networks MUST implement at least one. > > (This is a little different from the text I sent before, and > clearer, I > think.) > > All I'm saying is that we shouldn't try to enumerate all the > possible protocols at lower layers, we should just state the > general rule. It seems to me that this achieves the same > level of interoperability at all layers. > > --Richard > > > If there are exactly two LCPs all UAs must implement, and > any number > > of optional ones, then every network has to implement at > least one of > > those > two > > LCPs, and any number of optional ones. That means that > "any number of > > optional ones" is useless for both parties. > > If the network can limit UAs to ONLY those that implement > one of the > > optional protocols, then it works, but in practice, it is usually > impossible > > to do that. My example is the wired, Ethernet connected > phone in an > > RV traveling down the road with wireless data card in a > router. These > > EXIST, now. > > > > Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 10:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I think we need to pull up a level. It's not reasonable > for an RFC to > > try to list all of the location protocols out there, if for > no other > > reason than that it will rapidly become obsolete. Instead, > we should > > say something like the following: > > > > " > > INT-12 Devices MUST support the DHCP location options [RFC4776] and > > [RFC3825] and HELD > [I-D.ietf-geopriv-http-location-delivery]. Devices > > SHOULD support all location protocols supported at lower layers by > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > " > > > > > > > > > > Brian Rosen wrote: > >> The problem with SUPL is that the majority of networks where SUPL > >> would > be > >> available have a proxy (E-CSCF) insert location. It also has an > >> incompatible location representation, and an incompatible > privacy model. > >> That makes it very hard to interwork with any of the rest > of the IETF > > work. > >> I will say this. For quite some time, the IETF has been trying to > > interest > >> OMA into cooperation on location so that we have > interoperability at > >> the protocol, location representation and privacy levels. So far, > >> that has > > not > >> happened. If, as part of a comprehensive agreement to accomplish > >> such a goal, SUPL became one of the LCPs, I would not object. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Gabor.Bajko@nokia.com > >> Sent: Thursday, November 20, 2008 9:26 AM > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > >> Hi, > >> > >> Is the intent to list the LCPs which are access-type > agnostic but not > >> supported anywhere, or instead have a list of LCPs which > are highly > >> probable to produce the intended result? > >> > >> There are restrictions everywhere, things come at a cost > even in the > >> general Internet model. The reality is that most of the > devices with > >> internet access have a home network already. > >> > >> - Gabor > >> > >> > >> >-----Original Message----- > >> >From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > >> >Sent: Thursday, November 20, 2008 12:06 AM > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >> > > >> >Hi Gabor, > >> > > >> >The list of LCPs in the phone BCP is a must support list, and is > >> access- > >> >type agnostic. > >> >I am curious that you say that SUPL is a MUST support > given that: > >> >a) it requires a home network in order to operate > >> >b) it simply doesn't work for DSL or Cable > >> >c) it is questionable whether it is really deployable for WiFi > >> networks > >> > > >> >Can you perhaps describe how it fits into the general > Internet model? > >> > > >> >Cheers > >> >James > >> > > >> > > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >> >Sent: Thu 11/20/2008 12:48 AM > >> >To: ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > > >> >I was requested to send my observations regarding this > requirement: > >> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > location options > >> > [RFC4776] and [RFC3825], HELD > >> > [I-D.ietf-geopriv-http-location-delivery] and > LLDP-MED [LLDP-MED]. > >> > > >> > > >> >I believe we should come up with a list of LCPs which > are likely > >> to be > >> >supported in devices in a not so distant future. Since > I have no > >> seen or > >> >heard about LLDP support yet, at least that should be replaced > >> with what > >> >is mostly used today (OMA SUPL) and the 802.11 > mechanism, with the > >> >condition that this MUST only be supported if there is a wifi > >> interface > >> >available on the device. > >> > > >> >- Gabor > >> > > >> > > >> > > >> >________________________________ > >> > > >> >From: ext Tschofenig, Hannes > >> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >> >Subject: Location Protocols in Phone BCP > >> > > >> > > >> > > >> >Gabor, > >> > > >> >Could you please raise your question about location > protocols in > >> Phone > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > >> > > >> >Ciao > >> >Hannes > >> > > >> > > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >This message is for the designated recipient only and may > >> >contain privileged, proprietary, or otherwise private > information. > >> >If you have received it in error, please notify the sender > >> >immediately and delete the original. Any unauthorized use of > >> >this email is prohibited. > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >[mf2] > >> > >> _______________________________________________ > >> 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 > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 11:54:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F17528C1F4; Thu, 20 Nov 2008 11:54:43 -0800 (PST) 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 2093328C1F4 for ; Thu, 20 Nov 2008 11:54:42 -0800 (PST) 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 LUjIQTqJ-tZd for ; Thu, 20 Nov 2008 11:54:40 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 615C728C1D0 for ; Thu, 20 Nov 2008 11:54:40 -0800 (PST) Received: from [128.89.255.85] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3FbZ-0008VE-AH; Thu, 20 Nov 2008 14:54:21 -0500 Message-ID: <4925C06C.7090209@bbn.com> Date: Thu, 20 Nov 2008 13:54:20 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Marc Berryman References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, ecrit@ietf.org, hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think this argument makes sense. In the framework I was calling for earlier, this would be one of the "Layer 2" protocols, since it has explicit dependencies on the physical layer and particular structure of the network. So it would be RECOMMENDED under the principle that "if you're capable of a non-Internet-wide mechanism, you SHOULD support it." --Richard Marc Berryman wrote: > Roger makes a valid and compelling argument, one which I agree with. > > Marc B > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Roger Marshall > Sent: Thursday, November 20, 2008 1:36 PM > To: Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > If the choice is between preventing, allowing, or requiring PhoneBCP > suppport of SUPL, then my vote is to NOT prevent! I would prefer > 'require' since *most* of the location-aware 3G compatible > handsets/aircards over the next several years will (I predict) have a > SUPL stack included. In the same time frame, many of those will also > have WiFi support, others will have LTE or WiMAX support as hybrids. > > SUPL will be common-place. OMA may not be 'Open-Source', it is > open-minded, and there is movement afoot to expand OMA/SUPL (as we heard > in the geopriv mtg. on Tuesday) w/respect expected proposals such as > LocSIP, etc. Over the fairly near-term, I think there will be fewer > protocol, location representation, and privacy discontinuities - things > that too often get cited - yet are seldom well understood. > > Let's encourage continued IETF communication with OMA/SUPL - not block > its use altogether. This is a case where we need to be inclusive, not > exclusive. > > As to the mobile RV sample case, the solution is also forseeable - > especially given that the location of the 3G aircard in the router is > good enough for routing. The scenario given needs some integration, but > is doable. Given that the aircard acts as a logical SET, with a SUPL > stack on board, and a GPS/AGPS chipset inside. This combination *WILL* > (I believe) interoperate with a number of end client applications to > initiate and complete a location-routed, 3261 style SIP, emergency call > through the core, and into an ESInet. > > -roger. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Thursday, November 20, 2008 8:23 AM >> To: 'Richard Barnes' >> Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >> marc.linsner@cisco.com; ecrit@ietf.org >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> It's very hard to have L2 specific LCPs. The problem is that >> the clients are generally not very L2 aware. It's the >> clients that have the problem. >> You can do things like interwork an L2 specific LCP to a >> common LCP so that non L2 aware devices can work, but you >> have to do that, and usually, that's impractical. Use my >> example. Suppose that the L2 used SUPL. It's possible for >> the PC Card that is plugged into the router could implement a >> SUPL client and a HELD server and interwork SUPL in the GSM >> system to HELD on the Ethernet so the Ethernet VoIP phone >> could get location via HELD. Possible, but not practical. >> There are all sorts of these kinds of problems. That's why >> L2 specific LCPs don't work. >> >> Brian >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, November 20, 2008 11:11 AM >> To: Brian Rosen >> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >> ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> The IETF can't (and shouldn't) try to make particular >> standards for every access technology that's out there. What >> we can say is that the paradigm for those protocols should be >> the same as at the IP layer: >> Clients MUST implement all, networks MUST implement at least one. >> >> (This is a little different from the text I sent before, and >> clearer, I >> think.) >> >> All I'm saying is that we shouldn't try to enumerate all the >> possible protocols at lower layers, we should just state the >> general rule. It seems to me that this achieves the same >> level of interoperability at all layers. >> >> --Richard >> >>> If there are exactly two LCPs all UAs must implement, and >> any number >>> of optional ones, then every network has to implement at >> least one of >>> those >> two >>> LCPs, and any number of optional ones. That means that >> "any number of >>> optional ones" is useless for both parties. >>> If the network can limit UAs to ONLY those that implement >> one of the >>> optional protocols, then it works, but in practice, it is usually >> impossible >>> to do that. My example is the wired, Ethernet connected >> phone in an >>> RV traveling down the road with wireless data card in a >> router. These >>> EXIST, now. >>> >>> Brian >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Thursday, November 20, 2008 10:11 AM >>> To: Brian Rosen >>> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>> ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>> I think we need to pull up a level. It's not reasonable >> for an RFC to >>> try to list all of the location protocols out there, if for >> no other >>> reason than that it will rapidly become obsolete. Instead, >> we should >>> say something like the following: >>> >>> " >>> INT-12 Devices MUST support the DHCP location options [RFC4776] and >>> [RFC3825] and HELD >> [I-D.ietf-geopriv-http-location-delivery]. Devices >>> SHOULD support all location protocols supported at lower layers by >>> their interfaces (e.g., LLDP-MED [LLDP-MED]). >>> " >>> >>> >>> >>> >>> Brian Rosen wrote: >>>> The problem with SUPL is that the majority of networks where SUPL >>>> would >> be >>>> available have a proxy (E-CSCF) insert location. It also has an >>>> incompatible location representation, and an incompatible >> privacy model. >>>> That makes it very hard to interwork with any of the rest >> of the IETF >>> work. >>>> I will say this. For quite some time, the IETF has been trying to >>> interest >>>> OMA into cooperation on location so that we have >> interoperability at >>>> the protocol, location representation and privacy levels. So far, >>>> that has >>> not >>>> happened. If, as part of a comprehensive agreement to accomplish >>>> such a goal, SUPL became one of the LCPs, I would not object. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Gabor.Bajko@nokia.com >>>> Sent: Thursday, November 20, 2008 9:26 AM >>>> To: James.Winterbottom@andrew.com; ecrit@ietf.org >>>> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> >>>> Hi, >>>> >>>> Is the intent to list the LCPs which are access-type >> agnostic but not >>>> supported anywhere, or instead have a list of LCPs which >> are highly >>>> probable to produce the intended result? >>>> >>>> There are restrictions everywhere, things come at a cost >> even in the >>>> general Internet model. The reality is that most of the >> devices with >>>> internet access have a home network already. >>>> >>>> - Gabor >>>> >>>> >>>> >-----Original Message----- >>>> >From: ext Winterbottom, James >> [mailto:James.Winterbottom@andrew.com] >>>> >Sent: Thursday, November 20, 2008 12:06 AM >>>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >>>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>> > >>>> >Hi Gabor, >>>> > >>>> >The list of LCPs in the phone BCP is a must support list, and is >>>> access- >>>> >type agnostic. >>>> >I am curious that you say that SUPL is a MUST support >> given that: >>>> >a) it requires a home network in order to operate >>>> >b) it simply doesn't work for DSL or Cable >>>> >c) it is questionable whether it is really deployable for WiFi >>>> networks >>>> > >>>> >Can you perhaps describe how it fits into the general >> Internet model? >>>> > >>>> >Cheers >>>> >James >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >>>> >Sent: Thu 11/20/2008 12:48 AM >>>> >To: ecrit@ietf.org >>>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> > >>>> >I was requested to send my observations regarding this >> requirement: >>>> > >>>> > ED-21/INT-12 Devices MUST support all of: DHCP >> location options >>>> > [RFC4776] and [RFC3825], HELD >>>> > [I-D.ietf-geopriv-http-location-delivery] and >> LLDP-MED [LLDP-MED]. >>>> > >>>> > >>>> >I believe we should come up with a list of LCPs which >> are likely >>>> to be >>>> >supported in devices in a not so distant future. Since >> I have no >>>> seen or >>>> >heard about LLDP support yet, at least that should be replaced >>>> with what >>>> >is mostly used today (OMA SUPL) and the 802.11 >> mechanism, with the >>>> >condition that this MUST only be supported if there is a wifi >>>> interface >>>> >available on the device. >>>> > >>>> >- Gabor >>>> > >>>> > >>>> > >>>> >________________________________ >>>> > >>>> >From: ext Tschofenig, Hannes >>>> > >>>> >Sent: Tuesday, November 18, 2008 12:49 PM >>>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>>> >Subject: Location Protocols in Phone BCP >>>> > >>>> > >>>> > >>>> >Gabor, >>>> > >>>> >Could you please raise your question about location >> protocols in >>>> Phone >>>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>>> > >>>> >Ciao >>>> >Hannes >>>> > >>>> > >>>> >> -------------------------------------------------------------------- >>>>> --- >>>> -- >>>> >----------------------- >>>> >This message is for the designated recipient only and may >>>> >contain privileged, proprietary, or otherwise private >> information. >>>> >If you have received it in error, please notify the sender >>>> >immediately and delete the original. Any unauthorized use of >>>> >this email is prohibited. >>>> >> -------------------------------------------------------------------- >>>>> --- >>>> -- >>>> >----------------------- >>>> >[mf2] >>>> >>>> _______________________________________________ >>>> 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 >> > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Nov 20 11:58:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD1D28C248; Thu, 20 Nov 2008 11:58:50 -0800 (PST) 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 3D2D928C0FD for ; Thu, 20 Nov 2008 11:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 aaAOIl-CjB8B for ; Thu, 20 Nov 2008 11:58:47 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 3B56B28C25E for ; Thu, 20 Nov 2008 11:58:47 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3Ffi-0004Rr-Ba; Thu, 20 Nov 2008 13:58:39 -0600 From: "Brian Rosen" To: , References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EEE82@esebe111.NOE.Nokia.com> In-Reply-To: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EEE82@esebe111.NOE.Nokia.com> Date: Thu, 20 Nov 2008 14:58:42 -0500 Message-ID: <01e001c94b4a$6561c860$30255920$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAZqe/AAAR0q4A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org What we have is basic non-interoperability. Allowing SUPL is easy, and doesn't help. Adding SUPL to the list can't be done at the moment: we have to figure out how to interwork representation, and we have to figure out how to deal with the privacy issues. Repeating myself, these issues could be solved by cooperation between IETF and OMA. Brian -----Original Message----- From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Thursday, November 20, 2008 2:46 PM To: br@brianrosen.net; rbarnes@bbn.com Cc: James.Winterbottom@andrew.com; ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com Subject: RE: [Ecrit] Location Protocols in Phone BCP Oh, well. Do you want to have text which accommodates current client implementations or instead set requirements for implementations intended to support functionalities defined in ecrit? Some (most?) of the clients out there do use L2 specific location determination extensively. E.g., my device knows its location (at least roughly) by multiple means, being that A-GPS, 2G/3G cell-id, L7 based on L2 identifiers, etc. Since there is a DHCP client in the device, it wouldn't be a big deal supporting the two location specific options. But are there any DHCP servers out there which could provide me with reliable location while I am on the move? The problem I have is that what is used today is excluded from the draft, but we are including things there which may never be deployed. And it would be a naivity thinking that these LCPs would get deployed because they are included in this draft. - Gabor >-----Original Message----- >From: ext Brian Rosen [mailto:br@brianrosen.net] >Sent: Thursday, November 20, 2008 8:23 AM >To: 'Richard Barnes' >Cc: Bajko Gabor (Nokia-CIC/MtView); James.Winterbottom@andrew.com; >ecrit@ietf.org; marc.linsner@cisco.com; Tschofenig Hannes (NSN - >FI/Espoo) >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >It's very hard to have L2 specific LCPs. The problem is that the clients >are generally not very L2 aware. It's the clients that have the problem. >You can do things like interwork an L2 specific LCP to a common LCP so >that >non L2 aware devices can work, but you have to do that, and usually, >that's >impractical. Use my example. Suppose that the L2 used SUPL. It's >possible >for the PC Card that is plugged into the router could implement a SUPL >client and a HELD server and interwork SUPL in the GSM system to HELD on >the >Ethernet so the Ethernet VoIP phone could get location via HELD. >Possible, >but not practical. There are all sorts of these kinds of problems. >That's >why L2 specific LCPs don't work. > >Brian > >-----Original Message----- >From: Richard Barnes [mailto:rbarnes@bbn.com] >Sent: Thursday, November 20, 2008 11:11 AM >To: Brian Rosen >Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; ecrit@ietf.org; >marc.linsner@cisco.com; hannes.tschofenig@nsn.com >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >The IETF can't (and shouldn't) try to make particular standards for >every access technology that's out there. What we can say is that the >paradigm for those protocols should be the same as at the IP layer: >Clients MUST implement all, networks MUST implement at least one. > >(This is a little different from the text I sent before, and clearer, I >think.) > >All I'm saying is that we shouldn't try to enumerate all the possible >protocols at lower layers, we should just state the general rule. It >seems to me that this achieves the same level of interoperability at all >layers. > >--Richard > >> If there are exactly two LCPs all UAs must implement, and any number of >> optional ones, then every network has to implement at least one of >those >two >> LCPs, and any number of optional ones. That means that "any number of >> optional ones" is useless for both parties. >> If the network can limit UAs to ONLY those that implement one of the >> optional protocols, then it works, but in practice, it is usually >impossible >> to do that. My example is the wired, Ethernet connected phone in an RV >> traveling down the road with wireless data card in a router. These >EXIST, >> now. >> >> Brian >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, November 20, 2008 10:11 AM >> To: Brian Rosen >> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >ecrit@ietf.org; >> marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> I think we need to pull up a level. It's not reasonable for an RFC to >> try to list all of the location protocols out there, if for no other >> reason than that it will rapidly become obsolete. Instead, we should >> say something like the following: >> >> " >> INT-12 Devices MUST support the DHCP location options [RFC4776] and >> [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. Devices >> SHOULD support all location protocols supported at lower layers by >their >> interfaces (e.g., LLDP-MED [LLDP-MED]). >> " >> >> >> >> >> Brian Rosen wrote: >>> The problem with SUPL is that the majority of networks where SUPL >would >be >>> available have a proxy (E-CSCF) insert location. It also has an >>> incompatible location representation, and an incompatible privacy >model. >>> That makes it very hard to interwork with any of the rest of the IETF >> work. >>> I will say this. For quite some time, the IETF has been trying to >> interest >>> OMA into cooperation on location so that we have interoperability at >the >>> protocol, location representation and privacy levels. So far, that >has >> not >>> happened. If, as part of a comprehensive agreement to accomplish such >a >>> goal, SUPL became one of the LCPs, I would not object. >>> >>> Brian >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of >>> Gabor.Bajko@nokia.com >>> Sent: Thursday, November 20, 2008 9:26 AM >>> To: James.Winterbottom@andrew.com; ecrit@ietf.org >>> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>> Hi, >>> >>> Is the intent to list the LCPs which are access-type agnostic but not >>> supported anywhere, or instead have a list of LCPs which are highly >>> probable to produce the intended result? >>> >>> There are restrictions everywhere, things come at a cost even in the >>> general Internet model. The reality is that most of the devices with >>> internet access have a home network already. >>> >>> - Gabor >>> >>> >>> >-----Original Message----- >>> >From: ext Winterbottom, James >[mailto:James.Winterbottom@andrew.com] >>> >Sent: Thursday, November 20, 2008 12:06 AM >>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>> > >>> >Hi Gabor, >>> > >>> >The list of LCPs in the phone BCP is a must support list, and is >>> access- >>> >type agnostic. >>> >I am curious that you say that SUPL is a MUST support given that: >>> >a) it requires a home network in order to operate >>> >b) it simply doesn't work for DSL or Cable >>> >c) it is questionable whether it is really deployable for WiFi >>> networks >>> > >>> >Can you perhaps describe how it fits into the general Internet >model? >>> > >>> >Cheers >>> >James >>> > >>> > >>> >-----Original Message----- >>> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >>> >Sent: Thu 11/20/2008 12:48 AM >>> >To: ecrit@ietf.org >>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> > >>> >I was requested to send my observations regarding this requirement: >>> > >>> > ED-21/INT-12 Devices MUST support all of: DHCP location options >>> > [RFC4776] and [RFC3825], HELD >>> > [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP- >MED]. >>> > >>> > >>> >I believe we should come up with a list of LCPs which are likely to >>> be >>> >supported in devices in a not so distant future. Since I have no >seen >>> or >>> >heard about LLDP support yet, at least that should be replaced with >>> what >>> >is mostly used today (OMA SUPL) and the 802.11 mechanism, with the >>> >condition that this MUST only be supported if there is a wifi >>> interface >>> >available on the device. >>> > >>> >- Gabor >>> > >>> > >>> > >>> >________________________________ >>> > >>> >From: ext Tschofenig, Hannes >>> > >>> >Sent: Tuesday, November 18, 2008 12:49 PM >>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>> >Subject: Location Protocols in Phone BCP >>> > >>> > >>> > >>> >Gabor, >>> > >>> >Could you please raise your question about location protocols in >>> Phone >>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>> > >>> >Ciao >>> >Hannes >>> > >>> > >>> >>>> --------------------------------------------------------------------- >-- >>> -- >>> >----------------------- >>> >This message is for the designated recipient only and may >>> >contain privileged, proprietary, or otherwise private information. >>> >If you have received it in error, please notify the sender >>> >immediately and delete the original. Any unauthorized use of >>> >this email is prohibited. >>> >>>> --------------------------------------------------------------------- >-- >>> -- >>> >----------------------- >>> >[mf2] >>> >>> _______________________________________________ >>> 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 ecrit-bounces@ietf.org Thu Nov 20 12:02:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1C728C269; Thu, 20 Nov 2008 12:02:18 -0800 (PST) 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 E42FA28C268 for ; Thu, 20 Nov 2008 12:02:16 -0800 (PST) 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 Lb61Ua6O7NWM for ; Thu, 20 Nov 2008 12:02:15 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DF1CF28C274 for ; Thu, 20 Nov 2008 12:01:34 -0800 (PST) Received: from [128.89.255.85] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L3FiP-0000MQ-CU; Thu, 20 Nov 2008 15:01:26 -0500 Message-ID: <4925C215.4070207@bbn.com> Date: Thu, 20 Nov 2008 14:01:25 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Brian Rosen References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <01df01c94b49$7573d0f0$605b72d0$@net> In-Reply-To: <01df01c94b49$7573d0f0$605b72d0$@net> Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The problem is the scope of "all". I don't think it makes sense for an IETF document to try to enumerate all the Layer-2 ways that people access the Internet and their associated location protocols, but it *can* make a recommendation for how things work at those layers (namely, it can recommend that layer-2 entities follow the same "endpoint-all/network-one" principle -- "EAN1"?). Note: I'm grouping SUPL in with the "layer 2" mechanisms because it has dependencies on assumptions about the physical host (e.g., GPS in most cases), and about the structure of the network. The real distinction, I guess, is between protocols that work everywhere in the Internet (DHCP, HELD) and protocols that only work in specific environments, like SUPL or LLDP. The EAN1 principle applies to both of these classes, but is only an unconditional MUST for the Internet-wide ones, because it's not meaningful to mandate universal support for non-universal protocols. There could still be a *conditional* MUST, conditioned on the client and its network connectivity meeting the requirements of the constrained protocols. --Richard Brian Rosen wrote: > I'm not interested in preventing SUPL. The drafts allow others. The > problem is, and remains interoperability. The basic LCP "rule" is > "endpoints implement all, access networks implement one". That rule > provides interoperability. There is nothing you can do with SUPL that is > interoperable unless it goes on the list. If you implement SUPL, then the > network and the endpoints ALSO need to implement another protocol from the > list, or we don't have interoperability. It's possible for the network to > implement SUPL and some endpoints implement SUPL and those endpoints will > work. Others won't, and that is very bad. > > There is no short cut. Either SUPL goes on the list, or the network has to > implement one of the LCPs on the list. > > Given the current level of non-interoperability of SUPL with the rest of the > LCPs, I oppose adding SUPL to the list at this time. > > I don't understand your comments on the RV case. The card can implement a > SUPL client. Unless it implements a DHCP or HELD server and interworks the > SUPL location to the HELD/DHCP protocols, we have a problem. And of course, > we can't reasonably get the privacy right doing that, and in some cases we > can't interwork the location representation. > > Brian > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Thursday, November 20, 2008 2:36 PM > To: Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > If the choice is between preventing, allowing, or requiring PhoneBCP > suppport of SUPL, then my vote is to NOT prevent! I would prefer > 'require' since *most* of the location-aware 3G compatible > handsets/aircards over the next several years will (I predict) have a > SUPL stack included. In the same time frame, many of those will also > have WiFi support, others will have LTE or WiMAX support as hybrids. > > SUPL will be common-place. OMA may not be 'Open-Source', it is > open-minded, and there is movement afoot to expand OMA/SUPL (as we heard > in the geopriv mtg. on Tuesday) w/respect expected proposals such as > LocSIP, etc. Over the fairly near-term, I think there will be fewer > protocol, location representation, and privacy discontinuities - things > that too often get cited - yet are seldom well understood. > > Let's encourage continued IETF communication with OMA/SUPL - not block > its use altogether. This is a case where we need to be inclusive, not > exclusive. > > As to the mobile RV sample case, the solution is also forseeable - > especially given that the location of the 3G aircard in the router is > good enough for routing. The scenario given needs some integration, but > is doable. Given that the aircard acts as a logical SET, with a SUPL > stack on board, and a GPS/AGPS chipset inside. This combination *WILL* > (I believe) interoperate with a number of end client applications to > initiate and complete a location-routed, 3261 style SIP, emergency call > through the core, and into an ESInet. > > -roger. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Brian Rosen >> Sent: Thursday, November 20, 2008 8:23 AM >> To: 'Richard Barnes' >> Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >> marc.linsner@cisco.com; ecrit@ietf.org >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> It's very hard to have L2 specific LCPs. The problem is that >> the clients are generally not very L2 aware. It's the >> clients that have the problem. >> You can do things like interwork an L2 specific LCP to a >> common LCP so that non L2 aware devices can work, but you >> have to do that, and usually, that's impractical. Use my >> example. Suppose that the L2 used SUPL. It's possible for >> the PC Card that is plugged into the router could implement a >> SUPL client and a HELD server and interwork SUPL in the GSM >> system to HELD on the Ethernet so the Ethernet VoIP phone >> could get location via HELD. Possible, but not practical. >> There are all sorts of these kinds of problems. That's why >> L2 specific LCPs don't work. >> >> Brian >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, November 20, 2008 11:11 AM >> To: Brian Rosen >> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >> ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> The IETF can't (and shouldn't) try to make particular >> standards for every access technology that's out there. What >> we can say is that the paradigm for those protocols should be >> the same as at the IP layer: >> Clients MUST implement all, networks MUST implement at least one. >> >> (This is a little different from the text I sent before, and >> clearer, I >> think.) >> >> All I'm saying is that we shouldn't try to enumerate all the >> possible protocols at lower layers, we should just state the >> general rule. It seems to me that this achieves the same >> level of interoperability at all layers. >> >> --Richard >> >>> If there are exactly two LCPs all UAs must implement, and >> any number >>> of optional ones, then every network has to implement at >> least one of >>> those >> two >>> LCPs, and any number of optional ones. That means that >> "any number of >>> optional ones" is useless for both parties. >>> If the network can limit UAs to ONLY those that implement >> one of the >>> optional protocols, then it works, but in practice, it is usually >> impossible >>> to do that. My example is the wired, Ethernet connected >> phone in an >>> RV traveling down the road with wireless data card in a >> router. These >>> EXIST, now. >>> >>> Brian >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Thursday, November 20, 2008 10:11 AM >>> To: Brian Rosen >>> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>> ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>> I think we need to pull up a level. It's not reasonable >> for an RFC to >>> try to list all of the location protocols out there, if for >> no other >>> reason than that it will rapidly become obsolete. Instead, >> we should >>> say something like the following: >>> >>> " >>> INT-12 Devices MUST support the DHCP location options [RFC4776] and >>> [RFC3825] and HELD >> [I-D.ietf-geopriv-http-location-delivery]. Devices >>> SHOULD support all location protocols supported at lower layers by >>> their interfaces (e.g., LLDP-MED [LLDP-MED]). >>> " >>> >>> >>> >>> >>> Brian Rosen wrote: >>>> The problem with SUPL is that the majority of networks where SUPL >>>> would >> be >>>> available have a proxy (E-CSCF) insert location. It also has an >>>> incompatible location representation, and an incompatible >> privacy model. >>>> That makes it very hard to interwork with any of the rest >> of the IETF >>> work. >>>> I will say this. For quite some time, the IETF has been trying to >>> interest >>>> OMA into cooperation on location so that we have >> interoperability at >>>> the protocol, location representation and privacy levels. So far, >>>> that has >>> not >>>> happened. If, as part of a comprehensive agreement to accomplish >>>> such a goal, SUPL became one of the LCPs, I would not object. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Gabor.Bajko@nokia.com >>>> Sent: Thursday, November 20, 2008 9:26 AM >>>> To: James.Winterbottom@andrew.com; ecrit@ietf.org >>>> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> >>>> Hi, >>>> >>>> Is the intent to list the LCPs which are access-type >> agnostic but not >>>> supported anywhere, or instead have a list of LCPs which >> are highly >>>> probable to produce the intended result? >>>> >>>> There are restrictions everywhere, things come at a cost >> even in the >>>> general Internet model. The reality is that most of the >> devices with >>>> internet access have a home network already. >>>> >>>> - Gabor >>>> >>>> >>>> >-----Original Message----- >>>> >From: ext Winterbottom, James >> [mailto:James.Winterbottom@andrew.com] >>>> >Sent: Thursday, November 20, 2008 12:06 AM >>>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >>>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>> > >>>> >Hi Gabor, >>>> > >>>> >The list of LCPs in the phone BCP is a must support list, and is >>>> access- >>>> >type agnostic. >>>> >I am curious that you say that SUPL is a MUST support >> given that: >>>> >a) it requires a home network in order to operate >>>> >b) it simply doesn't work for DSL or Cable >>>> >c) it is questionable whether it is really deployable for WiFi >>>> networks >>>> > >>>> >Can you perhaps describe how it fits into the general >> Internet model? >>>> > >>>> >Cheers >>>> >James >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >>>> >Sent: Thu 11/20/2008 12:48 AM >>>> >To: ecrit@ietf.org >>>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> > >>>> >I was requested to send my observations regarding this >> requirement: >>>> > >>>> > ED-21/INT-12 Devices MUST support all of: DHCP >> location options >>>> > [RFC4776] and [RFC3825], HELD >>>> > [I-D.ietf-geopriv-http-location-delivery] and >> LLDP-MED [LLDP-MED]. >>>> > >>>> > >>>> >I believe we should come up with a list of LCPs which >> are likely >>>> to be >>>> >supported in devices in a not so distant future. Since >> I have no >>>> seen or >>>> >heard about LLDP support yet, at least that should be replaced >>>> with what >>>> >is mostly used today (OMA SUPL) and the 802.11 >> mechanism, with the >>>> >condition that this MUST only be supported if there is a wifi >>>> interface >>>> >available on the device. >>>> > >>>> >- Gabor >>>> > >>>> > >>>> > >>>> >________________________________ >>>> > >>>> >From: ext Tschofenig, Hannes >>>> > >>>> >Sent: Tuesday, November 18, 2008 12:49 PM >>>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>>> >Subject: Location Protocols in Phone BCP >>>> > >>>> > >>>> > >>>> >Gabor, >>>> > >>>> >Could you please raise your question about location >> protocols in >>>> Phone >>>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>>> > >>>> >Ciao >>>> >Hannes >>>> > >>>> > >>>> >> -------------------------------------------------------------------- >>>>> --- >>>> -- >>>> >----------------------- >>>> >This message is for the designated recipient only and may >>>> >contain privileged, proprietary, or otherwise private >> information. >>>> >If you have received it in error, please notify the sender >>>> >immediately and delete the original. Any unauthorized use of >>>> >this email is prohibited. >>>> >> -------------------------------------------------------------------- >>>>> --- >>>> -- >>>> >----------------------- >>>> >[mf2] >>>> >>>> _______________________________________________ >>>> 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 >> > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:06:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF1928C156; Thu, 20 Nov 2008 12:06:47 -0800 (PST) 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 8985C28C156 for ; Thu, 20 Nov 2008 12:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iiAbTR353dEg for ; Thu, 20 Nov 2008 12:06:44 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 929C23A677D for ; Thu, 20 Nov 2008 12:06:44 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3FnQ-0005Bn-1B; Thu, 20 Nov 2008 14:06:36 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Roger Marshall'" , "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> Date: Thu, 20 Nov 2008 15:06:38 -0500 Message-ID: <01e701c94b4b$813eb290$83bc17b0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Gabor accuses us of ignoring reality. The 3GPP crowd has its own version of that. All 3GPP networks I know of support a raw packet service. On that service will run applications like MSN or AOL instant messaging. Those services will need to be able to make emergency chats. To route properly, they need location. That means that EVERY handset must deploy some LCP, and must be able to get location suitable for emergency call routing and dispatch per -phonebcp. The RV example is yet another case of the same thing. The mistake is assuming that all emergency calls will come through the E-CSCF. They won't, and the 3GPP access network must conform to all the -phonebcp requirements. Generally, I agree that SUPL is unsuitable for access networks that don't use GPS or some form of measured location. Brian -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Thursday, November 20, 2008 2:54 PM To: Roger Marshall; Brian Rosen; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: RE: [Ecrit] Location Protocols in Phone BCP I cannot support requiring SUPL in DSL routers, desktop computers (and related operating systems, SIP soft clients), analog terminal adaptors, or other similar devices that are intended for use in a wireline environment. I think that organizations that can drive requirements for devices intended to be use in an environment where SUPL would actually work, should be responsible for having device requirements requiring SUPL. In other words, 3GPP/3GPP2 are absolutely in a position to require SUPL support for devices that operate in an environment where SUPL works. This is a perfect example of the "closed" network that Brian describes somewhere (framework, I think). Phonebcp is about requirements for devices in access environments where the operators of the access environment cannot be assumed to have any control over the type or nature of devices that connect to or through it. Phonebcp needs to continue to have that as its purpose. I agree that nothing in phonebcp should preclude the use of SUPL, or be incompatible with the use of SUPL. And I don't think it does. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, November 20, 2008 2:36 PM To: Brian Rosen; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP If the choice is between preventing, allowing, or requiring PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I would prefer 'require' since *most* of the location-aware 3G compatible handsets/aircards over the next several years will (I predict) have a SUPL stack included. In the same time frame, many of those will also have WiFi support, others will have LTE or WiMAX support as hybrids. SUPL will be common-place. OMA may not be 'Open-Source', it is open-minded, and there is movement afoot to expand OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) w/respect expected proposals such as LocSIP, etc. Over the fairly near-term, I think there will be fewer protocol, location representation, and privacy discontinuities - things that too often get cited - yet are seldom well understood. Let's encourage continued IETF communication with OMA/SUPL - not block its use altogether. This is a case where we need to be inclusive, not exclusive. As to the mobile RV sample case, the solution is also forseeable - especially given that the location of the 3G aircard in the router is good enough for routing. The scenario given needs some integration, but is doable. Given that the aircard acts as a logical SET, with a SUPL stack on board, and a GPS/AGPS chipset inside. This combination *WILL* (I believe) interoperate with a number of end client applications to initiate and complete a location-routed, 3261 style SIP, emergency call through the core, and into an ESInet. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 8:23 AM > To: 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > It's very hard to have L2 specific LCPs. The problem is that > the clients are generally not very L2 aware. It's the > clients that have the problem. > You can do things like interwork an L2 specific LCP to a > common LCP so that non L2 aware devices can work, but you > have to do that, and usually, that's impractical. Use my > example. Suppose that the L2 used SUPL. It's possible for > the PC Card that is plugged into the router could implement a > SUPL client and a HELD server and interwork SUPL in the GSM > system to HELD on the Ethernet so the Ethernet VoIP phone > could get location via HELD. Possible, but not practical. > There are all sorts of these kinds of problems. That's why > L2 specific LCPs don't work. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 20, 2008 11:11 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > The IETF can't (and shouldn't) try to make particular > standards for every access technology that's out there. What > we can say is that the paradigm for those protocols should be > the same as at the IP layer: > Clients MUST implement all, networks MUST implement at least one. > > (This is a little different from the text I sent before, and > clearer, I > think.) > > All I'm saying is that we shouldn't try to enumerate all the > possible protocols at lower layers, we should just state the > general rule. It seems to me that this achieves the same > level of interoperability at all layers. > > --Richard > > > If there are exactly two LCPs all UAs must implement, and > any number > > of optional ones, then every network has to implement at > least one of > > those > two > > LCPs, and any number of optional ones. That means that > "any number of > > optional ones" is useless for both parties. > > If the network can limit UAs to ONLY those that implement > one of the > > optional protocols, then it works, but in practice, it is usually > impossible > > to do that. My example is the wired, Ethernet connected > phone in an > > RV traveling down the road with wireless data card in a > router. These > > EXIST, now. > > > > Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 10:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I think we need to pull up a level. It's not reasonable > for an RFC to > > try to list all of the location protocols out there, if for > no other > > reason than that it will rapidly become obsolete. Instead, > we should > > say something like the following: > > > > " > > INT-12 Devices MUST support the DHCP location options [RFC4776] and > > [RFC3825] and HELD > [I-D.ietf-geopriv-http-location-delivery]. Devices > > SHOULD support all location protocols supported at lower layers by > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > " > > > > > > > > > > Brian Rosen wrote: > >> The problem with SUPL is that the majority of networks where SUPL > >> would > be > >> available have a proxy (E-CSCF) insert location. It also has an > >> incompatible location representation, and an incompatible > privacy model. > >> That makes it very hard to interwork with any of the rest > of the IETF > > work. > >> I will say this. For quite some time, the IETF has been trying to > > interest > >> OMA into cooperation on location so that we have > interoperability at > >> the protocol, location representation and privacy levels. So far, > >> that has > > not > >> happened. If, as part of a comprehensive agreement to accomplish > >> such a goal, SUPL became one of the LCPs, I would not object. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >> Behalf Of Gabor.Bajko@nokia.com > >> Sent: Thursday, November 20, 2008 9:26 AM > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > >> Hi, > >> > >> Is the intent to list the LCPs which are access-type > agnostic but not > >> supported anywhere, or instead have a list of LCPs which > are highly > >> probable to produce the intended result? > >> > >> There are restrictions everywhere, things come at a cost > even in the > >> general Internet model. The reality is that most of the > devices with > >> internet access have a home network already. > >> > >> - Gabor > >> > >> > >> >-----Original Message----- > >> >From: ext Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > >> >Sent: Thursday, November 20, 2008 12:06 AM > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > >> > > >> >Hi Gabor, > >> > > >> >The list of LCPs in the phone BCP is a must support list, and is > >> access- > >> >type agnostic. > >> >I am curious that you say that SUPL is a MUST support > given that: > >> >a) it requires a home network in order to operate > >> >b) it simply doesn't work for DSL or Cable > >> >c) it is questionable whether it is really deployable for WiFi > >> networks > >> > > >> >Can you perhaps describe how it fits into the general > Internet model? > >> > > >> >Cheers > >> >James > >> > > >> > > >> >-----Original Message----- > >> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com > >> >Sent: Thu 11/20/2008 12:48 AM > >> >To: ecrit@ietf.org > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > >> > > >> >I was requested to send my observations regarding this > requirement: > >> > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > location options > >> > [RFC4776] and [RFC3825], HELD > >> > [I-D.ietf-geopriv-http-location-delivery] and > LLDP-MED [LLDP-MED]. > >> > > >> > > >> >I believe we should come up with a list of LCPs which > are likely > >> to be > >> >supported in devices in a not so distant future. Since > I have no > >> seen or > >> >heard about LLDP support yet, at least that should be replaced > >> with what > >> >is mostly used today (OMA SUPL) and the 802.11 > mechanism, with the > >> >condition that this MUST only be supported if there is a wifi > >> interface > >> >available on the device. > >> > > >> >- Gabor > >> > > >> > > >> > > >> >________________________________ > >> > > >> >From: ext Tschofenig, Hannes > >> > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > >> >Subject: Location Protocols in Phone BCP > >> > > >> > > >> > > >> >Gabor, > >> > > >> >Could you please raise your question about location > protocols in > >> Phone > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > >> > > >> >Ciao > >> >Hannes > >> > > >> > > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >This message is for the designated recipient only and may > >> >contain privileged, proprietary, or otherwise private > information. > >> >If you have received it in error, please notify the sender > >> >immediately and delete the original. Any unauthorized use of > >> >this email is prohibited. > >> > >>> > -------------------------------------------------------------------- > >>> --- > >> -- > >> >----------------------- > >> >[mf2] > >> > >> _______________________________________________ > >> 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 > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:16:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F693A6A09; Thu, 20 Nov 2008 12:16:44 -0800 (PST) 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 0DF643A6A09 for ; Thu, 20 Nov 2008 12:16:43 -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 t006muPBqOqX for ; Thu, 20 Nov 2008 12:16:37 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 604A63A6A04 for ; Thu, 20 Nov 2008 12:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1227212191; x=1258748191; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<01e701c94b4b$813eb290$8 3bc17b0$@net>|References:=20=0D=0A=20<7A1F5E234FF 3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com>=0D=0A =20=0D=0A=20<7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@es ebe111.NOE.Nokia.com><00ff01c94b=0D=0A=201d$a5d11e50$f173 5af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a8 0=0D=0A=20$8a869f80$@net>=09<49258C15.2070303@bbn.com>=0D =0A=20<015401c94b2c$374c6ed0$a5e54c70$@net>=0D=0A=20<8C83 7214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecom sys.com>=0D=0A=20<7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F 6@crexc41p>=0D=0A=20<01e701c94b4b$813eb290$83bc17b0$@net> |Date:=20Thu,=2020=20Nov=202008=2014:16:12=20-0600|To:=20 Brian=20Rosen=20,=20"'Stark,=20Barbara '"=20,=0D=0A=20=20=20=20=20=20=20=20"'Rog er=20Marshall'"=20,=0D=0A=20=20 =20=20=20=20=20=20"'Richard=20Barnes'"=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20Location=20Protocols=20in=20P hone=20BCP|CC:=20"Gabor.Bajko@nokia.com"=20,=0D=0A=20=20=20=20=20=20=20=20"hannes.tschofeni g@nsn.com"=20,=0D=0A=20=20=20 =20=20=20=20=20"marc.linsner@cisco.com"=20,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org" =0D=0A=09|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5100,188,5440"=3B=20a=3D"13316337"; bh=queomiAPKLWagF1KP59AkqdBgFaYGvPwGZ63Sz67Fz4=; b=Op9vAJoB/HMFrb/8I6ZRV/LKxIRD/OViddnWgpWYTUwVYf6PhpxujBzy O7miSPEe8r+izSuvwiGLNKFPhlAK/xmQv1mcpaSip9KKZc1XxfV/82Vzf tWl5ujZecbawA6oM900HCdk67tx7A3EbSxcrkcN2fKXajAmM1ELwLDIF9 Y=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13316337" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 12:16:17 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKGHZr004302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 12:16:17 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKGGm0010671 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Nov 2008 12:16:17 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:16:15 -0800 Received: from [130.129.30.23] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:16:15 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <01e701c94b4b$813eb290$83bc17b0$@net> References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b 1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80 $8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> Date: Thu, 20 Nov 2008 14:16:12 -0600 To: Brian Rosen , "'Stark, Barbara'" , "'Roger Marshall'" , "'Richard Barnes'" From: Ted Hardie Cc: "Gabor.Bajko@nokia.com" , "marc.linsner@cisco.com" , "hannes.tschofenig@nsn.com" , "ecrit@ietf.org" Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:06 PM -0800 11/20/08, Brian Rosen wrote: >Gabor accuses us of ignoring reality. The 3GPP crowd has its own version of >that. > >All 3GPP networks I know of support a raw packet service. On that service >will run applications like MSN or AOL instant messaging. Those services >will need to be able to make emergency chats. Sorry, can you point me to the current text in PhoneBCP or Framework where we describe the emergency chats? Grep didn't find it for me, and I must have missed the fun on defining that. In general, it might be best not to change the subject, if we are to actually conclude this conversation. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:20:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC403A6A09; Thu, 20 Nov 2008 12:20:52 -0800 (PST) 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 F2A1B3A685E; Thu, 20 Nov 2008 12:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRfzujT7TXuw; Thu, 20 Nov 2008 12:20:49 -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 3E4163A68F7; Thu, 20 Nov 2008 12:20:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28512788" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 20:20:47 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKKl9t019690; Thu, 20 Nov 2008 15:20:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKKlRr022999; Thu, 20 Nov 2008 20:20:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:20:47 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.30]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:20:47 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 14:20:46 -0600 To: Janet P Gunn , "'ECRIT'" , ecrit-bounces@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 20:20:47.0196 (UTC) FILETIME=[7908E1C0:01C94B4D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8460; t=1227212447; x=1228076447; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20earlier=20comments=20Re=3A=20[Ecrit]=0A =20=20draft-ietf-ecrit-local-emergency-rph-namespace-00 |Sender:=20 |To:=20Janet=20P=20Gunn=20,=20=22'ECRIT'=22 =20,=0A=20=20=20=20=20=20=20=20ecrit-bounces @ietf.org; bh=yFVOVqSzQ2+2XcZhvZwOfEDmT6UMGPIW0bz/NozRCPc=; b=b4GeLTKQHWiJzrBS2hetTOBQ3WZoa1psbc5wmavGiSPWt9IgRY2pFZw3uX /tpKuwwFAAahKBRGzG5Nztsf1Yv61Wtz4gl1tQR8BJQNDLkXgzHHfGEZHQ4y gsv6V0ziDP; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] earlier comments Re: draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Janet BTW - I received your last message and just hadn't cycled the time to both respond to it and make any necessary text changes to address your acceptable concerns. I will get to your comments very soon (my mind is just focusing on other topics at the moment (other than the quick responses to Hannes's threat bashing the whole reason for this ID)). I apologize for not communicating this earlier James At 05:21 PM 11/18/2008, Janet P Gunn wrote: >Since we are now actively talking about this document, I am >resending my earlier comments. I expect they were missed because >everyone was in the middle of meeting the ID dead line. > >Janet > > >ecrit-bounces@ietf.org wrote on 10/27/2008 11:45:43 PM: > > > > > I apologize for not tracking this as closely as I meant to, as these > > comments apply to earlier versions as well. > > > > > > This sentence at the end of sec 1 doesn't quite work. > > "This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not just > > of those from citizens to PSAPs." (no clear antecedent for "those") > > > > Perhaps > > "This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not > > just for calls or sessions > > from citizens to PSAPs." > > > > Section 2 says > > "This document updates the behaviors of the SIP Resource Priority > > header, defined in [RFC4412], during the treatment options > > surrounding this new "esnet" namespace only. The usage of the > > "esnet" namespace does not have a normal, or routine call level. > > Every use of this namespace will be in times of an emergency, where > > at least one end of the signaling is with a local emergency > > organization." > > > > I don't see this as an "update of the behavior of 4412". Neither > > the ets namespace not the wps > > namespace have a "normal" or "routine" call level. Every use of the > > wps and ets namespaces will > > have priority over calls without RPH. > > > > You say "This > > namespace, therefore, MAY be overwritten or deleted, contrary to the > > rules of RFC 4412 [RFC4412]." > > > > It is not clear to me why this is "contrary to the rules of 4412". > > It is certainly anticipated > > that other RPH will be overwritten or deleted, when the UAS > > understands the namespace. > > > > 4412 says "Existing implementations of RFC 3261 that do not > participate in the > > resource priority mechanism follow the normal rules of RFC 3261, > > Section 8.2.2: "If a UAS does not understand a header field in a > > request (that is, the header field is not defined in this > > specification or in any supported extension), the server MUST ignore > > that header field and continue processing the message". " > > > > But I do not see anywhere that is says that a UAS that DOES > > understand the namespace is > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > that "the UAC > > MAY attempt a subsequent request with the same or different resource > > value." This certainly implies the ability to overwrite or > > delete an RPH namespace. > > > > (See also, for instance the PTSC SAC document on the use of the ets > > and wps namespaces) > > > > Immediately following these statements, you give 3 options- > > "These proxies in the service provider > > MAY either > > > > o accept the existing RPH value with "esnet" in it, if one is > > present, and grant relative preferential treatment to the request > > when forwarding it to the ESINet. > > > > o replace any existing RPH value, if one is present, and insert an > > "esnet" namespace and give relative preferential treatment to the > > request when forwarding it to the ESINet. > > > > o insert an "esnet" namespace in a new RPH and give relative > > preferential treatment to the request when forwarding the SIP > > request towards the ESINet." > > > > Why do you exclude the possibility of adding the esnet RPH value > > without "replacing" an existing RPH value? > > > > Finally, there is another point that needs to be made clear. At > > least one person has contacted me expressing concern that this ID > > implied that the esnet namespace would have priority over other > > namespaces (in particular wps and ets). I assured him that this was > > not the case, that there was nothing prevent the expected behavior - > > that the ets and wps namespaces would be prioritized ahead of esnet > > in GETS Service Provider networks. > > > > However, since the question has already arisen, it would be a good > > idea to clarify this, perhaps in section 3, where you discuss the > > other namespaces. In particular, it needs to be made clear in > > section 3.2 that, even if "the local jurisdiction preferred to > > preempt normal calls in lieu of > > completing emergency calls. ", esnet calls will NOT preempt wps > > or ets calls. > > > > By the way, I think you mean "the local jurisdiction preferred to > > preempt normal calls in order to complete emergency calls. " - not > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > preempt normal calls in lieu of dropping emergency calls. " > > > > In fact, it is not clear to me that 4412 permits a call with an RPH > > (e.g., esnet) to preempt a "normal" call (with no RPH namespace). > > Section 4.7.2.1 of 4412 says > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > A UAS compliant with this specification MUST terminate a session > > established with a valid namespace and lower-priority value in favor > > of a new session set up with a valid namespace and higher relative > > priority value, unless local policy has some form of call-waiting > > capability enabled. " > > > > It doesn't say anything about preempting a call with no RPH > > > > Thanks > > > > Janet > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > please delete without copying and kindly advise us by e-mail of the > > mistake in delivery. > > NOTE: Regardless of content, this e-mail shall not operate to bind > > CSC to any order or other contract unless pursuant to explicit > > written agreement or government initiative expressly permitting the > > use of e-mail for such purpose. > > > > > > > "James M. Polk" > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 08:32 PM > > > > To > > > > "'ECRIT'" > > > > cc > > > > Subject > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > ECRIT WG > > > > Here is a update to a ID I think is pretty near done, given that this > > is merely an IANA registration ID of an existing mechanism. > > > > Comments are wanted > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > >This draft is a work item of the Emergency Context Resolution with > > >Internet Technologies Working Group of the IETF. > > > > > > > > > Title : IANA Registering a SIP Resource Priority > > > Header Namespace for Local Emergency Communications > > > Author(s) : J. Polk > > > Filename : > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > Pages : 9 > > > Date : 2008-10-27 > > > > > >This document creates and IANA registers the new Session Initiation > > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > > >local emergency usage to a public safety answering point (PSAP), > > >between PSAPs, and between a PSAP and first responders and their > > >organizations. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Thu Nov 20 12:23:21 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C173A69D8; Thu, 20 Nov 2008 12:23:21 -0800 (PST) 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 C5AAE3A69D8 for ; Thu, 20 Nov 2008 12:23:20 -0800 (PST) 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 w03NANU64IPe for ; Thu, 20 Nov 2008 12:23:19 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id AB0423A698B for ; Thu, 20 Nov 2008 12:23:17 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 12:23:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 12:22:04 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <01e701c94b4b$813eb290$83bc17b0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> From: "Roger Marshall" To: "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > Generally, I agree that SUPL is unsuitable for access > networks that don't use GPS or some form of measured location. [rsm - measured only - really? - surely you aren't suggesting that OMA (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough location' via CellID, are you? Wiremap location - given (manually input)] CellID location - given Terrestial trilateration - measured Celestial trilateration - measured Geocoded/reverse geocoded - derived I would hope that PhoneBCP doesn't show a pre-disposition to 'given' location scenarios, aka wiremap, etc. that are more Wireline oriented, rather than mobile. For the future, wireline devices reduce in number, mobile (or even nomadic) devices will continue in their distribution bias. Fixed vs. Mobile has been the fundamental difference between how the IETF looks at things vs. these mentioned other fora. I contend that if we solve this for mobile - then we can begin communicating better with OMA/3GPP/3GPP2, and... Solving fixed will be easier. /] > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 20, 2008 12:07 PM > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Gabor accuses us of ignoring reality. The 3GPP crowd has its > own version of that. > > All 3GPP networks I know of support a raw packet service. On > that service will run applications like MSN or AOL instant > messaging. Those services > will need to be able to make emergency chats. To route > properly, they need > location. That means that EVERY handset must deploy some > LCP, and must be able to get location suitable for emergency > call routing and dispatch per -phonebcp. The RV example is > yet another case of the same thing. The mistake is assuming > that all emergency calls will come through the E-CSCF. > They won't, and the 3GPP access network must conform to all > the -phonebcp requirements. > > Generally, I agree that SUPL is unsuitable for access > networks that don't use GPS or some form of measured location. > > Brian > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 20, 2008 2:54 PM > To: Roger Marshall; Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > I cannot support requiring SUPL in DSL routers, desktop > computers (and related operating systems, SIP soft clients), > analog terminal adaptors, or other similar devices that are > intended for use in a wireline environment. I think that > organizations that can drive requirements for devices > intended to be use in an environment where SUPL would > actually work, should be responsible for having device > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > absolutely in a position to require SUPL support for devices > that operate in an environment where SUPL works. This is a > perfect example of the "closed" network that Brian describes > somewhere (framework, I think). > > Phonebcp is about requirements for devices in access > environments where the operators of the access environment > cannot be assumed to have any control over the type or nature > of devices that connect to or through it. Phonebcp needs to > continue to have that as its purpose. > > I agree that nothing in phonebcp should preclude the use of > SUPL, or be incompatible with the use of SUPL. And I don't > think it does. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, November 20, 2008 2:36 PM > To: Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > If the choice is between preventing, allowing, or requiring > PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I > would prefer 'require' since *most* of the location-aware 3G > compatible handsets/aircards over the next several years will > (I predict) have a SUPL stack included. In the same time > frame, many of those will also have WiFi support, others will > have LTE or WiMAX support as hybrids. > > SUPL will be common-place. OMA may not be 'Open-Source', it > is open-minded, and there is movement afoot to expand > OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) > w/respect expected proposals such as LocSIP, etc. Over the > fairly near-term, I think there will be fewer protocol, > location representation, and privacy discontinuities - things > that too often get cited - yet are seldom well understood. > > Let's encourage continued IETF communication with OMA/SUPL - > not block its use altogether. This is a case where we need > to be inclusive, not exclusive. > > As to the mobile RV sample case, the solution is also > forseeable - especially given that the location of the 3G > aircard in the router is good enough for routing. The > scenario given needs some integration, but is doable. Given > that the aircard acts as a logical SET, with a SUPL stack on > board, and a GPS/AGPS chipset inside. This combination > *WILL* (I believe) interoperate with a number of end client > applications to initiate and complete a location-routed, 3261 > style SIP, emergency call through the core, and into an ESInet. > > -roger. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Brian Rosen > > Sent: Thursday, November 20, 2008 8:23 AM > > To: 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > It's very hard to have L2 specific LCPs. The problem is that the > > clients are generally not very L2 aware. It's the clients > that have > > the problem. > > You can do things like interwork an L2 specific LCP to a > common LCP so > > that non L2 aware devices can work, but you have to do that, and > > usually, that's impractical. Use my example. Suppose that the L2 > > used SUPL. It's possible for the PC Card that is plugged into the > > router could implement a SUPL client and a HELD server and > interwork > > SUPL in the GSM system to HELD on the Ethernet so the Ethernet VoIP > > phone could get location via HELD. Possible, but not practical. > > There are all sorts of these kinds of problems. That's why > > L2 specific LCPs don't work. > > > > Brian > > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 11:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > The IETF can't (and shouldn't) try to make particular standards for > > every access technology that's out there. What we can say > is that the > > paradigm for those protocols should be the same as at the IP layer: > > Clients MUST implement all, networks MUST implement at least one. > > > > (This is a little different from the text I sent before, > and clearer, > > I > > think.) > > > > All I'm saying is that we shouldn't try to enumerate all > the possible > > protocols at lower layers, we should just state the general > rule. It > > seems to me that this achieves the same level of > interoperability at > > all layers. > > > > --Richard > > > > > If there are exactly two LCPs all UAs must implement, and > > any number > > > of optional ones, then every network has to implement at > > least one of > > > those > > two > > > LCPs, and any number of optional ones. That means that > > "any number of > > > optional ones" is useless for both parties. > > > If the network can limit UAs to ONLY those that implement > > one of the > > > optional protocols, then it works, but in practice, it is usually > > impossible > > > to do that. My example is the wired, Ethernet connected > > phone in an > > > RV traveling down the road with wireless data card in a > > router. These > > > EXIST, now. > > > > > > Brian > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, November 20, 2008 10:11 AM > > > To: Brian Rosen > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > I think we need to pull up a level. It's not reasonable > > for an RFC to > > > try to list all of the location protocols out there, if for > > no other > > > reason than that it will rapidly become obsolete. Instead, > > we should > > > say something like the following: > > > > > > " > > > INT-12 Devices MUST support the DHCP location options > [RFC4776] and > > > [RFC3825] and HELD > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > SHOULD support all location protocols supported at lower > layers by > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > " > > > > > > > > > > > > > > > Brian Rosen wrote: > > >> The problem with SUPL is that the majority of networks > where SUPL > > >> would > > be > > >> available have a proxy (E-CSCF) insert location. It also has an > > >> incompatible location representation, and an incompatible > > privacy model. > > >> That makes it very hard to interwork with any of the rest > > of the IETF > > > work. > > >> I will say this. For quite some time, the IETF has been > trying to > > > interest > > >> OMA into cooperation on location so that we have > > interoperability at > > >> the protocol, location representation and privacy > levels. So far, > > >> that has > > > not > > >> happened. If, as part of a comprehensive agreement to > accomplish > > >> such a goal, SUPL became one of the LCPs, I would not object. > > >> > > >> Brian > > >> > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >> Behalf Of Gabor.Bajko@nokia.com > > >> Sent: Thursday, November 20, 2008 9:26 AM > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > >> > > >> Hi, > > >> > > >> Is the intent to list the LCPs which are access-type > > agnostic but not > > >> supported anywhere, or instead have a list of LCPs which > > are highly > > >> probable to produce the intended result? > > >> > > >> There are restrictions everywhere, things come at a cost > > even in the > > >> general Internet model. The reality is that most of the > > devices with > > >> internet access have a home network already. > > >> > > >> - Gabor > > >> > > >> > > >> >-----Original Message----- > > >> >From: ext Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > >> > > > >> >Hi Gabor, > > >> > > > >> >The list of LCPs in the phone BCP is a must support > list, and is > > >> access- > > >> >type agnostic. > > >> >I am curious that you say that SUPL is a MUST support > > given that: > > >> >a) it requires a home network in order to operate > > >> >b) it simply doesn't work for DSL or Cable > > >> >c) it is questionable whether it is really deployable > for WiFi > > >> networks > > >> > > > >> >Can you perhaps describe how it fits into the general > > Internet model? > > >> > > > >> >Cheers > > >> >James > > >> > > > >> > > > >> >-----Original Message----- > > >> >From: ecrit-bounces@ietf.org on behalf of > Gabor.Bajko@nokia.com > > >> >Sent: Thu 11/20/2008 12:48 AM > > >> >To: ecrit@ietf.org > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > >> > > > >> >I was requested to send my observations regarding this > > requirement: > > >> > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > location options > > >> > [RFC4776] and [RFC3825], HELD > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > LLDP-MED [LLDP-MED]. > > >> > > > >> > > > >> >I believe we should come up with a list of LCPs which > > are likely > > >> to be > > >> >supported in devices in a not so distant future. Since > > I have no > > >> seen or > > >> >heard about LLDP support yet, at least that should be > replaced > > >> with what > > >> >is mostly used today (OMA SUPL) and the 802.11 > > mechanism, with the > > >> >condition that this MUST only be supported if there is a wifi > > >> interface > > >> >available on the device. > > >> > > > >> >- Gabor > > >> > > > >> > > > >> > > > >> >________________________________ > > >> > > > >> >From: ext Tschofenig, Hannes > > >> > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > >> >Subject: Location Protocols in Phone BCP > > >> > > > >> > > > >> > > > >> >Gabor, > > >> > > > >> >Could you please raise your question about location > > protocols in > > >> Phone > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > >> > > > >> >Ciao > > >> >Hannes > > >> > > > >> > > > >> > > >>> > > -------------------------------------------------------------------- > > >>> --- > > >> -- > > >> >----------------------- > > >> >This message is for the designated recipient only and may > > >> >contain privileged, proprietary, or otherwise private > > information. > > >> >If you have received it in error, please notify the sender > > >> >immediately and delete the original. Any unauthorized use of > > >> >this email is prohibited. > > >> > > >>> > > -------------------------------------------------------------------- > > >>> --- > > >> -- > > >> >----------------------- > > >> >[mf2] > > >> > > >> _______________________________________________ > > >> 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 > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may be privileged and/or confidential. If you are not > the intended recipient, or responsible for delivering this > message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication > or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender > immediately, and delete it and all attachments from your > computer and network. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact the > sender and delete the material from all computers. GA621 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:25:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5288028C1F4; Thu, 20 Nov 2008 12:25:30 -0800 (PST) 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 2971F28C1F4 for ; Thu, 20 Nov 2008 12:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzHUZnkkWC6D for ; Thu, 20 Nov 2008 12:25:27 -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 4522428C1DE for ; Thu, 20 Nov 2008 12:25:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28513443" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 20:25:25 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKPPjp022630; Thu, 20 Nov 2008 15:25:25 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKPOxE007881; Thu, 20 Nov 2008 20:25:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:25:24 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.30]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:25:24 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 14:25:23 -0600 To: "Brian Rosen" , "'Janet P Gunn'" , "'GOLDMAN, STUART O \(STUART\)'" From: "James M. Polk" In-Reply-To: <015301c94b2b$60155ee0$20401ca0$@net> References: <7D096A439A3D0D48A3D10872022CFD090359D22F@ILEXC1U02.ndc.lucent.com> <015301c94b2b$60155ee0$20401ca0$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 20:25:24.0459 (UTC) FILETIME=[1E4BDBB0:01C94B4E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10689; t=1227212725; x=1228076725; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Ecrit]=0A=20=20draft-ietf-ecr it-local-emergency-rph-namespace-00 |Sender:=20 |To:=20=22Brian=20Rosen=22=20,=20=22'Jan et=20P=20Gunn'=22=20,=0A=20=20=20=20=20=20=2 0=20=22'GOLDMAN,=20STUART=20O=20\(STUART\)'=22=20; bh=u5hNk+EMUe9X3coqlc+oo5phbipdw2Asiuh9/AqtxxI=; b=m3yKO9gGqcJQxCiw4Hxs+ts8aEmG1SLu/Odvy6VWc9KwqnfVLJ7fIUOXWe CUv3RSQ1jzb2g7AHx2+aUMANfuhbyGKUvAVEX9wa5U2fX2jGs+9jeC03LbUg v411/rCky1; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:16 AM 11/20/2008, Brian Rosen wrote: >A suggestion was made to me that we should define two namespaces. > >One would be used in public networks, and generally would be used to request >resource priority for citizen to authority and possibly authority to citizen >calls. This would have lower priority than ETS/WPS. > >The other would be for use within emergency services IP networks. It would >be unlikely that ETS/WPS would be used within those networks, but if it was, >some values within the namespace would need higher priority that ETS/WPS. >For example, a message which was an incident commanders "evacuate" message >would be higher than a ETS/WPS traffic. On the other hand, a citizen to >authority emergency call would have lower priority. > >I would be happier with one namespace and more values in that namespace for >all of this, but I was advised that two namespaces was a better choice. Brian I have to admit this is the first time I'm aware of this suggestion (of two namespaces). To your point about "I would be happier with one namespace and more values in that namespace"... is 5 priority-values not enough? If not, how many do you want? James >Brian > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Janet P Gunn >Sent: Thursday, November 20, 2008 11:00 AM >To: GOLDMAN, STUART O (STUART) >Cc: Ecrit@ietf.org >Subject: Re: [Ecrit] Ecrit] >draft-ietf-ecrit-local-emergency-rph-namespace-00 > > >Stu, > >I intended to say that the esnet namespace needs to be at a LOWER priority > than the ets and wps namespaces, in any network that recognizes ets and wps >as described in 10.5 and 10.6 of RFC4412. > >Janet > >"GOLDMAN, STUART O \(STUART\)" wrote on >11/20/2008 10:22:49 AM: > > > Janet, > > > > With regard to you e-mail below, did you intend that esnet could be > > at the same level of priority as ETS & WPS, or that ETS & WPS need > > to be at an even higher priority than esnet? > > > > > > > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 11:45 PM > > > > > > > > To > > > > "James M. Polk" > > > > cc > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > Subject > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant to, as these > > comments apply to earlier versions as well. > > > > > > This sentence at the end of sec 1 doesn't quite work. > > "This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not just > > of those from citizens to PSAPs." (no clear antecedent for "those") > > > > Perhaps > > "This document IANA registers the "esnet" > > RPH namespace for use within emergency services networks, not just > > for calls or sessions > > from citizens to PSAPs." > > > > Section 2 says > > "This document updates the behaviors of the SIP Resource Priority > > header, defined in [RFC4412], during the treatment options > > surrounding this new "esnet" namespace only. The usage of the > > "esnet" namespace does not have a normal, or routine call level. > > Every use of this namespace will be in times of an emergency, where > > at least one end of the signaling is with a local emergency > > organization." > > > > I don't see this as an "update of the behavior of 4412". Neither > > the ets namespace not the wps > > namespace have a "normal" or "routine" call level. Every use of the > > wps and ets namespaces will > > have priority over calls without RPH. > > > > You say "This > > namespace, therefore, MAY be overwritten or deleted, contrary to the > > rules of RFC 4412 [RFC4412]." > > > > It is not clear to me why this is "contrary to the rules of 4412". > > It is certainly anticipated > > that other RPH will be overwritten or deleted, when the UAS > > understands the namespace. > > > > 4412 says "Existing implementations of RFC 3261 that do not participate in >the > > resource priority mechanism follow the normal rules of RFC 3261, > > Section 8.2.2: "If a UAS does not understand a header field in a > > request (that is, the header field is not defined in this > > specification or in any supported extension), the server MUST ignore > > that header field and continue processing the message". " > > > > But I do not see anywhere that is says that a UAS that DOES > > understand the namespace is > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > that "the UAC > > MAY attempt a subsequent request with the same or different resource > > value." This certainly implies the ability to overwrite or delete > > an RPH namespace. > > > > (See also, for instance the PTSC SAC document on the use of the ets > > and wps namespaces) > > > > Immediately following these statements, you give 3 options- > > "These proxies in the service provider > > MAY either > > > > o accept the existing RPH value with "esnet" in it, if one is > > present, and grant relative preferential treatment to the request > > when forwarding it to the ESINet. > > > > o replace any existing RPH value, if one is present, and insert an > > "esnet" namespace and give relative preferential treatment to the > > request when forwarding it to the ESINet. > > > > o insert an "esnet" namespace in a new RPH and give relative > > preferential treatment to the request when forwarding the SIP > > request towards the ESINet." > > > > Why do you exclude the possibility of adding the esnet RPH value > > without "replacing" an existing RPH value? > > > > Finally, there is another point that needs to be made clear. At > > least one person has contacted me expressing concern that this ID > > implied that the esnet namespace would have priority over other > > namespaces (in particular wps and ets). I assured him that this was > > not the case, that there was nothing prevent the expected behavior - > > that the ets and wps namespaces would be prioritized ahead of esnet > > in GETS Service Provider networks. > > > > However, since the question has already arisen, it would be a good > > idea to clarify this, perhaps in section 3, where you discuss the > > other namespaces. In particular, it needs to be made clear in > > section 3.2 that, even if "the local jurisdiction preferred to > > preempt normal calls in lieu of > > completing emergency calls. ", esnet calls will NOT preempt wps or ets >calls. > > > > By the way, I think you mean "the local jurisdiction preferred to > > preempt normal calls in order to complete emergency calls. " - not > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > preempt normal calls in lieu of dropping emergency calls. " > > > > In fact, it is not clear to me that 4412 permits a call with an RPH > > (e.g., esnet) to preempt a "normal" call (with no RPH namespace). > > Section 4.7.2.1 of 4412 says > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > A UAS compliant with this specification MUST terminate a session > > established with a valid namespace and lower-priority value in favor > > of a new session set up with a valid namespace and higher relative > > priority value, unless local policy has some form of call-waiting > > capability enabled. " > > > > It doesn't say anything about preempting a call with no RPH > > > > Thanks > > > > Janet > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > please delete without copying and kindly advise us by e-mail of the > > mistake in delivery. > > NOTE: Regardless of content, this e-mail shall not operate to bind > > CSC to any order or other contract unless pursuant to explicit > > written agreement or government initiative expressly permitting the > > use of e-mail for such purpose. > > > > "James M. Polk" > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 08:32 PM > > > > > > > > > > To > > > > "'ECRIT'" > > > > cc > > > > > > > > Subject > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > Here is a update to a ID I think is pretty near done, given that this > > is merely an IANA registration ID of an existing mechanism. > > > > Comments are wanted > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > >This draft is a work item of the Emergency Context Resolution with > > >Internet Technologies Working Group of the IETF. > > > > > > > > > Title : IANA Registering a SIP Resource Priority > > > Header Namespace for Local Emergency Communications > > > Author(s) : J. Polk > > > Filename : > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > Pages : 9 > > > Date : 2008-10-27 > > > > > >This document creates and IANA registers the new Session Initiation > > >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for > > >local emergency usage to a public safety answering point (PSAP), > > >between PSAPs, and between a PSAP and first responders and their > > >organizations. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > _______________________________________________ > > 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 > > > > > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. > > > > > > > >_______________________________________________ >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 ecrit-bounces@ietf.org Thu Nov 20 12:28:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BEF3A6A37; Thu, 20 Nov 2008 12:28:44 -0800 (PST) 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 D3AFE28C1D2 for ; Thu, 20 Nov 2008 12:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoY2EEIlsx3k for ; Thu, 20 Nov 2008 12:28:41 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0092D3A698B for ; Thu, 20 Nov 2008 12:28:40 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAKKSYiD005523 for ; Thu, 20 Nov 2008 22:28:37 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 22:28:31 +0200 Received: from esebe111.NOE.Nokia.com ([172.21.143.154]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 22:28:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 22:28:29 +0200 Message-ID: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EEF15@esebe111.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Thread-Index: Ack5RPmctDaLBYLMQfOZ1eGL7U/9fgCsoe+wA9WV5bA= From: To: X-OriginalArrivalTime: 20 Nov 2008 20:28:31.0599 (UTC) FILETIME=[8DD727F0:01C94B4E] X-Nokia-AV: Clean Subject: [Ecrit] FW: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Regarding unauthenticated emergency access, the authors had some off-list message exchanges and a new version of the draft was posted. I was asked to forward this mail exchange to the list to help start discussion on it. Therefore, we would welcome comments. Henning did have answer to my comments, but I let him decide whether it wants to forward that to the list or not. - Gabor -----Original Message----- From: 'Bajko Gabor' Sent: Saturday, November 01, 2008 1:40 AM To: 'ext Henning Schulzrinne'; Hannes Tschofenig Cc: Stephen McCann Subject: RE: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - Section 1 Isn't it a safe assumtion that in case of NAA, the existence of a VSP does not matter? I.e., when the ISP gives access to an NAA device for emergency calls purposes, it is expected to provide additional assistance for the end host to place the emergency call, without requiring the end host to have a VSP. In NVP case the ISP has no means to know that it needs to provide emergency call related additional assistance to the end host. The end host is pretty much on its own and needs to have a way to determine its location and find a LoST server, even in case RFC5223 is not supported by the ISP. Or, have a separate requirement that ISPs committed to assist end hosts in emergency calling, need to support RFC5223. Or, as described in section 5, have an ESRP which routes the call to the PSAP to which that access network belongs to. The ZBP case can be split into either NVP or regular VoIP emergency call through a VoIP service provider, depending on whether the VSP is required by regulation to provide emergency calling services to such customers or not. I think it is good to have these definitions, but at the end it all comes down to what assistance an ISP needs to provide to an end host in the NAA case, or what the end host is supposed to do when it does have network access, but does not have a VSP which could assist it in emergency calling. - Gabor >-----Original Message----- >From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Tuesday, October 28, 2008 2:31 PM >To: Hannes Tschofenig >Cc: Bajko Gabor (Nokia-CIC/MtView); Stephen McCann >Subject: Comments on draft-schulzrinne-ecrit-unauthenticated-access-03 - >Section 1 > >I think the current terminology is really confusing, as it commingles >access authorization and VSP authorization, which have rather >different consequences. Thus, if this is the WiMax terminology, I >think they are just wrong and we shouldn't propagate their confusing >terminology. > >I'm not sure about my attempt below, so I'd appreciate comments. In >particular, there might be a better name instead of ZBP. > >--- > >Second paragraph and following: > >Roughly speaking, the IETF emergency services architecture [bcp] >divides responsibility for handling emergency calls between the access >network (ISP), the VoIP service provider (VSP) and the provider of >emergency signaling services, the emergency service network (ESN). The >access network may provide location information to end systems, but >does not have to provide any VoIP signaling functionality. The >emergency caller can reach the ESN either directly or through the VoIP >provider's outbound proxy. Any of the three parties can provide the >mapping from location to PSAP URI by offering LoST [RFC] services. > >In general, a set of automated configuration mechanisms allows a >device to function in a variety of architectures, without the user >being aware of the details on who provides location, mapping services >or call routing services. However, if emergency calling is to be >supported when the calling device lacks access network authorization >or does not have a VoIP provider, one or more of the providers may >need to provide additional services and functions. > >In all cases, the end device MUST be able to perform a LoST lookup and >otherwise conduct the emergency call in the same manner as when the >three exceptional conditions discussed below do not apply. > >We distinguish between three conditions: > >(1) No access authorization (NAA): The current access network requires >access authorization and the caller does not have valid user >credentials. (This includes the case where the access network allows >pay-per-use, as is common for wireless hotspots, but there is >insufficient time to pay for access.) > >(2) No VoIP provider (NVP): The caller does not have a VoIP service >provider (VSP) at the time of the call. > >(3) Zero-balance VoIP provider (ZBP): The caller has valid credentials >with a VSP, but is not allowed to place calls, e.g., because the user >has a zero balance in a prepaid account. > >A user may well suffer from both NAA and NVP or ZBP at the same time. >Depending on local policy and regulations, it may not be possible to >place emergency calls in the NAA case. Unless local regulations >require user identification, it should always be possible to place >calls in the NVP case, with minimal impact on the ISP. Unless the ESN >requires that all calls traverse a known set of VSPs, a caller should >be able to place an emergency call in the ZBP case. We discuss each >case in separate sections below. > >---- > >
No Access Authorization (NAA) > >In the NAA (No Access Authorization) case, the emergency caller does >not posses valid credentials for the access network. If local >regulations or policy allows or require, the access network may or >needs to cooperate in providing emergency calling services. Generally, >the ISP will want to ensure that devices do not pretend to place >emergency calls, but then abuse the access for obtaining more general >services fraudulently. > >In particular, the ISP MUST allow emergency callers to acquire an IP >address and to reach a LoST server, either provided by the ISP or some >third party. It SHOULD also provide location information via one of >the mechanisms specified in [bcp] without requiring authorization >unless it can safely assume that all nodes in the access network can >determine their own location, e.g., via GPS. > >The details of how filtering is performed depends on the details of >the ISP architecture and are beyond the scope of this document. We >illustrate a possible model. If the ISP runs its own LoST server, it >would maintain an access control list including all IP addresses >contained in responses returned by the LoST server, as well as the >LoST server itself. (It may need to translate the domain names >returned to IP addresses and hope that the resolution captures all >possible DNS responses.) Since the media destination addresses are not >predictable, the ISP also has to provide a SIP outbound proxy so that >it can determine the media addresses and add those to the filter list. > >
No VoIP Service Provider (NVP) > >In the second case, the emergency caller has no current VoIP service >provider (VSP). This case poses no particular difficulties unless it >is assumed that only VSPs provide LoST server or that ESNs only accept >calls that reach it through a set of known VSPs. However, since the >calling device cannot obtain configuration information from its VSP, >the ISP MUST provide the address of a LoST server via DHCP [rfc] if >this model is to be supported. The LoST server may be operated either >by the ISP or a third party. > >
Zero-Balance VoIP Service Provider (ZBP) > >In the case of zero-balance VoIP service provider, the VSP can >authenticate the caller, but the caller is not authorized to place >regular VoIP calls, e.g., because the contract has expired or the >prepaid account for the customer has been depleted. Naturally, a VSP >can simply disallow access by such customers, so that all such >customers find themselves in the NVP situation described above. If >VSPs desire or are required by regulation to provide emergency calling >services to such customers, they need to provide LoST services to such >customers and may need to provide outbound SIP proxy services. As >usual, the calling device looks up the LoST server via SIP >configuration. > >Unless the emergency call traverses a PSTN gateway or the VSP charges >for IP-to-IP calls, there is little potential for fraud. If the VSP >also operates the LoST server, the outbound proxy MAY restrict >outbound calls to the SIP URIs returned by the LoST server. It is NOT >RECOMMENDED to rely on a fixed list of SIP URIs, as that list may >change. > >--- > >Henning > > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:32:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C802328C1D2; Thu, 20 Nov 2008 12:32:13 -0800 (PST) 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 E014A3A6939 for ; Thu, 20 Nov 2008 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 SsS9gvUqfE-w for ; Thu, 20 Nov 2008 12:32:11 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 876153A6986 for ; Thu, 20 Nov 2008 12:32:10 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3GC1-0007IY-Ir; Thu, 20 Nov 2008 14:32:02 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , "'Stark, Barbara'" , "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> Date: Thu, 20 Nov 2008 15:32:06 -0500 Message-ID: <020601c94b4f$101d8740$305895c0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Phonebcp doesn't have a pre-disposition. It's neutral. If we need to parse more carefully, SUPL isn't very suitable for wiremap forms of location determination. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Thursday, November 20, 2008 3:22 PM To: Brian Rosen; Stark, Barbara; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: RE: [Ecrit] Location Protocols in Phone BCP > Generally, I agree that SUPL is unsuitable for access > networks that don't use GPS or some form of measured location. [rsm - measured only - really? - surely you aren't suggesting that OMA (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough location' via CellID, are you? Wiremap location - given (manually input)] CellID location - given Terrestial trilateration - measured Celestial trilateration - measured Geocoded/reverse geocoded - derived I would hope that PhoneBCP doesn't show a pre-disposition to 'given' location scenarios, aka wiremap, etc. that are more Wireline oriented, rather than mobile. For the future, wireline devices reduce in number, mobile (or even nomadic) devices will continue in their distribution bias. Fixed vs. Mobile has been the fundamental difference between how the IETF looks at things vs. these mentioned other fora. I contend that if we solve this for mobile - then we can begin communicating better with OMA/3GPP/3GPP2, and... Solving fixed will be easier. /] > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 20, 2008 12:07 PM > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Gabor accuses us of ignoring reality. The 3GPP crowd has its > own version of that. > > All 3GPP networks I know of support a raw packet service. On > that service will run applications like MSN or AOL instant > messaging. Those services > will need to be able to make emergency chats. To route > properly, they need > location. That means that EVERY handset must deploy some > LCP, and must be able to get location suitable for emergency > call routing and dispatch per -phonebcp. The RV example is > yet another case of the same thing. The mistake is assuming > that all emergency calls will come through the E-CSCF. > They won't, and the 3GPP access network must conform to all > the -phonebcp requirements. > > Generally, I agree that SUPL is unsuitable for access > networks that don't use GPS or some form of measured location. > > Brian > > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 20, 2008 2:54 PM > To: Roger Marshall; Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > I cannot support requiring SUPL in DSL routers, desktop > computers (and related operating systems, SIP soft clients), > analog terminal adaptors, or other similar devices that are > intended for use in a wireline environment. I think that > organizations that can drive requirements for devices > intended to be use in an environment where SUPL would > actually work, should be responsible for having device > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > absolutely in a position to require SUPL support for devices > that operate in an environment where SUPL works. This is a > perfect example of the "closed" network that Brian describes > somewhere (framework, I think). > > Phonebcp is about requirements for devices in access > environments where the operators of the access environment > cannot be assumed to have any control over the type or nature > of devices that connect to or through it. Phonebcp needs to > continue to have that as its purpose. > > I agree that nothing in phonebcp should preclude the use of > SUPL, or be incompatible with the use of SUPL. And I don't > think it does. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, November 20, 2008 2:36 PM > To: Brian Rosen; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > If the choice is between preventing, allowing, or requiring > PhoneBCP suppport of SUPL, then my vote is to NOT prevent! I > would prefer 'require' since *most* of the location-aware 3G > compatible handsets/aircards over the next several years will > (I predict) have a SUPL stack included. In the same time > frame, many of those will also have WiFi support, others will > have LTE or WiMAX support as hybrids. > > SUPL will be common-place. OMA may not be 'Open-Source', it > is open-minded, and there is movement afoot to expand > OMA/SUPL (as we heard in the geopriv mtg. on Tuesday) > w/respect expected proposals such as LocSIP, etc. Over the > fairly near-term, I think there will be fewer protocol, > location representation, and privacy discontinuities - things > that too often get cited - yet are seldom well understood. > > Let's encourage continued IETF communication with OMA/SUPL - > not block its use altogether. This is a case where we need > to be inclusive, not exclusive. > > As to the mobile RV sample case, the solution is also > forseeable - especially given that the location of the 3G > aircard in the router is good enough for routing. The > scenario given needs some integration, but is doable. Given > that the aircard acts as a logical SET, with a SUPL stack on > board, and a GPS/AGPS chipset inside. This combination > *WILL* (I believe) interoperate with a number of end client > applications to initiate and complete a location-routed, 3261 > style SIP, emergency call through the core, and into an ESInet. > > -roger. > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Brian Rosen > > Sent: Thursday, November 20, 2008 8:23 AM > > To: 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > It's very hard to have L2 specific LCPs. The problem is that the > > clients are generally not very L2 aware. It's the clients > that have > > the problem. > > You can do things like interwork an L2 specific LCP to a > common LCP so > > that non L2 aware devices can work, but you have to do that, and > > usually, that's impractical. Use my example. Suppose that the L2 > > used SUPL. It's possible for the PC Card that is plugged into the > > router could implement a SUPL client and a HELD server and > interwork > > SUPL in the GSM system to HELD on the Ethernet so the Ethernet VoIP > > phone could get location via HELD. Possible, but not practical. > > There are all sorts of these kinds of problems. That's why > > L2 specific LCPs don't work. > > > > Brian > > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 20, 2008 11:11 AM > > To: Brian Rosen > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > The IETF can't (and shouldn't) try to make particular standards for > > every access technology that's out there. What we can say > is that the > > paradigm for those protocols should be the same as at the IP layer: > > Clients MUST implement all, networks MUST implement at least one. > > > > (This is a little different from the text I sent before, > and clearer, > > I > > think.) > > > > All I'm saying is that we shouldn't try to enumerate all > the possible > > protocols at lower layers, we should just state the general > rule. It > > seems to me that this achieves the same level of > interoperability at > > all layers. > > > > --Richard > > > > > If there are exactly two LCPs all UAs must implement, and > > any number > > > of optional ones, then every network has to implement at > > least one of > > > those > > two > > > LCPs, and any number of optional ones. That means that > > "any number of > > > optional ones" is useless for both parties. > > > If the network can limit UAs to ONLY those that implement > > one of the > > > optional protocols, then it works, but in practice, it is usually > > impossible > > > to do that. My example is the wired, Ethernet connected > > phone in an > > > RV traveling down the road with wireless data card in a > > router. These > > > EXIST, now. > > > > > > Brian > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, November 20, 2008 10:11 AM > > > To: Brian Rosen > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > I think we need to pull up a level. It's not reasonable > > for an RFC to > > > try to list all of the location protocols out there, if for > > no other > > > reason than that it will rapidly become obsolete. Instead, > > we should > > > say something like the following: > > > > > > " > > > INT-12 Devices MUST support the DHCP location options > [RFC4776] and > > > [RFC3825] and HELD > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > SHOULD support all location protocols supported at lower > layers by > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > " > > > > > > > > > > > > > > > Brian Rosen wrote: > > >> The problem with SUPL is that the majority of networks > where SUPL > > >> would > > be > > >> available have a proxy (E-CSCF) insert location. It also has an > > >> incompatible location representation, and an incompatible > > privacy model. > > >> That makes it very hard to interwork with any of the rest > > of the IETF > > > work. > > >> I will say this. For quite some time, the IETF has been > trying to > > > interest > > >> OMA into cooperation on location so that we have > > interoperability at > > >> the protocol, location representation and privacy > levels. So far, > > >> that has > > > not > > >> happened. If, as part of a comprehensive agreement to > accomplish > > >> such a goal, SUPL became one of the LCPs, I would not object. > > >> > > >> Brian > > >> > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >> Behalf Of Gabor.Bajko@nokia.com > > >> Sent: Thursday, November 20, 2008 9:26 AM > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > >> > > >> Hi, > > >> > > >> Is the intent to list the LCPs which are access-type > > agnostic but not > > >> supported anywhere, or instead have a list of LCPs which > > are highly > > >> probable to produce the intended result? > > >> > > >> There are restrictions everywhere, things come at a cost > > even in the > > >> general Internet model. The reality is that most of the > > devices with > > >> internet access have a home network already. > > >> > > >> - Gabor > > >> > > >> > > >> >-----Original Message----- > > >> >From: ext Winterbottom, James > > [mailto:James.Winterbottom@andrew.com] > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > >> > > > >> >Hi Gabor, > > >> > > > >> >The list of LCPs in the phone BCP is a must support > list, and is > > >> access- > > >> >type agnostic. > > >> >I am curious that you say that SUPL is a MUST support > > given that: > > >> >a) it requires a home network in order to operate > > >> >b) it simply doesn't work for DSL or Cable > > >> >c) it is questionable whether it is really deployable > for WiFi > > >> networks > > >> > > > >> >Can you perhaps describe how it fits into the general > > Internet model? > > >> > > > >> >Cheers > > >> >James > > >> > > > >> > > > >> >-----Original Message----- > > >> >From: ecrit-bounces@ietf.org on behalf of > Gabor.Bajko@nokia.com > > >> >Sent: Thu 11/20/2008 12:48 AM > > >> >To: ecrit@ietf.org > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > >> > > > >> >I was requested to send my observations regarding this > > requirement: > > >> > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > location options > > >> > [RFC4776] and [RFC3825], HELD > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > LLDP-MED [LLDP-MED]. > > >> > > > >> > > > >> >I believe we should come up with a list of LCPs which > > are likely > > >> to be > > >> >supported in devices in a not so distant future. Since > > I have no > > >> seen or > > >> >heard about LLDP support yet, at least that should be > replaced > > >> with what > > >> >is mostly used today (OMA SUPL) and the 802.11 > > mechanism, with the > > >> >condition that this MUST only be supported if there is a wifi > > >> interface > > >> >available on the device. > > >> > > > >> >- Gabor > > >> > > > >> > > > >> > > > >> >________________________________ > > >> > > > >> >From: ext Tschofenig, Hannes > > >> > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > >> >Subject: Location Protocols in Phone BCP > > >> > > > >> > > > >> > > > >> >Gabor, > > >> > > > >> >Could you please raise your question about location > > protocols in > > >> Phone > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > >> > > > >> >Ciao > > >> >Hannes > > >> > > > >> > > > >> > > >>> > > -------------------------------------------------------------------- > > >>> --- > > >> -- > > >> >----------------------- > > >> >This message is for the designated recipient only and may > > >> >contain privileged, proprietary, or otherwise private > > information. > > >> >If you have received it in error, please notify the sender > > >> >immediately and delete the original. Any unauthorized use of > > >> >this email is prohibited. > > >> > > >>> > > -------------------------------------------------------------------- > > >>> --- > > >> -- > > >> >----------------------- > > >> >[mf2] > > >> > > >> _______________________________________________ > > >> 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 > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may be privileged and/or confidential. If you are not > the intended recipient, or responsible for delivering this > message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication > or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender > immediately, and delete it and all attachments from your > computer and network. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact the > sender and delete the material from all computers. GA621 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:35:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7C93A6A47; Thu, 20 Nov 2008 12:35:14 -0800 (PST) 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 E7EFD28C1DF for ; Thu, 20 Nov 2008 12:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oXVyICSoigYO for ; Thu, 20 Nov 2008 12:35:12 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id F1BE73A6A37 for ; Thu, 20 Nov 2008 12:35:11 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3GEx-0007XQ-C8; Thu, 20 Nov 2008 14:35:03 -0600 From: "Brian Rosen" To: "'Ted Hardie'" , "'Stark, Barbara'" , "'Roger Marshall'" , "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b 1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80 $8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> In-Reply-To: Date: Thu, 20 Nov 2008 15:35:07 -0500 Message-ID: <020a01c94b4f$7c0769d0$74163d70$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLTNwo8VYpAMMJSLCYRg6ZTnuKZwAAcxug Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org ED-78 You are clearly correct on thread drift. Sorry. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Thursday, November 20, 2008 3:16 PM To: Brian Rosen; 'Stark, Barbara'; 'Roger Marshall'; 'Richard Barnes' Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; marc.linsner@cisco.com; ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP At 12:06 PM -0800 11/20/08, Brian Rosen wrote: >Gabor accuses us of ignoring reality. The 3GPP crowd has its own version of >that. > >All 3GPP networks I know of support a raw packet service. On that service >will run applications like MSN or AOL instant messaging. Those services >will need to be able to make emergency chats. Sorry, can you point me to the current text in PhoneBCP or Framework where we describe the emergency chats? Grep didn't find it for me, and I must have missed the fun on defining that. In general, it might be best not to change the subject, if we are to actually conclude this conversation. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:46:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972CA3A6906; Thu, 20 Nov 2008 12:46:37 -0800 (PST) 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 C54893A6984 for ; Thu, 20 Nov 2008 12:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqJMhbm0qvGj for ; Thu, 20 Nov 2008 12:46:34 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E40D63A6906 for ; Thu, 20 Nov 2008 12:46:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="198569617" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2008 20:46:33 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKkWDo011860; Thu, 20 Nov 2008 12:46:32 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKkQ2B021875; Thu, 20 Nov 2008 20:46:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:46:32 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.30]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:46:31 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 14:46:30 -0600 To: "Roger Marshall" , "Brian Rosen" , "Janet P Gunn" From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533686@SEA-EXCHVS-2.tele comsys.com> References: <015301c94b2b$60155ee0$20401ca0$@net> <017a01c94b31$8bfa57d0$a3ef0770$@net> <8C837214C95C864C9F34F3635C2A65750B533686@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 20:46:31.0805 (UTC) FILETIME=[11B182D0:01C94B51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17350; t=1227213992; x=1228077992; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-00 |Sender:=20; bh=Ks1BjZwfxyunA33Fywvy2Ph+3pqYDBQxj8Tjx7sPp1g=; b=M95VYkegBnlJDnn+IotlbbvKDQX9kRHqiL9M2FNPjmccHo+011R5zBumg8 2+YR6Pg/Ck3aCZbhVfhJw1dWHkzJOVnz/OV0ro6lWptlxdm2eDGxOHc8MlR7 huJWygmVcZ; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:24 AM 11/20/2008, Roger Marshall wrote: >It seems like we're diverging here. In the ESInet, it seems to me, that >the owner/manager of that ESInet will set the priority treatment as they >deem fit. Only in the public network arena will real prioritization >have a chance to be "standardized". So far what do people say is the >ordering? Just to be clear, this discussion is NOT something my namespace ID should ever address. I have no issues with having this discussion - but I want to make clear that draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make priority decisions or even recommendations in the text of the doc. This ID only creates the namespace *and* the probably scenario in which it is intended. >Public net: >P1. ets/wps? (PSAPs may not be so eager to agree) >P2. esnet >P3. it's not as simple as that. each gets its own slot in any relative priority order (per section 8 of RFC4412). With this in mind, it is *possible* to have a relative priority order like this P1. ets.4 P2. esnet.4 P3. ets.3 wps.4 P4. esnet.3 esnet.2 P5. wps.3 ets.2 P6. wps.2 ets.1 P7. esnet.1 P8. esnet.0 P9. ets.0 wps.0 notice that within each , the numbering order is consistent, but that the order relative to the different namespaces is whatever the local operator wants to make them. I do show here that at each priority level (e.g., P3, P4, P5, P6 and P9) that there are more than one namespace.priority-value combination. This means, within this priority - it's a FIFO situation in which each of the namespace.priority-value combinations at this priority level compete (i.e., they are equivalent in priority). This is all a local decision. I think a way to address Brian's comment about preemption is also a local decision (because the local jurisdiction needs to live with the consequences). Here's how that can be addressed: - all these namespace.priority-value combinations *can* be preempted - only certain namespace.priority-value combinations *can* preempt another call. just a thought about how to solve this... James >Private net (ESInet): >(anything they want) > >Lastly, what kind of prioritization does a government official (a >servant of the people) get when they themselves initiate an emergency >call? esnet or ets/wps? (In a private ESInet, it may be to their >disadvantage to keep the wrong one.) > >-roger marshall. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Brian Rosen > > Sent: Thursday, November 20, 2008 9:01 AM > > To: 'Janet P Gunn' > > Cc: Ecrit@ietf.org > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > An "Emergency Services IP Network" is a private IP network to > > which, we hope, all public safety agencies are connected. It > > handles all the traffic of a public safety agency, which > > would include routine and priority citizen to authority, > > authority to authority and authority to citizen traffic. > > It's not entirely clear to me yet whether we can reuse a > > number of the existing name spaces as well as a new one. For > > example, some of the agency-agency traffic will require > > pre-emption, but the existing MLPP namespace may be quite sufficient. > > > > It does occur to me that we could have ETS and possibly WPS > > traffic, in that if the normal access to public facilities > > traversed the ESInet towards some kind of gateway to a public > > network, then we would either have to have the ETS/WPS > > values, or remark them at the edge if a caller inside the > > ESInet needed to call someone outside the ESInet and needed > > ETS/WPS priority to do so. If we carried the priority > > marking across the ESInet, ETS/WPS would be lower priority > > than some other traffic, but higher than, for example, > > citizen to authority emergency calls. > > > > Brian > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > Sent: Thursday, November 20, 2008 11:37 AM > > To: Brian Rosen > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > Brian, > > > > I need to understand this better. > > > > Exactly what are the constraints of the "emergency services > > IP network"? Is this a network in which EVERY call would > > have the RPH with the esnet namespace (just varying priority > > values),and there would be no "normal" calls? Or would their > > be a mixture of calls with and without RPH wit esnet? > > > > Janet > > > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > > > A suggestion was made to me that we should define two namespaces. > > > > > > One would be used in public networks, and generally would > > be used to request > > > resource priority for citizen to authority and possibly > > authority to citizen > > > calls. This would have lower priority than ETS/WPS. > > > > > > The other would be for use within emergency services IP > > networks. It would > > > be unlikely that ETS/WPS would be used within those > > networks, but if it was, > > > some values within the namespace would need higher priority > > that ETS/WPS. > > > For example, a message which was an incident commanders > > "evacuate" message > > > would be higher than a ETS/WPS traffic. On the other hand, > > a citizen to > > > authority emergency call would have lower priority. > > > > > > I would be happier with one namespace and more values in > > that namespace for > > > all of this, but I was advised that two namespaces was a > > better choice. > > > > > > Brian > > > > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > Janet P Gunn > > > Sent: Thursday, November 20, 2008 11:00 AM > > > To: GOLDMAN, STUART O (STUART) > > > Cc: Ecrit@ietf.org > > > Subject: Re: [Ecrit] Ecrit] > > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > Stu, > > > > > > I intended to say that the esnet namespace needs to be at a > > LOWER priority > > > than the ets and wps namespaces, in any network that > > recognizes ets and wps > > > as described in 10.5 and 10.6 of RFC4412. > > > > > > Janet > > > > > > "GOLDMAN, STUART O \(STUART\)" > > wrote on > > > 11/20/2008 10:22:49 AM: > > > > > > > Janet, > > > > > > > > With regard to you e-mail below, did you intend that > > esnet could be > > > > at the same level of priority as ETS & WPS, or that ETS > > & WPS need > > > > to be at an even higher priority than esnet? > > > > > > > > > > > > > > > > Stuart Goldman > > > > Alcatel-Lucent > > > > Stuart.Goldman@alcatel-lucent.com > > > > +1 602 493 8438 > > > > +1 480 414 1260 mobile > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > > Sent by: ecrit-bounces@ietf.org > > > > 10/27/2008 11:45 PM > > > > > > > > > > > > > > > > To > > > > > > > > "James M. Polk" > > > > > > > > cc > > > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > > > Subject > > > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > > to, as these > > > > comments apply to earlier versions as well. > > > > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > > "This document IANA registers the "esnet" > > > > RPH namespace for use within emergency services > > networks, not just > > > > of those from citizens to PSAPs." (no clear antecedent > > for "those") > > > > > > > > Perhaps > > > > "This document IANA registers the "esnet" > > > > RPH namespace for use within emergency services > > networks, not just > > > > for calls or sessions > > > > from citizens to PSAPs." > > > > > > > > Section 2 says > > > > "This document updates the behaviors of the SIP Resource Priority > > > > header, defined in [RFC4412], during the treatment options > > > > surrounding this new "esnet" namespace only. The usage of the > > > > "esnet" namespace does not have a normal, or routine > > call level. > > > > Every use of this namespace will be in times of an > > emergency, where > > > > at least one end of the signaling is with a local emergency > > > > organization." > > > > > > > > I don't see this as an "update of the behavior of 4412". Neither > > > > the ets namespace not the wps > > > > namespace have a "normal" or "routine" call level. Every > > use of the > > > > wps and ets namespaces will > > > > have priority over calls without RPH. > > > > > > > > You say "This > > > > namespace, therefore, MAY be overwritten or deleted, > > contrary to the > > > > rules of RFC 4412 [RFC4412]." > > > > > > > > It is not clear to me why this is "contrary to the rules > > of 4412". > > > > It is certainly anticipated > > > > that other RPH will be overwritten or deleted, when the UAS > > > > understands the namespace. > > > > > > > > 4412 says "Existing implementations of RFC 3261 that do > > not participate in > > > the > > > > resource priority mechanism follow the normal rules of RFC 3261, > > > > Section 8.2.2: "If a UAS does not understand a header field in a > > > > request (that is, the header field is not defined in this > > > > specification or in any supported extension), the server > > MUST ignore > > > > that header field and continue processing the message". " > > > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > > understand the namespace is > > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > > > that "the UAC > > > > MAY attempt a subsequent request with the same or > > different resource > > > > value." This certainly implies the ability to overwrite > > or delete > > > > an RPH namespace. > > > > > > > > (See also, for instance the PTSC SAC document on the use > > of the ets > > > > and wps namespaces) > > > > > > > > Immediately following these statements, you give 3 options- > > > > "These proxies in the service provider > > > > MAY either > > > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > > present, and grant relative preferential treatment to > > the request > > > > when forwarding it to the ESINet. > > > > > > > > o replace any existing RPH value, if one is present, > > and insert an > > > > "esnet" namespace and give relative preferential > > treatment to the > > > > request when forwarding it to the ESINet. > > > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > > preferential treatment to the request when forwarding the SIP > > > > request towards the ESINet." > > > > > > > > Why do you exclude the possibility of adding the esnet RPH value > > > > without "replacing" an existing RPH value? > > > > > > > > Finally, there is another point that needs to be made clear. At > > > > least one person has contacted me expressing concern that this ID > > > > implied that the esnet namespace would have priority over other > > > > namespaces (in particular wps and ets). I assured him > > that this was > > > > not the case, that there was nothing prevent the expected > > behavior - > > > > that the ets and wps namespaces would be prioritized > > ahead of esnet > > > > in GETS Service Provider networks. > > > > > > > > However, since the question has already arisen, it would > > be a good > > > > idea to clarify this, perhaps in section 3, where you > > discuss the > > > > other namespaces. In particular, it needs to be made clear in > > > > section 3.2 that, even if "the local jurisdiction > > preferred to > > > > preempt normal calls in lieu of > > > > completing emergency calls. ", esnet calls will NOT > > preempt wps or ets > > > calls. > > > > > > > > By the way, I think you mean "the local jurisdiction > > preferred to > > > > preempt normal calls in order to complete emergency > > calls. " - not > > > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > > > In fact, it is not clear to me that 4412 permits a call > > with an RPH > > > > (e.g., esnet) to preempt a "normal" call (with no RPH > > namespace). > > > > Section 4.7.2.1 of 4412 says > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > > > A UAS compliant with this specification MUST terminate a session > > > > established with a valid namespace and lower-priority > > value in favor > > > > of a new session set up with a valid namespace and > > higher relative > > > > priority value, unless local policy has some form of > > call-waiting > > > > capability enabled. " > > > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > > > Thanks > > > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > > > please delete without copying and kindly advise us by > > e-mail of the > > > > mistake in delivery. > > > > NOTE: Regardless of content, this e-mail shall not > > operate to bind > > > > CSC to any order or other contract unless pursuant to explicit > > > > written agreement or government initiative expressly > > permitting the > > > > use of e-mail for such purpose. > > > > > > > > "James M. Polk" > > > > Sent by: ecrit-bounces@ietf.org > > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > > > > > > To > > > > > > > > "'ECRIT'" > > > > > > > > cc > > > > > > > > > > > > > > > > Subject > > > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > > > Here is a update to a ID I think is pretty near done, > > given that this > > > > is merely an IANA registration ID of an existing mechanism. > > > > > > > > Comments are wanted > > > > > > > > >A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > >directories. > > > > >This draft is a work item of the Emergency Context > > Resolution with > > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > > > > Title : IANA Registering a SIP > > Resource Priority > > > > > Header Namespace for Local Emergency Communications > > > > > Author(s) : J. Polk > > > > > Filename : > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > > Pages : 9 > > > > > Date : 2008-10-27 > > > > > > > > > >This document creates and IANA registers the new Session > > Initiation > > > > >Protocol (SIP) Resource Priority header (RPH) namespace > > "esnet" for > > > > >local emergency usage to a public safety answering point (PSAP), > > > > >between PSAPs, and between a PSAP and first responders and their > > > > >organizations. > > > > > > > > > >A URL for this Internet-Draft is: > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > Stuart Goldman > > > > Alcatel-Lucent > > > > Stuart.Goldman@alcatel-lucent.com > > > > +1 602 493 8438 > > > > +1 480 414 1260 mobile > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > >CONFIDENTIALITY NOTICE: The information contained in this message >may be privileged and/or confidential. If you are not the intended >recipient, or responsible for delivering this message to the >intended recipient, any review, forwarding, dissemination, >distribution or copying of this communication or any attachment(s) >is strictly prohibited. If you have received this message in error, >please notify the sender immediately, and delete it and all >attachments from your computer and network. >_______________________________________________ >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 ecrit-bounces@ietf.org Thu Nov 20 12:49:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8583E3A6A47; Thu, 20 Nov 2008 12:49:10 -0800 (PST) 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 9C6733A6984 for ; Thu, 20 Nov 2008 12:49:09 -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 D8wIK1OfgQjX for ; Thu, 20 Nov 2008 12:49:08 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A164F3A6A46 for ; Thu, 20 Nov 2008 12:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1227214147; x=1258750147; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<020a01c94b4f$7c0769d0$7 4163d70$@net>|References:=20=0D=0A=20<7A1F5E234FF 3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com>=0D=0A =20=0D=0A=20<7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@es ebe111.NOE.Nokia.com><00ff01c94b=0D=0A=201d$a5d11e50$f173 5af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a8 0=0D=0A=20$8a869f80$@net>=09<49258C15.2070303@bbn.com>=0D =0A=20<015401c94b2c$374c6ed0$a5e54c70$@net>=0D=0A=20<8C83 7214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecom sys.com>=0D=0A=20<7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F 6@crexc41p>=0D=0A=20<01e701c94b4b$813eb290$83bc17b0$@net> =0D=0A=20=0D=0A=20 <020a01c94b4f$7c0769d0$74163d70$@net>|Date:=20Thu,=2020 =20Nov=202008=2014:49:03=20-0600|To:=20 |From:=20Ted=20Hardie=20|Subject:=20 Removing/revising=20ED-78|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5100,188,5440"=3B=20a=3D"13317301"; bh=2Z9zZcxzNOALp0VbfhuNliyUZj+rvakwNe69grvzIzI=; b=y3uCVCxStcdLNO/STLPFZKacakBgLgxnEWKye8BjXiD8Ay1uEfOs11wM yhKl7I/CmxTZtzcEeSx3fPYSRUB0wop/OaHfjPAFszBwv/GX0yDK8fQLK BiyQRXFxeA2ObzBpmHWzPCx0CjzeQZ/CgVlSOT9QY1EvOZQMrwHh/sj9n w=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13317301" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 12:49:07 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKn7hL008511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Nov 2008 12:49:07 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKKn6qn028988 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Nov 2008 12:49:07 -0800 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:49:06 -0800 Received: from [130.129.30.23] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 20 Nov 2008 12:49:06 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <020a01c94b4f$7c0769d0$74163d70$@net> References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b 1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80 $8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <020a01c94b4f$7c0769d0$74163d70$@net> Date: Thu, 20 Nov 2008 14:49:03 -0600 To: From: Ted Hardie Subject: [Ecrit] Removing/revising ED-78 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In another thread, Brian pointed out the existence of ED-78. His initial statement was: >All 3GPP networks I know of support a raw packet service. On that service >>will run applications like MSN or AOL instant messaging. Those services >>will need to be able to make emergency chats. ED-78 actually says: ED-78 Endpoints supporting Instant Messaging (IM) MUST support both [RFC3428] and [RFC4975]. RFC 3428 is "Session Initiation Protocol (SIP) Extension for Instant Messaging" and RFC 4975 is The Message Session Relay Protocol (MSRP). These two are in conflict. The first proposes that the instant messaging services which are common and commercially deployed need to be supported, need to have access to location, etc. The second requires the SIP/SIMPLE and MSRP be supported if any IM service is. I do not think that any of this is currently best current practice, and I think attempting to mandate SIP/SIMPLE & MSRP for anyone wishing to support any IM is not practical. IM can often be added by third party applications, and I see no practical way to ensure that they are compelled by this. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 12:58:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957FA3A6A37; Thu, 20 Nov 2008 12:58:13 -0800 (PST) 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 CB51C3A6A09 for ; Thu, 20 Nov 2008 12:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhStr8ef-3oA for ; Thu, 20 Nov 2008 12:58:10 -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 C0EEE3A67F0 for ; Thu, 20 Nov 2008 12:58:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28517505" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 20:58:08 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKKw8XF008242; Thu, 20 Nov 2008 15:58:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKKw88b018122; Thu, 20 Nov 2008 20:58:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:58:07 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.238.30]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 15:58:07 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 14:58:06 -0600 To: Richard Barnes , Brian Rosen From: "James M. Polk" In-Reply-To: <4925C215.4070207@bbn.com> References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <01df01c94b49$7573d0f0$605b72d0$@net> <4925C215.4070207@bbn.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 20:58:07.0399 (UTC) FILETIME=[B04CBB70:01C94B52] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14407; t=1227214688; x=1228078688; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20Protocols=20in=20P hone=20BCP |Sender:=20 |To:=20Richard=20Barnes=20,=20Brian=20Rose n=20; bh=KWjgARUj2Oh25xmx/aroueKPmzrSUcv9mtVOvTyZSYI=; b=gKmzQxxl/RtOVVeNsgB8MB+oHwDbxVBXtiXvvKLKBmiClmUobGW1pwhIq9 3rs9XBFDaI1e27s7XxPx6WVuWoyvF+USmP8kInpuGa0EqGOM4Q28iHf1dMOS /TCGjgJn3X; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:01 PM 11/20/2008, Richard Barnes wrote: >The problem is the scope of "all". I don't think it makes sense for >an IETF document to try to enumerate all the Layer-2 ways that >people access the Internet and their associated location protocols, >but it *can* make a recommendation for how things work at those >layers (namely, it can recommend that layer-2 entities follow the >same "endpoint-all/network-one" principle -- "EAN1"?). > >Note: I'm grouping SUPL in with the "layer 2" mechanisms because it >has dependencies on assumptions about the physical host (e.g., GPS >in most cases), and about the structure of the network. > >The real distinction, I guess, is between protocols that work >everywhere in the Internet (DHCP, HELD) and protocols that only work >in specific environments, like SUPL or LLDP. The EAN1 principle >applies to both of these classes, but is only an unconditional MUST >for the Internet-wide ones, because it's not meaningful to mandate >universal support for non-universal protocols. There could still be >a *conditional* MUST, conditioned on the client and its network >connectivity meeting the requirements of the constrained protocols. MUSTs in IETF-speak is not conditional, ever. SHOULDs are conditional based on a "really good reason for an implementer to not implement something. >--Richard > > > > >Brian Rosen wrote: >>I'm not interested in preventing SUPL. The drafts allow others. The >>problem is, and remains interoperability. The basic LCP "rule" is >>"endpoints implement all, access networks implement one". That rule >>provides interoperability. There is nothing you can do with SUPL that is >>interoperable unless it goes on the list. If you implement SUPL, then the >>network and the endpoints ALSO need to implement another protocol from the >>list, or we don't have interoperability. It's possible for the network to >>implement SUPL and some endpoints implement SUPL and those endpoints will >>work. Others won't, and that is very bad. >>There is no short cut. Either SUPL goes on the list, or the network has to >>implement one of the LCPs on the list. >>Given the current level of non-interoperability of SUPL with the rest of the >>LCPs, I oppose adding SUPL to the list at this time. >>I don't understand your comments on the RV case. The card can implement a >>SUPL client. Unless it implements a DHCP or HELD server and interworks the >>SUPL location to the HELD/DHCP protocols, we have a problem. And of course, >>we can't reasonably get the privacy right doing that, and in some cases we >>can't interwork the location representation. >>Brian >>-----Original Message----- >>From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: >>Thursday, November 20, 2008 2:36 PM >>To: Brian Rosen; Richard Barnes >>Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >>marc.linsner@cisco.com; ecrit@ietf.org >>Subject: RE: [Ecrit] Location Protocols in Phone BCP >> If the choice is between preventing, allowing, or requiring PhoneBCP >>suppport of SUPL, then my vote is to NOT prevent! I would prefer >>'require' since *most* of the location-aware 3G compatible >>handsets/aircards over the next several years will (I predict) have a >>SUPL stack included. In the same time frame, many of those will also >>have WiFi support, others will have LTE or WiMAX support as hybrids. >>SUPL will be common-place. OMA may not be 'Open-Source', it is >>open-minded, and there is movement afoot to expand OMA/SUPL (as we heard >>in the geopriv mtg. on Tuesday) w/respect expected proposals such as >>LocSIP, etc. Over the fairly near-term, I think there will be fewer >>protocol, location representation, and privacy discontinuities - things >>that too often get cited - yet are seldom well understood. >>Let's encourage continued IETF communication with OMA/SUPL - not block >>its use altogether. This is a case where we need to be inclusive, not >>exclusive. >>As to the mobile RV sample case, the solution is also forseeable - >>especially given that the location of the 3G aircard in the router is >>good enough for routing. The scenario given needs some integration, but >>is doable. Given that the aircard acts as a logical SET, with a SUPL >>stack on board, and a GPS/AGPS chipset inside. This combination *WILL* >>(I believe) interoperate with a number of end client applications to >>initiate and complete a location-routed, 3261 style SIP, emergency call >>through the core, and into an ESInet. >>-roger. >> >>>-----Original Message----- >>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>Behalf Of Brian Rosen >>>Sent: Thursday, November 20, 2008 8:23 AM >>>To: 'Richard Barnes' >>>Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >>>marc.linsner@cisco.com; ecrit@ietf.org >>>Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>>It's very hard to have L2 specific LCPs. The problem is that the >>>clients are generally not very L2 aware. It's the clients that >>>have the problem. >>>You can do things like interwork an L2 specific LCP to a common >>>LCP so that non L2 aware devices can work, but you have to do >>>that, and usually, that's impractical. Use my example. Suppose >>>that the L2 used SUPL. It's possible for the PC Card that is >>>plugged into the router could implement a SUPL client and a HELD >>>server and interwork SUPL in the GSM system to HELD on the >>>Ethernet so the Ethernet VoIP phone could get location via >>>HELD. Possible, but not practical. >>>There are all sorts of these kinds of problems. That's why L2 >>>specific LCPs don't work. >>> >>>Brian >>> >>>-----Original Message----- >>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>Sent: Thursday, November 20, 2008 11:11 AM >>>To: Brian Rosen >>>Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>>ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>Subject: Re: [Ecrit] Location Protocols in Phone BCP >>> >>>The IETF can't (and shouldn't) try to make particular standards >>>for every access technology that's out there. What we can say is >>>that the paradigm for those protocols should be the same as at the >>>IP layer: Clients MUST implement all, networks MUST implement at least one. >>> >>>(This is a little different from the text I sent before, and clearer, I >>>think.) >>> >>>All I'm saying is that we shouldn't try to enumerate all the >>>possible protocols at lower layers, we should just state the >>>general rule. It seems to me that this achieves the same level of >>>interoperability at all layers. >>> >>>--Richard >>> >>>>If there are exactly two LCPs all UAs must implement, and >>>any number >>>>of optional ones, then every network has to implement at >>>least one of >>>>those >>>two >>>>LCPs, and any number of optional ones. That means that >>>"any number of >>>>optional ones" is useless for both parties. >>>>If the network can limit UAs to ONLY those that implement >>>one of the >>>>optional protocols, then it works, but in practice, it is usually >>>impossible >>>>to do that. My example is the wired, Ethernet connected >>>phone in an >>>>RV traveling down the road with wireless data card in a >>>router. These >>>>EXIST, now. >>>> >>>>Brian >>>>-----Original Message----- >>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>Sent: Thursday, November 20, 2008 10:11 AM >>>>To: Brian Rosen >>>>Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>>>ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>>Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> >>>>I think we need to pull up a level. It's not reasonable >>>for an RFC to >>>>try to list all of the location protocols out there, if for >>>no other >>>>reason than that it will rapidly become obsolete. Instead, >>>we should >>>>say something like the following: >>>> >>>>" >>>>INT-12 Devices MUST support the DHCP location options [RFC4776] >>>>and [RFC3825] and HELD >>>[I-D.ietf-geopriv-http-location-delivery]. Devices >>>>SHOULD support all location protocols supported at lower layers >>>>by their interfaces (e.g., LLDP-MED [LLDP-MED]). >>>>" >>>> >>>> >>>> >>>> >>>>Brian Rosen wrote: >>>>>The problem with SUPL is that the majority of networks where SUPL would >>>be >>>>>available have a proxy (E-CSCF) insert location. It also has an >>>>>incompatible location representation, and an incompatible >>>privacy model. >>>>>That makes it very hard to interwork with any of the rest >>>of the IETF >>>>work. >>>>>I will say this. For quite some time, the IETF has been trying to >>>>interest >>>>>OMA into cooperation on location so that we have >>>interoperability at >>>>>the protocol, location representation and privacy levels. So >>>>>far, that has >>>>not >>>>>happened. If, as part of a comprehensive agreement to >>>>>accomplish such a goal, SUPL became one of the LCPs, I would not object. >>>>> >>>>>Brian >>>>> >>>>>-----Original Message----- >>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>Behalf Of Gabor.Bajko@nokia.com >>>>>Sent: Thursday, November 20, 2008 9:26 AM >>>>>To: James.Winterbottom@andrew.com; ecrit@ietf.org >>>>>Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>>>>Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>> >>>>>Hi, >>>>> >>>>>Is the intent to list the LCPs which are access-type >>>agnostic but not >>>>>supported anywhere, or instead have a list of LCPs which >>>are highly >>>>>probable to produce the intended result? >>>>> >>>>>There are restrictions everywhere, things come at a cost >>>even in the >>>>>general Internet model. The reality is that most of the >>>devices with >>>>>internet access have a home network already. >>>>> >>>>>- Gabor >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: ext Winterbottom, James >>>[mailto:James.Winterbottom@andrew.com] >>>>> >Sent: Thursday, November 20, 2008 12:06 AM >>>>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>>>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN - FI/Espoo) >>>>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>>> > >>>>> >Hi Gabor, >>>>> > >>>>> >The list of LCPs in the phone BCP is a must support list, and is >>>>>access- >>>>> >type agnostic. >>>>> >I am curious that you say that SUPL is a MUST support >>>given that: >>>>> >a) it requires a home network in order to operate >>>>> >b) it simply doesn't work for DSL or Cable >>>>> >c) it is questionable whether it is really deployable for >>>>> WiFi networks >>>>> > >>>>> >Can you perhaps describe how it fits into the general >>>Internet model? >>>>> > >>>>> >Cheers >>>>> >James >>>>> > >>>>> > >>>>> >-----Original Message----- >>>>> >From: ecrit-bounces@ietf.org on behalf of Gabor.Bajko@nokia.com >>>>> >Sent: Thu 11/20/2008 12:48 AM >>>>> >To: ecrit@ietf.org >>>>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>> > >>>>> >I was requested to send my observations regarding this >>>requirement: >>>>> > >>>>> > ED-21/INT-12 Devices MUST support all of: DHCP >>>location options >>>>> > [RFC4776] and [RFC3825], HELD >>>>> > [I-D.ietf-geopriv-http-location-delivery] and >>>LLDP-MED [LLDP-MED]. >>>>> > >>>>> > >>>>> >I believe we should come up with a list of LCPs which >>>are likely >>>>>to be >>>>> >supported in devices in a not so distant future. Since >>>I have no >>>>>seen or >>>>> >heard about LLDP support yet, at least that should be >>>>> replaced with what >>>>> >is mostly used today (OMA SUPL) and the 802.11 >>>mechanism, with the >>>>> >condition that this MUST only be supported if there is a >>>>> wifi interface >>>>> >available on the device. >>>>> > >>>>> >- Gabor >>>>> > >>>>> > >>>>> > >>>>> >________________________________ >>>>> > >>>>> >From: ext Tschofenig, Hannes >>>>> > >>>>> >Sent: Tuesday, November 18, 2008 12:49 PM >>>>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>>>> >Subject: Location Protocols in Phone BCP >>>>> > >>>>> > >>>>> > >>>>> >Gabor, >>>>> > >>>>> >Could you please raise your question about location >>>protocols in >>>>>Phone >>>>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>>>> > >>>>> >Ciao >>>>> >Hannes >>>>> > >>>>> > >>>>> >>>-------------------------------------------------------------------- >>>>>>--- >>>>>-- >>>>> >----------------------- >>>>> >This message is for the designated recipient only and may >>>>> >contain privileged, proprietary, or otherwise private >>>information. >>>>> >If you have received it in error, please notify the sender >>>>> >immediately and delete the original. Any unauthorized use of >>>>> >this email is prohibited. >>>>> >>>-------------------------------------------------------------------- >>>>>>--- >>>>>-- >>>>> >----------------------- >>>>> >[mf2] >>>>> >>>>>_______________________________________________ >>>>>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 >>CONFIDENTIALITY NOTICE: The information contained in this message may be >>privileged and/or confidential. If you are not the intended recipient, or >>responsible for delivering this message to the intended recipient, any >>review, forwarding, dissemination, distribution or copying of this >>communication or any attachment(s) is strictly prohibited. If you have >>received this message in error, please notify the sender immediately, and >>delete it and all attachments from your computer and network. >_______________________________________________ >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 ecrit-bounces@ietf.org Thu Nov 20 13:04:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2CD3A67F0; Thu, 20 Nov 2008 13:04:11 -0800 (PST) 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 4533C3A67F0 for ; Thu, 20 Nov 2008 13:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOODZ0jsub7A for ; Thu, 20 Nov 2008 13:04:07 -0800 (PST) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id 0F5DE3A677D for ; Thu, 20 Nov 2008 13:04:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-64.messagelabs.com!1227215041!89803064!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 10996 invoked from network); 20 Nov 2008 21:04:02 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-5.tower-64.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 21:04:02 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAKL41qq026520 for ; Thu, 20 Nov 2008 16:04:01 -0500 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 20 Nov 2008 16:03:55 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/20/2008 04:06:31 PM, Serialize complete at 11/20/2008 04:06:31 PM Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============0491196783==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0491196783== Content-Type: multipart/alternative; boundary="=_alternative 0073B7B085257507_=" This is a multipart message in MIME format. --=_alternative 0073B7B085257507_= Content-Type: text/plain; charset="US-ASCII" "James M. Polk" wrote on 11/20/2008 03:46:30 PM: > > Just to be clear, this discussion is NOT something my namespace ID > should ever address. I have no issues with having this discussion - > but I want to make clear that > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make > priority decisions or even recommendations in the text of the doc. > > This ID only creates the namespace *and* the probably scenario in > which it is intended. > Agree > > >Public net: > >P1. ets/wps? (PSAPs may not be so eager to agree) > >P2. esnet > >P3. > > it's not as simple as that. > > each gets its own slot in any relative > priority order (per section 8 of RFC4412). > > With this in mind, it is *possible* to have a relative priority > order like this > > P1. ets.4 > P2. esnet.4 > P3. ets.3 wps.4 > P4. esnet.3 esnet.2 > P5. wps.3 ets.2 > P6. wps.2 ets.1 > P7. esnet.1 > P8. esnet.0 > P9. ets.0 wps.0 > > notice that within each , the numbering order is > consistent, but that the order relative to the different namespaces > is whatever the local operator wants to make them. At the risk of being a nitnoid, this would NOT be an RFC4412-legal ordering,as it reverses the priority values of ets and wps (0 is the highest). I do show here > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there > are more than one namespace.priority-value combination. This means, > within this priority - it's a FIFO situation in which each of the > namespace.priority-value combinations at this priority level compete > (i.e., they are equivalent in priority). This is all a local decision. > > I think a way to address Brian's comment about preemption is also a > local decision (because the local jurisdiction needs to live with the > consequences). Here's how that can be addressed: > > - all these namespace.priority-value combinations *can* be preempted I have serious heartburn with this statement. In the circuit switched paradigm of preemption (MLPP and eMLPP), only calls that are identified a-priori as "part of a preemption domain (or similar term)" can be preempted. "Normal" (unmarked, as opposed to marked "routine") calls cannot be preempted. I REALLY don't think we should break that aspect of the paradigm without investigating "unintended consequences" in great detail. > - only certain namespace.priority-value combinations *can* preempt > another call. > > just a thought about how to solve this... > > James > > > >Private net (ESInet): > >(anything they want) > > > >Lastly, what kind of prioritization does a government official (a > >servant of the people) get when they themselves initiate an emergency > >call? esnet or ets/wps? (In a private ESInet, it may be to their > >disadvantage to keep the wrong one.) > > > >-roger marshall. > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf Of Brian Rosen > > > Sent: Thursday, November 20, 2008 9:01 AM > > > To: 'Janet P Gunn' > > > Cc: Ecrit@ietf.org > > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > An "Emergency Services IP Network" is a private IP network to > > > which, we hope, all public safety agencies are connected. It > > > handles all the traffic of a public safety agency, which > > > would include routine and priority citizen to authority, > > > authority to authority and authority to citizen traffic. > > > It's not entirely clear to me yet whether we can reuse a > > > number of the existing name spaces as well as a new one. For > > > example, some of the agency-agency traffic will require > > > pre-emption, but the existing MLPP namespace may be quite sufficient. > > > > > > It does occur to me that we could have ETS and possibly WPS > > > traffic, in that if the normal access to public facilities > > > traversed the ESInet towards some kind of gateway to a public > > > network, then we would either have to have the ETS/WPS > > > values, or remark them at the edge if a caller inside the > > > ESInet needed to call someone outside the ESInet and needed > > > ETS/WPS priority to do so. If we carried the priority > > > marking across the ESInet, ETS/WPS would be lower priority > > > than some other traffic, but higher than, for example, > > > citizen to authority emergency calls. > > > > > > Brian > > > > > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > Sent: Thursday, November 20, 2008 11:37 AM > > > To: Brian Rosen > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > Brian, > > > > > > I need to understand this better. > > > > > > Exactly what are the constraints of the "emergency services > > > IP network"? Is this a network in which EVERY call would > > > have the RPH with the esnet namespace (just varying priority > > > values),and there would be no "normal" calls? Or would their > > > be a mixture of calls with and without RPH wit esnet? > > > > > > Janet > > > > > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > > > > > A suggestion was made to me that we should define two namespaces. > > > > > > > > One would be used in public networks, and generally would > > > be used to request > > > > resource priority for citizen to authority and possibly > > > authority to citizen > > > > calls. This would have lower priority than ETS/WPS. > > > > > > > > The other would be for use within emergency services IP > > > networks. It would > > > > be unlikely that ETS/WPS would be used within those > > > networks, but if it was, > > > > some values within the namespace would need higher priority > > > that ETS/WPS. > > > > For example, a message which was an incident commanders > > > "evacuate" message > > > > would be higher than a ETS/WPS traffic. On the other hand, > > > a citizen to > > > > authority emergency call would have lower priority. > > > > > > > > I would be happier with one namespace and more values in > > > that namespace for > > > > all of this, but I was advised that two namespaces was a > > > better choice. > > > > > > > > Brian > > > > > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > Janet P Gunn > > > > Sent: Thursday, November 20, 2008 11:00 AM > > > > To: GOLDMAN, STUART O (STUART) > > > > Cc: Ecrit@ietf.org > > > > Subject: Re: [Ecrit] Ecrit] > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > Stu, > > > > > > > > I intended to say that the esnet namespace needs to be at a > > > LOWER priority > > > > than the ets and wps namespaces, in any network that > > > recognizes ets and wps > > > > as described in 10.5 and 10.6 of RFC4412. > > > > > > > > Janet > > > > > > > > "GOLDMAN, STUART O \(STUART\)" > > > wrote on > > > > 11/20/2008 10:22:49 AM: > > > > > > > > > Janet, > > > > > > > > > > With regard to you e-mail below, did you intend that > > > esnet could be > > > > > at the same level of priority as ETS & WPS, or that ETS > > > & WPS need > > > > > to be at an even higher priority than esnet? > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > Alcatel-Lucent > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > +1 602 493 8438 > > > > > +1 480 414 1260 mobile > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > > > Sent by: ecrit-bounces@ietf.org > > > > > 10/27/2008 11:45 PM > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > "James M. Polk" > > > > > > > > > > cc > > > > > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > > > > > Subject > > > > > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > > > to, as these > > > > > comments apply to earlier versions as well. > > > > > > > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > > > "This document IANA registers the "esnet" > > > > > RPH namespace for use within emergency services > > > networks, not just > > > > > of those from citizens to PSAPs." (no clear antecedent > > > for "those") > > > > > > > > > > Perhaps > > > > > "This document IANA registers the "esnet" > > > > > RPH namespace for use within emergency services > > > networks, not just > > > > > for calls or sessions > > > > > from citizens to PSAPs." > > > > > > > > > > Section 2 says > > > > > "This document updates the behaviors of the SIP Resource Priority > > > > > header, defined in [RFC4412], during the treatment options > > > > > surrounding this new "esnet" namespace only. The usage of the > > > > > "esnet" namespace does not have a normal, or routine > > > call level. > > > > > Every use of this namespace will be in times of an > > > emergency, where > > > > > at least one end of the signaling is with a local emergency > > > > > organization." > > > > > > > > > > I don't see this as an "update of the behavior of 4412". Neither > > > > > the ets namespace not the wps > > > > > namespace have a "normal" or "routine" call level. Every > > > use of the > > > > > wps and ets namespaces will > > > > > have priority over calls without RPH. > > > > > > > > > > You say "This > > > > > namespace, therefore, MAY be overwritten or deleted, > > > contrary to the > > > > > rules of RFC 4412 [RFC4412]." > > > > > > > > > > It is not clear to me why this is "contrary to the rules > > > of 4412". > > > > > It is certainly anticipated > > > > > that other RPH will be overwritten or deleted, when the UAS > > > > > understands the namespace. > > > > > > > > > > 4412 says "Existing implementations of RFC 3261 that do > > > not participate in > > > > the > > > > > resource priority mechanism follow the normal rules of RFC 3261, > > > > > Section 8.2.2: "If a UAS does not understand a header field in a > > > > > request (that is, the header field is not defined in this > > > > > specification or in any supported extension), the server > > > MUST ignore > > > > > that header field and continue processing the message". " > > > > > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > > > understand the namespace is > > > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > > > > that "the UAC > > > > > MAY attempt a subsequent request with the same or > > > different resource > > > > > value." This certainly implies the ability to overwrite > > > or delete > > > > > an RPH namespace. > > > > > > > > > > (See also, for instance the PTSC SAC document on the use > > > of the ets > > > > > and wps namespaces) > > > > > > > > > > Immediately following these statements, you give 3 options- > > > > > "These proxies in the service provider > > > > > MAY either > > > > > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > > > present, and grant relative preferential treatment to > > > the request > > > > > when forwarding it to the ESINet. > > > > > > > > > > o replace any existing RPH value, if one is present, > > > and insert an > > > > > "esnet" namespace and give relative preferential > > > treatment to the > > > > > request when forwarding it to the ESINet. > > > > > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > > > preferential treatment to the request when forwarding the SIP > > > > > request towards the ESINet." > > > > > > > > > > Why do you exclude the possibility of adding the esnet RPH value > > > > > without "replacing" an existing RPH value? > > > > > > > > > > Finally, there is another point that needs to be made clear. At > > > > > least one person has contacted me expressing concern that this ID > > > > > implied that the esnet namespace would have priority over other > > > > > namespaces (in particular wps and ets). I assured him > > > that this was > > > > > not the case, that there was nothing prevent the expected > > > behavior - > > > > > that the ets and wps namespaces would be prioritized > > > ahead of esnet > > > > > in GETS Service Provider networks. > > > > > > > > > > However, since the question has already arisen, it would > > > be a good > > > > > idea to clarify this, perhaps in section 3, where you > > > discuss the > > > > > other namespaces. In particular, it needs to be made clear in > > > > > section 3.2 that, even if "the local jurisdiction > > > preferred to > > > > > preempt normal calls in lieu of > > > > > completing emergency calls. ", esnet calls will NOT > > > preempt wps or ets > > > > calls. > > > > > > > > > > By the way, I think you mean "the local jurisdiction > > > preferred to > > > > > preempt normal calls in order to complete emergency > > > calls. " - not > > > > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > > > > > In fact, it is not clear to me that 4412 permits a call > > > with an RPH > > > > > (e.g., esnet) to preempt a "normal" call (with no RPH > > > namespace). > > > > > Section 4.7.2.1 of 4412 says > > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > > > > > A UAS compliant with this specification MUST terminate a session > > > > > established with a valid namespace and lower-priority > > > value in favor > > > > > of a new session set up with a valid namespace and > > > higher relative > > > > > priority value, unless local policy has some form of > > > call-waiting > > > > > capability enabled. " > > > > > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > > > > > Thanks > > > > > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > > > > please delete without copying and kindly advise us by > > > e-mail of the > > > > > mistake in delivery. > > > > > NOTE: Regardless of content, this e-mail shall not > > > operate to bind > > > > > CSC to any order or other contract unless pursuant to explicit > > > > > written agreement or government initiative expressly > > > permitting the > > > > > use of e-mail for such purpose. > > > > > > > > > > "James M. Polk" > > > > > Sent by: ecrit-bounces@ietf.org > > > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > "'ECRIT'" > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > > > Subject > > > > > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > > > > > Here is a update to a ID I think is pretty near done, > > > given that this > > > > > is merely an IANA registration ID of an existing mechanism. > > > > > > > > > > Comments are wanted > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > >directories. > > > > > >This draft is a work item of the Emergency Context > > > Resolution with > > > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > > > > > > > Title : IANA Registering a SIP > > > Resource Priority > > > > > > Header Namespace for Local Emergency Communications > > > > > > Author(s) : J. Polk > > > > > > Filename : > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > > > Pages : 9 > > > > > > Date : 2008-10-27 > > > > > > > > > > > >This document creates and IANA registers the new Session > > > Initiation > > > > > >Protocol (SIP) Resource Priority header (RPH) namespace > > > "esnet" for > > > > > >local emergency usage to a public safety answering point (PSAP), > > > > > >between PSAPs, and between a PSAP and first responders and their > > > > > >organizations. > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > Stuart Goldman > > > > > Alcatel-Lucent > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > +1 602 493 8438 > > > > > +1 480 414 1260 mobile > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >CONFIDENTIALITY NOTICE: The information contained in this message > >may be privileged and/or confidential. If you are not the intended > >recipient, or responsible for delivering this message to the > >intended recipient, any review, forwarding, dissemination, > >distribution or copying of this communication or any attachment(s) > >is strictly prohibited. If you have received this message in error, > >please notify the sender immediately, and delete it and all > >attachments from your computer and network. > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > --=_alternative 0073B7B085257507_= Content-Type: text/html; charset="US-ASCII"

"James M. Polk" <jmpolk@cisco.com> wrote on 11/20/2008 03:46:30 PM:


>
> Just to be clear, this discussion is NOT something my namespace ID
> should ever address.  I have no issues with having this discussion -
> but I want to make clear that
> draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make
> priority decisions or even recommendations in the text of the doc.
>
> This ID only creates the namespace *and* the probably scenario in
> which it is intended.
>
Agree
>
> >Public net:
> >P1. ets/wps? (PSAPs may not be so eager to agree)
> >P2. esnet
> >P3. <other/null>
>
> it's not as simple as that.
>
> each <namsepace.priority-value> gets its own slot in any relative
> priority order (per section 8 of RFC4412).
>
> With this in mind, it is *possible* to have a relative priority
> order like this
>
> P1. ets.4
> P2. esnet.4
> P3. ets.3  wps.4
> P4. esnet.3  esnet.2
> P5. wps.3  ets.2
> P6. wps.2  ets.1
> P7. esnet.1
> P8. esnet.0
> P9. ets.0  wps.0
>
> notice that within each <namespace>, the numbering order is
> consistent, but that the order relative to the different namespaces
> is whatever the local operator wants to make them.

At the risk of being a nitnoid, this would NOT be an RFC4412-legal ordering,as it reverses the priority values of ets and wps (0 is the highest).


 I do show here
> that at each priority level (e.g., P3, P4, P5, P6 and P9) that there
> are more than one namespace.priority-value combination.  This means,
> within this priority - it's a FIFO situation in which each of the
> namespace.priority-value combinations at this priority level compete
> (i.e., they are equivalent in priority). This is all a local decision.
>
> I think a way to address Brian's comment about preemption is also a
> local decision (because the local jurisdiction needs to live with the
> consequences).  Here's how that can be addressed:
>
> - all these namespace.priority-value combinations *can* be preempted

I have serious heartburn with this statement.  

In the circuit switched paradigm of preemption (MLPP and eMLPP), only calls that are identified a-priori as "part of a preemption domain (or similar term)" can be preempted.  "Normal" (unmarked, as opposed to marked "routine") calls cannot be preempted. I REALLY don't think we should break that aspect of the paradigm without investigating "unintended consequences" in great detail.

> - only certain namespace.priority-value combinations *can* preempt
> another call.
>
> just a thought about how to solve this...
>
> James
>
>
> >Private net (ESInet):
> >(anything they want)
> >
> >Lastly, what kind of prioritization does a government official (a
> >servant of the people) get when they themselves initiate an emergency
> >call?  esnet or ets/wps?  (In a private ESInet, it may be to their
> >disadvantage to keep the wrong one.)
> >
> >-roger marshall.
> >
> >
> > > -----Original Message-----
> > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> > > On Behalf Of Brian Rosen
> > > Sent: Thursday, November 20, 2008 9:01 AM
> > > To: 'Janet P Gunn'
> > > Cc: Ecrit@ietf.org
> > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > > An "Emergency Services IP Network" is a private IP network to
> > > which, we hope, all public safety agencies are connected.  It
> > > handles all the traffic of a public safety agency, which
> > > would include routine and priority citizen to authority,
> > > authority to authority and authority to citizen traffic.
> > > It's not entirely clear to me yet whether we can reuse a
> > > number of the existing name spaces as well as a new one.  For
> > > example, some of the agency-agency traffic will require
> > > pre-emption, but the existing MLPP namespace may be quite sufficient.
> > >
> > > It does occur to me that we could have ETS and possibly WPS
> > > traffic, in that if the normal access to public facilities
> > > traversed the ESInet towards some kind of gateway to a public
> > > network, then we would either have to have the ETS/WPS
> > > values, or remark them at the edge if a caller inside the
> > > ESInet needed to call someone outside the ESInet and needed
> > > ETS/WPS priority to do so.   If we carried the priority
> > > marking across the ESInet, ETS/WPS would be lower priority
> > > than some other traffic, but higher than, for example,
> > > citizen to authority emergency calls.
> > >
> > > Brian
> > >
> > >
> > >
> > > From: Janet P Gunn [mailto:jgunn6@csc.com]
> > > Sent: Thursday, November 20, 2008 11:37 AM
> > > To: Brian Rosen
> > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)'
> > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > >
> > > Brian,
> > >
> > > I need to understand this better.
> > >
> > > Exactly what are the constraints of the "emergency services
> > > IP network"?  Is this a network in which EVERY call would
> > > have the RPH with the  esnet namespace (just varying priority
> > > values),and there would be no "normal" calls?  Or would their
> > > be a mixture of calls with and without RPH wit esnet?
> > >
> > > Janet
> > >
> > > "Brian Rosen" <br@brianrosen.net> wrote on 11/20/2008 11:16:39 AM:
> > >
> > > > A suggestion was made to me that we should define two namespaces.
> > > >
> > > > One would be used in public networks, and generally would
> > > be used to request
> > > > resource priority for citizen to authority and possibly
> > > authority to citizen
> > > > calls.  This would have lower priority than ETS/WPS.
> > > >
> > > > The other would be for use within emergency services IP
> > > networks.  It would
> > > > be unlikely that ETS/WPS would be used within those
> > > networks, but if it was,
> > > > some values within the namespace would need higher priority
> > > that ETS/WPS.
> > > > For example, a message which was an incident commanders
> > > "evacuate" message
> > > > would be higher than a ETS/WPS traffic.  On the other hand,
> > > a citizen to
> > > > authority emergency call would have lower priority.
> > > >
> > > > I would be happier with one namespace and more values in
> > > that namespace for
> > > > all of this, but I was advised that two namespaces was a
> > > better choice.
> > > >
> > > > Brian
> > > >
> > > > From: ecrit-bounces@ietf.org
> > > [mailto:ecrit-bounces@ietf.org] On Behalf Of
> > > > Janet P Gunn
> > > > Sent: Thursday, November 20, 2008 11:00 AM
> > > > To: GOLDMAN, STUART O (STUART)
> > > > Cc: Ecrit@ietf.org
> > > > Subject: Re: [Ecrit] Ecrit]
> > > > draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > >
> > > >
> > > > Stu,
> > > >
> > > > I intended to say that the esnet namespace needs to be at a
> > > LOWER priority
> > > >  than the ets and wps namespaces, in any network that
> > > recognizes ets and wps
> > > > as described in 10.5 and 10.6 of RFC4412.
> > > >
> > > > Janet
> > > >
> > > > "GOLDMAN, STUART O \(STUART\)"
> > > <sgoldman@alcatel-lucent.com> wrote on
> > > > 11/20/2008 10:22:49 AM:
> > > >
> > > > > Janet,
> > > > >
> > > > > With regard to you e-mail below, did you intend that
> > > esnet could be
> > > > > at the same level of priority as ETS & WPS,  or that ETS
> > > & WPS need
> > > > > to be at an even higher priority than esnet?
> > > > >
> > > > >
> > > > >
> > > > > Stuart Goldman
> > > > > Alcatel-Lucent
> > > > > Stuart.Goldman@alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Janet P Gunn/FED/CSC@CSC
> > > > > Sent by: ecrit-bounces@ietf.org
> > > > > 10/27/2008 11:45 PM
> > > > >
> > > > >
> > > > >
> > > > > To
> > > > >
> > > > > "James M. Polk" <jmpolk@cisco.com>
> > > > >
> > > > > cc
> > > > >
> > > > > "'ECRIT'" <ecrit@ietf.org>, ecrit-bounces@ietf.org
> > > > >
> > > > > Subject
> > > > >
> > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I apologize for not tracking this as closely as I meant
> > > to, as these
> > > > > comments apply to  earlier versions as well.
> > > > >
> > > > >
> > > > > This sentence at the end of sec 1 doesn't quite work.
> > > > > "This document IANA registers the "esnet"
> > > > >  RPH namespace for use within emergency services
> > > networks, not just
> > > > >  of those from citizens to PSAPs." (no clear antecedent
> > > for "those")
> > > > >
> > > > > Perhaps
> > > > > "This document IANA registers the "esnet"
> > > > >  RPH namespace for use within emergency services
> > > networks, not just
> > > > > for calls or sessions
> > > > >   from citizens to PSAPs."
> > > > >
> > > > > Section 2 says
> > > > > "This document updates the behaviors of the SIP Resource Priority
> > > > >  header, defined in [RFC4412], during the treatment options
> > > > >  surrounding this new "esnet" namespace only. The usage of the
> > > > >  "esnet" namespace does not have a normal, or routine
> > > call level.
> > > > >  Every use of this namespace will be in times of an
> > > emergency, where
> > > > >  at least one end of the signaling is with a local emergency
> > > > >  organization."
> > > > >
> > > > > I don't see this as an "update of the behavior of 4412".  Neither
> > > > > the ets namespace not the wps
> > > > > namespace have a "normal" or "routine" call level.  Every
> > > use of the
> > > > > wps and ets namespaces will
> > > > > have priority over calls without RPH.
> > > > >
> > > > > You say "This
> > > > >  namespace, therefore, MAY be overwritten or deleted,
> > > contrary to the
> > > > >  rules of RFC 4412 [RFC4412]."
> > > > >
> > > > > It is not clear to me why this is "contrary to the rules
> > > of 4412".
> > > > > It is certainly anticipated
> > > > > that other RPH will be overwritten or deleted, when the UAS
> > > > > understands the namespace.
> > > > >
> > > > > 4412 says "Existing implementations of RFC 3261 that do
> > > not participate in
> > > > the
> > > > >  resource priority mechanism follow the normal rules of RFC 3261,
> > > > >  Section 8.2.2: "If a UAS does not understand a header field in a
> > > > >  request (that is, the header field is not defined in this
> > > > >  specification or in any supported extension), the server
> > > MUST ignore
> > > > >  that header field and continue processing the message". "
> > > > >
> > > > > But I do not see anywhere that is says that a UAS that DOES
> > > > > understand the namespace is
> > > > > forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says
> > > > > that "the UAC
> > > > >  MAY attempt a subsequent request with the same or
> > > different resource
> > > > >  value."  This certainly implies the ability to overwrite
> > > or delete
> > > > > an RPH namespace.
> > > > >
> > > > > (See also, for instance the PTSC SAC document on the use
> > > of the ets
> > > > > and wps namespaces)
> > > > >
> > > > > Immediately following these statements, you give 3 options-
> > > > > "These proxies in the service provider
> > > > >  MAY either
> > > > >
> > > > >  o  accept the existing RPH value with "esnet" in it, if one is
> > > > >     present, and grant relative preferential treatment to
> > > the request
> > > > >     when forwarding it to the ESINet.
> > > > >
> > > > >  o  replace any existing RPH value, if one is present,
> > > and insert an
> > > > >     "esnet" namespace and give relative preferential
> > > treatment to the
> > > > >     request when forwarding it to the ESINet.
> > > > >
> > > > >  o  insert an "esnet" namespace in a new RPH and give relative
> > > > >     preferential treatment to the request when forwarding the SIP
> > > > >     request towards the ESINet."
> > > > >
> > > > > Why do you exclude the possibility of adding the esnet RPH value
> > > > > without "replacing" an existing RPH value?
> > > > >
> > > > > Finally, there is another point that  needs to be made clear.  At
> > > > > least one person has contacted me expressing concern that this ID
> > > > > implied that the esnet namespace would  have priority over other
> > > > > namespaces (in particular wps and ets).  I assured him
> > > that this was
> > > > > not the case, that there was nothing prevent the expected
> > > behavior -
> > > > > that the ets and wps namespaces would be prioritized
> > > ahead of esnet
> > > > > in GETS Service Provider networks.
> > > > >
> > > > > However, since the question has already arisen, it would
> > > be a good
> > > > > idea to clarify  this, perhaps in  section 3, where you
> > > discuss  the
> > > > > other namespaces.  In particular, it needs to be made clear in
> > > > > section 3.2  that, even if  "the   local jurisdiction
> > > preferred to
> > > > > preempt normal calls in lieu of
> > > > >  completing emergency calls. ", esnet calls will NOT
> > > preempt wps or ets
> > > > calls.
> > > > >
> > > > > By the way, I think you mean "the   local jurisdiction
> > > preferred to
> > > > > preempt normal calls in order to complete emergency
> > > calls. "  - not
> > > > > "in lieu of".  Or perhaps "the   local jurisdiction preferred to
> > > > > preempt normal calls in lieu of  dropping emergency calls. "
> > > > >
> > > > > In fact, it is not clear to me that 4412 permits a call
> > > with an RPH
> > > > > (e.g., esnet)  to preempt a "normal" call (with no RPH
> > > namespace).
> > > > > Section 4.7.2.1 of 4412 says
> > > > > "4.7.2.1.  User Agent Servers and Preemption Algorithm
> > > > >
> > > > >  A UAS compliant with this specification MUST terminate a session
> > > > >  established with a valid namespace and lower-priority
> > > value in favor
> > > > >  of a new session set up with a valid namespace and
> > > higher relative
> > > > >  priority value, unless local policy has some form of
> > > call-waiting
> > > > >  capability enabled. "
> > > > >
> > > > > It doesn't say anything about preempting a call with no RPH
> > > > >
> > > > > Thanks
> > > > >
> > > > > Janet
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > This is a PRIVATE message. If you are not the intended recipient,
> > > > > please delete without copying and kindly advise us by
> > > e-mail of the
> > > > > mistake in delivery.
> > > > > NOTE: Regardless of content, this e-mail shall not
> > > operate to bind
> > > > > CSC to any order or other contract unless pursuant to explicit
> > > > > written agreement or government initiative expressly
> > > permitting the
> > > > > use of e-mail for such purpose.
> > > > >
> > > > > "James M. Polk" <jmpolk@cisco.com>
> > > > > Sent by: ecrit-bounces@ietf.org
> > > > > 10/27/2008 08:32 PM
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To
> > > > >
> > > > > "'ECRIT'" <ecrit@ietf.org>
> > > > >
> > > > > cc
> > > > >
> > > > >
> > > > >
> > > > > Subject
> > > > >
> > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ECRIT WG
> > > > >
> > > > > Here is a update to a ID I think is pretty near done,
> > > given that this
> > > > > is merely an IANA registration ID of an existing mechanism.
> > > > >
> > > > > Comments are wanted
> > > > >
> > > > > >A New Internet-Draft is available from the on-line
> > > Internet-Drafts
> > > > > >directories.
> > > > > >This draft is a work item of the Emergency Context
> > > Resolution with
> > > > > >Internet Technologies Working Group of the IETF.
> > > > > >
> > > > > >
> > > > > >         Title           : IANA Registering a SIP
> > > Resource Priority
> > > > > > Header Namespace for Local Emergency Communications
> > > > > >         Author(s)       : J. Polk
> > > > > >         Filename        :
> > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
> > > > > >         Pages           : 9
> > > > > >         Date            : 2008-10-27
> > > > > >
> > > > > >This document creates and IANA registers the new Session
> > > Initiation
> > > > > >Protocol (SIP) Resource Priority header (RPH) namespace
> > > "esnet" for
> > > > > >local emergency usage to a public safety answering point (PSAP),
> > > > > >between PSAPs, and between a PSAP and first responders and their
> > > > > >organizations.
> > > > > >
> > > > > >A URL for this Internet-Draft is:
> > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> > > > > emergency-rph-namespace-00.txt
> > > > > >
> > > > > >
> > > > > >
> > > > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local->  
> >  > > emergency-rph-namespace-00.txt>
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > > >
> > > > >
> > > > > Stuart Goldman
> > > > > Alcatel-Lucent
> > > > > Stuart.Goldman@alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ecrit
> > >
> >
> >CONFIDENTIALITY NOTICE: The information contained in this message
> >may be privileged and/or confidential. If you are not the intended
> >recipient, or responsible for delivering this message to the
> >intended recipient, any review, forwarding, dissemination,
> >distribution or copying of this communication or any attachment(s)
> >is strictly prohibited. If you have received this message in error,
> >please notify the sender immediately, and delete it and all
> >attachments from your computer and network.
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit@ietf.org
> >https://www.ietf.org/mailman/listinfo/ecrit
>
--=_alternative 0073B7B085257507_=-- --===============0491196783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0491196783==-- From ecrit-bounces@ietf.org Thu Nov 20 13:08:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E003A6A77; Thu, 20 Nov 2008 13:08:25 -0800 (PST) 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 D2ECB3A6A77 for ; Thu, 20 Nov 2008 13:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0VWhDp1o6nyW for ; Thu, 20 Nov 2008 13:08:21 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 604073A677D for ; Thu, 20 Nov 2008 13:08:21 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 13:08:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 13:06:56 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <020601c94b4f$101d8740$305895c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQ References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> From: "Roger Marshall" To: "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Isn't there a need to set the scope [text] of phonebcp, so that it makes clear what that the requirements apply (without bias) to both fixed and mobile end devices (and their associated network deployment types)? Below is some keyword sampling to show some implications with regard to fixed vs. mobile, but which isn't as crisp as it could be (depending on the scope). A search of phonebcp for the following terms yields the associated references: Fixed: (none); Wireline: (none); Mobile: AN-11; ED-35/AN-19; ED-35; Wireless: AN-7/INT-6; AN-9; AN-7; INT-6; >From the toc, it is listed... 6.2.2. Access network "wire database" location information . 7 6.2.3. End-system measured location information . . . . . . . 7 6.2.4. Network-measured location information . . . . . . . . 8 -roger. No mention of fixed, wireline, wireless, or mobile in any of the text sections (Intro, etc.) > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 20, 2008 12:32 PM > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Phonebcp doesn't have a pre-disposition. It's neutral. If > we need to parse more carefully, SUPL isn't very suitable for > wiremap forms of location determination. > > Brian > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Thursday, November 20, 2008 3:22 PM > To: Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > Generally, I agree that SUPL is unsuitable for access > > networks that don't use GPS or some form of measured location. > > [rsm - measured only - really? - surely you aren't suggesting > that OMA (and therefore 3GPP, 3GPP2) throw away their > reliance on 'rough location' via CellID, are you? > > Wiremap location - given (manually input)] CellID location - > given Terrestial trilateration - measured Celestial > trilateration - measured Geocoded/reverse geocoded - derived > > I would hope that PhoneBCP doesn't show a pre-disposition to 'given' > location scenarios, aka wiremap, etc. that are more Wireline > oriented, rather than mobile. For the future, wireline > devices reduce in number, mobile (or even nomadic) devices > will continue in their distribution bias. Fixed vs. Mobile > has been the fundamental difference between how the IETF > looks at things vs. these mentioned other fora. I contend > that if we solve this for mobile - then we can begin > communicating better with OMA/3GPP/3GPP2, and... Solving > fixed will be easier. > /] > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 20, 2008 12:07 PM > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Gabor accuses us of ignoring reality. The 3GPP crowd has its own > > version of that. > > > > All 3GPP networks I know of support a raw packet service. On that > > service will run applications like MSN or AOL instant messaging. > > Those services > > will need to be able to make emergency chats. To route > > properly, they need > > location. That means that EVERY handset must deploy some LCP, and > > must be able to get location suitable for emergency call > routing and > > dispatch per -phonebcp. The RV example is yet another case of the > > same thing. The mistake is assuming that all emergency calls will > > come through the E-CSCF. > > They won't, and the 3GPP access network must conform to all the > > -phonebcp requirements. > > > > Generally, I agree that SUPL is unsuitable for access networks that > > don't use GPS or some form of measured location. > > > > Brian > > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 20, 2008 2:54 PM > > To: Roger Marshall; Brian Rosen; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > I cannot support requiring SUPL in DSL routers, desktop > computers (and > > related operating systems, SIP soft clients), analog terminal > > adaptors, or other similar devices that are intended for use in a > > wireline environment. I think that organizations that can drive > > requirements for devices intended to be use in an environment where > > SUPL would actually work, should be responsible for having device > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > absolutely > > in a position to require SUPL support for devices that > operate in an > > environment where SUPL works. This is a perfect example of the > > "closed" network that Brian describes somewhere (framework, > I think). > > > > Phonebcp is about requirements for devices in access environments > > where the operators of the access environment cannot be assumed to > > have any control over the type or nature of devices that > connect to or > > through it. Phonebcp needs to continue to have that as its purpose. > > > > I agree that nothing in phonebcp should preclude the use of > SUPL, or > > be incompatible with the use of SUPL. And I don't think it does. > > Barbara > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, November 20, 2008 2:36 PM > > To: Brian Rosen; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > If the choice is between preventing, allowing, or > requiring PhoneBCP > > suppport of SUPL, then my vote is to NOT prevent! I would prefer > > 'require' since *most* of the location-aware 3G compatible > > handsets/aircards over the next several years will (I > predict) have a > > SUPL stack included. In the same time frame, many of those > will also > > have WiFi support, others will have LTE or WiMAX support as hybrids. > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > open-minded, and there is movement afoot to expand OMA/SUPL (as we > > heard in the geopriv mtg. on Tuesday) w/respect expected proposals > > such as LocSIP, etc. Over the fairly near-term, I think > there will be > > fewer protocol, location representation, and privacy > discontinuities - > > things that too often get cited - yet are seldom well understood. > > > > Let's encourage continued IETF communication with OMA/SUPL > - not block > > its use altogether. This is a case where we need to be > inclusive, not > > exclusive. > > > > As to the mobile RV sample case, the solution is also forseeable - > > especially given that the location of the 3G aircard in the > router is > > good enough for routing. The scenario given needs some > integration, > > but is doable. Given that the aircard acts as a logical > SET, with a > > SUPL stack on board, and a GPS/AGPS chipset inside. This > combination > > *WILL* (I believe) interoperate with a number of end client > > applications to initiate and complete a location-routed, 3261 style > > SIP, emergency call through the core, and into an ESInet. > > > > -roger. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Brian Rosen > > > Sent: Thursday, November 20, 2008 8:23 AM > > > To: 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > It's very hard to have L2 specific LCPs. The problem is that the > > > clients are generally not very L2 aware. It's the clients > > that have > > > the problem. > > > You can do things like interwork an L2 specific LCP to a > > common LCP so > > > that non L2 aware devices can work, but you have to do that, and > > > usually, that's impractical. Use my example. Suppose > that the L2 > > > used SUPL. It's possible for the PC Card that is plugged > into the > > > router could implement a SUPL client and a HELD server and > > interwork > > > SUPL in the GSM system to HELD on the Ethernet so the > Ethernet VoIP > > > phone could get location via HELD. Possible, but not practical. > > > There are all sorts of these kinds of problems. That's why > > > L2 specific LCPs don't work. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, November 20, 2008 11:11 AM > > > To: Brian Rosen > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > The IETF can't (and shouldn't) try to make particular > standards for > > > every access technology that's out there. What we can say > > is that the > > > paradigm for those protocols should be the same as at the > IP layer: > > > Clients MUST implement all, networks MUST implement at least one. > > > > > > (This is a little different from the text I sent before, > > and clearer, > > > I > > > think.) > > > > > > All I'm saying is that we shouldn't try to enumerate all > > the possible > > > protocols at lower layers, we should just state the general > > rule. It > > > seems to me that this achieves the same level of > > interoperability at > > > all layers. > > > > > > --Richard > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > any number > > > > of optional ones, then every network has to implement at > > > least one of > > > > those > > > two > > > > LCPs, and any number of optional ones. That means that > > > "any number of > > > > optional ones" is useless for both parties. > > > > If the network can limit UAs to ONLY those that implement > > > one of the > > > > optional protocols, then it works, but in practice, it > is usually > > > impossible > > > > to do that. My example is the wired, Ethernet connected > > > phone in an > > > > RV traveling down the road with wireless data card in a > > > router. These > > > > EXIST, now. > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > To: Brian Rosen > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I think we need to pull up a level. It's not reasonable > > > for an RFC to > > > > try to list all of the location protocols out there, if for > > > no other > > > > reason than that it will rapidly become obsolete. Instead, > > > we should > > > > say something like the following: > > > > > > > > " > > > > INT-12 Devices MUST support the DHCP location options > > [RFC4776] and > > > > [RFC3825] and HELD > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > SHOULD support all location protocols supported at lower > > layers by > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > " > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > >> The problem with SUPL is that the majority of networks > > where SUPL > > > >> would > > > be > > > >> available have a proxy (E-CSCF) insert location. It > also has an > > > >> incompatible location representation, and an incompatible > > > privacy model. > > > >> That makes it very hard to interwork with any of the rest > > > of the IETF > > > > work. > > > >> I will say this. For quite some time, the IETF has been > > trying to > > > > interest > > > >> OMA into cooperation on location so that we have > > > interoperability at > > > >> the protocol, location representation and privacy > > levels. So far, > > > >> that has > > > > not > > > >> happened. If, as part of a comprehensive agreement to > > accomplish > > > >> such a goal, SUPL became one of the LCPs, I would not object. > > > >> > > > >> Brian > > > >> > > > >> -----Original Message----- > > > >> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > > >> Behalf Of Gabor.Bajko@nokia.com > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >> > > > >> Hi, > > > >> > > > >> Is the intent to list the LCPs which are access-type > > > agnostic but not > > > >> supported anywhere, or instead have a list of LCPs which > > > are highly > > > >> probable to produce the intended result? > > > >> > > > >> There are restrictions everywhere, things come at a cost > > > even in the > > > >> general Internet model. The reality is that most of the > > > devices with > > > >> internet access have a home network already. > > > >> > > > >> - Gabor > > > >> > > > >> > > > >> >-----Original Message----- > > > >> >From: ext Winterbottom, James > > > [mailto:James.Winterbottom@andrew.com] > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > - FI/Espoo) > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > >> > > > > >> >Hi Gabor, > > > >> > > > > >> >The list of LCPs in the phone BCP is a must support > > list, and is > > > >> access- > > > >> >type agnostic. > > > >> >I am curious that you say that SUPL is a MUST support > > > given that: > > > >> >a) it requires a home network in order to operate > > > >> >b) it simply doesn't work for DSL or Cable > > > >> >c) it is questionable whether it is really deployable > > for WiFi > > > >> networks > > > >> > > > > >> >Can you perhaps describe how it fits into the general > > > Internet model? > > > >> > > > > >> >Cheers > > > >> >James > > > >> > > > > >> > > > > >> >-----Original Message----- > > > >> >From: ecrit-bounces@ietf.org on behalf of > > Gabor.Bajko@nokia.com > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > >> >To: ecrit@ietf.org > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >> > > > > >> >I was requested to send my observations regarding this > > > requirement: > > > >> > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > location options > > > >> > [RFC4776] and [RFC3825], HELD > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > LLDP-MED [LLDP-MED]. > > > >> > > > > >> > > > > >> >I believe we should come up with a list of LCPs which > > > are likely > > > >> to be > > > >> >supported in devices in a not so distant future. Since > > > I have no > > > >> seen or > > > >> >heard about LLDP support yet, at least that should be > > replaced > > > >> with what > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > mechanism, with the > > > >> >condition that this MUST only be supported if there > is a wifi > > > >> interface > > > >> >available on the device. > > > >> > > > > >> >- Gabor > > > >> > > > > >> > > > > >> > > > > >> >________________________________ > > > >> > > > > >> >From: ext Tschofenig, Hannes > > > >> > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > > >> >Subject: Location Protocols in Phone BCP > > > >> > > > > >> > > > > >> > > > > >> >Gabor, > > > >> > > > > >> >Could you please raise your question about location > > > protocols in > > > >> Phone > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > >> > > > > >> >Ciao > > > >> >Hannes > > > >> > > > > >> > > > > >> > > > >>> > > > > -------------------------------------------------------------------- > > > >>> --- > > > >> -- > > > >> >----------------------- > > > >> >This message is for the designated recipient only and may > > > >> >contain privileged, proprietary, or otherwise private > > > information. > > > >> >If you have received it in error, please notify the sender > > > >> >immediately and delete the original. Any > unauthorized use of > > > >> >this email is prohibited. > > > >> > > > >>> > > > > -------------------------------------------------------------------- > > > >>> --- > > > >> -- > > > >> >----------------------- > > > >> >[mf2] > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may > > be privileged and/or confidential. If you are not the intended > > recipient, or responsible for delivering this message to > the intended > > recipient, any review, forwarding, dissemination, distribution or > > copying of this communication or any attachment(s) is strictly > > prohibited. If you have received this message in error, > please notify > > the sender immediately, and delete it and all attachments from your > > computer and network. > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person > or entity > > to which it is addressed and may contain confidential, proprietary, > > and/or privileged material. Any review, retransmission, > dissemination > > or other use of, or taking of any action in reliance upon this > > information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact the > > sender and delete the material from all computers. GA621 > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 13:14:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1613A28C234; Thu, 20 Nov 2008 13:14:46 -0800 (PST) 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 612BA28C234 for ; Thu, 20 Nov 2008 13:14:44 -0800 (PST) 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 duLeNv-DcRW6 for ; Thu, 20 Nov 2008 13:14:42 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 86FE628C0F5 for ; Thu, 20 Nov 2008 13:14:41 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 13:14:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 13:13:23 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <020601c94b4f$101d8740$305895c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3Q References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> From: "Roger Marshall" To: "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No objection to saying that SUPL in its present form is not a good choice for wire-map, but would object to saying the same for other types of 'non-measured' location. Rather, SUPL is in fact an excellent choice for non-endpoint measured location such as 'CellID'. -roger. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 20, 2008 12:32 PM > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Phonebcp doesn't have a pre-disposition. It's neutral. If > we need to parse more carefully, SUPL isn't very suitable for > wiremap forms of location determination. > > Brian > > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Thursday, November 20, 2008 3:22 PM > To: Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > Generally, I agree that SUPL is unsuitable for access > > networks that don't use GPS or some form of measured location. > > [rsm - measured only - really? - surely you aren't suggesting > that OMA (and therefore 3GPP, 3GPP2) throw away their > reliance on 'rough location' via CellID, are you? > > Wiremap location - given (manually input)] CellID location - > given Terrestial trilateration - measured Celestial > trilateration - measured Geocoded/reverse geocoded - derived > > I would hope that PhoneBCP doesn't show a pre-disposition to 'given' > location scenarios, aka wiremap, etc. that are more Wireline > oriented, rather than mobile. For the future, wireline > devices reduce in number, mobile (or even nomadic) devices > will continue in their distribution bias. Fixed vs. Mobile > has been the fundamental difference between how the IETF > looks at things vs. these mentioned other fora. I contend > that if we solve this for mobile - then we can begin > communicating better with OMA/3GPP/3GPP2, and... Solving > fixed will be easier. > /] > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 20, 2008 12:07 PM > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Gabor accuses us of ignoring reality. The 3GPP crowd has its own > > version of that. > > > > All 3GPP networks I know of support a raw packet service. On that > > service will run applications like MSN or AOL instant messaging. > > Those services > > will need to be able to make emergency chats. To route > > properly, they need > > location. That means that EVERY handset must deploy some LCP, and > > must be able to get location suitable for emergency call > routing and > > dispatch per -phonebcp. The RV example is yet another case of the > > same thing. The mistake is assuming that all emergency calls will > > come through the E-CSCF. > > They won't, and the 3GPP access network must conform to all the > > -phonebcp requirements. > > > > Generally, I agree that SUPL is unsuitable for access networks that > > don't use GPS or some form of measured location. > > > > Brian > > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 20, 2008 2:54 PM > > To: Roger Marshall; Brian Rosen; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > I cannot support requiring SUPL in DSL routers, desktop > computers (and > > related operating systems, SIP soft clients), analog terminal > > adaptors, or other similar devices that are intended for use in a > > wireline environment. I think that organizations that can drive > > requirements for devices intended to be use in an environment where > > SUPL would actually work, should be responsible for having device > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > absolutely > > in a position to require SUPL support for devices that > operate in an > > environment where SUPL works. This is a perfect example of the > > "closed" network that Brian describes somewhere (framework, > I think). > > > > Phonebcp is about requirements for devices in access environments > > where the operators of the access environment cannot be assumed to > > have any control over the type or nature of devices that > connect to or > > through it. Phonebcp needs to continue to have that as its purpose. > > > > I agree that nothing in phonebcp should preclude the use of > SUPL, or > > be incompatible with the use of SUPL. And I don't think it does. > > Barbara > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, November 20, 2008 2:36 PM > > To: Brian Rosen; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > If the choice is between preventing, allowing, or > requiring PhoneBCP > > suppport of SUPL, then my vote is to NOT prevent! I would prefer > > 'require' since *most* of the location-aware 3G compatible > > handsets/aircards over the next several years will (I > predict) have a > > SUPL stack included. In the same time frame, many of those > will also > > have WiFi support, others will have LTE or WiMAX support as hybrids. > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > open-minded, and there is movement afoot to expand OMA/SUPL (as we > > heard in the geopriv mtg. on Tuesday) w/respect expected proposals > > such as LocSIP, etc. Over the fairly near-term, I think > there will be > > fewer protocol, location representation, and privacy > discontinuities - > > things that too often get cited - yet are seldom well understood. > > > > Let's encourage continued IETF communication with OMA/SUPL > - not block > > its use altogether. This is a case where we need to be > inclusive, not > > exclusive. > > > > As to the mobile RV sample case, the solution is also forseeable - > > especially given that the location of the 3G aircard in the > router is > > good enough for routing. The scenario given needs some > integration, > > but is doable. Given that the aircard acts as a logical > SET, with a > > SUPL stack on board, and a GPS/AGPS chipset inside. This > combination > > *WILL* (I believe) interoperate with a number of end client > > applications to initiate and complete a location-routed, 3261 style > > SIP, emergency call through the core, and into an ESInet. > > > > -roger. > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Brian Rosen > > > Sent: Thursday, November 20, 2008 8:23 AM > > > To: 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > It's very hard to have L2 specific LCPs. The problem is that the > > > clients are generally not very L2 aware. It's the clients > > that have > > > the problem. > > > You can do things like interwork an L2 specific LCP to a > > common LCP so > > > that non L2 aware devices can work, but you have to do that, and > > > usually, that's impractical. Use my example. Suppose > that the L2 > > > used SUPL. It's possible for the PC Card that is plugged > into the > > > router could implement a SUPL client and a HELD server and > > interwork > > > SUPL in the GSM system to HELD on the Ethernet so the > Ethernet VoIP > > > phone could get location via HELD. Possible, but not practical. > > > There are all sorts of these kinds of problems. That's why > > > L2 specific LCPs don't work. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, November 20, 2008 11:11 AM > > > To: Brian Rosen > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > The IETF can't (and shouldn't) try to make particular > standards for > > > every access technology that's out there. What we can say > > is that the > > > paradigm for those protocols should be the same as at the > IP layer: > > > Clients MUST implement all, networks MUST implement at least one. > > > > > > (This is a little different from the text I sent before, > > and clearer, > > > I > > > think.) > > > > > > All I'm saying is that we shouldn't try to enumerate all > > the possible > > > protocols at lower layers, we should just state the general > > rule. It > > > seems to me that this achieves the same level of > > interoperability at > > > all layers. > > > > > > --Richard > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > any number > > > > of optional ones, then every network has to implement at > > > least one of > > > > those > > > two > > > > LCPs, and any number of optional ones. That means that > > > "any number of > > > > optional ones" is useless for both parties. > > > > If the network can limit UAs to ONLY those that implement > > > one of the > > > > optional protocols, then it works, but in practice, it > is usually > > > impossible > > > > to do that. My example is the wired, Ethernet connected > > > phone in an > > > > RV traveling down the road with wireless data card in a > > > router. These > > > > EXIST, now. > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > To: Brian Rosen > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I think we need to pull up a level. It's not reasonable > > > for an RFC to > > > > try to list all of the location protocols out there, if for > > > no other > > > > reason than that it will rapidly become obsolete. Instead, > > > we should > > > > say something like the following: > > > > > > > > " > > > > INT-12 Devices MUST support the DHCP location options > > [RFC4776] and > > > > [RFC3825] and HELD > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > SHOULD support all location protocols supported at lower > > layers by > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > " > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > >> The problem with SUPL is that the majority of networks > > where SUPL > > > >> would > > > be > > > >> available have a proxy (E-CSCF) insert location. It > also has an > > > >> incompatible location representation, and an incompatible > > > privacy model. > > > >> That makes it very hard to interwork with any of the rest > > > of the IETF > > > > work. > > > >> I will say this. For quite some time, the IETF has been > > trying to > > > > interest > > > >> OMA into cooperation on location so that we have > > > interoperability at > > > >> the protocol, location representation and privacy > > levels. So far, > > > >> that has > > > > not > > > >> happened. If, as part of a comprehensive agreement to > > accomplish > > > >> such a goal, SUPL became one of the LCPs, I would not object. > > > >> > > > >> Brian > > > >> > > > >> -----Original Message----- > > > >> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On > > > >> Behalf Of Gabor.Bajko@nokia.com > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >> > > > >> Hi, > > > >> > > > >> Is the intent to list the LCPs which are access-type > > > agnostic but not > > > >> supported anywhere, or instead have a list of LCPs which > > > are highly > > > >> probable to produce the intended result? > > > >> > > > >> There are restrictions everywhere, things come at a cost > > > even in the > > > >> general Internet model. The reality is that most of the > > > devices with > > > >> internet access have a home network already. > > > >> > > > >> - Gabor > > > >> > > > >> > > > >> >-----Original Message----- > > > >> >From: ext Winterbottom, James > > > [mailto:James.Winterbottom@andrew.com] > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > - FI/Espoo) > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > >> > > > > >> >Hi Gabor, > > > >> > > > > >> >The list of LCPs in the phone BCP is a must support > > list, and is > > > >> access- > > > >> >type agnostic. > > > >> >I am curious that you say that SUPL is a MUST support > > > given that: > > > >> >a) it requires a home network in order to operate > > > >> >b) it simply doesn't work for DSL or Cable > > > >> >c) it is questionable whether it is really deployable > > for WiFi > > > >> networks > > > >> > > > > >> >Can you perhaps describe how it fits into the general > > > Internet model? > > > >> > > > > >> >Cheers > > > >> >James > > > >> > > > > >> > > > > >> >-----Original Message----- > > > >> >From: ecrit-bounces@ietf.org on behalf of > > Gabor.Bajko@nokia.com > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > >> >To: ecrit@ietf.org > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > >> > > > > >> >I was requested to send my observations regarding this > > > requirement: > > > >> > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > location options > > > >> > [RFC4776] and [RFC3825], HELD > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > LLDP-MED [LLDP-MED]. > > > >> > > > > >> > > > > >> >I believe we should come up with a list of LCPs which > > > are likely > > > >> to be > > > >> >supported in devices in a not so distant future. Since > > > I have no > > > >> seen or > > > >> >heard about LLDP support yet, at least that should be > > replaced > > > >> with what > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > mechanism, with the > > > >> >condition that this MUST only be supported if there > is a wifi > > > >> interface > > > >> >available on the device. > > > >> > > > > >> >- Gabor > > > >> > > > > >> > > > > >> > > > > >> >________________________________ > > > >> > > > > >> >From: ext Tschofenig, Hannes > > > >> > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > > >> >Subject: Location Protocols in Phone BCP > > > >> > > > > >> > > > > >> > > > > >> >Gabor, > > > >> > > > > >> >Could you please raise your question about location > > > protocols in > > > >> Phone > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > >> > > > > >> >Ciao > > > >> >Hannes > > > >> > > > > >> > > > > >> > > > >>> > > > > -------------------------------------------------------------------- > > > >>> --- > > > >> -- > > > >> >----------------------- > > > >> >This message is for the designated recipient only and may > > > >> >contain privileged, proprietary, or otherwise private > > > information. > > > >> >If you have received it in error, please notify the sender > > > >> >immediately and delete the original. Any > unauthorized use of > > > >> >this email is prohibited. > > > >> > > > >>> > > > > -------------------------------------------------------------------- > > > >>> --- > > > >> -- > > > >> >----------------------- > > > >> >[mf2] > > > >> > > > >> _______________________________________________ > > > >> 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 > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > message may > > be privileged and/or confidential. If you are not the intended > > recipient, or responsible for delivering this message to > the intended > > recipient, any review, forwarding, dissemination, distribution or > > copying of this communication or any attachment(s) is strictly > > prohibited. If you have received this message in error, > please notify > > the sender immediately, and delete it and all attachments from your > > computer and network. > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person > or entity > > to which it is addressed and may contain confidential, proprietary, > > and/or privileged material. Any review, retransmission, > dissemination > > or other use of, or taking of any action in reliance upon this > > information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact the > > sender and delete the material from all computers. GA621 > > > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 14:10:16 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2343528C0F2; Thu, 20 Nov 2008 14:10:16 -0800 (PST) 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 18BF83A6906 for ; Thu, 20 Nov 2008 14:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 oJmosuIFtPfp for ; Thu, 20 Nov 2008 14:10:13 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BB9783A68D4 for ; Thu, 20 Nov 2008 14:10:12 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_16_27_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 16:27:50 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 16:10:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 16:06:51 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3QAAHvRyA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" X-OriginalArrivalTime: 20 Nov 2008 22:10:10.0642 (UTC) FILETIME=[C1274320:01C94B5C] Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Only if the device is connected to its home network, else you require a world in a database solution. Inter-carrier roaming with SUPL is problematic to say the least. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Friday, 21 November 2008 8:13 AM > To: Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > No objection to saying that SUPL in its present form is not a good > choice for wire-map, but would object to saying the same for other types > of 'non-measured' location. > > Rather, SUPL is in fact an excellent choice for non-endpoint measured > location such as 'CellID'. > > -roger. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 20, 2008 12:32 PM > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > we need to parse more carefully, SUPL isn't very suitable for > > wiremap forms of location determination. > > > > Brian > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Thursday, November 20, 2008 3:22 PM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that don't use GPS or some form of measured location. > > > > [rsm - measured only - really? - surely you aren't suggesting > > that OMA (and therefore 3GPP, 3GPP2) throw away their > > reliance on 'rough location' via CellID, are you? > > > > Wiremap location - given (manually input)] CellID location - > > given Terrestial trilateration - measured Celestial > > trilateration - measured Geocoded/reverse geocoded - derived > > > > I would hope that PhoneBCP doesn't show a pre-disposition to 'given' > > location scenarios, aka wiremap, etc. that are more Wireline > > oriented, rather than mobile. For the future, wireline > > devices reduce in number, mobile (or even nomadic) devices > > will continue in their distribution bias. Fixed vs. Mobile > > has been the fundamental difference between how the IETF > > looks at things vs. these mentioned other fora. I contend > > that if we solve this for mobile - then we can begin > > communicating better with OMA/3GPP/3GPP2, and... Solving > > fixed will be easier. > > /] > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:07 PM > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd has its own > > > version of that. > > > > > > All 3GPP networks I know of support a raw packet service. On that > > > service will run applications like MSN or AOL instant messaging. > > > Those services > > > will need to be able to make emergency chats. To route > > > properly, they need > > > location. That means that EVERY handset must deploy some LCP, and > > > must be able to get location suitable for emergency call > > routing and > > > dispatch per -phonebcp. The RV example is yet another case of the > > > same thing. The mistake is assuming that all emergency calls will > > > come through the E-CSCF. > > > They won't, and the 3GPP access network must conform to all the > > > -phonebcp requirements. > > > > > > Generally, I agree that SUPL is unsuitable for access networks that > > > don't use GPS or some form of measured location. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 20, 2008 2:54 PM > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > computers (and > > > related operating systems, SIP soft clients), analog terminal > > > adaptors, or other similar devices that are intended for use in a > > > wireline environment. I think that organizations that can drive > > > requirements for devices intended to be use in an environment where > > > SUPL would actually work, should be responsible for having device > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > absolutely > > > in a position to require SUPL support for devices that > > operate in an > > > environment where SUPL works. This is a perfect example of the > > > "closed" network that Brian describes somewhere (framework, > > I think). > > > > > > Phonebcp is about requirements for devices in access environments > > > where the operators of the access environment cannot be assumed to > > > have any control over the type or nature of devices that > > connect to or > > > through it. Phonebcp needs to continue to have that as its purpose. > > > > > > I agree that nothing in phonebcp should preclude the use of > > SUPL, or > > > be incompatible with the use of SUPL. And I don't think it does. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 2:36 PM > > > To: Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > If the choice is between preventing, allowing, or > > requiring PhoneBCP > > > suppport of SUPL, then my vote is to NOT prevent! I would prefer > > > 'require' since *most* of the location-aware 3G compatible > > > handsets/aircards over the next several years will (I > > predict) have a > > > SUPL stack included. In the same time frame, many of those > > will also > > > have WiFi support, others will have LTE or WiMAX support as hybrids. > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > open-minded, and there is movement afoot to expand OMA/SUPL (as we > > > heard in the geopriv mtg. on Tuesday) w/respect expected proposals > > > such as LocSIP, etc. Over the fairly near-term, I think > > there will be > > > fewer protocol, location representation, and privacy > > discontinuities - > > > things that too often get cited - yet are seldom well understood. > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > - not block > > > its use altogether. This is a case where we need to be > > inclusive, not > > > exclusive. > > > > > > As to the mobile RV sample case, the solution is also forseeable - > > > especially given that the location of the 3G aircard in the > > router is > > > good enough for routing. The scenario given needs some > > integration, > > > but is doable. Given that the aircard acts as a logical > > SET, with a > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > combination > > > *WILL* (I believe) interoperate with a number of end client > > > applications to initiate and complete a location-routed, 3261 style > > > SIP, emergency call through the core, and into an ESInet. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Brian Rosen > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > To: 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that the > > > > clients are generally not very L2 aware. It's the clients > > > that have > > > > the problem. > > > > You can do things like interwork an L2 specific LCP to a > > > common LCP so > > > > that non L2 aware devices can work, but you have to do that, and > > > > usually, that's impractical. Use my example. Suppose > > that the L2 > > > > used SUPL. It's possible for the PC Card that is plugged > > into the > > > > router could implement a SUPL client and a HELD server and > > > interwork > > > > SUPL in the GSM system to HELD on the Ethernet so the > > Ethernet VoIP > > > > phone could get location via HELD. Possible, but not practical. > > > > There are all sorts of these kinds of problems. That's why > > > > L2 specific LCPs don't work. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > To: Brian Rosen > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > The IETF can't (and shouldn't) try to make particular > > standards for > > > > every access technology that's out there. What we can say > > > is that the > > > > paradigm for those protocols should be the same as at the > > IP layer: > > > > Clients MUST implement all, networks MUST implement at least one. > > > > > > > > (This is a little different from the text I sent before, > > > and clearer, > > > > I > > > > think.) > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > the possible > > > > protocols at lower layers, we should just state the general > > > rule. It > > > > seems to me that this achieves the same level of > > > interoperability at > > > > all layers. > > > > > > > > --Richard > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > any number > > > > > of optional ones, then every network has to implement at > > > > least one of > > > > > those > > > > two > > > > > LCPs, and any number of optional ones. That means that > > > > "any number of > > > > > optional ones" is useless for both parties. > > > > > If the network can limit UAs to ONLY those that implement > > > > one of the > > > > > optional protocols, then it works, but in practice, it > > is usually > > > > impossible > > > > > to do that. My example is the wired, Ethernet connected > > > > phone in an > > > > > RV traveling down the road with wireless data card in a > > > > router. These > > > > > EXIST, now. > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > for an RFC to > > > > > try to list all of the location protocols out there, if for > > > > no other > > > > > reason than that it will rapidly become obsolete. Instead, > > > > we should > > > > > say something like the following: > > > > > > > > > > " > > > > > INT-12 Devices MUST support the DHCP location options > > > [RFC4776] and > > > > > [RFC3825] and HELD > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > SHOULD support all location protocols supported at lower > > > layers by > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > >> The problem with SUPL is that the majority of networks > > > where SUPL > > > > >> would > > > > be > > > > >> available have a proxy (E-CSCF) insert location. It > > also has an > > > > >> incompatible location representation, and an incompatible > > > > privacy model. > > > > >> That makes it very hard to interwork with any of the rest > > > > of the IETF > > > > > work. > > > > >> I will say this. For quite some time, the IETF has been > > > trying to > > > > > interest > > > > >> OMA into cooperation on location so that we have > > > > interoperability at > > > > >> the protocol, location representation and privacy > > > levels. So far, > > > > >> that has > > > > > not > > > > >> happened. If, as part of a comprehensive agreement to > > > accomplish > > > > >> such a goal, SUPL became one of the LCPs, I would not object. > > > > >> > > > > >> Brian > > > > >> > > > > >> -----Original Message----- > > > > >> From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > >> Hi, > > > > >> > > > > >> Is the intent to list the LCPs which are access-type > > > > agnostic but not > > > > >> supported anywhere, or instead have a list of LCPs which > > > > are highly > > > > >> probable to produce the intended result? > > > > >> > > > > >> There are restrictions everywhere, things come at a cost > > > > even in the > > > > >> general Internet model. The reality is that most of the > > > > devices with > > > > >> internet access have a home network already. > > > > >> > > > > >> - Gabor > > > > >> > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: ext Winterbottom, James > > > > [mailto:James.Winterbottom@andrew.com] > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > - FI/Espoo) > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >Hi Gabor, > > > > >> > > > > > >> >The list of LCPs in the phone BCP is a must support > > > list, and is > > > > >> access- > > > > >> >type agnostic. > > > > >> >I am curious that you say that SUPL is a MUST support > > > > given that: > > > > >> >a) it requires a home network in order to operate > > > > >> >b) it simply doesn't work for DSL or Cable > > > > >> >c) it is questionable whether it is really deployable > > > for WiFi > > > > >> networks > > > > >> > > > > > >> >Can you perhaps describe how it fits into the general > > > > Internet model? > > > > >> > > > > > >> >Cheers > > > > >> >James > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > Gabor.Bajko@nokia.com > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > >> >To: ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >I was requested to send my observations regarding this > > > > requirement: > > > > >> > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > location options > > > > >> > [RFC4776] and [RFC3825], HELD > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > LLDP-MED [LLDP-MED]. > > > > >> > > > > > >> > > > > > >> >I believe we should come up with a list of LCPs which > > > > are likely > > > > >> to be > > > > >> >supported in devices in a not so distant future. Since > > > > I have no > > > > >> seen or > > > > >> >heard about LLDP support yet, at least that should be > > > replaced > > > > >> with what > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > mechanism, with the > > > > >> >condition that this MUST only be supported if there > > is a wifi > > > > >> interface > > > > >> >available on the device. > > > > >> > > > > > >> >- Gabor > > > > >> > > > > > >> > > > > > >> > > > > > >> >________________________________ > > > > >> > > > > > >> >From: ext Tschofenig, Hannes > > > > >> > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > > > >> >Subject: Location Protocols in Phone BCP > > > > >> > > > > > >> > > > > > >> > > > > > >> >Gabor, > > > > >> > > > > > >> >Could you please raise your question about location > > > > protocols in > > > > >> Phone > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > >> > > > > > >> >Ciao > > > > >> >Hannes > > > > >> > > > > > >> > > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >This message is for the designated recipient only and may > > > > >> >contain privileged, proprietary, or otherwise private > > > > information. > > > > >> >If you have received it in error, please notify the sender > > > > >> >immediately and delete the original. Any > > unauthorized use of > > > > >> >this email is prohibited. > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >[mf2] > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may > > > be privileged and/or confidential. If you are not the intended > > > recipient, or responsible for delivering this message to > > the intended > > > recipient, any review, forwarding, dissemination, distribution or > > > copying of this communication or any attachment(s) is strictly > > > prohibited. If you have received this message in error, > > please notify > > > the sender immediately, and delete it and all attachments from your > > > computer and network. > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > > to which it is addressed and may contain confidential, proprietary, > > > and/or privileged material. Any review, retransmission, > > dissemination > > > or other use of, or taking of any action in reliance upon this > > > information by persons or entities other than the intended > > recipient > > > is prohibited. If you received this in error, please contact the > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 14:22:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD8A3A6898; Thu, 20 Nov 2008 14:22:51 -0800 (PST) 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 7715B3A6898 for ; Thu, 20 Nov 2008 14:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 CrAi0fFXhFTK for ; Thu, 20 Nov 2008 14:22:48 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 292233A677D for ; Thu, 20 Nov 2008 14:22:47 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_16_40_27 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 16:40:26 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 16:22:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 16:22:42 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQAANRXyA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" X-OriginalArrivalTime: 20 Nov 2008 22:22:46.0609 (UTC) FILETIME=[83BEAC10:01C94B5E] Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The distinction between fixed and mobile, wireline and wireless is relevant, it is old-school thinking and isn't really applicable anymore. We are talking about an Internet-based device, which can be any or all of the above, and often at the same time. I think that dissecting the networks in the manner being described below leads to a very slippery slope very quickly. Our requirements for an LCP were that it MUST be implemented by all devices, not that it MUST be implemented by all device if.... LCPs, the ones currently in Phone BCP, all provide a local service discovery technique, SUPL does not. This aspect of an LCP is important, as it puts the target device in contact with the location server responsible for determining the location of the Target in the local access network. In this way, it is possible for the device to ask for location in the same way every time, regardless of the network technology. Again, this is not true for SUPL, different access technologies require the Device and the home SLP to support new measurement types, and potentially additional "out of scope" connectivity back to the actual serving network to use this information. Don't get me wrong, SUPL has a place in providing location in some access network architectures, but it is far from ubiquitous, the aim of phone BCP is specify what MUST be supported by all devices. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Roger Marshall > Sent: Friday, 21 November 2008 8:07 AM > To: Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Isn't there a need to set the scope [text] of phonebcp, so that it makes > clear what that the requirements apply (without bias) to both fixed and > mobile end devices (and their associated network deployment types)? > > Below is some keyword sampling to show some implications with regard to > fixed vs. mobile, but which isn't as crisp as it could be (depending on > the scope). > > A search of phonebcp for the following terms yields the associated > references: > > Fixed: > (none); > > Wireline: > (none); > > Mobile: > AN-11; > ED-35/AN-19; > ED-35; > > Wireless: > AN-7/INT-6; > AN-9; > AN-7; > INT-6; > > From the toc, it is listed... > > 6.2.2. Access network "wire database" location information . 7 > 6.2.3. End-system measured location information . . . . . . . 7 > 6.2.4. Network-measured location information . . . . . . . . 8 > > -roger. > > > No mention of fixed, wireline, wireless, or mobile in any of the text > sections (Intro, etc.) > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 20, 2008 12:32 PM > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > we need to parse more carefully, SUPL isn't very suitable for > > wiremap forms of location determination. > > > > Brian > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Thursday, November 20, 2008 3:22 PM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that don't use GPS or some form of measured location. > > > > [rsm - measured only - really? - surely you aren't suggesting > > that OMA (and therefore 3GPP, 3GPP2) throw away their > > reliance on 'rough location' via CellID, are you? > > > > Wiremap location - given (manually input)] CellID location - > > given Terrestial trilateration - measured Celestial > > trilateration - measured Geocoded/reverse geocoded - derived > > > > I would hope that PhoneBCP doesn't show a pre-disposition to 'given' > > location scenarios, aka wiremap, etc. that are more Wireline > > oriented, rather than mobile. For the future, wireline > > devices reduce in number, mobile (or even nomadic) devices > > will continue in their distribution bias. Fixed vs. Mobile > > has been the fundamental difference between how the IETF > > looks at things vs. these mentioned other fora. I contend > > that if we solve this for mobile - then we can begin > > communicating better with OMA/3GPP/3GPP2, and... Solving > > fixed will be easier. > > /] > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:07 PM > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd has its own > > > version of that. > > > > > > All 3GPP networks I know of support a raw packet service. On that > > > service will run applications like MSN or AOL instant messaging. > > > Those services > > > will need to be able to make emergency chats. To route > > > properly, they need > > > location. That means that EVERY handset must deploy some LCP, and > > > must be able to get location suitable for emergency call > > routing and > > > dispatch per -phonebcp. The RV example is yet another case of the > > > same thing. The mistake is assuming that all emergency calls will > > > come through the E-CSCF. > > > They won't, and the 3GPP access network must conform to all the > > > -phonebcp requirements. > > > > > > Generally, I agree that SUPL is unsuitable for access networks that > > > don't use GPS or some form of measured location. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 20, 2008 2:54 PM > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > computers (and > > > related operating systems, SIP soft clients), analog terminal > > > adaptors, or other similar devices that are intended for use in a > > > wireline environment. I think that organizations that can drive > > > requirements for devices intended to be use in an environment where > > > SUPL would actually work, should be responsible for having device > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > absolutely > > > in a position to require SUPL support for devices that > > operate in an > > > environment where SUPL works. This is a perfect example of the > > > "closed" network that Brian describes somewhere (framework, > > I think). > > > > > > Phonebcp is about requirements for devices in access environments > > > where the operators of the access environment cannot be assumed to > > > have any control over the type or nature of devices that > > connect to or > > > through it. Phonebcp needs to continue to have that as its purpose. > > > > > > I agree that nothing in phonebcp should preclude the use of > > SUPL, or > > > be incompatible with the use of SUPL. And I don't think it does. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 2:36 PM > > > To: Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > If the choice is between preventing, allowing, or > > requiring PhoneBCP > > > suppport of SUPL, then my vote is to NOT prevent! I would prefer > > > 'require' since *most* of the location-aware 3G compatible > > > handsets/aircards over the next several years will (I > > predict) have a > > > SUPL stack included. In the same time frame, many of those > > will also > > > have WiFi support, others will have LTE or WiMAX support as hybrids. > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > open-minded, and there is movement afoot to expand OMA/SUPL (as we > > > heard in the geopriv mtg. on Tuesday) w/respect expected proposals > > > such as LocSIP, etc. Over the fairly near-term, I think > > there will be > > > fewer protocol, location representation, and privacy > > discontinuities - > > > things that too often get cited - yet are seldom well understood. > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > - not block > > > its use altogether. This is a case where we need to be > > inclusive, not > > > exclusive. > > > > > > As to the mobile RV sample case, the solution is also forseeable - > > > especially given that the location of the 3G aircard in the > > router is > > > good enough for routing. The scenario given needs some > > integration, > > > but is doable. Given that the aircard acts as a logical > > SET, with a > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > combination > > > *WILL* (I believe) interoperate with a number of end client > > > applications to initiate and complete a location-routed, 3261 style > > > SIP, emergency call through the core, and into an ESInet. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Brian Rosen > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > To: 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that the > > > > clients are generally not very L2 aware. It's the clients > > > that have > > > > the problem. > > > > You can do things like interwork an L2 specific LCP to a > > > common LCP so > > > > that non L2 aware devices can work, but you have to do that, and > > > > usually, that's impractical. Use my example. Suppose > > that the L2 > > > > used SUPL. It's possible for the PC Card that is plugged > > into the > > > > router could implement a SUPL client and a HELD server and > > > interwork > > > > SUPL in the GSM system to HELD on the Ethernet so the > > Ethernet VoIP > > > > phone could get location via HELD. Possible, but not practical. > > > > There are all sorts of these kinds of problems. That's why > > > > L2 specific LCPs don't work. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > To: Brian Rosen > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > ecrit@ietf.org; marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > The IETF can't (and shouldn't) try to make particular > > standards for > > > > every access technology that's out there. What we can say > > > is that the > > > > paradigm for those protocols should be the same as at the > > IP layer: > > > > Clients MUST implement all, networks MUST implement at least one. > > > > > > > > (This is a little different from the text I sent before, > > > and clearer, > > > > I > > > > think.) > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > the possible > > > > protocols at lower layers, we should just state the general > > > rule. It > > > > seems to me that this achieves the same level of > > > interoperability at > > > > all layers. > > > > > > > > --Richard > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > any number > > > > > of optional ones, then every network has to implement at > > > > least one of > > > > > those > > > > two > > > > > LCPs, and any number of optional ones. That means that > > > > "any number of > > > > > optional ones" is useless for both parties. > > > > > If the network can limit UAs to ONLY those that implement > > > > one of the > > > > > optional protocols, then it works, but in practice, it > > is usually > > > > impossible > > > > > to do that. My example is the wired, Ethernet connected > > > > phone in an > > > > > RV traveling down the road with wireless data card in a > > > > router. These > > > > > EXIST, now. > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > for an RFC to > > > > > try to list all of the location protocols out there, if for > > > > no other > > > > > reason than that it will rapidly become obsolete. Instead, > > > > we should > > > > > say something like the following: > > > > > > > > > > " > > > > > INT-12 Devices MUST support the DHCP location options > > > [RFC4776] and > > > > > [RFC3825] and HELD > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > SHOULD support all location protocols supported at lower > > > layers by > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > >> The problem with SUPL is that the majority of networks > > > where SUPL > > > > >> would > > > > be > > > > >> available have a proxy (E-CSCF) insert location. It > > also has an > > > > >> incompatible location representation, and an incompatible > > > > privacy model. > > > > >> That makes it very hard to interwork with any of the rest > > > > of the IETF > > > > > work. > > > > >> I will say this. For quite some time, the IETF has been > > > trying to > > > > > interest > > > > >> OMA into cooperation on location so that we have > > > > interoperability at > > > > >> the protocol, location representation and privacy > > > levels. So far, > > > > >> that has > > > > > not > > > > >> happened. If, as part of a comprehensive agreement to > > > accomplish > > > > >> such a goal, SUPL became one of the LCPs, I would not object. > > > > >> > > > > >> Brian > > > > >> > > > > >> -----Original Message----- > > > > >> From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > >> Hi, > > > > >> > > > > >> Is the intent to list the LCPs which are access-type > > > > agnostic but not > > > > >> supported anywhere, or instead have a list of LCPs which > > > > are highly > > > > >> probable to produce the intended result? > > > > >> > > > > >> There are restrictions everywhere, things come at a cost > > > > even in the > > > > >> general Internet model. The reality is that most of the > > > > devices with > > > > >> internet access have a home network already. > > > > >> > > > > >> - Gabor > > > > >> > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: ext Winterbottom, James > > > > [mailto:James.Winterbottom@andrew.com] > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > - FI/Espoo) > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >Hi Gabor, > > > > >> > > > > > >> >The list of LCPs in the phone BCP is a must support > > > list, and is > > > > >> access- > > > > >> >type agnostic. > > > > >> >I am curious that you say that SUPL is a MUST support > > > > given that: > > > > >> >a) it requires a home network in order to operate > > > > >> >b) it simply doesn't work for DSL or Cable > > > > >> >c) it is questionable whether it is really deployable > > > for WiFi > > > > >> networks > > > > >> > > > > > >> >Can you perhaps describe how it fits into the general > > > > Internet model? > > > > >> > > > > > >> >Cheers > > > > >> >James > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > Gabor.Bajko@nokia.com > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > >> >To: ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >I was requested to send my observations regarding this > > > > requirement: > > > > >> > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > location options > > > > >> > [RFC4776] and [RFC3825], HELD > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > LLDP-MED [LLDP-MED]. > > > > >> > > > > > >> > > > > > >> >I believe we should come up with a list of LCPs which > > > > are likely > > > > >> to be > > > > >> >supported in devices in a not so distant future. Since > > > > I have no > > > > >> seen or > > > > >> >heard about LLDP support yet, at least that should be > > > replaced > > > > >> with what > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > mechanism, with the > > > > >> >condition that this MUST only be supported if there > > is a wifi > > > > >> interface > > > > >> >available on the device. > > > > >> > > > > > >> >- Gabor > > > > >> > > > > > >> > > > > > >> > > > > > >> >________________________________ > > > > >> > > > > > >> >From: ext Tschofenig, Hannes > > > > >> > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > > > >> >Subject: Location Protocols in Phone BCP > > > > >> > > > > > >> > > > > > >> > > > > > >> >Gabor, > > > > >> > > > > > >> >Could you please raise your question about location > > > > protocols in > > > > >> Phone > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > >> > > > > > >> >Ciao > > > > >> >Hannes > > > > >> > > > > > >> > > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >This message is for the designated recipient only and may > > > > >> >contain privileged, proprietary, or otherwise private > > > > information. > > > > >> >If you have received it in error, please notify the sender > > > > >> >immediately and delete the original. Any > > unauthorized use of > > > > >> >this email is prohibited. > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >[mf2] > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may > > > be privileged and/or confidential. If you are not the intended > > > recipient, or responsible for delivering this message to > > the intended > > > recipient, any review, forwarding, dissemination, distribution or > > > copying of this communication or any attachment(s) is strictly > > > prohibited. If you have received this message in error, > > please notify > > > the sender immediately, and delete it and all attachments from your > > > computer and network. > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > > to which it is addressed and may contain confidential, proprietary, > > > and/or privileged material. Any review, retransmission, > > dissemination > > > or other use of, or taking of any action in reliance upon this > > > information by persons or entities other than the intended > > recipient > > > is prohibited. If you received this in error, please contact the > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 14:33:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D0F3A6A1A; Thu, 20 Nov 2008 14:33:14 -0800 (PST) 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 90EE43A6A01 for ; Thu, 20 Nov 2008 14:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BHmHUQxWW3K1 for ; Thu, 20 Nov 2008 14:33:11 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 470EC3A6806 for ; Thu, 20 Nov 2008 14:33:11 -0800 (PST) Received: from [128.89.255.112] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L3I56-0004ik-Dk; Thu, 20 Nov 2008 17:33:00 -0500 Message-ID: <4925E59B.7020500@bbn.com> Date: Thu, 20 Nov 2008 16:32:59 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Winterbottom, James" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, ecrit@ietf.org, hannes.tschofenig@nsn.com Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think James is saying about what I was before: Phonebcp just needs to distinguish Internet vs. non-Internet LCPs (not fixed vs mobile, etc). In the former class are HELD and DHCP location; in the latter, everything else. The EAN1 principle applies in both cases, but in the non-Internet case, is conditioned on the endpoint actually having the capability (in terms of hardware and network) to use the LCP. --Richard Winterbottom, James wrote: > The distinction between fixed and mobile, wireline and wireless is > relevant, it is old-school thinking and isn't really applicable anymore. > We are talking about an Internet-based device, which can be any or all > of the above, and often at the same time. > > I think that dissecting the networks in the manner being described below > leads to a very slippery slope very quickly. > > Our requirements for an LCP were that it MUST be implemented by all > devices, not that it MUST be implemented by all device if.... > > LCPs, the ones currently in Phone BCP, all provide a local service > discovery technique, SUPL does not. This aspect of an LCP is important, > as it puts the target device in contact with the location server > responsible for determining the location of the Target in the local > access network. In this way, it is possible for the device to ask for > location in the same way every time, regardless of the network > technology. Again, this is not true for SUPL, different access > technologies require the Device and the home SLP to support new > measurement types, and potentially additional "out of scope" > connectivity back to the actual serving network to use this information. > > Don't get me wrong, SUPL has a place in providing location in some > access network architectures, but it is far from ubiquitous, the aim of > phone BCP is specify what MUST be supported by all devices. > > > Cheers > James > > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of >> Roger Marshall >> Sent: Friday, 21 November 2008 8:07 AM >> To: Brian Rosen; Stark, Barbara; Richard Barnes >> Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >> marc.linsner@cisco.com; ecrit@ietf.org >> Subject: Re: [Ecrit] Location Protocols in Phone BCP >> >> Isn't there a need to set the scope [text] of phonebcp, so that it > makes >> clear what that the requirements apply (without bias) to both fixed > and >> mobile end devices (and their associated network deployment types)? >> >> Below is some keyword sampling to show some implications with regard > to >> fixed vs. mobile, but which isn't as crisp as it could be (depending > on >> the scope). >> >> A search of phonebcp for the following terms yields the associated >> references: >> >> Fixed: >> (none); >> >> Wireline: >> (none); >> >> Mobile: >> AN-11; >> ED-35/AN-19; >> ED-35; >> >> Wireless: >> AN-7/INT-6; >> AN-9; >> AN-7; >> INT-6; >> >> From the toc, it is listed... >> >> 6.2.2. Access network "wire database" location information . > 7 >> 6.2.3. End-system measured location information . . . . . . . > 7 >> 6.2.4. Network-measured location information . . . . . . . . > 8 >> -roger. >> >> >> No mention of fixed, wireline, wireless, or mobile in any of the text >> sections (Intro, etc.) >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Thursday, November 20, 2008 12:32 PM >>> To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' >>> Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; >>> hannes.tschofenig@nsn.com; ecrit@ietf.org >>> Subject: RE: [Ecrit] Location Protocols in Phone BCP >>> >>> Phonebcp doesn't have a pre-disposition. It's neutral. If >>> we need to parse more carefully, SUPL isn't very suitable for >>> wiremap forms of location determination. >>> >>> Brian >>> >>> -----Original Message----- >>> From: Roger Marshall [mailto:RMarshall@telecomsys.com] >>> Sent: Thursday, November 20, 2008 3:22 PM >>> To: Brian Rosen; Stark, Barbara; Richard Barnes >>> Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; >>> hannes.tschofenig@nsn.com; ecrit@ietf.org >>> Subject: RE: [Ecrit] Location Protocols in Phone BCP >>> >>> > Generally, I agree that SUPL is unsuitable for access >>>> networks that don't use GPS or some form of measured location. >>> [rsm - measured only - really? - surely you aren't suggesting >>> that OMA (and therefore 3GPP, 3GPP2) throw away their >>> reliance on 'rough location' via CellID, are you? >>> >>> Wiremap location - given (manually input)] CellID location - >>> given Terrestial trilateration - measured Celestial >>> trilateration - measured Geocoded/reverse geocoded - derived >>> >>> I would hope that PhoneBCP doesn't show a pre-disposition to 'given' >>> location scenarios, aka wiremap, etc. that are more Wireline >>> oriented, rather than mobile. For the future, wireline >>> devices reduce in number, mobile (or even nomadic) devices >>> will continue in their distribution bias. Fixed vs. Mobile >>> has been the fundamental difference between how the IETF >>> looks at things vs. these mentioned other fora. I contend >>> that if we solve this for mobile - then we can begin >>> communicating better with OMA/3GPP/3GPP2, and... Solving >>> fixed will be easier. >>> /] >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Thursday, November 20, 2008 12:07 PM >>>> To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' >>>> Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; >>>> hannes.tschofenig@nsn.com; ecrit@ietf.org >>>> Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>> >>>> Gabor accuses us of ignoring reality. The 3GPP crowd has its own >>>> version of that. >>>> >>>> All 3GPP networks I know of support a raw packet service. On that >>>> service will run applications like MSN or AOL instant messaging. >>>> Those services >>>> will need to be able to make emergency chats. To route >>>> properly, they need >>>> location. That means that EVERY handset must deploy some LCP, and >>>> must be able to get location suitable for emergency call >>> routing and >>>> dispatch per -phonebcp. The RV example is yet another case of the >>>> same thing. The mistake is assuming that all emergency calls will >>>> come through the E-CSCF. >>>> They won't, and the 3GPP access network must conform to all the >>>> -phonebcp requirements. >>>> >>>> Generally, I agree that SUPL is unsuitable for access networks > that >>>> don't use GPS or some form of measured location. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Stark, Barbara [mailto:bs7652@att.com] >>>> Sent: Thursday, November 20, 2008 2:54 PM >>>> To: Roger Marshall; Brian Rosen; Richard Barnes >>>> Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; >>>> hannes.tschofenig@nsn.com; ecrit@ietf.org >>>> Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>> >>>> I cannot support requiring SUPL in DSL routers, desktop >>> computers (and >>>> related operating systems, SIP soft clients), analog terminal >>>> adaptors, or other similar devices that are intended for use in a >>>> wireline environment. I think that organizations that can drive >>>> requirements for devices intended to be use in an environment > where >>>> SUPL would actually work, should be responsible for having device >>>> requirements requiring SUPL. In other words, 3GPP/3GPP2 are >>> absolutely >>>> in a position to require SUPL support for devices that >>> operate in an >>>> environment where SUPL works. This is a perfect example of the >>>> "closed" network that Brian describes somewhere (framework, >>> I think). >>>> Phonebcp is about requirements for devices in access environments >>>> where the operators of the access environment cannot be assumed to >>>> have any control over the type or nature of devices that >>> connect to or >>>> through it. Phonebcp needs to continue to have that as its > purpose. >>>> I agree that nothing in phonebcp should preclude the use of >>> SUPL, or >>>> be incompatible with the use of SUPL. And I don't think it does. >>>> Barbara >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Roger Marshall >>>> Sent: Thursday, November 20, 2008 2:36 PM >>>> To: Brian Rosen; Richard Barnes >>>> Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; >>>> hannes.tschofenig@nsn.com; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>> >>>> >>>> If the choice is between preventing, allowing, or >>> requiring PhoneBCP >>>> suppport of SUPL, then my vote is to NOT prevent! I would prefer >>>> 'require' since *most* of the location-aware 3G compatible >>>> handsets/aircards over the next several years will (I >>> predict) have a >>>> SUPL stack included. In the same time frame, many of those >>> will also >>>> have WiFi support, others will have LTE or WiMAX support as > hybrids. >>>> SUPL will be common-place. OMA may not be 'Open-Source', it is >>>> open-minded, and there is movement afoot to expand OMA/SUPL (as we >>>> heard in the geopriv mtg. on Tuesday) w/respect expected proposals >>>> such as LocSIP, etc. Over the fairly near-term, I think >>> there will be >>>> fewer protocol, location representation, and privacy >>> discontinuities - >>>> things that too often get cited - yet are seldom well understood. >>>> >>>> Let's encourage continued IETF communication with OMA/SUPL >>> - not block >>>> its use altogether. This is a case where we need to be >>> inclusive, not >>>> exclusive. >>>> >>>> As to the mobile RV sample case, the solution is also forseeable - >>>> especially given that the location of the 3G aircard in the >>> router is >>>> good enough for routing. The scenario given needs some >>> integration, >>>> but is doable. Given that the aircard acts as a logical >>> SET, with a >>>> SUPL stack on board, and a GPS/AGPS chipset inside. This >>> combination >>>> *WILL* (I believe) interoperate with a number of end client >>>> applications to initiate and complete a location-routed, 3261 > style >>>> SIP, emergency call through the core, and into an ESInet. >>>> >>>> -roger. >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On Behalf >>>>> Of Brian Rosen >>>>> Sent: Thursday, November 20, 2008 8:23 AM >>>>> To: 'Richard Barnes' >>>>> Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; >>>>> marc.linsner@cisco.com; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>> >>>>> It's very hard to have L2 specific LCPs. The problem is that > the >>>>> clients are generally not very L2 aware. It's the clients >>>> that have >>>>> the problem. >>>>> You can do things like interwork an L2 specific LCP to a >>>> common LCP so >>>>> that non L2 aware devices can work, but you have to do that, and >>>>> usually, that's impractical. Use my example. Suppose >>> that the L2 >>>>> used SUPL. It's possible for the PC Card that is plugged >>> into the >>>>> router could implement a SUPL client and a HELD server and >>>> interwork >>>>> SUPL in the GSM system to HELD on the Ethernet so the >>> Ethernet VoIP >>>>> phone could get location via HELD. Possible, but not practical. >>>>> There are all sorts of these kinds of problems. That's why >>>>> L2 specific LCPs don't work. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Thursday, November 20, 2008 11:11 AM >>>>> To: Brian Rosen >>>>> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>>>> ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com >>>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>> >>>>> The IETF can't (and shouldn't) try to make particular >>> standards for >>>>> every access technology that's out there. What we can say >>>> is that the >>>>> paradigm for those protocols should be the same as at the >>> IP layer: >>>>> Clients MUST implement all, networks MUST implement at least > one. >>>>> (This is a little different from the text I sent before, >>>> and clearer, >>>>> I >>>>> think.) >>>>> >>>>> All I'm saying is that we shouldn't try to enumerate all >>>> the possible >>>>> protocols at lower layers, we should just state the general >>>> rule. It >>>>> seems to me that this achieves the same level of >>>> interoperability at >>>>> all layers. >>>>> >>>>> --Richard >>>>> >>>>>> If there are exactly two LCPs all UAs must implement, and >>>>> any number >>>>>> of optional ones, then every network has to implement at >>>>> least one of >>>>>> those >>>>> two >>>>>> LCPs, and any number of optional ones. That means that >>>>> "any number of >>>>>> optional ones" is useless for both parties. >>>>>> If the network can limit UAs to ONLY those that implement >>>>> one of the >>>>>> optional protocols, then it works, but in practice, it >>> is usually >>>>> impossible >>>>>> to do that. My example is the wired, Ethernet connected >>>>> phone in an >>>>>> RV traveling down the road with wireless data card in a >>>>> router. These >>>>>> EXIST, now. >>>>>> >>>>>> Brian >>>>>> -----Original Message----- >>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>> Sent: Thursday, November 20, 2008 10:11 AM >>>>>> To: Brian Rosen >>>>>> Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; >>>>>> ecrit@ietf.org; marc.linsner@cisco.com; >>> hannes.tschofenig@nsn.com >>>>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>>> >>>>>> I think we need to pull up a level. It's not reasonable >>>>> for an RFC to >>>>>> try to list all of the location protocols out there, if for >>>>> no other >>>>>> reason than that it will rapidly become obsolete. Instead, >>>>> we should >>>>>> say something like the following: >>>>>> >>>>>> " >>>>>> INT-12 Devices MUST support the DHCP location options >>>> [RFC4776] and >>>>>> [RFC3825] and HELD >>>>> [I-D.ietf-geopriv-http-location-delivery]. Devices >>>>>> SHOULD support all location protocols supported at lower >>>> layers by >>>>>> their interfaces (e.g., LLDP-MED [LLDP-MED]). >>>>>> " >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Brian Rosen wrote: >>>>>>> The problem with SUPL is that the majority of networks >>>> where SUPL >>>>>>> would >>>>> be >>>>>>> available have a proxy (E-CSCF) insert location. It >>> also has an >>>>>>> incompatible location representation, and an incompatible >>>>> privacy model. >>>>>>> That makes it very hard to interwork with any of the rest >>>>> of the IETF >>>>>> work. >>>>>>> I will say this. For quite some time, the IETF has been >>>> trying to >>>>>> interest >>>>>>> OMA into cooperation on location so that we have >>>>> interoperability at >>>>>>> the protocol, location representation and privacy >>>> levels. So far, >>>>>>> that has >>>>>> not >>>>>>> happened. If, as part of a comprehensive agreement to >>>> accomplish >>>>>>> such a goal, SUPL became one of the LCPs, I would not object. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of Gabor.Bajko@nokia.com >>>>>>> Sent: Thursday, November 20, 2008 9:26 AM >>>>>>> To: James.Winterbottom@andrew.com; ecrit@ietf.org >>>>>>> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com >>>>>>> Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Is the intent to list the LCPs which are access-type >>>>> agnostic but not >>>>>>> supported anywhere, or instead have a list of LCPs which >>>>> are highly >>>>>>> probable to produce the intended result? >>>>>>> >>>>>>> There are restrictions everywhere, things come at a cost >>>>> even in the >>>>>>> general Internet model. The reality is that most of the >>>>> devices with >>>>>>> internet access have a home network already. >>>>>>> >>>>>>> - Gabor >>>>>>> >>>>>>> >>>>>>> >-----Original Message----- >>>>>>> >From: ext Winterbottom, James >>>>> [mailto:James.Winterbottom@andrew.com] >>>>>>> >Sent: Thursday, November 20, 2008 12:06 AM >>>>>>> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org >>>>>>> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN >>> - FI/Espoo) >>>>>>> >Subject: RE: [Ecrit] Location Protocols in Phone BCP >>>>>>> > >>>>>>> >Hi Gabor, >>>>>>> > >>>>>>> >The list of LCPs in the phone BCP is a must support >>>> list, and is >>>>>>> access- >>>>>>> >type agnostic. >>>>>>> >I am curious that you say that SUPL is a MUST support >>>>> given that: >>>>>>> >a) it requires a home network in order to operate >>>>>>> >b) it simply doesn't work for DSL or Cable >>>>>>> >c) it is questionable whether it is really deployable >>>> for WiFi >>>>>>> networks >>>>>>> > >>>>>>> >Can you perhaps describe how it fits into the general >>>>> Internet model? >>>>>>> > >>>>>>> >Cheers >>>>>>> >James >>>>>>> > >>>>>>> > >>>>>>> >-----Original Message----- >>>>>>> >From: ecrit-bounces@ietf.org on behalf of >>>> Gabor.Bajko@nokia.com >>>>>>> >Sent: Thu 11/20/2008 12:48 AM >>>>>>> >To: ecrit@ietf.org >>>>>>> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com >>>>>>> >Subject: Re: [Ecrit] Location Protocols in Phone BCP >>>>>>> > >>>>>>> >I was requested to send my observations regarding this >>>>> requirement: >>>>>>> > >>>>>>> > ED-21/INT-12 Devices MUST support all of: DHCP >>>>> location options >>>>>>> > [RFC4776] and [RFC3825], HELD >>>>>>> > [I-D.ietf-geopriv-http-location-delivery] and >>>>> LLDP-MED [LLDP-MED]. >>>>>>> > >>>>>>> > >>>>>>> >I believe we should come up with a list of LCPs which >>>>> are likely >>>>>>> to be >>>>>>> >supported in devices in a not so distant future. Since >>>>> I have no >>>>>>> seen or >>>>>>> >heard about LLDP support yet, at least that should be >>>> replaced >>>>>>> with what >>>>>>> >is mostly used today (OMA SUPL) and the 802.11 >>>>> mechanism, with the >>>>>>> >condition that this MUST only be supported if there >>> is a wifi >>>>>>> interface >>>>>>> >available on the device. >>>>>>> > >>>>>>> >- Gabor >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >________________________________ >>>>>>> > >>>>>>> >From: ext Tschofenig, Hannes >>>>>>> > >>>>>>> >Sent: Tuesday, November 18, 2008 12:49 PM >>>>>>> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com >>>>>>> >Subject: Location Protocols in Phone BCP >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >Gabor, >>>>>>> > >>>>>>> >Could you please raise your question about location >>>>> protocols in >>>>>>> Phone >>>>>>> >BCP mentioned at ESW5 in the ECRIT WG session again? >>>>>>> > >>>>>>> >Ciao >>>>>>> >Hannes >>>>>>> > >>>>>>> > >>>>>>> >>> -------------------------------------------------------------------- >>>>>>>> --- >>>>>>> -- >>>>>>> >----------------------- >>>>>>> >This message is for the designated recipient only and may >>>>>>> >contain privileged, proprietary, or otherwise private >>>>> information. >>>>>>> >If you have received it in error, please notify the sender >>>>>>> >immediately and delete the original. Any >>> unauthorized use of >>>>>>> >this email is prohibited. >>>>>>> >>> -------------------------------------------------------------------- >>>>>>>> --- >>>>>>> -- >>>>>>> >----------------------- >>>>>>> >[mf2] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> CONFIDENTIALITY NOTICE: The information contained in this >>> message may >>>> be privileged and/or confidential. If you are not the intended >>>> recipient, or responsible for delivering this message to >>> the intended >>>> recipient, any review, forwarding, dissemination, distribution or >>>> copying of this communication or any attachment(s) is strictly >>>> prohibited. If you have received this message in error, >>> please notify >>>> the sender immediately, and delete it and all attachments from > your >>>> computer and network. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> ***** >>>> >>>> The information transmitted is intended only for the person >>> or entity >>>> to which it is addressed and may contain confidential, > proprietary, >>>> and/or privileged material. Any review, retransmission, >>> dissemination >>>> or other use of, or taking of any action in reliance upon this >>>> information by persons or entities other than the intended >>> recipient >>>> is prohibited. If you received this in error, please contact the >>>> sender and delete the material from all computers. GA621 >>>> >>>> >>>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 14:34:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E21B3A6A01; Thu, 20 Nov 2008 14:34:54 -0800 (PST) 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 C68B63A6A01 for ; Thu, 20 Nov 2008 14:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 EiLvyonpSijG for ; Thu, 20 Nov 2008 14:34:51 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 43BFC3A677D for ; Thu, 20 Nov 2008 14:34:50 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mAKMYjcs008729; Thu, 20 Nov 2008 16:34:45 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 16:34:44 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 23:34:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 23:34:40 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918002513271@DEEXC1U01.de.lucent.com> In-Reply-To: <015301c94b2b$60155ee0$20401ca0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 Thread-Index: AclLKUkpF0vf9MMORIuko725aI68oAAASrzQAA0GeJA= References: <7D096A439A3D0D48A3D10872022CFD090359D22F@ILEXC1U02.ndc.lucent.com> <015301c94b2b$60155ee0$20401ca0$@net> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Janet P Gunn" , "GOLDMAN, STUART O \(STUART\)" X-OriginalArrivalTime: 20 Nov 2008 22:34:42.0010 (UTC) FILETIME=[2E2833A0:01C94B60] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Ecrit@ietf.org Subject: Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org 1) Remember that the relationship between namespaces is entirely up to the = agreements with the network operator. So referring to something as required= to be higher priority is invalid for two reasons: - the standards simply will not cover this - priority is not simply a matter of servicing all messages in one namespac= e before another. There may be undertakings to process a certain number of = such messages from any namespace within any time period, or any of a host o= f other conditions. Look at it more as a way of dividing the traffic into s= eparate queues where the queues are serviced by an algorithm which is not s= tandardised but is based on agreements made with the namespace owner. That = does not prevent certain namespaces being addressed before anything else. Certainly with emergency calls, it is common that the traffic can be handle= d separately, but I believe it is rare that emergency calls take total prio= rity over even normal traffic. I do agree that callbacks need to be handled separately from citizen to aut= hority calls. I would also suggest that if a call has reached an answer poi= nt and is now being redirected to a first responder, that is yet another cl= assification (if such traffic appears on a common network). To distinguish = them the appropriate way to to this is to give them different namespaces. The immediate need in my view is to address the citizen to authority case. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = > On Behalf Of Brian Rosen > Sent: Thursday, November 20, 2008 4:17 PM > To: 'Janet P Gunn'; GOLDMAN, STUART O (STUART) > Cc: Ecrit@ietf.org > Subject: Re: [Ecrit] Ecrit] = > draft-ietf-ecrit-local-emergency-rph-namespace-00 > = > A suggestion was made to me that we should define two namespaces. > = > One would be used in public networks, and generally would be = > used to request resource priority for citizen to authority = > and possibly authority to citizen calls. This would have = > lower priority than ETS/WPS. > = > The other would be for use within emergency services IP = > networks. It would be unlikely that ETS/WPS would be used = > within those networks, but if it was, some values within the = > namespace would need higher priority that ETS/WPS. > For example, a message which was an incident commanders = > "evacuate" message would be higher than a ETS/WPS traffic. = > On the other hand, a citizen to authority emergency call = > would have lower priority. > = > I would be happier with one namespace and more values in that = > namespace for all of this, but I was advised that two = > namespaces was a better choice. > = > Brian > = > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = > On Behalf Of Janet P Gunn > Sent: Thursday, November 20, 2008 11:00 AM > To: GOLDMAN, STUART O (STUART) > Cc: Ecrit@ietf.org > Subject: Re: [Ecrit] Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > = > = > Stu, = > = > I intended to say that the esnet namespace needs to be at a = > LOWER priority > =A0than the ets and wps namespaces, in any network that = > recognizes ets and wps as described in 10.5 and 10.6 of RFC4412. = > = > Janet = > = > "GOLDMAN, STUART O \(STUART\)" wrote on > 11/20/2008 10:22:49 AM: > = > > Janet, > > =A0 = > > With regard to you e-mail below, did you intend that esnet = > could be at = > > the same level of priority as ETS & WPS, =A0or that ETS & WPS = > need to be = > > at an even higher priority than esnet? > > =A0 = > > =A0 = > > =A0 = > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. = > > =A0 = > > =A0 = > > =A0 = > > = > > Janet P Gunn/FED/CSC@CSC > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 11:45 PM > > = > > =A0 = > > = > > To > > = > > "James M. Polk" > > = > > cc > > = > > "'ECRIT'" , ecrit-bounces@ietf.org > > = > > Subject > > = > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > = > > = > > =A0 = > > =A0 = > > = > > =A0 = > > = > > =A0 = > > = > > = > > = > > = > > = > > = > > I apologize for not tracking this as closely as I meant to, = > as these = > > comments apply to =A0earlier versions as well. > > = > > = > > This sentence at the end of sec 1 doesn't quite work. = > > "This document IANA registers the "esnet" = > > =A0RPH namespace for use within emergency services networks, not just > > =A0of those from citizens to PSAPs." (no clear antecedent for "those") > > = > > Perhaps > > "This document IANA registers the "esnet" = > > =A0RPH namespace for use within emergency services networks, not just = > > for calls or sessions > > =A0 from citizens to PSAPs." = > > = > > Section 2 says > > "This document updates the behaviors of the SIP Resource Priority > > =A0header, defined in [RFC4412], during the treatment options > > =A0surrounding this new "esnet" namespace only. The usage of the > > =A0"esnet" namespace does not have a normal, or routine call level. > > =A0Every use of this namespace will be in times of an emergency, where > > =A0at least one end of the signaling is with a local emergency > > =A0organization." = > > = > > I don't see this as an "update of the behavior of 4412". =A0 > Neither the = > > ets namespace not the wps namespace have a "normal" or = > "routine" call = > > level. =A0Every use of the wps and ets namespaces will have priority = > > over calls without RPH. > > = > > You say "This > > =A0namespace, therefore, MAY be overwritten or deleted, = > contrary to the > > =A0rules of RFC 4412 [RFC4412]." = > > = > > It is not clear to me why this is "contrary to the rules of = > 4412". It = > > is certainly anticipated that other RPH will be overwritten or = > > deleted, when the UAS understands the namespace. > > = > > 4412 says "Existing implementations of RFC 3261 that do not = > > participate in > the > > =A0resource priority mechanism follow the normal rules of RFC 3261, > > =A0Section 8.2.2: "If a UAS does not understand a header field in a > > =A0request (that is, the header field is not defined in this > > =A0specification or in any supported extension), the server = > MUST ignore > > =A0that header field and continue processing the message". " = > > = > > But I do not see anywhere that is says that a UAS that DOES = > understand = > > the namespace is forbidden from deleting it. =A0For instance, = > sec 4.7.1 = > > of 4412 says that "the UAC > > =A0MAY attempt a subsequent request with the same or = > different resource > > =A0value." =A0This certainly implies the ability to overwrite = > or delete an = > > RPH namespace. > > = > > (See also, for instance the PTSC SAC document on the use of the ets = > > and wps namespaces) > > = > > Immediately following these statements, you give 3 options- "These = > > proxies in the service provider > > =A0MAY either > > = > > =A0o =A0accept the existing RPH value with "esnet" in it, if one is > > =A0 =A0 present, and grant relative preferential treatment to = > the request > > =A0 =A0 when forwarding it to the ESINet. = > > = > > =A0o =A0replace any existing RPH value, if one is present, and insert an > > =A0 =A0 "esnet" namespace and give relative preferential = > treatment to the > > =A0 =A0 request when forwarding it to the ESINet. = > > = > > =A0o =A0insert an "esnet" namespace in a new RPH and give relative > > =A0 =A0 preferential treatment to the request when forwarding the SIP > > =A0 =A0 request towards the ESINet." = > > = > > Why do you exclude the possibility of adding the esnet RPH value = > > without "replacing" an existing RPH value? > > = > > Finally, there is another point that =A0needs to be made clear. =A0At = > > least one person has contacted me expressing concern that this ID = > > implied that the esnet namespace would =A0have priority over other = > > namespaces (in particular wps and ets). =A0I assured him that = > this was = > > not the case, that there was nothing prevent the expected = > behavior - = > > that the ets and wps namespaces would be prioritized ahead = > of esnet in = > > GETS Service Provider networks. > > = > > However, since the question has already arisen, it would be a good = > > idea to clarify =A0this, perhaps in =A0section 3, where you = > discuss =A0the = > > other namespaces. =A0In particular, it needs to be made clear = > in section = > > 3.2 =A0that, even if =A0"the =A0 local jurisdiction preferred to preemp= t = > > normal calls in lieu of > > =A0completing emergency calls. ", esnet calls will NOT preempt wps or = > > ets > calls. > > = > > By the way, I think you mean "the =A0 local jurisdiction preferred to = > > preempt normal calls in order to complete emergency calls. " =A0- not = > > "in lieu of". =A0Or perhaps "the =A0 local jurisdiction preferred to = > > preempt normal calls in lieu of =A0dropping emergency calls. " > > = > > In fact, it is not clear to me that 4412 permits a call with an RPH = > > (e.g., esnet) =A0to preempt a "normal" call (with no RPH namespace). > > Section 4.7.2.1 of 4412 says > > "4.7.2.1. =A0User Agent Servers and Preemption Algorithm > > = > > =A0A UAS compliant with this specification MUST terminate a session > > =A0established with a valid namespace and lower-priority = > value in favor > > =A0of a new session set up with a valid namespace and higher relative > > =A0priority value, unless local policy has some form of call-waiting > > =A0capability enabled. " = > > = > > It doesn't say anything about preempting a call with no RPH > > = > > Thanks > > = > > Janet > > = > > = > > = > > = > > = > > = > > This is a PRIVATE message. If you are not the intended recipient, = > > please delete without copying and kindly advise us by e-mail of the = > > mistake in delivery. > > NOTE: Regardless of content, this e-mail shall not operate = > to bind CSC = > > to any order or other contract unless pursuant to explicit written = > > agreement or government initiative expressly permitting the use of = > > e-mail for such purpose. > > = > > "James M. Polk" > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 08:32 PM > > = > > =A0 = > > =A0 = > > = > > To > > = > > "'ECRIT'" > > = > > cc > > = > > =A0 = > > = > > Subject > > = > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > = > > = > > =A0 = > > =A0 = > > = > > =A0 = > > = > > =A0 = > > = > > = > > = > > = > > = > > = > > ECRIT WG > > = > > Here is a update to a ID I think is pretty near done, given = > that this = > > is merely an IANA registration ID of an existing mechanism. > > = > > Comments are wanted > > = > > >A New Internet-Draft is available from the on-line Internet-Drafts = > > >directories. > > >This draft is a work item of the Emergency Context Resolution with = > > >Internet Technologies Working Group of the IETF. > > > > > > > > > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : IANA Registering a SIP Re= source = > Priority = > > > Header Namespace for Local Emergency Communications > > > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Polk > > > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: = > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9 > > > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2008-10-27 > > > > > >This document creates and IANA registers the new Session = > Initiation = > > >Protocol (SIP) Resource Priority header (RPH) namespace = > "esnet" for = > > >local emergency usage to a public safety answering point (PSAP), = > > >between PSAPs, and between a PSAP and first responders and their = > > >organizations. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > = > > _______________________________________________ > > 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 > > =A0 = > > =A0 = > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. = > > =A0 = > > =A0 = > > =A0 > = > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Nov 20 14:59:39 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEB53A68F1; Thu, 20 Nov 2008 14:59:39 -0800 (PST) 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 49A693A68F1 for ; Thu, 20 Nov 2008 14:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzwXLEXuA-vp for ; Thu, 20 Nov 2008 14:59:36 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DAB073A67F0 for ; Thu, 20 Nov 2008 14:59:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28567952" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2008 22:59:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAKMxYT0008151; Thu, 20 Nov 2008 17:59:34 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKMxYCS002105; Thu, 20 Nov 2008 22:59:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 17:59:33 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.218.221]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 17:59:33 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 16:59:32 -0600 To: Janet P Gunn From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 22:59:33.0649 (UTC) FILETIME=[A73E4010:01C94B63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20026; t=1227221974; x=1228085974; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-00 |Sender:=20 |To:=20Janet=20P=20Gunn=20; bh=C+qU2TKk4VuAt8u7uyRmS+Difs9nAXwyEYRlZAbfcrA=; b=fqyOsOygKSp921VGdNkChJQ9V+Sbhvxf4EGZmIwmz2/BDPEyJgCQDcCxJE 9drYI0qQofqJOdELVKjjuSbkZaMK5Y7CjOCVl/0mY2zB3TIDXnNM2Sma44xS xVfYvc/7jK; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:03 PM 11/20/2008, Janet P Gunn wrote: >"James M. Polk" wrote on 11/20/2008 03:46:30 PM: > > > > > > Just to be clear, this discussion is NOT something my namespace ID > > should ever address. I have no issues with having this discussion - > > but I want to make clear that > > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make > > priority decisions or even recommendations in the text of the doc. > > > > This ID only creates the namespace *and* the probably scenario in > > which it is intended. > > >Agree > > > > >Public net: > > >P1. ets/wps? (PSAPs may not be so eager to agree) > > >P2. esnet > > >P3. > > > > it's not as simple as that. > > > > each gets its own slot in any relative > > priority order (per section 8 of RFC4412). > > > > With this in mind, it is *possible* to have a relative priority > > order like this > > > > P1. ets.4 > > P2. esnet.4 > > P3. ets.3 wps.4 > > P4. esnet.3 esnet.2 > > P5. wps.3 ets.2 > > P6. wps.2 ets.1 > > P7. esnet.1 > > P8. esnet.0 > > P9. ets.0 wps.0 > > > > notice that within each , the numbering order is > > consistent, but that the order relative to the different namespaces > > is whatever the local operator wants to make them. > >At the risk of being a nitnoid, this would NOT be an RFC4412-legal >ordering,as it reverses the priority values of ets and wps (0 is the highest). shoot me for not remembering off the top of my pointy head the order of ets and wps ;-) the concept still holds though > I do show here > > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there > > are more than one namespace.priority-value combination. This means, > > within this priority - it's a FIFO situation in which each of the > > namespace.priority-value combinations at this priority level compete > > (i.e., they are equivalent in priority). This is all a local decision. > > > > I think a way to address Brian's comment about preemption is also a > > local decision (because the local jurisdiction needs to live with the > > consequences). Here's how that can be addressed: > > > > - all these namespace.priority-value combinations *can* be preempted > >I have serious heartburn with this statement. this is a comment that is NOT tied to this ID, because there is no guidance in this doc to be given on local policy other that the concept of relative priority, just to be clear >In the circuit switched paradigm of preemption (MLPP and eMLPP), >only calls that are identified a-priori as "part of a preemption >domain (or similar term)" can be preempted. "Normal" (unmarked, as >opposed to marked "routine") calls cannot be preempted. I REALLY >don't think we should break that aspect of the paradigm without >investigating "unintended consequences" in great detail. > > > - only certain namespace.priority-value combinations *can* preempt > > another call. > > > > just a thought about how to solve this... > > > > James > > > > > > >Private net (ESInet): > > >(anything they want) > > > > > >Lastly, what kind of prioritization does a government official (a > > >servant of the people) get when they themselves initiate an emergency > > >call? esnet or ets/wps? (In a private ESInet, it may be to their > > >disadvantage to keep the wrong one.) > > > > > >-roger marshall. > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > On Behalf Of Brian Rosen > > > > Sent: Thursday, November 20, 2008 9:01 AM > > > > To: 'Janet P Gunn' > > > > Cc: Ecrit@ietf.org > > > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > An "Emergency Services IP Network" is a private IP network to > > > > which, we hope, all public safety agencies are connected. It > > > > handles all the traffic of a public safety agency, which > > > > would include routine and priority citizen to authority, > > > > authority to authority and authority to citizen traffic. > > > > It's not entirely clear to me yet whether we can reuse a > > > > number of the existing name spaces as well as a new one. For > > > > example, some of the agency-agency traffic will require > > > > pre-emption, but the existing MLPP namespace may be quite sufficient. > > > > > > > > It does occur to me that we could have ETS and possibly WPS > > > > traffic, in that if the normal access to public facilities > > > > traversed the ESInet towards some kind of gateway to a public > > > > network, then we would either have to have the ETS/WPS > > > > values, or remark them at the edge if a caller inside the > > > > ESInet needed to call someone outside the ESInet and needed > > > > ETS/WPS priority to do so. If we carried the priority > > > > marking across the ESInet, ETS/WPS would be lower priority > > > > than some other traffic, but higher than, for example, > > > > citizen to authority emergency calls. > > > > > > > > Brian > > > > > > > > > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > > Sent: Thursday, November 20, 2008 11:37 AM > > > > To: Brian Rosen > > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > Brian, > > > > > > > > I need to understand this better. > > > > > > > > Exactly what are the constraints of the "emergency services > > > > IP network"? Is this a network in which EVERY call would > > > > have the RPH with the esnet namespace (just varying priority > > > > values),and there would be no "normal" calls? Or would their > > > > be a mixture of calls with and without RPH wit esnet? > > > > > > > > Janet > > > > > > > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > > > > > > > A suggestion was made to me that we should define two namespaces. > > > > > > > > > > One would be used in public networks, and generally would > > > > be used to request > > > > > resource priority for citizen to authority and possibly > > > > authority to citizen > > > > > calls. This would have lower priority than ETS/WPS. > > > > > > > > > > The other would be for use within emergency services IP > > > > networks. It would > > > > > be unlikely that ETS/WPS would be used within those > > > > networks, but if it was, > > > > > some values within the namespace would need higher priority > > > > that ETS/WPS. > > > > > For example, a message which was an incident commanders > > > > "evacuate" message > > > > > would be higher than a ETS/WPS traffic. On the other hand, > > > > a citizen to > > > > > authority emergency call would have lower priority. > > > > > > > > > > I would be happier with one namespace and more values in > > > > that namespace for > > > > > all of this, but I was advised that two namespaces was a > > > > better choice. > > > > > > > > > > Brian > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > > Janet P Gunn > > > > > Sent: Thursday, November 20, 2008 11:00 AM > > > > > To: GOLDMAN, STUART O (STUART) > > > > > Cc: Ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Ecrit] > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > Stu, > > > > > > > > > > I intended to say that the esnet namespace needs to be at a > > > > LOWER priority > > > > > than the ets and wps namespaces, in any network that > > > > recognizes ets and wps > > > > > as described in 10.5 and 10.6 of RFC4412. > > > > > > > > > > Janet > > > > > > > > > > "GOLDMAN, STUART O \(STUART\)" > > > > wrote on > > > > > 11/20/2008 10:22:49 AM: > > > > > > > > > > > Janet, > > > > > > > > > > > > With regard to you e-mail below, did you intend that > > > > esnet could be > > > > > > at the same level of priority as ETS & WPS, or that ETS > > > > & WPS need > > > > > > to be at an even higher priority than esnet? > > > > > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > Alcatel-Lucent > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > +1 602 493 8438 > > > > > > +1 480 414 1260 mobile > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > 10/27/2008 11:45 PM > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > "James M. Polk" > > > > > > > > > > > > cc > > > > > > > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > > > > > > > Subject > > > > > > > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > > > > to, as these > > > > > > comments apply to earlier versions as well. > > > > > > > > > > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > > > > "This document IANA registers the "esnet" > > > > > > RPH namespace for use within emergency services > > > > networks, not just > > > > > > of those from citizens to PSAPs." (no clear antecedent > > > > for "those") > > > > > > > > > > > > Perhaps > > > > > > "This document IANA registers the "esnet" > > > > > > RPH namespace for use within emergency services > > > > networks, not just > > > > > > for calls or sessions > > > > > > from citizens to PSAPs." > > > > > > > > > > > > Section 2 says > > > > > > "This document updates the behaviors of the SIP Resource Priority > > > > > > header, defined in [RFC4412], during the treatment options > > > > > > surrounding this new "esnet" namespace only. The usage of the > > > > > > "esnet" namespace does not have a normal, or routine > > > > call level. > > > > > > Every use of this namespace will be in times of an > > > > emergency, where > > > > > > at least one end of the signaling is with a local emergency > > > > > > organization." > > > > > > > > > > > > I don't see this as an "update of the behavior of 4412". Neither > > > > > > the ets namespace not the wps > > > > > > namespace have a "normal" or "routine" call level. Every > > > > use of the > > > > > > wps and ets namespaces will > > > > > > have priority over calls without RPH. > > > > > > > > > > > > You say "This > > > > > > namespace, therefore, MAY be overwritten or deleted, > > > > contrary to the > > > > > > rules of RFC 4412 [RFC4412]." > > > > > > > > > > > > It is not clear to me why this is "contrary to the rules > > > > of 4412". > > > > > > It is certainly anticipated > > > > > > that other RPH will be overwritten or deleted, when the UAS > > > > > > understands the namespace. > > > > > > > > > > > > 4412 says "Existing implementations of RFC 3261 that do > > > > not participate in > > > > > the > > > > > > resource priority mechanism follow the normal rules of RFC 3261, > > > > > > Section 8.2.2: "If a UAS does not understand a header field in a > > > > > > request (that is, the header field is not defined in this > > > > > > specification or in any supported extension), the server > > > > MUST ignore > > > > > > that header field and continue processing the message". " > > > > > > > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > > > > understand the namespace is > > > > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > > > > > that "the UAC > > > > > > MAY attempt a subsequent request with the same or > > > > different resource > > > > > > value." This certainly implies the ability to overwrite > > > > or delete > > > > > > an RPH namespace. > > > > > > > > > > > > (See also, for instance the PTSC SAC document on the use > > > > of the ets > > > > > > and wps namespaces) > > > > > > > > > > > > Immediately following these statements, you give 3 options- > > > > > > "These proxies in the service provider > > > > > > MAY either > > > > > > > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > > > > present, and grant relative preferential treatment to > > > > the request > > > > > > when forwarding it to the ESINet. > > > > > > > > > > > > o replace any existing RPH value, if one is present, > > > > and insert an > > > > > > "esnet" namespace and give relative preferential > > > > treatment to the > > > > > > request when forwarding it to the ESINet. > > > > > > > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > > > > preferential treatment to the request when forwarding the SIP > > > > > > request towards the ESINet." > > > > > > > > > > > > Why do you exclude the possibility of adding the esnet RPH value > > > > > > without "replacing" an existing RPH value? > > > > > > > > > > > > Finally, there is another point that needs to be made clear. At > > > > > > least one person has contacted me expressing concern that this ID > > > > > > implied that the esnet namespace would have priority over other > > > > > > namespaces (in particular wps and ets). I assured him > > > > that this was > > > > > > not the case, that there was nothing prevent the expected > > > > behavior - > > > > > > that the ets and wps namespaces would be prioritized > > > > ahead of esnet > > > > > > in GETS Service Provider networks. > > > > > > > > > > > > However, since the question has already arisen, it would > > > > be a good > > > > > > idea to clarify this, perhaps in section 3, where you > > > > discuss the > > > > > > other namespaces. In particular, it needs to be made clear in > > > > > > section 3.2 that, even if "the local jurisdiction > > > > preferred to > > > > > > preempt normal calls in lieu of > > > > > > completing emergency calls. ", esnet calls will NOT > > > > preempt wps or ets > > > > > calls. > > > > > > > > > > > > By the way, I think you mean "the local jurisdiction > > > > preferred to > > > > > > preempt normal calls in order to complete emergency > > > > calls. " - not > > > > > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > > > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > > > > > > > In fact, it is not clear to me that 4412 permits a call > > > > with an RPH > > > > > > (e.g., esnet) to preempt a "normal" call (with no RPH > > > > namespace). > > > > > > Section 4.7.2.1 of 4412 says > > > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > > > > > > > A UAS compliant with this specification MUST terminate a session > > > > > > established with a valid namespace and lower-priority > > > > value in favor > > > > > > of a new session set up with a valid namespace and > > > > higher relative > > > > > > priority value, unless local policy has some form of > > > > call-waiting > > > > > > capability enabled. " > > > > > > > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > > > > > > > Thanks > > > > > > > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > > > > > please delete without copying and kindly advise us by > > > > e-mail of the > > > > > > mistake in delivery. > > > > > > NOTE: Regardless of content, this e-mail shall not > > > > operate to bind > > > > > > CSC to any order or other contract unless pursuant to explicit > > > > > > written agreement or government initiative expressly > > > > permitting the > > > > > > use of e-mail for such purpose. > > > > > > > > > > > > "James M. Polk" > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > "'ECRIT'" > > > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > > > > > > > Subject > > > > > > > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > > > > > > > Here is a update to a ID I think is pretty near done, > > > > given that this > > > > > > is merely an IANA registration ID of an existing mechanism. > > > > > > > > > > > > Comments are wanted > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > >directories. > > > > > > >This draft is a work item of the Emergency Context > > > > Resolution with > > > > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > > > > > > > > > > Title : IANA Registering a SIP > > > > Resource Priority > > > > > > > Header Namespace for Local Emergency Communications > > > > > > > Author(s) : J. Polk > > > > > > > Filename : > > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > > > > Pages : 9 > > > > > > > Date : 2008-10-27 > > > > > > > > > > > > > >This document creates and IANA registers the new Session > > > > Initiation > > > > > > >Protocol (SIP) Resource Priority header (RPH) namespace > > > > "esnet" for > > > > > > >local emergency usage to a public safety answering point (PSAP), > > > > > > >between PSAPs, and between a PSAP and first responders and their > > > > > > >organizations. > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > Alcatel-Lucent > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > +1 602 493 8438 > > > > > > +1 480 414 1260 mobile > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > >CONFIDENTIALITY NOTICE: The information contained in this message > > >may be privileged and/or confidential. If you are not the intended > > >recipient, or responsible for delivering this message to the > > >intended recipient, any review, forwarding, dissemination, > > >distribution or copying of this communication or any attachment(s) > > >is strictly prohibited. If you have received this message in error, > > >please notify the sender immediately, and delete it and all > > >attachments from your computer and network. > > >_______________________________________________ > > >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 ecrit-bounces@ietf.org Thu Nov 20 15:10:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785E53A6A35; Thu, 20 Nov 2008 15:10:38 -0800 (PST) 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 3E4A628C0FA for ; Thu, 20 Nov 2008 15:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvRxwqDLbiFu for ; Thu, 20 Nov 2008 15:10:32 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 746333A699A for ; Thu, 20 Nov 2008 15:10:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-171.messagelabs.com!1227222625!12568005!5 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 20124 invoked from network); 20 Nov 2008 23:10:29 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 23:10:29 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAKNAO9f019602 for ; Thu, 20 Nov 2008 18:10:28 -0500 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 20 Nov 2008 18:10:19 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/20/2008 06:12:59 PM, Serialize complete at 11/20/2008 06:12:59 PM Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Type: multipart/mixed; boundary="===============1988947786==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1988947786== Content-Type: multipart/alternative; boundary="=_alternative 007F49DA85257507_=" This is a multipart message in MIME format. --=_alternative 007F49DA85257507_= Content-Type: text/plain; charset="US-ASCII" Agree. Just needs to be made clearer that "there is no guidance in this doc to be given on local policy" Janet "James M. Polk" wrote on 11/20/2008 05:59:32 PM: > At 03:03 PM 11/20/2008, Janet P Gunn wrote: > > > >"James M. Polk" wrote on 11/20/2008 03:46:30 PM: > > > > > > > > > > Just to be clear, this discussion is NOT something my namespace ID > > > should ever address. I have no issues with having this discussion - > > > but I want to make clear that > > > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make > > > priority decisions or even recommendations in the text of the doc. > > > > > > This ID only creates the namespace *and* the probably scenario in > > > which it is intended. > > > > >Agree > > > > > > >Public net: > > > >P1. ets/wps? (PSAPs may not be so eager to agree) > > > >P2. esnet > > > >P3. > > > > > > it's not as simple as that. > > > > > > each gets its own slot in any relative > > > priority order (per section 8 of RFC4412). > > > > > > With this in mind, it is *possible* to have a relative priority > > > order like this > > > > > > P1. ets.4 > > > P2. esnet.4 > > > P3. ets.3 wps.4 > > > P4. esnet.3 esnet.2 > > > P5. wps.3 ets.2 > > > P6. wps.2 ets.1 > > > P7. esnet.1 > > > P8. esnet.0 > > > P9. ets.0 wps.0 > > > > > > notice that within each , the numbering order is > > > consistent, but that the order relative to the different namespaces > > > is whatever the local operator wants to make them. > > > >At the risk of being a nitnoid, this would NOT be an RFC4412-legal > >ordering,as it reverses the priority values of ets and wps (0 is > the highest). > > shoot me for not remembering off the top of my pointy head the order > of ets and wps > > ;-) > > the concept still holds though > > > > > I do show here > > > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there > > > are more than one namespace.priority-value combination. This means, > > > within this priority - it's a FIFO situation in which each of the > > > namespace.priority-value combinations at this priority level compete > > > (i.e., they are equivalent in priority). This is all a local decision. > > > > > > I think a way to address Brian's comment about preemption is also a > > > local decision (because the local jurisdiction needs to live with the > > > consequences). Here's how that can be addressed: > > > > > > - all these namespace.priority-value combinations *can* be preempted > > > >I have serious heartburn with this statement. > > this is a comment that is NOT tied to this ID, because there is no > guidance in this doc to be given on local policy other that the > concept of relative priority, just to be clear > > > >In the circuit switched paradigm of preemption (MLPP and eMLPP), > >only calls that are identified a-priori as "part of a preemption > >domain (or similar term)" can be preempted. "Normal" (unmarked, as > >opposed to marked "routine") calls cannot be preempted. I REALLY > >don't think we should break that aspect of the paradigm without > >investigating "unintended consequences" in great detail. > > > > > - only certain namespace.priority-value combinations *can* preempt > > > another call. > > > > > > just a thought about how to solve this... > > > > > > James > > > > > > > > > >Private net (ESInet): > > > >(anything they want) > > > > > > > >Lastly, what kind of prioritization does a government official (a > > > >servant of the people) get when they themselves initiate an emergency > > > >call? esnet or ets/wps? (In a private ESInet, it may be to their > > > >disadvantage to keep the wrong one.) > > > > > > > >-roger marshall. > > > > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > > On Behalf Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 9:01 AM > > > > > To: 'Janet P Gunn' > > > > > Cc: Ecrit@ietf.org > > > > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > An "Emergency Services IP Network" is a private IP network to > > > > > which, we hope, all public safety agencies are connected. It > > > > > handles all the traffic of a public safety agency, which > > > > > would include routine and priority citizen to authority, > > > > > authority to authority and authority to citizen traffic. > > > > > It's not entirely clear to me yet whether we can reuse a > > > > > number of the existing name spaces as well as a new one. For > > > > > example, some of the agency-agency traffic will require > > > > > pre-emption, but the existing MLPP namespace may be quite sufficient. > > > > > > > > > > It does occur to me that we could have ETS and possibly WPS > > > > > traffic, in that if the normal access to public facilities > > > > > traversed the ESInet towards some kind of gateway to a public > > > > > network, then we would either have to have the ETS/WPS > > > > > values, or remark them at the edge if a caller inside the > > > > > ESInet needed to call someone outside the ESInet and needed > > > > > ETS/WPS priority to do so. If we carried the priority > > > > > marking across the ESInet, ETS/WPS would be lower priority > > > > > than some other traffic, but higher than, for example, > > > > > citizen to authority emergency calls. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > > > Sent: Thursday, November 20, 2008 11:37 AM > > > > > To: Brian Rosen > > > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > > > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > Brian, > > > > > > > > > > I need to understand this better. > > > > > > > > > > Exactly what are the constraints of the "emergency services > > > > > IP network"? Is this a network in which EVERY call would > > > > > have the RPH with the esnet namespace (just varying priority > > > > > values),and there would be no "normal" calls? Or would their > > > > > be a mixture of calls with and without RPH wit esnet? > > > > > > > > > > Janet > > > > > > > > > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > > > > > > > > > A suggestion was made to me that we should define two namespaces. > > > > > > > > > > > > One would be used in public networks, and generally would > > > > > be used to request > > > > > > resource priority for citizen to authority and possibly > > > > > authority to citizen > > > > > > calls. This would have lower priority than ETS/WPS. > > > > > > > > > > > > The other would be for use within emergency services IP > > > > > networks. It would > > > > > > be unlikely that ETS/WPS would be used within those > > > > > networks, but if it was, > > > > > > some values within the namespace would need higher priority > > > > > that ETS/WPS. > > > > > > For example, a message which was an incident commanders > > > > > "evacuate" message > > > > > > would be higher than a ETS/WPS traffic. On the other hand, > > > > > a citizen to > > > > > > authority emergency call would have lower priority. > > > > > > > > > > > > I would be happier with one namespace and more values in > > > > > that namespace for > > > > > > all of this, but I was advised that two namespaces was a > > > > > better choice. > > > > > > > > > > > > Brian > > > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > > > Janet P Gunn > > > > > > Sent: Thursday, November 20, 2008 11:00 AM > > > > > > To: GOLDMAN, STUART O (STUART) > > > > > > Cc: Ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Ecrit] > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > Stu, > > > > > > > > > > > > I intended to say that the esnet namespace needs to be at a > > > > > LOWER priority > > > > > > than the ets and wps namespaces, in any network that > > > > > recognizes ets and wps > > > > > > as described in 10.5 and 10.6 of RFC4412. > > > > > > > > > > > > Janet > > > > > > > > > > > > "GOLDMAN, STUART O \(STUART\)" > > > > > wrote on > > > > > > 11/20/2008 10:22:49 AM: > > > > > > > > > > > > > Janet, > > > > > > > > > > > > > > With regard to you e-mail below, did you intend that > > > > > esnet could be > > > > > > > at the same level of priority as ETS & WPS, or that ETS > > > > > & WPS need > > > > > > > to be at an even higher priority than esnet? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > > Alcatel-Lucent > > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > > +1 602 493 8438 > > > > > > > +1 480 414 1260 mobile > > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > > 10/27/2008 11:45 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > > > "James M. Polk" > > > > > > > > > > > > > > cc > > > > > > > > > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > > > > > > > > > Subject > > > > > > > > > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > > > > > to, as these > > > > > > > comments apply to earlier versions as well. > > > > > > > > > > > > > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > > > > > "This document IANA registers the "esnet" > > > > > > > RPH namespace for use within emergency services > > > > > networks, not just > > > > > > > of those from citizens to PSAPs." (no clear antecedent > > > > > for "those") > > > > > > > > > > > > > > Perhaps > > > > > > > "This document IANA registers the "esnet" > > > > > > > RPH namespace for use within emergency services > > > > > networks, not just > > > > > > > for calls or sessions > > > > > > > from citizens to PSAPs." > > > > > > > > > > > > > > Section 2 says > > > > > > > "This document updates the behaviors of the SIP Resource Priority > > > > > > > header, defined in [RFC4412], during the treatment options > > > > > > > surrounding this new "esnet" namespace only. The usage of the > > > > > > > "esnet" namespace does not have a normal, or routine > > > > > call level. > > > > > > > Every use of this namespace will be in times of an > > > > > emergency, where > > > > > > > at least one end of the signaling is with a local emergency > > > > > > > organization." > > > > > > > > > > > > > > I don't see this as an "update of the behavior of 4412". Neither > > > > > > > the ets namespace not the wps > > > > > > > namespace have a "normal" or "routine" call level. Every > > > > > use of the > > > > > > > wps and ets namespaces will > > > > > > > have priority over calls without RPH. > > > > > > > > > > > > > > You say "This > > > > > > > namespace, therefore, MAY be overwritten or deleted, > > > > > contrary to the > > > > > > > rules of RFC 4412 [RFC4412]." > > > > > > > > > > > > > > It is not clear to me why this is "contrary to the rules > > > > > of 4412". > > > > > > > It is certainly anticipated > > > > > > > that other RPH will be overwritten or deleted, when the UAS > > > > > > > understands the namespace. > > > > > > > > > > > > > > 4412 says "Existing implementations of RFC 3261 that do > > > > > not participate in > > > > > > the > > > > > > > resource priority mechanism follow the normal rules of RFC 3261, > > > > > > > Section 8.2.2: "If a UAS does not understand a header field in a > > > > > > > request (that is, the header field is not defined in this > > > > > > > specification or in any supported extension), the server > > > > > MUST ignore > > > > > > > that header field and continue processing the message". " > > > > > > > > > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > > > > > understand the namespace is > > > > > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says > > > > > > > that "the UAC > > > > > > > MAY attempt a subsequent request with the same or > > > > > different resource > > > > > > > value." This certainly implies the ability to overwrite > > > > > or delete > > > > > > > an RPH namespace. > > > > > > > > > > > > > > (See also, for instance the PTSC SAC document on the use > > > > > of the ets > > > > > > > and wps namespaces) > > > > > > > > > > > > > > Immediately following these statements, you give 3 options- > > > > > > > "These proxies in the service provider > > > > > > > MAY either > > > > > > > > > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > > > > > present, and grant relative preferential treatment to > > > > > the request > > > > > > > when forwarding it to the ESINet. > > > > > > > > > > > > > > o replace any existing RPH value, if one is present, > > > > > and insert an > > > > > > > "esnet" namespace and give relative preferential > > > > > treatment to the > > > > > > > request when forwarding it to the ESINet. > > > > > > > > > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > > > > > preferential treatment to the request when forwarding the SIP > > > > > > > request towards the ESINet." > > > > > > > > > > > > > > Why do you exclude the possibility of adding the esnet RPH value > > > > > > > without "replacing" an existing RPH value? > > > > > > > > > > > > > > Finally, there is another point that needs to be made clear. At > > > > > > > least one person has contacted me expressing concern that this ID > > > > > > > implied that the esnet namespace would have priority over other > > > > > > > namespaces (in particular wps and ets). I assured him > > > > > that this was > > > > > > > not the case, that there was nothing prevent the expected > > > > > behavior - > > > > > > > that the ets and wps namespaces would be prioritized > > > > > ahead of esnet > > > > > > > in GETS Service Provider networks. > > > > > > > > > > > > > > However, since the question has already arisen, it would > > > > > be a good > > > > > > > idea to clarify this, perhaps in section 3, where you > > > > > discuss the > > > > > > > other namespaces. In particular, it needs to be made clear in > > > > > > > section 3.2 that, even if "the local jurisdiction > > > > > preferred to > > > > > > > preempt normal calls in lieu of > > > > > > > completing emergency calls. ", esnet calls will NOT > > > > > preempt wps or ets > > > > > > calls. > > > > > > > > > > > > > > By the way, I think you mean "the local jurisdiction > > > > > preferred to > > > > > > > preempt normal calls in order to complete emergency > > > > > calls. " - not > > > > > > > "in lieu of". Or perhaps "the local jurisdiction preferred to > > > > > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > > > > > > > > > In fact, it is not clear to me that 4412 permits a call > > > > > with an RPH > > > > > > > (e.g., esnet) to preempt a "normal" call (with no RPH > > > > > namespace). > > > > > > > Section 4.7.2.1 of 4412 says > > > > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > > > > > > > > > A UAS compliant with this specification MUST terminate a session > > > > > > > established with a valid namespace and lower-priority > > > > > value in favor > > > > > > > of a new session set up with a valid namespace and > > > > > higher relative > > > > > > > priority value, unless local policy has some form of > > > > > call-waiting > > > > > > > capability enabled. " > > > > > > > > > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the intended recipient, > > > > > > > please delete without copying and kindly advise us by > > > > > e-mail of the > > > > > > > mistake in delivery. > > > > > > > NOTE: Regardless of content, this e-mail shall not > > > > > operate to bind > > > > > > > CSC to any order or other contract unless pursuant to explicit > > > > > > > written agreement or government initiative expressly > > > > > permitting the > > > > > > > use of e-mail for such purpose. > > > > > > > > > > > > > > "James M. Polk" > > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > > > "'ECRIT'" > > > > > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject > > > > > > > > > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > > > > > > > > > Here is a update to a ID I think is pretty near done, > > > > > given that this > > > > > > > is merely an IANA registration ID of an existing mechanism. > > > > > > > > > > > > > > Comments are wanted > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > > Internet-Drafts > > > > > > > >directories. > > > > > > > >This draft is a work item of the Emergency Context > > > > > Resolution with > > > > > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > > > > > > > > > > > > > Title : IANA Registering a SIP > > > > > Resource Priority > > > > > > > > Header Namespace for Local Emergency Communications > > > > > > > > Author(s) : J. Polk > > > > > > > > Filename : > > > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > > > > > Pages : 9 > > > > > > > > Date : 2008-10-27 > > > > > > > > > > > > > > > >This document creates and IANA registers the new Session > > > > > Initiation > > > > > > > >Protocol (SIP) Resource Priority header (RPH) namespace > > > > > "esnet" for > > > > > > > >local emergency usage to a public safety answering point (PSAP), > > > > > > > >between PSAPs, and between a PSAP and first responders and their > > > > > > > >organizations. > > > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > > > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > > Alcatel-Lucent > > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > > +1 602 493 8438 > > > > > > > +1 480 414 1260 mobile > > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > >CONFIDENTIALITY NOTICE: The information contained in this message > > > >may be privileged and/or confidential. If you are not the intended > > > >recipient, or responsible for delivering this message to the > > > >intended recipient, any review, forwarding, dissemination, > > > >distribution or copying of this communication or any attachment(s) > > > >is strictly prohibited. If you have received this message in error, > > > >please notify the sender immediately, and delete it and all > > > >attachments from your computer and network. > > > >_______________________________________________ > > > >Ecrit mailing list > > > >Ecrit@ietf.org > > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > --=_alternative 007F49DA85257507_= Content-Type: text/html; charset="US-ASCII"

Agree.
Just needs to be made clearer that "there is no guidance in this doc to be given on local policy"
Janet

"James M. Polk" <jmpolk@cisco.com> wrote on 11/20/2008 05:59:32 PM:

> At 03:03 PM 11/20/2008, Janet P Gunn wrote:
>
>
> >"James M. Polk" <jmpolk@cisco.com> wrote on 11/20/2008 03:46:30 PM:
> >
> >
> > >
> > > Just to be clear, this discussion is NOT something my namespace ID
> > > should ever address.  I have no issues with having this discussion -
> > > but I want to make clear that
> > > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make
> > > priority decisions or even recommendations in the text of the doc.
> > >
> > > This ID only creates the namespace *and* the probably scenario in
> > > which it is intended.
> > >
> >Agree
> > >
> > > >Public net:
> > > >P1. ets/wps? (PSAPs may not be so eager to agree)
> > > >P2. esnet
> > > >P3. <other/null>
> > >
> > > it's not as simple as that.
> > >
> > > each <namsepace.priority-value> gets its own slot in any relative
> > > priority order (per section 8 of RFC4412).
> > >
> > > With this in mind, it is *possible* to have a relative priority
> > > order like this
> > >
> > > P1. ets.4
> > > P2. esnet.4
> > > P3. ets.3  wps.4
> > > P4. esnet.3  esnet.2
> > > P5. wps.3  ets.2
> > > P6. wps.2  ets.1
> > > P7. esnet.1
> > > P8. esnet.0
> > > P9. ets.0  wps.0
> > >
> > > notice that within each <namespace>, the numbering order is
> > > consistent, but that the order relative to the different namespaces
> > > is whatever the local operator wants to make them.
> >
> >At the risk of being a nitnoid, this would NOT be an RFC4412-legal
> >ordering,as it reverses the priority values of ets and wps (0 is
> the highest).
>
> shoot me for not remembering off the top of my pointy head the order
> of ets and wps
>
> ;-)
>
> the concept still holds though
>
>
>
> >  I do show here
> > > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there
> > > are more than one namespace.priority-value combination.  This means,
> > > within this priority - it's a FIFO situation in which each of the
> > > namespace.priority-value combinations at this priority level compete
> > > (i.e., they are equivalent in priority). This is all a local decision.
> > >
> > > I think a way to address Brian's comment about preemption is also a
> > > local decision (because the local jurisdiction needs to live with the
> > > consequences).  Here's how that can be addressed:
> > >
> > > - all these namespace.priority-value combinations *can* be preempted
> >
> >I have serious heartburn with this statement.
>
> this is a comment that is NOT tied to this ID, because there is no
> guidance in this doc to be given on local policy other that the
> concept of relative priority, just to be clear
>
>
> >In the circuit switched paradigm of preemption (MLPP and eMLPP),
> >only calls that are identified a-priori as "part of a preemption
> >domain (or similar term)" can be preempted.  "Normal" (unmarked, as
> >opposed to marked "routine") calls cannot be preempted. I REALLY
> >don't think we should break that aspect of the paradigm without
> >investigating "unintended consequences" in great detail.
> >
> > > - only certain namespace.priority-value combinations *can* preempt
> > > another call.
> > >
> > > just a thought about how to solve this...
> > >
> > > James
> > >
> > >
> > > >Private net (ESInet):
> > > >(anything they want)
> > > >
> > > >Lastly, what kind of prioritization does a government official (a
> > > >servant of the people) get when they themselves initiate an emergency
> > > >call?  esnet or ets/wps?  (In a private ESInet, it may be to their
> > > >disadvantage to keep the wrong one.)
> > > >
> > > >-roger marshall.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]
> > > > > On Behalf Of Brian Rosen
> > > > > Sent: Thursday, November 20, 2008 9:01 AM
> > > > > To: 'Janet P Gunn'
> > > > > Cc: Ecrit@ietf.org
> > > > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > > An "Emergency Services IP Network" is a private IP network to
> > > > > which, we hope, all public safety agencies are connected.  It
> > > > > handles all the traffic of a public safety agency, which
> > > > > would include routine and priority citizen to authority,
> > > > > authority to authority and authority to citizen traffic.
> > > > > It's not entirely clear to me yet whether we can reuse a
> > > > > number of the existing name spaces as well as a new one.  For
> > > > > example, some of the agency-agency traffic will require
> > > > > pre-emption, but the existing MLPP namespace may be quite sufficient.
> > > > >
> > > > > It does occur to me that we could have ETS and possibly WPS
> > > > > traffic, in that if the normal access to public facilities
> > > > > traversed the ESInet towards some kind of gateway to a public
> > > > > network, then we would either have to have the ETS/WPS
> > > > > values, or remark them at the edge if a caller inside the
> > > > > ESInet needed to call someone outside the ESInet and needed
> > > > > ETS/WPS priority to do so.   If we carried the priority
> > > > > marking across the ESInet, ETS/WPS would be lower priority
> > > > > than some other traffic, but higher than, for example,
> > > > > citizen to authority emergency calls.
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >
> > > > > From: Janet P Gunn [mailto:jgunn6@csc.com]
> > > > > Sent: Thursday, November 20, 2008 11:37 AM
> > > > > To: Brian Rosen
> > > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)'
> > > > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > >
> > > > > Brian,
> > > > >
> > > > > I need to understand this better.
> > > > >
> > > > > Exactly what are the constraints of the "emergency services
> > > > > IP network"?  Is this a network in which EVERY call would
> > > > > have the RPH with the  esnet namespace (just varying priority
> > > > > values),and there would be no "normal" calls?  Or would their
> > > > > be a mixture of calls with and without RPH wit esnet?
> > > > >
> > > > > Janet
> > > > >
> > > > > "Brian Rosen" <br@brianrosen.net> wrote on 11/20/2008 11:16:39 AM:
> > > > >
> > > > > > A suggestion was made to me that we should define two namespaces.
> > > > > >
> > > > > > One would be used in public networks, and generally would
> > > > > be used to request
> > > > > > resource priority for citizen to authority and possibly
> > > > > authority to citizen
> > > > > > calls.  This would have lower priority than ETS/WPS.
> > > > > >
> > > > > > The other would be for use within emergency services IP
> > > > > networks.  It would
> > > > > > be unlikely that ETS/WPS would be used within those
> > > > > networks, but if it was,
> > > > > > some values within the namespace would need higher priority
> > > > > that ETS/WPS.
> > > > > > For example, a message which was an incident commanders
> > > > > "evacuate" message
> > > > > > would be higher than a ETS/WPS traffic.  On the other hand,
> > > > > a citizen to
> > > > > > authority emergency call would have lower priority.
> > > > > >
> > > > > > I would be happier with one namespace and more values in
> > > > > that namespace for
> > > > > > all of this, but I was advised that two namespaces was a
> > > > > better choice.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > From: ecrit-bounces@ietf.org
> > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of
> > > > > > Janet P Gunn
> > > > > > Sent: Thursday, November 20, 2008 11:00 AM
> > > > > > To: GOLDMAN, STUART O (STUART)
> > > > > > Cc: Ecrit@ietf.org
> > > > > > Subject: Re: [Ecrit] Ecrit]
> > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > > >
> > > > > >
> > > > > > Stu,
> > > > > >
> > > > > > I intended to say that the esnet namespace needs to be at a
> > > > > LOWER priority
> > > > > >  than the ets and wps namespaces, in any network that
> > > > > recognizes ets and wps
> > > > > > as described in 10.5 and 10.6 of RFC4412.
> > > > > >
> > > > > > Janet
> > > > > >
> > > > > > "GOLDMAN, STUART O \(STUART\)"
> > > > > <sgoldman@alcatel-lucent.com> wrote on
> > > > > > 11/20/2008 10:22:49 AM:
> > > > > >
> > > > > > > Janet,
> > > > > > >
> > > > > > > With regard to you e-mail below, did you intend that
> > > > > esnet could be
> > > > > > > at the same level of priority as ETS & WPS,  or that ETS
> > > > > & WPS need
> > > > > > > to be at an even higher priority than esnet?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Stuart Goldman
> > > > > > > Alcatel-Lucent
> > > > > > > Stuart.Goldman@alcatel-lucent.com
> > > > > > > +1 602 493 8438
> > > > > > > +1 480 414 1260 mobile
> > > > > > > P please save a tree by not printing this e-mail.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Janet P Gunn/FED/CSC@CSC
> > > > > > > Sent by: ecrit-bounces@ietf.org
> > > > > > > 10/27/2008 11:45 PM
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To
> > > > > > >
> > > > > > > "James M. Polk" <jmpolk@cisco.com>
> > > > > > >
> > > > > > > cc
> > > > > > >
> > > > > > > "'ECRIT'" <ecrit@ietf.org>, ecrit-bounces@ietf.org
> > > > > > >
> > > > > > > Subject
> > > > > > >
> > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I apologize for not tracking this as closely as I meant
> > > > > to, as these
> > > > > > > comments apply to  earlier versions as well.
> > > > > > >
> > > > > > >
> > > > > > > This sentence at the end of sec 1 doesn't quite work.
> > > > > > > "This document IANA registers the "esnet"
> > > > > > >  RPH namespace for use within emergency services
> > > > > networks, not just
> > > > > > >  of those from citizens to PSAPs." (no clear antecedent
> > > > > for "those")
> > > > > > >
> > > > > > > Perhaps
> > > > > > > "This document IANA registers the "esnet"
> > > > > > >  RPH namespace for use within emergency services
> > > > > networks, not just
> > > > > > > for calls or sessions
> > > > > > >   from citizens to PSAPs."
> > > > > > >
> > > > > > > Section 2 says
> > > > > > > "This document updates the behaviors of the SIP Resource Priority
> > > > > > >  header, defined in [RFC4412], during the treatment options
> > > > > > >  surrounding this new "esnet" namespace only. The usage of the
> > > > > > >  "esnet" namespace does not have a normal, or routine
> > > > > call level.
> > > > > > >  Every use of this namespace will be in times of an
> > > > > emergency, where
> > > > > > >  at least one end of the signaling is with a local emergency
> > > > > > >  organization."
> > > > > > >
> > > > > > > I don't see this as an "update of the behavior of 4412".  Neither
> > > > > > > the ets namespace not the wps
> > > > > > > namespace have a "normal" or "routine" call level.  Every
> > > > > use of the
> > > > > > > wps and ets namespaces will
> > > > > > > have priority over calls without RPH.
> > > > > > >
> > > > > > > You say "This
> > > > > > >  namespace, therefore, MAY be overwritten or deleted,
> > > > > contrary to the
> > > > > > >  rules of RFC 4412 [RFC4412]."
> > > > > > >
> > > > > > > It is not clear to me why this is "contrary to the rules
> > > > > of 4412".
> > > > > > > It is certainly anticipated
> > > > > > > that other RPH will be overwritten or deleted, when the UAS
> > > > > > > understands the namespace.
> > > > > > >
> > > > > > > 4412 says "Existing implementations of RFC 3261 that do
> > > > > not participate in
> > > > > > the
> > > > > > >  resource priority mechanism follow the normal rules of RFC 3261,
> > > > > > >  Section 8.2.2: "If a UAS does not understand a header field in a
> > > > > > >  request (that is, the header field is not defined in this
> > > > > > >  specification or in any supported extension), the server
> > > > > MUST ignore
> > > > > > >  that header field and continue processing the message". "
> > > > > > >
> > > > > > > But I do not see anywhere that is says that a UAS that DOES
> > > > > > > understand the namespace is
> > > > > > > forbidden from deleting it.  For instance, sec 4.7.1 of 4412 says
> > > > > > > that "the UAC
> > > > > > >  MAY attempt a subsequent request with the same or
> > > > > different resource
> > > > > > >  value."  This certainly implies the ability to overwrite
> > > > > or delete
> > > > > > > an RPH namespace.
> > > > > > >
> > > > > > > (See also, for instance the PTSC SAC document on the use
> > > > > of the ets
> > > > > > > and wps namespaces)
> > > > > > >
> > > > > > > Immediately following these statements, you give 3 options-
> > > > > > > "These proxies in the service provider
> > > > > > >  MAY either
> > > > > > >
> > > > > > >  o  accept the existing RPH value with "esnet" in it, if one is
> > > > > > >     present, and grant relative preferential treatment to
> > > > > the request
> > > > > > >     when forwarding it to the ESINet.
> > > > > > >
> > > > > > >  o  replace any existing RPH value, if one is present,
> > > > > and insert an
> > > > > > >     "esnet" namespace and give relative preferential
> > > > > treatment to the
> > > > > > >     request when forwarding it to the ESINet.
> > > > > > >
> > > > > > >  o  insert an "esnet" namespace in a new RPH and give relative
> > > > > > >     preferential treatment to the request when forwarding the SIP
> > > > > > >     request towards the ESINet."
> > > > > > >
> > > > > > > Why do you exclude the possibility of adding the esnet RPH value
> > > > > > > without "replacing" an existing RPH value?
> > > > > > >
> > > > > > > Finally, there is another point that  needs to be made clear.  At
> > > > > > > least one person has contacted me expressing concern that this ID
> > > > > > > implied that the esnet namespace would  have priority over other
> > > > > > > namespaces (in particular wps and ets).  I assured him
> > > > > that this was
> > > > > > > not the case, that there was nothing prevent the expected
> > > > > behavior -
> > > > > > > that the ets and wps namespaces would be prioritized
> > > > > ahead of esnet
> > > > > > > in GETS Service Provider networks.
> > > > > > >
> > > > > > > However, since the question has already arisen, it would
> > > > > be a good
> > > > > > > idea to clarify  this, perhaps in  section 3, where you
> > > > > discuss  the
> > > > > > > other namespaces.  In particular, it needs to be made clear in
> > > > > > > section 3.2  that, even if  "the   local jurisdiction
> > > > > preferred to
> > > > > > > preempt normal calls in lieu of
> > > > > > >  completing emergency calls. ", esnet calls will NOT
> > > > > preempt wps or ets
> > > > > > calls.
> > > > > > >
> > > > > > > By the way, I think you mean "the   local jurisdiction
> > > > > preferred to
> > > > > > > preempt normal calls in order to complete emergency
> > > > > calls. "  - not
> > > > > > > "in lieu of".  Or perhaps "the   local jurisdiction preferred to
> > > > > > > preempt normal calls in lieu of  dropping emergency calls. "
> > > > > > >
> > > > > > > In fact, it is not clear to me that 4412 permits a call
> > > > > with an RPH
> > > > > > > (e.g., esnet)  to preempt a "normal" call (with no RPH
> > > > > namespace).
> > > > > > > Section 4.7.2.1 of 4412 says
> > > > > > > "4.7.2.1.  User Agent Servers and Preemption Algorithm
> > > > > > >
> > > > > > >  A UAS compliant with this specification MUST terminate a session
> > > > > > >  established with a valid namespace and lower-priority
> > > > > value in favor
> > > > > > >  of a new session set up with a valid namespace and
> > > > > higher relative
> > > > > > >  priority value, unless local policy has some form of
> > > > > call-waiting
> > > > > > >  capability enabled. "
> > > > > > >
> > > > > > > It doesn't say anything about preempting a call with no RPH
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Janet
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This is a PRIVATE message. If you are not the intended recipient,
> > > > > > > please delete without copying and kindly advise us by
> > > > > e-mail of the
> > > > > > > mistake in delivery.
> > > > > > > NOTE: Regardless of content, this e-mail shall not
> > > > > operate to bind
> > > > > > > CSC to any order or other contract unless pursuant to explicit
> > > > > > > written agreement or government initiative expressly
> > > > > permitting the
> > > > > > > use of e-mail for such purpose.
> > > > > > >
> > > > > > > "James M. Polk" <jmpolk@cisco.com>
> > > > > > > Sent by: ecrit-bounces@ietf.org
> > > > > > > 10/27/2008 08:32 PM
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To
> > > > > > >
> > > > > > > "'ECRIT'" <ecrit@ietf.org>
> > > > > > >
> > > > > > > cc
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Subject
> > > > > > >
> > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ECRIT WG
> > > > > > >
> > > > > > > Here is a update to a ID I think is pretty near done,
> > > > > given that this
> > > > > > > is merely an IANA registration ID of an existing mechanism.
> > > > > > >
> > > > > > > Comments are wanted
> > > > > > >
> > > > > > > >A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts
> > > > > > > >directories.
> > > > > > > >This draft is a work item of the Emergency Context
> > > > > Resolution with
> > > > > > > >Internet Technologies Working Group of the IETF.
> > > > > > > >
> > > > > > > >
> > > > > > > >         Title           : IANA Registering a SIP
> > > > > Resource Priority
> > > > > > > > Header Namespace for Local Emergency Communications
> > > > > > > >         Author(s)       : J. Polk
> > > > > > > >         Filename        :
> > > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
> > > > > > > >         Pages           : 9
> > > > > > > >         Date            : 2008-10-27
> > > > > > > >
> > > > > > > >This document creates and IANA registers the new Session
> > > > > Initiation
> > > > > > > >Protocol (SIP) Resource Priority header (RPH) namespace
> > > > > "esnet" for
> > > > > > > >local emergency usage to a public safety answering point (PSAP),
> > > > > > > >between PSAPs, and between a PSAP and first responders and their
> > > > > > > >organizations.
> > > > > > > >
> > > > > > > >A URL for this Internet-Draft is:
> > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> > > > > > > emergency-rph-namespace-00.txt
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local->
> > > >  > > emergency-rph-namespace-00.txt>
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > > Stuart Goldman
> > > > > > > Alcatel-Lucent
> > > > > > > Stuart.Goldman@alcatel-lucent.com
> > > > > > > +1 602 493 8438
> > > > > > > +1 480 414 1260 mobile
> > > > > > > P please save a tree by not printing this e-mail.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > >
> > > >CONFIDENTIALITY NOTICE: The information contained in this message
> > > >may be privileged and/or confidential. If you are not the intended
> > > >recipient, or responsible for delivering this message to the
> > > >intended recipient, any review, forwarding, dissemination,
> > > >distribution or copying of this communication or any attachment(s)
> > > >is strictly prohibited. If you have received this message in error,
> > > >please notify the sender immediately, and delete it and all
> > > >attachments from your computer and network.
> > > >_______________________________________________
> > > >Ecrit mailing list
> > > >Ecrit@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/ecrit
> > >
>
--=_alternative 007F49DA85257507_=-- --===============1988947786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1988947786==-- From ecrit-bounces@ietf.org Thu Nov 20 15:11:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68A028C129; Thu, 20 Nov 2008 15:11:13 -0800 (PST) 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 D12EB28C129 for ; Thu, 20 Nov 2008 15:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0hZHGexZmLL3 for ; Thu, 20 Nov 2008 15:11:09 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 4F3353A6907 for ; Thu, 20 Nov 2008 15:11:09 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 15:10:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 15:09:30 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3QAAHvRyAAAMac8A== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Winterbottom, James" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Wait on... not the case for non-IMS emergency calls in SUPL. While it is true that SUPL goes to its home network for commercial location and for any IMS call, it is not specified to do so with non-IMS Emergency Roaming in SUPL 2.0 (Section 5.1.15.3). For that, an emergency call uses the local (visited) E-SLP (and lesser-tiered V-SLP). Both are assumed to be in the visited network. The device discovers the E-SLP via MNC/MCC (network & country codes) supplied. -roger. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, November 20, 2008 2:07 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Only if the device is connected to its home network, else you > require a world in a database solution. Inter-carrier roaming > with SUPL is problematic to say the least. > > Cheers > James > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Roger Marshall > > Sent: Friday, 21 November 2008 8:13 AM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > No objection to saying that SUPL in its present form is not a good > > choice for wire-map, but would object to saying the same for other > types > > of 'non-measured' location. > > > > Rather, SUPL is in fact an excellent choice for > non-endpoint measured > > location such as 'CellID'. > > > > -roger. > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:32 PM > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. > If we need > > > to parse more carefully, SUPL isn't very suitable for > wiremap forms > > > of location determination. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Thursday, November 20, 2008 3:22 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that don't use GPS or some form of measured location. > > > > > > [rsm - measured only - really? - surely you aren't > suggesting that > > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance > on 'rough > > > location' via CellID, are you? > > > > > > Wiremap location - given (manually input)] CellID > location - given > > > Terrestial trilateration - measured Celestial trilateration - > > > measured Geocoded/reverse geocoded - derived > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > to 'given' > > > location scenarios, aka wiremap, etc. that are more Wireline > > > oriented, rather than mobile. For the future, wireline devices > > > reduce in number, mobile (or even nomadic) devices will > continue in > > > their distribution bias. Fixed vs. Mobile has been the > fundamental > > > difference between how the IETF looks at things vs. these > mentioned > > > other fora. I contend that if we solve this for mobile - then we > > > can begin communicating better with OMA/3GPP/3GPP2, > and... Solving > > > fixed will be easier. > > > /] > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > has its own > > > > version of that. > > > > > > > > All 3GPP networks I know of support a raw packet > service. On that > > > > service will run applications like MSN or AOL instant messaging. > > > > Those services > > > > will need to be able to make emergency chats. To route > > > > properly, they need > > > > location. That means that EVERY handset must deploy > some LCP, and > > > > must be able to get location suitable for emergency call > > > routing and > > > > dispatch per -phonebcp. The RV example is yet another > case of the > > > > same thing. The mistake is assuming that all emergency > calls will > > > > come through the E-CSCF. > > > > They won't, and the 3GPP access network must conform to all the > > > > -phonebcp requirements. > > > > > > > > Generally, I agree that SUPL is unsuitable for access networks > that > > > > don't use GPS or some form of measured location. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > computers (and > > > > related operating systems, SIP soft clients), analog terminal > > > > adaptors, or other similar devices that are intended > for use in a > > > > wireline environment. I think that organizations that can drive > > > > requirements for devices intended to be use in an environment > where > > > > SUPL would actually work, should be responsible for > having device > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > absolutely > > > > in a position to require SUPL support for devices that > > > operate in an > > > > environment where SUPL works. This is a perfect example of the > > > > "closed" network that Brian describes somewhere (framework, > > > I think). > > > > > > > > Phonebcp is about requirements for devices in access > environments > > > > where the operators of the access environment cannot be > assumed to > > > > have any control over the type or nature of devices that > > > connect to or > > > > through it. Phonebcp needs to continue to have that as its > purpose. > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > SUPL, or > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > To: Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > requiring PhoneBCP > > > > suppport of SUPL, then my vote is to NOT prevent! I > would prefer > > > > 'require' since *most* of the location-aware 3G compatible > > > > handsets/aircards over the next several years will (I > > > predict) have a > > > > SUPL stack included. In the same time frame, many of those > > > will also > > > > have WiFi support, others will have LTE or WiMAX support as > hybrids. > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > open-minded, and there is movement afoot to expand > OMA/SUPL (as we > > > > heard in the geopriv mtg. on Tuesday) w/respect > expected proposals > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > there will be > > > > fewer protocol, location representation, and privacy > > > discontinuities - > > > > things that too often get cited - yet are seldom well > understood. > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > - not block > > > > its use altogether. This is a case where we need to be > > > inclusive, not > > > > exclusive. > > > > > > > > As to the mobile RV sample case, the solution is also > forseeable - > > > > especially given that the location of the 3G aircard in the > > > router is > > > > good enough for routing. The scenario given needs some > > > integration, > > > > but is doable. Given that the aircard acts as a logical > > > SET, with a > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > combination > > > > *WILL* (I believe) interoperate with a number of end client > > > > applications to initiate and complete a location-routed, 3261 > style > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > To: 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that > the > > > > > clients are generally not very L2 aware. It's the clients > > > > that have > > > > > the problem. > > > > > You can do things like interwork an L2 specific LCP to a > > > > common LCP so > > > > > that non L2 aware devices can work, but you have to > do that, and > > > > > usually, that's impractical. Use my example. Suppose > > > that the L2 > > > > > used SUPL. It's possible for the PC Card that is plugged > > > into the > > > > > router could implement a SUPL client and a HELD server and > > > > interwork > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > Ethernet VoIP > > > > > phone could get location via HELD. Possible, but not > practical. > > > > > There are all sorts of these kinds of problems. That's why > > > > > L2 specific LCPs don't work. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > standards for > > > > > every access technology that's out there. What we can say > > > > is that the > > > > > paradigm for those protocols should be the same as at the > > > IP layer: > > > > > Clients MUST implement all, networks MUST implement at least > one. > > > > > > > > > > (This is a little different from the text I sent before, > > > > and clearer, > > > > > I > > > > > think.) > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > the possible > > > > > protocols at lower layers, we should just state the general > > > > rule. It > > > > > seems to me that this achieves the same level of > > > > interoperability at > > > > > all layers. > > > > > > > > > > --Richard > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > any number > > > > > > of optional ones, then every network has to implement at > > > > > least one of > > > > > > those > > > > > two > > > > > > LCPs, and any number of optional ones. That means that > > > > > "any number of > > > > > > optional ones" is useless for both parties. > > > > > > If the network can limit UAs to ONLY those that implement > > > > > one of the > > > > > > optional protocols, then it works, but in practice, it > > > is usually > > > > > impossible > > > > > > to do that. My example is the wired, Ethernet connected > > > > > phone in an > > > > > > RV traveling down the road with wireless data card in a > > > > > router. These > > > > > > EXIST, now. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > for an RFC to > > > > > > try to list all of the location protocols out there, if for > > > > > no other > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > we should > > > > > > say something like the following: > > > > > > > > > > > > " > > > > > > INT-12 Devices MUST support the DHCP location options > > > > [RFC4776] and > > > > > > [RFC3825] and HELD > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > SHOULD support all location protocols supported at lower > > > > layers by > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > >> The problem with SUPL is that the majority of networks > > > > where SUPL > > > > > >> would > > > > > be > > > > > >> available have a proxy (E-CSCF) insert location. It > > > also has an > > > > > >> incompatible location representation, and an incompatible > > > > > privacy model. > > > > > >> That makes it very hard to interwork with any of the rest > > > > > of the IETF > > > > > > work. > > > > > >> I will say this. For quite some time, the IETF has been > > > > trying to > > > > > > interest > > > > > >> OMA into cooperation on location so that we have > > > > > interoperability at > > > > > >> the protocol, location representation and privacy > > > > levels. So far, > > > > > >> that has > > > > > > not > > > > > >> happened. If, as part of a comprehensive agreement to > > > > accomplish > > > > > >> such a goal, SUPL became one of the LCPs, I would > not object. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Is the intent to list the LCPs which are access-type > > > > > agnostic but not > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > are highly > > > > > >> probable to produce the intended result? > > > > > >> > > > > > >> There are restrictions everywhere, things come at a cost > > > > > even in the > > > > > >> general Internet model. The reality is that most of the > > > > > devices with > > > > > >> internet access have a home network already. > > > > > >> > > > > > >> - Gabor > > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Winterbottom, James > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > - FI/Espoo) > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >Hi Gabor, > > > > > >> > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > list, and is > > > > > >> access- > > > > > >> >type agnostic. > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > given that: > > > > > >> >a) it requires a home network in order to operate > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > >> >c) it is questionable whether it is really deployable > > > > for WiFi > > > > > >> networks > > > > > >> > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > Internet model? > > > > > >> > > > > > > >> >Cheers > > > > > >> >James > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > Gabor.Bajko@nokia.com > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > >> >To: ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >I was requested to send my observations regarding this > > > > > requirement: > > > > > >> > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > location options > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > LLDP-MED [LLDP-MED]. > > > > > >> > > > > > > >> > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > are likely > > > > > >> to be > > > > > >> >supported in devices in a not so distant future. Since > > > > > I have no > > > > > >> seen or > > > > > >> >heard about LLDP support yet, at least that should be > > > > replaced > > > > > >> with what > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > mechanism, with the > > > > > >> >condition that this MUST only be supported if there > > > is a wifi > > > > > >> interface > > > > > >> >available on the device. > > > > > >> > > > > > > >> >- Gabor > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >________________________________ > > > > > >> > > > > > > >> >From: ext Tschofenig, Hannes > > > > > >> > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > marc.linsner@cisco.com > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >Gabor, > > > > > >> > > > > > > >> >Could you please raise your question about location > > > > > protocols in > > > > > >> Phone > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > >> > > > > > > >> >Ciao > > > > > >> >Hannes > > > > > >> > > > > > > >> > > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >This message is for the designated recipient > only and may > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > information. > > > > > >> >If you have received it in error, please notify > the sender > > > > > >> >immediately and delete the original. Any > > > unauthorized use of > > > > > >> >this email is prohibited. > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >[mf2] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments from > your > > > > computer and network. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please > contact the > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 15:25:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371EC28C155; Thu, 20 Nov 2008 15:25:32 -0800 (PST) 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 3558D28C155 for ; Thu, 20 Nov 2008 15:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oRMn+bxKhgkk for ; Thu, 20 Nov 2008 15:25:28 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 76D7A28C128 for ; Thu, 20 Nov 2008 15:25:28 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 20 Nov 2008 15:25:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 15:24:10 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533AF1@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQAANRXyAAAiQaMA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Winterbottom, James" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I don't think those fixed operator's wanting to introduce mobile services think of these feature distinctions as 'old school'. Nor do I believe that current mobile operators view the separation as a slippery slope. I do think you are failing to tease out the reasons why SUPL does contain those specific measurement techniques - that is, that it does the job of an LCP for conforming mobile networks, as well as additional underlying data exchange (which LCP's by design, don't do - but rely on other associated protocol suggestions like the new grip, the draft titled, 'Providing Satellite Navigation Assistance Data using HELD', etc. ). So, in a way, SUPL HELD + GRIP p.s. I think you meant "is NOT relevant" > The distinction between fixed and mobile, wireline and > wireless is relevant, -roger. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, November 20, 2008 2:23 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > The distinction between fixed and mobile, wireline and > wireless is relevant, it is old-school thinking and isn't > really applicable anymore. > We are talking about an Internet-based device, which can be > any or all of the above, and often at the same time. > > I think that dissecting the networks in the manner being > described below leads to a very slippery slope very quickly. > > Our requirements for an LCP were that it MUST be implemented > by all devices, not that it MUST be implemented by all device if.... > > LCPs, the ones currently in Phone BCP, all provide a local > service discovery technique, SUPL does not. This aspect of an > LCP is important, as it puts the target device in contact > with the location server responsible for determining the > location of the Target in the local access network. In this > way, it is possible for the device to ask for location in the > same way every time, regardless of the network technology. > Again, this is not true for SUPL, different access > technologies require the Device and the home SLP to support > new measurement types, and potentially additional "out of scope" > connectivity back to the actual serving network to use this > information. > > Don't get me wrong, SUPL has a place in providing location in > some access network architectures, but it is far from > ubiquitous, the aim of phone BCP is specify what MUST be > supported by all devices. > > > Cheers > James > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Roger Marshall > > Sent: Friday, 21 November 2008 8:07 AM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > makes > > clear what that the requirements apply (without bias) to both fixed > and > > mobile end devices (and their associated network deployment types)? > > > > Below is some keyword sampling to show some implications with regard > to > > fixed vs. mobile, but which isn't as crisp as it could be (depending > on > > the scope). > > > > A search of phonebcp for the following terms yields the associated > > references: > > > > Fixed: > > (none); > > > > Wireline: > > (none); > > > > Mobile: > > AN-11; > > ED-35/AN-19; > > ED-35; > > > > Wireless: > > AN-7/INT-6; > > AN-9; > > AN-7; > > INT-6; > > > > From the toc, it is listed... > > > > 6.2.2. Access network "wire database" location > information . > 7 > > 6.2.3. End-system measured location information . . > . . . . . > 7 > > 6.2.4. Network-measured location information . . . > . . . . . > 8 > > > > -roger. > > > > > > No mention of fixed, wireline, wireless, or mobile in any > of the text > > sections (Intro, etc.) > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:32 PM > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. > If we need > > > to parse more carefully, SUPL isn't very suitable for > wiremap forms > > > of location determination. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Thursday, November 20, 2008 3:22 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that don't use GPS or some form of measured location. > > > > > > [rsm - measured only - really? - surely you aren't > suggesting that > > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance > on 'rough > > > location' via CellID, are you? > > > > > > Wiremap location - given (manually input)] CellID > location - given > > > Terrestial trilateration - measured Celestial trilateration - > > > measured Geocoded/reverse geocoded - derived > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > to 'given' > > > location scenarios, aka wiremap, etc. that are more Wireline > > > oriented, rather than mobile. For the future, wireline devices > > > reduce in number, mobile (or even nomadic) devices will > continue in > > > their distribution bias. Fixed vs. Mobile has been the > fundamental > > > difference between how the IETF looks at things vs. these > mentioned > > > other fora. I contend that if we solve this for mobile - then we > > > can begin communicating better with OMA/3GPP/3GPP2, > and... Solving > > > fixed will be easier. > > > /] > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > has its own > > > > version of that. > > > > > > > > All 3GPP networks I know of support a raw packet > service. On that > > > > service will run applications like MSN or AOL instant messaging. > > > > Those services > > > > will need to be able to make emergency chats. To route > > > > properly, they need > > > > location. That means that EVERY handset must deploy > some LCP, and > > > > must be able to get location suitable for emergency call > > > routing and > > > > dispatch per -phonebcp. The RV example is yet another > case of the > > > > same thing. The mistake is assuming that all emergency > calls will > > > > come through the E-CSCF. > > > > They won't, and the 3GPP access network must conform to all the > > > > -phonebcp requirements. > > > > > > > > Generally, I agree that SUPL is unsuitable for access networks > that > > > > don't use GPS or some form of measured location. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > computers (and > > > > related operating systems, SIP soft clients), analog terminal > > > > adaptors, or other similar devices that are intended > for use in a > > > > wireline environment. I think that organizations that can drive > > > > requirements for devices intended to be use in an environment > where > > > > SUPL would actually work, should be responsible for > having device > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > absolutely > > > > in a position to require SUPL support for devices that > > > operate in an > > > > environment where SUPL works. This is a perfect example of the > > > > "closed" network that Brian describes somewhere (framework, > > > I think). > > > > > > > > Phonebcp is about requirements for devices in access > environments > > > > where the operators of the access environment cannot be > assumed to > > > > have any control over the type or nature of devices that > > > connect to or > > > > through it. Phonebcp needs to continue to have that as its > purpose. > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > SUPL, or > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > To: Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > requiring PhoneBCP > > > > suppport of SUPL, then my vote is to NOT prevent! I > would prefer > > > > 'require' since *most* of the location-aware 3G compatible > > > > handsets/aircards over the next several years will (I > > > predict) have a > > > > SUPL stack included. In the same time frame, many of those > > > will also > > > > have WiFi support, others will have LTE or WiMAX support as > hybrids. > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > open-minded, and there is movement afoot to expand > OMA/SUPL (as we > > > > heard in the geopriv mtg. on Tuesday) w/respect > expected proposals > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > there will be > > > > fewer protocol, location representation, and privacy > > > discontinuities - > > > > things that too often get cited - yet are seldom well > understood. > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > - not block > > > > its use altogether. This is a case where we need to be > > > inclusive, not > > > > exclusive. > > > > > > > > As to the mobile RV sample case, the solution is also > forseeable - > > > > especially given that the location of the 3G aircard in the > > > router is > > > > good enough for routing. The scenario given needs some > > > integration, > > > > but is doable. Given that the aircard acts as a logical > > > SET, with a > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > combination > > > > *WILL* (I believe) interoperate with a number of end client > > > > applications to initiate and complete a location-routed, 3261 > style > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > To: 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that > the > > > > > clients are generally not very L2 aware. It's the clients > > > > that have > > > > > the problem. > > > > > You can do things like interwork an L2 specific LCP to a > > > > common LCP so > > > > > that non L2 aware devices can work, but you have to > do that, and > > > > > usually, that's impractical. Use my example. Suppose > > > that the L2 > > > > > used SUPL. It's possible for the PC Card that is plugged > > > into the > > > > > router could implement a SUPL client and a HELD server and > > > > interwork > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > Ethernet VoIP > > > > > phone could get location via HELD. Possible, but not > practical. > > > > > There are all sorts of these kinds of problems. That's why > > > > > L2 specific LCPs don't work. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > standards for > > > > > every access technology that's out there. What we can say > > > > is that the > > > > > paradigm for those protocols should be the same as at the > > > IP layer: > > > > > Clients MUST implement all, networks MUST implement at least > one. > > > > > > > > > > (This is a little different from the text I sent before, > > > > and clearer, > > > > > I > > > > > think.) > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > the possible > > > > > protocols at lower layers, we should just state the general > > > > rule. It > > > > > seems to me that this achieves the same level of > > > > interoperability at > > > > > all layers. > > > > > > > > > > --Richard > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > any number > > > > > > of optional ones, then every network has to implement at > > > > > least one of > > > > > > those > > > > > two > > > > > > LCPs, and any number of optional ones. That means that > > > > > "any number of > > > > > > optional ones" is useless for both parties. > > > > > > If the network can limit UAs to ONLY those that implement > > > > > one of the > > > > > > optional protocols, then it works, but in practice, it > > > is usually > > > > > impossible > > > > > > to do that. My example is the wired, Ethernet connected > > > > > phone in an > > > > > > RV traveling down the road with wireless data card in a > > > > > router. These > > > > > > EXIST, now. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > for an RFC to > > > > > > try to list all of the location protocols out there, if for > > > > > no other > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > we should > > > > > > say something like the following: > > > > > > > > > > > > " > > > > > > INT-12 Devices MUST support the DHCP location options > > > > [RFC4776] and > > > > > > [RFC3825] and HELD > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > SHOULD support all location protocols supported at lower > > > > layers by > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > >> The problem with SUPL is that the majority of networks > > > > where SUPL > > > > > >> would > > > > > be > > > > > >> available have a proxy (E-CSCF) insert location. It > > > also has an > > > > > >> incompatible location representation, and an incompatible > > > > > privacy model. > > > > > >> That makes it very hard to interwork with any of the rest > > > > > of the IETF > > > > > > work. > > > > > >> I will say this. For quite some time, the IETF has been > > > > trying to > > > > > > interest > > > > > >> OMA into cooperation on location so that we have > > > > > interoperability at > > > > > >> the protocol, location representation and privacy > > > > levels. So far, > > > > > >> that has > > > > > > not > > > > > >> happened. If, as part of a comprehensive agreement to > > > > accomplish > > > > > >> such a goal, SUPL became one of the LCPs, I would > not object. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Is the intent to list the LCPs which are access-type > > > > > agnostic but not > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > are highly > > > > > >> probable to produce the intended result? > > > > > >> > > > > > >> There are restrictions everywhere, things come at a cost > > > > > even in the > > > > > >> general Internet model. The reality is that most of the > > > > > devices with > > > > > >> internet access have a home network already. > > > > > >> > > > > > >> - Gabor > > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Winterbottom, James > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > - FI/Espoo) > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >Hi Gabor, > > > > > >> > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > list, and is > > > > > >> access- > > > > > >> >type agnostic. > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > given that: > > > > > >> >a) it requires a home network in order to operate > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > >> >c) it is questionable whether it is really deployable > > > > for WiFi > > > > > >> networks > > > > > >> > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > Internet model? > > > > > >> > > > > > > >> >Cheers > > > > > >> >James > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > Gabor.Bajko@nokia.com > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > >> >To: ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >I was requested to send my observations regarding this > > > > > requirement: > > > > > >> > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > location options > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > LLDP-MED [LLDP-MED]. > > > > > >> > > > > > > >> > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > are likely > > > > > >> to be > > > > > >> >supported in devices in a not so distant future. Since > > > > > I have no > > > > > >> seen or > > > > > >> >heard about LLDP support yet, at least that should be > > > > replaced > > > > > >> with what > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > mechanism, with the > > > > > >> >condition that this MUST only be supported if there > > > is a wifi > > > > > >> interface > > > > > >> >available on the device. > > > > > >> > > > > > > >> >- Gabor > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >________________________________ > > > > > >> > > > > > > >> >From: ext Tschofenig, Hannes > > > > > >> > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > marc.linsner@cisco.com > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >Gabor, > > > > > >> > > > > > > >> >Could you please raise your question about location > > > > > protocols in > > > > > >> Phone > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > >> > > > > > > >> >Ciao > > > > > >> >Hannes > > > > > >> > > > > > > >> > > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >This message is for the designated recipient > only and may > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > information. > > > > > >> >If you have received it in error, please notify > the sender > > > > > >> >immediately and delete the original. Any > > > unauthorized use of > > > > > >> >this email is prohibited. > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >[mf2] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments from > your > > > > computer and network. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please > contact the > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 15:29:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5503D3A6939; Thu, 20 Nov 2008 15:29:29 -0800 (PST) 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 51B173A6939 for ; Thu, 20 Nov 2008 15:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuCiERis3AtA for ; Thu, 20 Nov 2008 15:29:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C03AA3A6907 for ; Thu, 20 Nov 2008 15:29:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28571337" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2008 23:29:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKNTOHO003596; Thu, 20 Nov 2008 18:29:24 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKNTOrM011217; Thu, 20 Nov 2008 23:29:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:29:24 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.218.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:29:23 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Nov 2008 17:29:22 -0600 To: Janet P Gunn From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 20 Nov 2008 23:29:23.0614 (UTC) FILETIME=[D2253BE0:01C94B67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22549; t=1227223764; x=1228087764; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-00 |Sender:=20 |To:=20Janet=20P=20Gunn=20; bh=eOpK6UUPQo2FAUmgDXsaWfjdjewbgcaRUHa63IeV4w0=; b=o0oV6imx6ibhskCg3TOjxVU6ibjfCGwOnvNs4RNp9WViSg+yqNMCh6ZeMW 7mdP2A+3EeChR5OLOORbmhMwQIF65ZP02dGW+KIYgRfvseALXXceBBYaKpya MjvB+bcRTT; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:10 PM 11/20/2008, Janet P Gunn wrote: >Agree. >Just needs to be made clearer that "there is no guidance in this doc >to be given on local policy" it already does this - but I can look (seriously) at making is clearer >Janet > >"James M. Polk" wrote on 11/20/2008 05:59:32 PM: > > > At 03:03 PM 11/20/2008, Janet P Gunn wrote: > > > > > > >"James M. Polk" wrote on 11/20/2008 03:46:30 PM: > > > > > > > > > > > > > > Just to be clear, this discussion is NOT something my namespace ID > > > > should ever address. I have no issues with having this discussion - > > > > but I want to make clear that > > > > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make > > > > priority decisions or even recommendations in the text of the doc. > > > > > > > > This ID only creates the namespace *and* the probably scenario in > > > > which it is intended. > > > > > > >Agree > > > > > > > > >Public net: > > > > >P1. ets/wps? (PSAPs may not be so eager to agree) > > > > >P2. esnet > > > > >P3. > > > > > > > > it's not as simple as that. > > > > > > > > each gets its own slot in any relative > > > > priority order (per section 8 of RFC4412). > > > > > > > > With this in mind, it is *possible* to have a relative priority > > > > order like this > > > > > > > > P1. ets.4 > > > > P2. esnet.4 > > > > P3. ets.3 wps.4 > > > > P4. esnet.3 esnet.2 > > > > P5. wps.3 ets.2 > > > > P6. wps.2 ets.1 > > > > P7. esnet.1 > > > > P8. esnet.0 > > > > P9. ets.0 wps.0 > > > > > > > > notice that within each , the numbering order is > > > > consistent, but that the order relative to the different namespaces > > > > is whatever the local operator wants to make them. > > > > > >At the risk of being a nitnoid, this would NOT be an RFC4412-legal > > >ordering,as it reverses the priority values of ets and wps (0 is > > the highest). > > > > shoot me for not remembering off the top of my pointy head the order > > of ets and wps > > > > ;-) > > > > the concept still holds though > > > > > > > > > I do show here > > > > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there > > > > are more than one namespace.priority-value combination. This means, > > > > within this priority - it's a FIFO situation in which each of the > > > > namespace.priority-value combinations at this priority level compete > > > > (i.e., they are equivalent in priority). This is all a local decision. > > > > > > > > I think a way to address Brian's comment about preemption is also a > > > > local decision (because the local jurisdiction needs to live with the > > > > consequences). Here's how that can be addressed: > > > > > > > > - all these namespace.priority-value combinations *can* be preempted > > > > > >I have serious heartburn with this statement. > > > > this is a comment that is NOT tied to this ID, because there is no > > guidance in this doc to be given on local policy other that the > > concept of relative priority, just to be clear > > > > > > >In the circuit switched paradigm of preemption (MLPP and eMLPP), > > >only calls that are identified a-priori as "part of a preemption > > >domain (or similar term)" can be preempted. "Normal" (unmarked, as > > >opposed to marked "routine") calls cannot be preempted. I REALLY > > >don't think we should break that aspect of the paradigm without > > >investigating "unintended consequences" in great detail. > > > > > > > - only certain namespace.priority-value combinations *can* preempt > > > > another call. > > > > > > > > just a thought about how to solve this... > > > > > > > > James > > > > > > > > > > > > >Private net (ESInet): > > > > >(anything they want) > > > > > > > > > >Lastly, what kind of prioritization does a government official (a > > > > >servant of the people) get when they themselves initiate an emergency > > > > >call? esnet or ets/wps? (In a private ESInet, it may be to their > > > > >disadvantage to keep the wrong one.) > > > > > > > > > >-roger marshall. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > > > On Behalf Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 9:01 AM > > > > > > To: 'Janet P Gunn' > > > > > > Cc: Ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > An "Emergency Services IP Network" is a private IP network to > > > > > > which, we hope, all public safety agencies are connected. It > > > > > > handles all the traffic of a public safety agency, which > > > > > > would include routine and priority citizen to authority, > > > > > > authority to authority and authority to citizen traffic. > > > > > > It's not entirely clear to me yet whether we can reuse a > > > > > > number of the existing name spaces as well as a new one. For > > > > > > example, some of the agency-agency traffic will require > > > > > > pre-emption, but the existing MLPP namespace may be quite > sufficient. > > > > > > > > > > > > It does occur to me that we could have ETS and possibly WPS > > > > > > traffic, in that if the normal access to public facilities > > > > > > traversed the ESInet towards some kind of gateway to a public > > > > > > network, then we would either have to have the ETS/WPS > > > > > > values, or remark them at the edge if a caller inside the > > > > > > ESInet needed to call someone outside the ESInet and needed > > > > > > ETS/WPS priority to do so. If we carried the priority > > > > > > marking across the ESInet, ETS/WPS would be lower priority > > > > > > than some other traffic, but higher than, for example, > > > > > > citizen to authority emergency calls. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > > > > Sent: Thursday, November 20, 2008 11:37 AM > > > > > > To: Brian Rosen > > > > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > > > > > Subject: RE: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > Brian, > > > > > > > > > > > > I need to understand this better. > > > > > > > > > > > > Exactly what are the constraints of the "emergency services > > > > > > IP network"? Is this a network in which EVERY call would > > > > > > have the RPH with the esnet namespace (just varying priority > > > > > > values),and there would be no "normal" calls? Or would their > > > > > > be a mixture of calls with and without RPH wit esnet? > > > > > > > > > > > > Janet > > > > > > > > > > > > "Brian Rosen" wrote on 11/20/2008 11:16:39 AM: > > > > > > > > > > > > > A suggestion was made to me that we should define two namespaces. > > > > > > > > > > > > > > One would be used in public networks, and generally would > > > > > > be used to request > > > > > > > resource priority for citizen to authority and possibly > > > > > > authority to citizen > > > > > > > calls. This would have lower priority than ETS/WPS. > > > > > > > > > > > > > > The other would be for use within emergency services IP > > > > > > networks. It would > > > > > > > be unlikely that ETS/WPS would be used within those > > > > > > networks, but if it was, > > > > > > > some values within the namespace would need higher priority > > > > > > that ETS/WPS. > > > > > > > For example, a message which was an incident commanders > > > > > > "evacuate" message > > > > > > > would be higher than a ETS/WPS traffic. On the other hand, > > > > > > a citizen to > > > > > > > authority emergency call would have lower priority. > > > > > > > > > > > > > > I would be happier with one namespace and more values in > > > > > > that namespace for > > > > > > > all of this, but I was advised that two namespaces was a > > > > > > better choice. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > > > > Janet P Gunn > > > > > > > Sent: Thursday, November 20, 2008 11:00 AM > > > > > > > To: GOLDMAN, STUART O (STUART) > > > > > > > Cc: Ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Ecrit] > > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > Stu, > > > > > > > > > > > > > > I intended to say that the esnet namespace needs to be at a > > > > > > LOWER priority > > > > > > > than the ets and wps namespaces, in any network that > > > > > > recognizes ets and wps > > > > > > > as described in 10.5 and 10.6 of RFC4412. > > > > > > > > > > > > > > Janet > > > > > > > > > > > > > > "GOLDMAN, STUART O \(STUART\)" > > > > > > wrote on > > > > > > > 11/20/2008 10:22:49 AM: > > > > > > > > > > > > > > > Janet, > > > > > > > > > > > > > > > > With regard to you e-mail below, did you intend that > > > > > > esnet could be > > > > > > > > at the same level of priority as ETS & WPS, or that ETS > > > > > > & WPS need > > > > > > > > to be at an even higher priority than esnet? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > > > Alcatel-Lucent > > > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > > > +1 602 493 8438 > > > > > > > > +1 480 414 1260 mobile > > > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > > > 10/27/2008 11:45 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > > > > > "James M. Polk" > > > > > > > > > > > > > > > > cc > > > > > > > > > > > > > > > > "'ECRIT'" , ecrit-bounces@ietf.org > > > > > > > > > > > > > > > > Subject > > > > > > > > > > > > > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize for not tracking this as closely as I meant > > > > > > to, as these > > > > > > > > comments apply to earlier versions as well. > > > > > > > > > > > > > > > > > > > > > > > > This sentence at the end of sec 1 doesn't quite work. > > > > > > > > "This document IANA registers the "esnet" > > > > > > > > RPH namespace for use within emergency services > > > > > > networks, not just > > > > > > > > of those from citizens to PSAPs." (no clear antecedent > > > > > > for "those") > > > > > > > > > > > > > > > > Perhaps > > > > > > > > "This document IANA registers the "esnet" > > > > > > > > RPH namespace for use within emergency services > > > > > > networks, not just > > > > > > > > for calls or sessions > > > > > > > > from citizens to PSAPs." > > > > > > > > > > > > > > > > Section 2 says > > > > > > > > "This document updates the behaviors of the SIP > Resource Priority > > > > > > > > header, defined in [RFC4412], during the treatment options > > > > > > > > surrounding this new "esnet" namespace only. The usage of the > > > > > > > > "esnet" namespace does not have a normal, or routine > > > > > > call level. > > > > > > > > Every use of this namespace will be in times of an > > > > > > emergency, where > > > > > > > > at least one end of the signaling is with a local emergency > > > > > > > > organization." > > > > > > > > > > > > > > > > I don't see this as an "update of the behavior of > 4412". Neither > > > > > > > > the ets namespace not the wps > > > > > > > > namespace have a "normal" or "routine" call level. Every > > > > > > use of the > > > > > > > > wps and ets namespaces will > > > > > > > > have priority over calls without RPH. > > > > > > > > > > > > > > > > You say "This > > > > > > > > namespace, therefore, MAY be overwritten or deleted, > > > > > > contrary to the > > > > > > > > rules of RFC 4412 [RFC4412]." > > > > > > > > > > > > > > > > It is not clear to me why this is "contrary to the rules > > > > > > of 4412". > > > > > > > > It is certainly anticipated > > > > > > > > that other RPH will be overwritten or deleted, when the UAS > > > > > > > > understands the namespace. > > > > > > > > > > > > > > > > 4412 says "Existing implementations of RFC 3261 that do > > > > > > not participate in > > > > > > > the > > > > > > > > resource priority mechanism follow the normal rules > of RFC 3261, > > > > > > > > Section 8.2.2: "If a UAS does not understand a > header field in a > > > > > > > > request (that is, the header field is not defined in this > > > > > > > > specification or in any supported extension), the server > > > > > > MUST ignore > > > > > > > > that header field and continue processing the message". " > > > > > > > > > > > > > > > > But I do not see anywhere that is says that a UAS that DOES > > > > > > > > understand the namespace is > > > > > > > > forbidden from deleting it. For instance, sec 4.7.1 > of 4412 says > > > > > > > > that "the UAC > > > > > > > > MAY attempt a subsequent request with the same or > > > > > > different resource > > > > > > > > value." This certainly implies the ability to overwrite > > > > > > or delete > > > > > > > > an RPH namespace. > > > > > > > > > > > > > > > > (See also, for instance the PTSC SAC document on the use > > > > > > of the ets > > > > > > > > and wps namespaces) > > > > > > > > > > > > > > > > Immediately following these statements, you give 3 options- > > > > > > > > "These proxies in the service provider > > > > > > > > MAY either > > > > > > > > > > > > > > > > o accept the existing RPH value with "esnet" in it, if one is > > > > > > > > present, and grant relative preferential treatment to > > > > > > the request > > > > > > > > when forwarding it to the ESINet. > > > > > > > > > > > > > > > > o replace any existing RPH value, if one is present, > > > > > > and insert an > > > > > > > > "esnet" namespace and give relative preferential > > > > > > treatment to the > > > > > > > > request when forwarding it to the ESINet. > > > > > > > > > > > > > > > > o insert an "esnet" namespace in a new RPH and give relative > > > > > > > > preferential treatment to the request when > forwarding the SIP > > > > > > > > request towards the ESINet." > > > > > > > > > > > > > > > > Why do you exclude the possibility of adding the > esnet RPH value > > > > > > > > without "replacing" an existing RPH value? > > > > > > > > > > > > > > > > Finally, there is another point that needs to be > made clear. At > > > > > > > > least one person has contacted me expressing concern > that this ID > > > > > > > > implied that the esnet namespace would have priority > over other > > > > > > > > namespaces (in particular wps and ets). I assured him > > > > > > that this was > > > > > > > > not the case, that there was nothing prevent the expected > > > > > > behavior - > > > > > > > > that the ets and wps namespaces would be prioritized > > > > > > ahead of esnet > > > > > > > > in GETS Service Provider networks. > > > > > > > > > > > > > > > > However, since the question has already arisen, it would > > > > > > be a good > > > > > > > > idea to clarify this, perhaps in section 3, where you > > > > > > discuss the > > > > > > > > other namespaces. In particular, it needs to be made clear in > > > > > > > > section 3.2 that, even if "the local jurisdiction > > > > > > preferred to > > > > > > > > preempt normal calls in lieu of > > > > > > > > completing emergency calls. ", esnet calls will NOT > > > > > > preempt wps or ets > > > > > > > calls. > > > > > > > > > > > > > > > > By the way, I think you mean "the local jurisdiction > > > > > > preferred to > > > > > > > > preempt normal calls in order to complete emergency > > > > > > calls. " - not > > > > > > > > "in lieu of". Or perhaps "the local jurisdiction > preferred to > > > > > > > > preempt normal calls in lieu of dropping emergency calls. " > > > > > > > > > > > > > > > > In fact, it is not clear to me that 4412 permits a call > > > > > > with an RPH > > > > > > > > (e.g., esnet) to preempt a "normal" call (with no RPH > > > > > > namespace). > > > > > > > > Section 4.7.2.1 of 4412 says > > > > > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm > > > > > > > > > > > > > > > > A UAS compliant with this specification MUST > terminate a session > > > > > > > > established with a valid namespace and lower-priority > > > > > > value in favor > > > > > > > > of a new session set up with a valid namespace and > > > > > > higher relative > > > > > > > > priority value, unless local policy has some form of > > > > > > call-waiting > > > > > > > > capability enabled. " > > > > > > > > > > > > > > > > It doesn't say anything about preempting a call with no RPH > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Janet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a PRIVATE message. If you are not the > intended recipient, > > > > > > > > please delete without copying and kindly advise us by > > > > > > e-mail of the > > > > > > > > mistake in delivery. > > > > > > > > NOTE: Regardless of content, this e-mail shall not > > > > > > operate to bind > > > > > > > > CSC to any order or other contract unless pursuant to explicit > > > > > > > > written agreement or government initiative expressly > > > > > > permitting the > > > > > > > > use of e-mail for such purpose. > > > > > > > > > > > > > > > > "James M. Polk" > > > > > > > > Sent by: ecrit-bounces@ietf.org > > > > > > > > 10/27/2008 08:32 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To > > > > > > > > > > > > > > > > "'ECRIT'" > > > > > > > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject > > > > > > > > > > > > > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ECRIT WG > > > > > > > > > > > > > > > > Here is a update to a ID I think is pretty near done, > > > > > > given that this > > > > > > > > is merely an IANA registration ID of an existing mechanism. > > > > > > > > > > > > > > > > Comments are wanted > > > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts > > > > > > > > >directories. > > > > > > > > >This draft is a work item of the Emergency Context > > > > > > Resolution with > > > > > > > > >Internet Technologies Working Group of the IETF. > > > > > > > > > > > > > > > > > > > > > > > > > > > Title : IANA Registering a SIP > > > > > > Resource Priority > > > > > > > > > Header Namespace for Local Emergency Communications > > > > > > > > > Author(s) : J. Polk > > > > > > > > > Filename : > > > > > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > > > > > > > Pages : 9 > > > > > > > > > Date : 2008-10-27 > > > > > > > > > > > > > > > > > >This document creates and IANA registers the new Session > > > > > > Initiation > > > > > > > > >Protocol (SIP) Resource Priority header (RPH) namespace > > > > > > "esnet" for > > > > > > > > >local emergency usage to a public safety answering > point (PSAP), > > > > > > > > >between PSAPs, and between a PSAP and first > responders and their > > > > > > > > >organizations. > > > > > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local- > > > > > > > > emergency-rph-namespace-00.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > emergency-rph-namespace-00.txt> > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > Stuart Goldman > > > > > > > > Alcatel-Lucent > > > > > > > > Stuart.Goldman@alcatel-lucent.com > > > > > > > > +1 602 493 8438 > > > > > > > > +1 480 414 1260 mobile > > > > > > > > P please save a tree by not printing this e-mail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > >CONFIDENTIALITY NOTICE: The information contained in this message > > > > >may be privileged and/or confidential. If you are not the intended > > > > >recipient, or responsible for delivering this message to the > > > > >intended recipient, any review, forwarding, dissemination, > > > > >distribution or copying of this communication or any attachment(s) > > > > >is strictly prohibited. If you have received this message in error, > > > > >please notify the sender immediately, and delete it and all > > > > >attachments from your computer and network. > > > > >_______________________________________________ > > > > >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 ecrit-bounces@ietf.org Thu Nov 20 15:30:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3199428C199; Thu, 20 Nov 2008 15:30:25 -0800 (PST) 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 3331B28C198 for ; Thu, 20 Nov 2008 15:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 KsHbyPDyvuZ6 for ; Thu, 20 Nov 2008 15:30:22 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C644628C197 for ; Thu, 20 Nov 2008 15:30:21 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_17_48_00 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 17:48:00 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 17:30:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 17:30:06 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3QAAHvRyAAAMac8AACEELQ References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> From: "Winterbottom, James" To: "Roger Marshall" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" X-OriginalArrivalTime: 20 Nov 2008 23:30:19.0740 (UTC) FILETIME=[F39961C0:01C94B67] Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, You and I have a different understanding then on how SUPL is invoked for emergency calling. It is my understanding that a SET has N x E-SLP certificates configured into it. When an emergency call is made, the network (P-CSCF) determines that an emergency call is being made, and proceeds to contact the local E-SLP. At that point, the E-SLP contacts the device, and IF the device has the cert for that E-SLP, then it will initiate communication back to the E-SLP for SUPL to continue. This is not really device discovery of the LCP-server in the same way that is done for HELD or DHCP. Cheers James > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, 21 November 2008 10:10 AM > To: Winterbottom, James; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Wait on... not the case for non-IMS emergency calls in SUPL. > > While it is true that SUPL goes to its home network for commercial > location and for any IMS call, it is not specified to do so with non-IMS > Emergency Roaming in SUPL 2.0 (Section 5.1.15.3). For that, an > emergency call uses the local (visited) E-SLP (and lesser-tiered V-SLP). > Both are assumed to be in the visited network. The device discovers the > E-SLP via MNC/MCC (network & country codes) supplied. > > -roger. > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, November 20, 2008 2:07 PM > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Only if the device is connected to its home network, else you > > require a world in a database solution. Inter-carrier roaming > > with SUPL is problematic to say the least. > > > > Cheers > > James > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > > > Roger Marshall > > > Sent: Friday, 21 November 2008 8:13 AM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > No objection to saying that SUPL in its present form is not a good > > > choice for wire-map, but would object to saying the same for other > > types > > > of 'non-measured' location. > > > > > > Rather, SUPL is in fact an excellent choice for > > non-endpoint measured > > > location such as 'CellID'. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. > > If we need > > > > to parse more carefully, SUPL isn't very suitable for > > wiremap forms > > > > of location determination. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > networks that don't use GPS or some form of measured location. > > > > > > > > [rsm - measured only - really? - surely you aren't > > suggesting that > > > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance > > on 'rough > > > > location' via CellID, are you? > > > > > > > > Wiremap location - given (manually input)] CellID > > location - given > > > > Terrestial trilateration - measured Celestial trilateration - > > > > measured Geocoded/reverse geocoded - derived > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > to 'given' > > > > location scenarios, aka wiremap, etc. that are more Wireline > > > > oriented, rather than mobile. For the future, wireline devices > > > > reduce in number, mobile (or even nomadic) devices will > > continue in > > > > their distribution bias. Fixed vs. Mobile has been the > > fundamental > > > > difference between how the IETF looks at things vs. these > > mentioned > > > > other fora. I contend that if we solve this for mobile - then we > > > > can begin communicating better with OMA/3GPP/3GPP2, > > and... Solving > > > > fixed will be easier. > > > > /] > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > has its own > > > > > version of that. > > > > > > > > > > All 3GPP networks I know of support a raw packet > > service. On that > > > > > service will run applications like MSN or AOL instant messaging. > > > > > Those services > > > > > will need to be able to make emergency chats. To route > > > > > properly, they need > > > > > location. That means that EVERY handset must deploy > > some LCP, and > > > > > must be able to get location suitable for emergency call > > > > routing and > > > > > dispatch per -phonebcp. The RV example is yet another > > case of the > > > > > same thing. The mistake is assuming that all emergency > > calls will > > > > > come through the E-CSCF. > > > > > They won't, and the 3GPP access network must conform to all the > > > > > -phonebcp requirements. > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access networks > > that > > > > > don't use GPS or some form of measured location. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > computers (and > > > > > related operating systems, SIP soft clients), analog terminal > > > > > adaptors, or other similar devices that are intended > > for use in a > > > > > wireline environment. I think that organizations that can drive > > > > > requirements for devices intended to be use in an environment > > where > > > > > SUPL would actually work, should be responsible for > > having device > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > absolutely > > > > > in a position to require SUPL support for devices that > > > > operate in an > > > > > environment where SUPL works. This is a perfect example of the > > > > > "closed" network that Brian describes somewhere (framework, > > > > I think). > > > > > > > > > > Phonebcp is about requirements for devices in access > > environments > > > > > where the operators of the access environment cannot be > > assumed to > > > > > have any control over the type or nature of devices that > > > > connect to or > > > > > through it. Phonebcp needs to continue to have that as its > > purpose. > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > SUPL, or > > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > To: Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > requiring PhoneBCP > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > would prefer > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > handsets/aircards over the next several years will (I > > > > predict) have a > > > > > SUPL stack included. In the same time frame, many of those > > > > will also > > > > > have WiFi support, others will have LTE or WiMAX support as > > hybrids. > > > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > > open-minded, and there is movement afoot to expand > > OMA/SUPL (as we > > > > > heard in the geopriv mtg. on Tuesday) w/respect > > expected proposals > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > there will be > > > > > fewer protocol, location representation, and privacy > > > > discontinuities - > > > > > things that too often get cited - yet are seldom well > > understood. > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > - not block > > > > > its use altogether. This is a case where we need to be > > > > inclusive, not > > > > > exclusive. > > > > > > > > > > As to the mobile RV sample case, the solution is also > > forseeable - > > > > > especially given that the location of the 3G aircard in the > > > > router is > > > > > good enough for routing. The scenario given needs some > > > > integration, > > > > > but is doable. Given that the aircard acts as a logical > > > > SET, with a > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > combination > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > applications to initiate and complete a location-routed, 3261 > > style > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > -roger. > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > To: 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that > > the > > > > > > clients are generally not very L2 aware. It's the clients > > > > > that have > > > > > > the problem. > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > common LCP so > > > > > > that non L2 aware devices can work, but you have to > > do that, and > > > > > > usually, that's impractical. Use my example. Suppose > > > > that the L2 > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > into the > > > > > > router could implement a SUPL client and a HELD server and > > > > > interwork > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > Ethernet VoIP > > > > > > phone could get location via HELD. Possible, but not > > practical. > > > > > > There are all sorts of these kinds of problems. That's why > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > standards for > > > > > > every access technology that's out there. What we can say > > > > > is that the > > > > > > paradigm for those protocols should be the same as at the > > > > IP layer: > > > > > > Clients MUST implement all, networks MUST implement at least > > one. > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > and clearer, > > > > > > I > > > > > > think.) > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > the possible > > > > > > protocols at lower layers, we should just state the general > > > > > rule. It > > > > > > seems to me that this achieves the same level of > > > > > interoperability at > > > > > > all layers. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > > any number > > > > > > > of optional ones, then every network has to implement at > > > > > > least one of > > > > > > > those > > > > > > two > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > "any number of > > > > > > > optional ones" is useless for both parties. > > > > > > > If the network can limit UAs to ONLY those that implement > > > > > > one of the > > > > > > > optional protocols, then it works, but in practice, it > > > > is usually > > > > > > impossible > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > phone in an > > > > > > > RV traveling down the road with wireless data card in a > > > > > > router. These > > > > > > > EXIST, now. > > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > for an RFC to > > > > > > > try to list all of the location protocols out there, if for > > > > > > no other > > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > > we should > > > > > > > say something like the following: > > > > > > > > > > > > > > " > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > [RFC4776] and > > > > > > > [RFC3825] and HELD > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > SHOULD support all location protocols supported at lower > > > > > layers by > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > >> The problem with SUPL is that the majority of networks > > > > > where SUPL > > > > > > >> would > > > > > > be > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > also has an > > > > > > >> incompatible location representation, and an incompatible > > > > > > privacy model. > > > > > > >> That makes it very hard to interwork with any of the rest > > > > > > of the IETF > > > > > > > work. > > > > > > >> I will say this. For quite some time, the IETF has been > > > > > trying to > > > > > > > interest > > > > > > >> OMA into cooperation on location so that we have > > > > > > interoperability at > > > > > > >> the protocol, location representation and privacy > > > > > levels. So far, > > > > > > >> that has > > > > > > > not > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > accomplish > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > not object. > > > > > > >> > > > > > > >> Brian > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > >> Hi, > > > > > > >> > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > agnostic but not > > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > > are highly > > > > > > >> probable to produce the intended result? > > > > > > >> > > > > > > >> There are restrictions everywhere, things come at a cost > > > > > > even in the > > > > > > >> general Internet model. The reality is that most of the > > > > > > devices with > > > > > > >> internet access have a home network already. > > > > > > >> > > > > > > >> - Gabor > > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > > >> >From: ext Winterbottom, James > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > - FI/Espoo) > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >Hi Gabor, > > > > > > >> > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > list, and is > > > > > > >> access- > > > > > > >> >type agnostic. > > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > > given that: > > > > > > >> >a) it requires a home network in order to operate > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > >> >c) it is questionable whether it is really deployable > > > > > for WiFi > > > > > > >> networks > > > > > > >> > > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > > Internet model? > > > > > > >> > > > > > > > >> >Cheers > > > > > > >> >James > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > Gabor.Bajko@nokia.com > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > >> >To: ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >I was requested to send my observations regarding this > > > > > > requirement: > > > > > > >> > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > location options > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > LLDP-MED [LLDP-MED]. > > > > > > >> > > > > > > > >> > > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > > are likely > > > > > > >> to be > > > > > > >> >supported in devices in a not so distant future. Since > > > > > > I have no > > > > > > >> seen or > > > > > > >> >heard about LLDP support yet, at least that should be > > > > > replaced > > > > > > >> with what > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > mechanism, with the > > > > > > >> >condition that this MUST only be supported if there > > > > is a wifi > > > > > > >> interface > > > > > > >> >available on the device. > > > > > > >> > > > > > > > >> >- Gabor > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >________________________________ > > > > > > >> > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > >> > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > marc.linsner@cisco.com > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >Gabor, > > > > > > >> > > > > > > > >> >Could you please raise your question about location > > > > > > protocols in > > > > > > >> Phone > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > >> > > > > > > > >> >Ciao > > > > > > >> >Hannes > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >This message is for the designated recipient > > only and may > > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > > information. > > > > > > >> >If you have received it in error, please notify > > the sender > > > > > > >> >immediately and delete the original. Any > > > > unauthorized use of > > > > > > >> >this email is prohibited. > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >[mf2] > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 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 > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > message may > > > > > be privileged and/or confidential. If you are not the intended > > > > > recipient, or responsible for delivering this message to > > > > the intended > > > > > recipient, any review, forwarding, dissemination, > > distribution or > > > > > copying of this communication or any attachment(s) is strictly > > > > > prohibited. If you have received this message in error, > > > > please notify > > > > > the sender immediately, and delete it and all attachments from > > your > > > > > computer and network. > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person > > > > or entity > > > > > to which it is addressed and may contain confidential, > > proprietary, > > > > > and/or privileged material. Any review, retransmission, > > > > dissemination > > > > > or other use of, or taking of any action in reliance upon this > > > > > information by persons or entities other than the intended > > > > recipient > > > > > is prohibited. If you received this in error, please > > contact the > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 15:39:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB623A6A71; Thu, 20 Nov 2008 15:39:49 -0800 (PST) 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 2C6D43A6A71 for ; Thu, 20 Nov 2008 15:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 Q8FiJy5FBjvW for ; Thu, 20 Nov 2008 15:39:45 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B4CFF3A6A5E for ; Thu, 20 Nov 2008 15:39:44 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_17_56_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 17:56:53 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 17:39:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 17:39:07 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3QAAHvRyAAAMac8AAB2EGw References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> From: "Dawson, Martin" To: "Roger Marshall" , "Winterbottom, James" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" X-OriginalArrivalTime: 20 Nov 2008 23:39:13.0445 (UTC) FILETIME=[31B64D50:01C94B69] Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Right - SUPL 2.0 now covers the option of SLPs that are present in the access and intended to support emergency location. However, the E-SLP procedures require a network-initiated ULP session to be established with the SET in order to get location. That is, the VSP/IMS service has to get this procedure kicked off. Then you get to the question of how the SET deals with an otherwise unsolicited location request from an SLP it doesn't recognize (i.e. didn't discover). This procedure is not consistent with ECRIT emergency call procedures - they are device centric with respect to initiating/controlling the location acquisition. It isn't even clear how a VSP could possibly know where to direct an MLP request to in order to bring the E-SLP into play. It works in certain IMS architectures but not in the general Internet case. There is clearly no reason that a suitably controlled environment couldn't use SUPL for the VoIP emergency call case - at least for initial location - and I don't think that BCP is saying it can't be the mechanism for generating location for an emergency call. It wouldn't be right to mandate that all devices have to have SUPL, for a number of reasons including the constraint that you can't actually have SUPL without a home SLP provider being configured into the SET. A vanilla, off the shelf, device can have perfectly functional HELD/DHCP capabilities without any third party dependency. In the case of the RV example, the 3G router could definitely have a SUPL client. I think the issue Brian is talking about is that all of the devices in the RV (that would actually be the source of the emergency call) would either be using WiFi or Ethernet to talk to the VSP. It doesn't help them that the router is a SET - unless the router turns around and acts as a LIS or provides location by DHCP. It would also be challenged by the lack of ability to get a location reference from the SLP that could be used for location updates in a mobile environment. Location URI is not available via SUPL. I think that, perhaps, the opportunity is to make the BCP more clearly state that other methods aren't excluded by the mandatory LCP list - it's just that the IETF isn't saying that all devices that use the ECRIT emergency calling model must also support those other methods. I believe I'm echoing Richard Barnes' sentiment in this respect. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Friday, 21 November 2008 10:10 AM To: Winterbottom, James; Brian Rosen; Stark, Barbara; Richard Barnes Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP Wait on... not the case for non-IMS emergency calls in SUPL. While it is true that SUPL goes to its home network for commercial location and for any IMS call, it is not specified to do so with non-IMS Emergency Roaming in SUPL 2.0 (Section 5.1.15.3). For that, an emergency call uses the local (visited) E-SLP (and lesser-tiered V-SLP). Both are assumed to be in the visited network. The device discovers the E-SLP via MNC/MCC (network & country codes) supplied. -roger. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, November 20, 2008 2:07 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Only if the device is connected to its home network, else you > require a world in a database solution. Inter-carrier roaming > with SUPL is problematic to say the least. > > Cheers > James > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Roger Marshall > > Sent: Friday, 21 November 2008 8:13 AM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > No objection to saying that SUPL in its present form is not a good > > choice for wire-map, but would object to saying the same for other > types > > of 'non-measured' location. > > > > Rather, SUPL is in fact an excellent choice for > non-endpoint measured > > location such as 'CellID'. > > > > -roger. > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:32 PM > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. > If we need > > > to parse more carefully, SUPL isn't very suitable for > wiremap forms > > > of location determination. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Thursday, November 20, 2008 3:22 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that don't use GPS or some form of measured location. > > > > > > [rsm - measured only - really? - surely you aren't > suggesting that > > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance > on 'rough > > > location' via CellID, are you? > > > > > > Wiremap location - given (manually input)] CellID > location - given > > > Terrestial trilateration - measured Celestial trilateration - > > > measured Geocoded/reverse geocoded - derived > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > to 'given' > > > location scenarios, aka wiremap, etc. that are more Wireline > > > oriented, rather than mobile. For the future, wireline devices > > > reduce in number, mobile (or even nomadic) devices will > continue in > > > their distribution bias. Fixed vs. Mobile has been the > fundamental > > > difference between how the IETF looks at things vs. these > mentioned > > > other fora. I contend that if we solve this for mobile - then we > > > can begin communicating better with OMA/3GPP/3GPP2, > and... Solving > > > fixed will be easier. > > > /] > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > has its own > > > > version of that. > > > > > > > > All 3GPP networks I know of support a raw packet > service. On that > > > > service will run applications like MSN or AOL instant messaging. > > > > Those services > > > > will need to be able to make emergency chats. To route > > > > properly, they need > > > > location. That means that EVERY handset must deploy > some LCP, and > > > > must be able to get location suitable for emergency call > > > routing and > > > > dispatch per -phonebcp. The RV example is yet another > case of the > > > > same thing. The mistake is assuming that all emergency > calls will > > > > come through the E-CSCF. > > > > They won't, and the 3GPP access network must conform to all the > > > > -phonebcp requirements. > > > > > > > > Generally, I agree that SUPL is unsuitable for access networks > that > > > > don't use GPS or some form of measured location. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > computers (and > > > > related operating systems, SIP soft clients), analog terminal > > > > adaptors, or other similar devices that are intended > for use in a > > > > wireline environment. I think that organizations that can drive > > > > requirements for devices intended to be use in an environment > where > > > > SUPL would actually work, should be responsible for > having device > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > absolutely > > > > in a position to require SUPL support for devices that > > > operate in an > > > > environment where SUPL works. This is a perfect example of the > > > > "closed" network that Brian describes somewhere (framework, > > > I think). > > > > > > > > Phonebcp is about requirements for devices in access > environments > > > > where the operators of the access environment cannot be > assumed to > > > > have any control over the type or nature of devices that > > > connect to or > > > > through it. Phonebcp needs to continue to have that as its > purpose. > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > SUPL, or > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > To: Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > requiring PhoneBCP > > > > suppport of SUPL, then my vote is to NOT prevent! I > would prefer > > > > 'require' since *most* of the location-aware 3G compatible > > > > handsets/aircards over the next several years will (I > > > predict) have a > > > > SUPL stack included. In the same time frame, many of those > > > will also > > > > have WiFi support, others will have LTE or WiMAX support as > hybrids. > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > open-minded, and there is movement afoot to expand > OMA/SUPL (as we > > > > heard in the geopriv mtg. on Tuesday) w/respect > expected proposals > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > there will be > > > > fewer protocol, location representation, and privacy > > > discontinuities - > > > > things that too often get cited - yet are seldom well > understood. > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > - not block > > > > its use altogether. This is a case where we need to be > > > inclusive, not > > > > exclusive. > > > > > > > > As to the mobile RV sample case, the solution is also > forseeable - > > > > especially given that the location of the 3G aircard in the > > > router is > > > > good enough for routing. The scenario given needs some > > > integration, > > > > but is doable. Given that the aircard acts as a logical > > > SET, with a > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > combination > > > > *WILL* (I believe) interoperate with a number of end client > > > > applications to initiate and complete a location-routed, 3261 > style > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > To: 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem is that > the > > > > > clients are generally not very L2 aware. It's the clients > > > > that have > > > > > the problem. > > > > > You can do things like interwork an L2 specific LCP to a > > > > common LCP so > > > > > that non L2 aware devices can work, but you have to > do that, and > > > > > usually, that's impractical. Use my example. Suppose > > > that the L2 > > > > > used SUPL. It's possible for the PC Card that is plugged > > > into the > > > > > router could implement a SUPL client and a HELD server and > > > > interwork > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > Ethernet VoIP > > > > > phone could get location via HELD. Possible, but not > practical. > > > > > There are all sorts of these kinds of problems. That's why > > > > > L2 specific LCPs don't work. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > standards for > > > > > every access technology that's out there. What we can say > > > > is that the > > > > > paradigm for those protocols should be the same as at the > > > IP layer: > > > > > Clients MUST implement all, networks MUST implement at least > one. > > > > > > > > > > (This is a little different from the text I sent before, > > > > and clearer, > > > > > I > > > > > think.) > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > the possible > > > > > protocols at lower layers, we should just state the general > > > > rule. It > > > > > seems to me that this achieves the same level of > > > > interoperability at > > > > > all layers. > > > > > > > > > > --Richard > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > any number > > > > > > of optional ones, then every network has to implement at > > > > > least one of > > > > > > those > > > > > two > > > > > > LCPs, and any number of optional ones. That means that > > > > > "any number of > > > > > > optional ones" is useless for both parties. > > > > > > If the network can limit UAs to ONLY those that implement > > > > > one of the > > > > > > optional protocols, then it works, but in practice, it > > > is usually > > > > > impossible > > > > > > to do that. My example is the wired, Ethernet connected > > > > > phone in an > > > > > > RV traveling down the road with wireless data card in a > > > > > router. These > > > > > > EXIST, now. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > for an RFC to > > > > > > try to list all of the location protocols out there, if for > > > > > no other > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > we should > > > > > > say something like the following: > > > > > > > > > > > > " > > > > > > INT-12 Devices MUST support the DHCP location options > > > > [RFC4776] and > > > > > > [RFC3825] and HELD > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > SHOULD support all location protocols supported at lower > > > > layers by > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > >> The problem with SUPL is that the majority of networks > > > > where SUPL > > > > > >> would > > > > > be > > > > > >> available have a proxy (E-CSCF) insert location. It > > > also has an > > > > > >> incompatible location representation, and an incompatible > > > > > privacy model. > > > > > >> That makes it very hard to interwork with any of the rest > > > > > of the IETF > > > > > > work. > > > > > >> I will say this. For quite some time, the IETF has been > > > > trying to > > > > > > interest > > > > > >> OMA into cooperation on location so that we have > > > > > interoperability at > > > > > >> the protocol, location representation and privacy > > > > levels. So far, > > > > > >> that has > > > > > > not > > > > > >> happened. If, as part of a comprehensive agreement to > > > > accomplish > > > > > >> such a goal, SUPL became one of the LCPs, I would > not object. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Is the intent to list the LCPs which are access-type > > > > > agnostic but not > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > are highly > > > > > >> probable to produce the intended result? > > > > > >> > > > > > >> There are restrictions everywhere, things come at a cost > > > > > even in the > > > > > >> general Internet model. The reality is that most of the > > > > > devices with > > > > > >> internet access have a home network already. > > > > > >> > > > > > >> - Gabor > > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Winterbottom, James > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > - FI/Espoo) > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >Hi Gabor, > > > > > >> > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > list, and is > > > > > >> access- > > > > > >> >type agnostic. > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > given that: > > > > > >> >a) it requires a home network in order to operate > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > >> >c) it is questionable whether it is really deployable > > > > for WiFi > > > > > >> networks > > > > > >> > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > Internet model? > > > > > >> > > > > > > >> >Cheers > > > > > >> >James > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > Gabor.Bajko@nokia.com > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > >> >To: ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >I was requested to send my observations regarding this > > > > > requirement: > > > > > >> > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > location options > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > LLDP-MED [LLDP-MED]. > > > > > >> > > > > > > >> > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > are likely > > > > > >> to be > > > > > >> >supported in devices in a not so distant future. Since > > > > > I have no > > > > > >> seen or > > > > > >> >heard about LLDP support yet, at least that should be > > > > replaced > > > > > >> with what > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > mechanism, with the > > > > > >> >condition that this MUST only be supported if there > > > is a wifi > > > > > >> interface > > > > > >> >available on the device. > > > > > >> > > > > > > >> >- Gabor > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >________________________________ > > > > > >> > > > > > > >> >From: ext Tschofenig, Hannes > > > > > >> > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > marc.linsner@cisco.com > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >Gabor, > > > > > >> > > > > > > >> >Could you please raise your question about location > > > > > protocols in > > > > > >> Phone > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > >> > > > > > > >> >Ciao > > > > > >> >Hannes > > > > > >> > > > > > > >> > > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >This message is for the designated recipient > only and may > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > information. > > > > > >> >If you have received it in error, please notify > the sender > > > > > >> >immediately and delete the original. Any > > > unauthorized use of > > > > > >> >this email is prohibited. > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >[mf2] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments from > your > > > > computer and network. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please > contact the > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 15:42:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D793A689E; Thu, 20 Nov 2008 15:42:19 -0800 (PST) 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 0D0993A689E for ; Thu, 20 Nov 2008 15:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJwba+SDsyH6 for ; Thu, 20 Nov 2008 15:42: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 CC9CA3A67F0 for ; Thu, 20 Nov 2008 15:42:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208,217";a="28539816" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 23:42:16 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKNgGWd011274 for ; Thu, 20 Nov 2008 18:42:16 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKNgGJv015269 for ; Thu, 20 Nov 2008 23:42:16 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:42:16 -0500 Received: from [130.129.94.188] ([10.21.87.210]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:42:01 -0500 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 20 Nov 2008 18:42:00 -0500 From: Marc Linsner To: "'ECRIT'" Message-ID: Thread-Topic: Webex and conference bridge info Thread-Index: AclLaZT8iUBdQRTtpkmt9NC1OWqOBA== Mime-version: 1.0 X-OriginalArrivalTime: 20 Nov 2008 23:42:02.0174 (UTC) FILETIME=[96484DE0:01C94B69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3237; t=1227224536; x=1228088536; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Webex=20and=20conference=20bridge=20info |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=q+XONEOCVzd35l3GcMwCAo7f0O+zsRms2PJAyX0Alaw=; b=CNv1cIxyA2MVXKigmDP2ma8Cvqlpm0fxK1FPdEyFOloqWWplvpbpIR3etX GbRLgc5wygI3RGSfFq7diqp4vMU0FOWQFyDymhfni97572xSSuKsX+BnqdHo CxK7/y+3Ta; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Ecrit] Webex and conference bridge info 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: , Content-Type: multipart/mixed; boundary="===============1214131277==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1214131277== Content-type: multipart/alternative; boundary="B_3310051321_2445712" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3310051321_2445712 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit * Conference Bridge We are also going to setup a conference bridge and maybe using Webex (see Jabber room before the meeting for more info). Here is the bridge info: Number: +1 (712) 432-1100 PIN: 292812# Webex for slides ONLY! (use the conference bridge above for audio) Topic: ECRIT Date: Thursday, November 20, 2008 Time: 6:45 pm, Eastern Standard Time (GMT -05:00, New York) Meeting Number: 920 537 309 Meeting Password: ecrit Please click the link below to see more information, or to join the meeting. ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=111133252&UID=0&PW=00dc0910 160f1b 2. Enter your name and email address. 3. Enter the meeting password: ecrit 4. Click "Join Now". 5. A 'Join Teleconference' dialogue box will be presented, select your country code, then enter your local number and click OK from the Web Conference to join the Voice Conference portion of the meeting. --B_3310051321_2445712 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Webex and conference bridge info * Conference Bridge

We are also going to setup a conference bridge and maybe using Webex
(see Jabber room before the meeting for more info). Here is the bridge
info:

Number: +1 (712) 432-1100
PIN: 292812#

Webex for slides ONLY! (use the conference bridge above for audio)
 Topic: ECRIT
 Date: Thursday, November 20, 2008
 Time: 6:45 pm, Eastern Standard Time (GMT -05:00, New York)
 Meeting Number: 920 537 309
 Meeting Password: ecrit
 
 Please click the link below to see more information, or to join the m= eeting.
 
 -------------------------------------------------------
 To join the online meeting
 -------------------------------------------------------
 1. Go to https://ci= scosales.webex.com/ciscosales/j.php?ED=3D111133252&UID=3D0&PW=3D00dc091016= 0f1b
 2. Enter your name and email address.
 3. Enter the meeting password: ecrit
 4. Click "Join Now".
 5. A 'Join Teleconference' dialogue box will be presented, select you= r country code, then enter your local number and click OK from the Web Confe= rence to join the Voice Conference portion of the meeting.
  --B_3310051321_2445712-- --===============1214131277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1214131277==-- From ecrit-bounces@ietf.org Thu Nov 20 17:20:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7A03A6A59; Thu, 20 Nov 2008 17:20:32 -0800 (PST) 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 B3ECC28C100 for ; Thu, 20 Nov 2008 17:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 ZIdZgI8ybLYz for ; Thu, 20 Nov 2008 17:20:31 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 09A623A69D8 for ; Thu, 20 Nov 2008 17:20:31 -0800 (PST) Received: from [128.89.255.114] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L3Kh6-00062D-DN for ecrit@ietf.org; Thu, 20 Nov 2008 20:20:24 -0500 Message-ID: <49260CD7.4020005@bbn.com> Date: Thu, 20 Nov 2008 19:20:23 -0600 From: Richard Barnes User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: ECRIT Subject: [Ecrit] Emergency calling without endpoint/VSP location support 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org In the ECRIT meeting at IETF 73, Hannes proposed forming a Design Team on what I'll call "IP-to-location" mapping. He correctly observed that several planned architectures for VoIP emergency calling involve PSAPs or VSPs doing something like the following process in order to get location information for endpoints: 1. Gets an emergency call from a caller at a given IP address 2. Determine the ISP responsible for that IP address 3. Fetch location from the ISP The solution above is *obviously* a hack, because step 2 involves a lot of uncertainty on any reasonable scale. However, the problem it addresses is real, especially in the short term: How should a VSP route a call if endpoints don't support location? (Likewise, how should a PSAP get location if VSPs and endpoints don't support location?) In order to address this problem, some sort of IP-to-location mapping will be required. As Jon pointed out in the meeting, this will not be solvable for the general Internet, for the same reason that we've always assumed that ISPs and VSPs are decoupled. However, I think this mapping can be enabled in certain circumstances, if the parties involved (ISPs, VSPs/PSAPs) have the right relationships and implement the right things. (Purposely vague, because I don't have a solution!) So I'd like to suggest that ECRIT think about a document of the following form: 1. Problem statement: Need to route emergency calls even when endpoints don't support location (get endpoint location at the PSAP when endpoints and VSPs don't provide it) 2. How and when this problem can be solved (and why it doesn't scale up to Internet) 3. How to transition from this system to the ECRIT architecture I don't know if I'm the best person to write such a document, but I'd be glad to help out. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 17:29:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE0B3A689E; Thu, 20 Nov 2008 17:29:47 -0800 (PST) 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 84BDA3A689E for ; Thu, 20 Nov 2008 17:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 CTZ8eun4BHgV for ; Thu, 20 Nov 2008 17:29:44 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 529C23A6873 for ; Thu, 20 Nov 2008 17:29:43 -0800 (PST) Received: (qmail invoked by alias); 21 Nov 2008 01:29:41 -0000 Received: from unknown (EHLO laura) [130.129.30.126] by mail.gmx.net (mp064) with SMTP; 21 Nov 2008 02:29:41 +0100 X-Authenticated: #51447468 X-Provags-ID: V01U2FsdGVkX19lr2IKaHJlJ6Ph/ct5IBtbHlaLwhPQ1D9H0pMwt5 2u5et7Fx2VCBaG Message-ID: From: "Laura Liess" To: "Richard Barnes" , "ECRIT" References: <49260CD7.4020005@bbn.com> Date: Fri, 21 Nov 2008 02:29:47 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Emergency calling without endpoint/VSP location support 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I fully support Richard's proposal. This is a real problem and must be solved. Laura ----- Original Message ----- From: "Richard Barnes" To: "ECRIT" Sent: Friday, November 21, 2008 2:20 AM Subject: [Ecrit] Emergency calling without endpoint/VSP location support > In the ECRIT meeting at IETF 73, Hannes proposed forming a Design Team on > what I'll call "IP-to-location" mapping. He correctly observed that > several planned architectures for VoIP emergency calling involve PSAPs or > VSPs doing something like the following process in order to get location > information for endpoints: > 1. Gets an emergency call from a caller at a given IP address > 2. Determine the ISP responsible for that IP address > 3. Fetch location from the ISP > > The solution above is *obviously* a hack, because step 2 involves a lot of > uncertainty on any reasonable scale. However, the problem it addresses is > real, especially in the short term: How should a VSP route a call if > endpoints don't support location? (Likewise, how should a PSAP get > location if VSPs and endpoints don't support location?) > > In order to address this problem, some sort of IP-to-location mapping will > be required. As Jon pointed out in the meeting, this will not be solvable > for the general Internet, for the same reason that we've always assumed > that ISPs and VSPs are decoupled. However, I think this mapping can be > enabled in certain circumstances, if the parties involved (ISPs, > VSPs/PSAPs) have the right relationships and implement the right things. > (Purposely vague, because I don't have a solution!) > > So I'd like to suggest that ECRIT think about a document of the following > form: > 1. Problem statement: Need to route emergency calls even when endpoints > don't support location (get endpoint location at the PSAP when endpoints > and VSPs don't provide it) > 2. How and when this problem can be solved (and why it doesn't scale up to > Internet) > 3. How to transition from this system to the ECRIT architecture > > I don't know if I'm the best person to write such a document, but I'd be > glad to help out. > > --Richard > _______________________________________________ > 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 ecrit-bounces@ietf.org Thu Nov 20 17:38:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107513A68F1; Thu, 20 Nov 2008 17:38:47 -0800 (PST) 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 F138E3A68EC for ; Thu, 20 Nov 2008 17:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 VozJH3iV37ws for ; Thu, 20 Nov 2008 17:38:45 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1B2F13A689E for ; Thu, 20 Nov 2008 17:38:44 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_20_19_56_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Nov 2008 19:56:24 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 19:38:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 19:38:41 -0600 Message-ID: In-Reply-To: <49260CD7.4020005@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency calling without endpoint/VSP location support Thread-Index: AclLd/jxA1YJN5LaT0eZ7moiTRw8xAAAWr6A References: <49260CD7.4020005@bbn.com> From: "Thomson, Martin" To: "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 21 Nov 2008 01:38:43.0473 (UTC) FILETIME=[E361C010:01C94B79] Subject: Re: [Ecrit] Emergency calling without endpoint/VSP location support 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I believe that the tie between PSAP and ISP might be possible - both require a physical presence. Under the conditions where the VSP also has a tie, this could work. I've seen a number of proposals and am quite interested in working on a solution. Cheers, Martin (My gut feel is that this might cross over into the GEOPRIV work relating to LIS discovery, but we can work that out as we go.) > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 20 November 2008 7:20 PM > To: ECRIT > Subject: [Ecrit] Emergency calling without endpoint/VSP location > support > > In the ECRIT meeting at IETF 73, Hannes proposed forming a Design Team > on what I'll call "IP-to-location" mapping. He correctly observed that > several planned architectures for VoIP emergency calling involve PSAPs > or VSPs doing something like the following process in order to get > location information for endpoints: > 1. Gets an emergency call from a caller at a given IP address > 2. Determine the ISP responsible for that IP address > 3. Fetch location from the ISP > > The solution above is *obviously* a hack, because step 2 involves a lot > of uncertainty on any reasonable scale. However, the problem it > addresses is real, especially in the short term: How should a VSP route > a call if endpoints don't support location? (Likewise, how should a > PSAP get location if VSPs and endpoints don't support location?) > > In order to address this problem, some sort of IP-to-location mapping > will be required. As Jon pointed out in the meeting, this will not be > solvable for the general Internet, for the same reason that we've > always > assumed that ISPs and VSPs are decoupled. However, I think this > mapping > can be enabled in certain circumstances, if the parties involved (ISPs, > VSPs/PSAPs) have the right relationships and implement the right > things. > (Purposely vague, because I don't have a solution!) > > So I'd like to suggest that ECRIT think about a document of the > following form: > 1. Problem statement: Need to route emergency calls even when endpoints > don't support location (get endpoint location at the PSAP when > endpoints > and VSPs don't provide it) > 2. How and when this problem can be solved (and why it doesn't scale up > to Internet) > 3. How to transition from this system to the ECRIT architecture > > I don't know if I'm the best person to write such a document, but I'd > be > glad to help out. > > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 18:16:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D053A68F1; Thu, 20 Nov 2008 18:16:03 -0800 (PST) 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 542573A68F1 for ; Thu, 20 Nov 2008 18:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 IZxyf5qVqoBv for ; Thu, 20 Nov 2008 18:16:01 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 564303A68B4 for ; Thu, 20 Nov 2008 18:16:01 -0800 (PST) Received: from [192.168.0.61] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAL2Fs2E009398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 20 Nov 2008 21:15:57 -0500 (EST) Message-Id: <3477F54D-EA09-4789-8003-65F9B20E3136@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 21:15:54 -0500 X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Following up on what Ted said, I think one of the problems we may have in communicating is that we haven't quite captured all the cases. Currently, it says "mistakes are inevitablely made", but doesn't really identify whose mistakes. (This sounds like something said after Katrina...) I think the crucial distinction is the intent of the user for "premature disconnects", where we have roughly three cases: (1) unintentional, user error (hit wrong button) (2) unintentional, system error (something wrong in the end system, proxy or call path, e.g., our VoIP phone system predictably drops all calls after one hour or certain NATs start having a senior moment). (3) intentional disconnect (user really meant to disconnect), but call taker wants to keep talking. I think we all agree that we want to prevent (1) to the extent feasible. The (1) problem goes beyond disconnect. As I just found out during the ECRIT session, forgetting to disengage the mute button is at least as common as accidentally hanging up. (2) is much harder, as the end system may not know that anything is amiss. In the case I mentioned, the phone keeps on sending audio. I don't think we can reasonably solve (2) in this context, as setting up a new call may exactly fix the problem, since it gets things unwedged. (This is true for the case of our one-hour call limit and may also be true for forgetful-NAT cases.) On (3), we probably disagree how much work the caller needs to declare his or her intent, but we seem to agree on the general principle that the device owner is ultimately in charge. Also, in the requirements, I think it would be helpful to distinguish two cases, again echoing Ted (and others), namely whether the end system reliably knows that it is in an emergency call (or callback) or whether it doesn't. Starting with teasing apart the cases in the Section 1 may help us to make progress. I'd also re-title the document from "premature" to "unintentional". Finally, what's feasible for various user actions strongly depends on the physical characteristics of the phone, and we probably have different pictures in our minds as to the ones we care about. A cell phone, LCD-equipped desk phone or soft phone have very different possibilities than a hard phone connected via a terminal adapter. Obviously, the current experience is mostly with devices that are much closer to 2500 sets than smart phones, but that's not exactly the future. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 20 21:21:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27253A69ED; Thu, 20 Nov 2008 21:21:52 -0800 (PST) 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 3D7D33A69ED for ; Thu, 20 Nov 2008 21:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 EKumHBTsIAau for ; Thu, 20 Nov 2008 21:21:50 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2EB503A6922 for ; Thu, 20 Nov 2008 21:21:49 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAL5Ld8E010054; Thu, 20 Nov 2008 23:21:39 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 23:21:38 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 06:21:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 06:21:33 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> From: "DRAGE, Keith \(Keith\)" To: "Roger Marshall" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" X-OriginalArrivalTime: 21 Nov 2008 05:21:36.0273 (UTC) FILETIME=[06311810:01C94B99] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We are moving towards a state where devices support multiple of these, and in some cases where they may be active at the same time. We certainly already have devices that may be simultaneously registered in WLAN and 3GPP access. As soon as you start distinguishing any type of phone by access technology, you will end up with these devices having to support multiple different requirements. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Roger Marshall > Sent: Thursday, November 20, 2008 9:07 PM > To: Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Isn't there a need to set the scope [text] of phonebcp, so > that it makes clear what that the requirements apply (without > bias) to both fixed and mobile end devices (and their > associated network deployment types)? > > Below is some keyword sampling to show some implications with > regard to fixed vs. mobile, but which isn't as crisp as it > could be (depending on the scope). > > A search of phonebcp for the following terms yields the associated > references: > > Fixed: > (none); > > Wireline: > (none); > > Mobile: > AN-11; > ED-35/AN-19; > ED-35; > > Wireless: > AN-7/INT-6; > AN-9; > AN-7; > INT-6; > > From the toc, it is listed... > > 6.2.2. Access network "wire database" location > information . 7 > 6.2.3. End-system measured location information . . . > . . . . 7 > 6.2.4. Network-measured location information . . . . > . . . . 8 > > -roger. > > > No mention of fixed, wireline, wireless, or mobile in any of > the text sections (Intro, etc.) > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 20, 2008 12:32 PM > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > we need to > > parse more carefully, SUPL isn't very suitable for wiremap forms of > > location determination. > > > > Brian > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Thursday, November 20, 2008 3:22 PM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that don't use GPS or some form of measured location. > > > > [rsm - measured only - really? - surely you aren't > suggesting that OMA > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > location' via CellID, are you? > > > > Wiremap location - given (manually input)] CellID location - given > > Terrestial trilateration - measured Celestial trilateration > - measured > > Geocoded/reverse geocoded - derived > > > > I would hope that PhoneBCP doesn't show a pre-disposition to 'given' > > location scenarios, aka wiremap, etc. that are more > Wireline oriented, > > rather than mobile. For the future, wireline devices reduce in > > number, mobile (or even nomadic) devices will continue in their > > distribution bias. Fixed vs. Mobile has been the fundamental > > difference between how the IETF looks at things vs. these mentioned > > other fora. I contend that if we solve this for mobile - > then we can > > begin communicating better with OMA/3GPP/3GPP2, and... > Solving fixed > > will be easier. > > /] > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:07 PM > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd has its own > > > version of that. > > > > > > All 3GPP networks I know of support a raw packet service. > On that > > > service will run applications like MSN or AOL instant messaging. > > > Those services > > > will need to be able to make emergency chats. To route > > > properly, they need > > > location. That means that EVERY handset must deploy some > LCP, and > > > must be able to get location suitable for emergency call > > routing and > > > dispatch per -phonebcp. The RV example is yet another > case of the > > > same thing. The mistake is assuming that all emergency > calls will > > > come through the E-CSCF. > > > They won't, and the 3GPP access network must conform to all the > > > -phonebcp requirements. > > > > > > Generally, I agree that SUPL is unsuitable for access > networks that > > > don't use GPS or some form of measured location. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 20, 2008 2:54 PM > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > computers (and > > > related operating systems, SIP soft clients), analog terminal > > > adaptors, or other similar devices that are intended for use in a > > > wireline environment. I think that organizations that can drive > > > requirements for devices intended to be use in an > environment where > > > SUPL would actually work, should be responsible for having device > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > absolutely > > > in a position to require SUPL support for devices that > > operate in an > > > environment where SUPL works. This is a perfect example of the > > > "closed" network that Brian describes somewhere (framework, > > I think). > > > > > > Phonebcp is about requirements for devices in access environments > > > where the operators of the access environment cannot be > assumed to > > > have any control over the type or nature of devices that > > connect to or > > > through it. Phonebcp needs to continue to have that as > its purpose. > > > > > > I agree that nothing in phonebcp should preclude the use of > > SUPL, or > > > be incompatible with the use of SUPL. And I don't think it does. > > > Barbara > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 2:36 PM > > > To: Brian Rosen; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > If the choice is between preventing, allowing, or > > requiring PhoneBCP > > > suppport of SUPL, then my vote is to NOT prevent! I would prefer > > > 'require' since *most* of the location-aware 3G compatible > > > handsets/aircards over the next several years will (I > > predict) have a > > > SUPL stack included. In the same time frame, many of those > > will also > > > have WiFi support, others will have LTE or WiMAX support > as hybrids. > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > open-minded, and there is movement afoot to expand > OMA/SUPL (as we > > > heard in the geopriv mtg. on Tuesday) w/respect expected > proposals > > > such as LocSIP, etc. Over the fairly near-term, I think > > there will be > > > fewer protocol, location representation, and privacy > > discontinuities - > > > things that too often get cited - yet are seldom well understood. > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > - not block > > > its use altogether. This is a case where we need to be > > inclusive, not > > > exclusive. > > > > > > As to the mobile RV sample case, the solution is also > forseeable - > > > especially given that the location of the 3G aircard in the > > router is > > > good enough for routing. The scenario given needs some > > integration, > > > but is doable. Given that the aircard acts as a logical > > SET, with a > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > combination > > > *WILL* (I believe) interoperate with a number of end client > > > applications to initiate and complete a location-routed, > 3261 style > > > SIP, emergency call through the core, and into an ESInet. > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Brian Rosen > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > To: 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > It's very hard to have L2 specific LCPs. The problem > is that the > > > > clients are generally not very L2 aware. It's the clients > > > that have > > > > the problem. > > > > You can do things like interwork an L2 specific LCP to a > > > common LCP so > > > > that non L2 aware devices can work, but you have to do > that, and > > > > usually, that's impractical. Use my example. Suppose > > that the L2 > > > > used SUPL. It's possible for the PC Card that is plugged > > into the > > > > router could implement a SUPL client and a HELD server and > > > interwork > > > > SUPL in the GSM system to HELD on the Ethernet so the > > Ethernet VoIP > > > > phone could get location via HELD. Possible, but not practical. > > > > There are all sorts of these kinds of problems. That's why > > > > L2 specific LCPs don't work. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > To: Brian Rosen > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > ecrit@ietf.org; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > The IETF can't (and shouldn't) try to make particular > > standards for > > > > every access technology that's out there. What we can say > > > is that the > > > > paradigm for those protocols should be the same as at the > > IP layer: > > > > Clients MUST implement all, networks MUST implement at > least one. > > > > > > > > (This is a little different from the text I sent before, > > > and clearer, > > > > I > > > > think.) > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > the possible > > > > protocols at lower layers, we should just state the general > > > rule. It > > > > seems to me that this achieves the same level of > > > interoperability at > > > > all layers. > > > > > > > > --Richard > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > any number > > > > > of optional ones, then every network has to implement at > > > > least one of > > > > > those > > > > two > > > > > LCPs, and any number of optional ones. That means that > > > > "any number of > > > > > optional ones" is useless for both parties. > > > > > If the network can limit UAs to ONLY those that implement > > > > one of the > > > > > optional protocols, then it works, but in practice, it > > is usually > > > > impossible > > > > > to do that. My example is the wired, Ethernet connected > > > > phone in an > > > > > RV traveling down the road with wireless data card in a > > > > router. These > > > > > EXIST, now. > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > for an RFC to > > > > > try to list all of the location protocols out there, if for > > > > no other > > > > > reason than that it will rapidly become obsolete. Instead, > > > > we should > > > > > say something like the following: > > > > > > > > > > " > > > > > INT-12 Devices MUST support the DHCP location options > > > [RFC4776] and > > > > > [RFC3825] and HELD > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > SHOULD support all location protocols supported at lower > > > layers by > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > >> The problem with SUPL is that the majority of networks > > > where SUPL > > > > >> would > > > > be > > > > >> available have a proxy (E-CSCF) insert location. It > > also has an > > > > >> incompatible location representation, and an incompatible > > > > privacy model. > > > > >> That makes it very hard to interwork with any of the rest > > > > of the IETF > > > > > work. > > > > >> I will say this. For quite some time, the IETF has been > > > trying to > > > > > interest > > > > >> OMA into cooperation on location so that we have > > > > interoperability at > > > > >> the protocol, location representation and privacy > > > levels. So far, > > > > >> that has > > > > > not > > > > >> happened. If, as part of a comprehensive agreement to > > > accomplish > > > > >> such a goal, SUPL became one of the LCPs, I would not object. > > > > >> > > > > >> Brian > > > > >> > > > > >> -----Original Message----- > > > > >> From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > >> Hi, > > > > >> > > > > >> Is the intent to list the LCPs which are access-type > > > > agnostic but not > > > > >> supported anywhere, or instead have a list of LCPs which > > > > are highly > > > > >> probable to produce the intended result? > > > > >> > > > > >> There are restrictions everywhere, things come at a cost > > > > even in the > > > > >> general Internet model. The reality is that most of the > > > > devices with > > > > >> internet access have a home network already. > > > > >> > > > > >> - Gabor > > > > >> > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: ext Winterbottom, James > > > > [mailto:James.Winterbottom@andrew.com] > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > - FI/Espoo) > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >Hi Gabor, > > > > >> > > > > > >> >The list of LCPs in the phone BCP is a must support > > > list, and is > > > > >> access- > > > > >> >type agnostic. > > > > >> >I am curious that you say that SUPL is a MUST support > > > > given that: > > > > >> >a) it requires a home network in order to operate > > > > >> >b) it simply doesn't work for DSL or Cable > > > > >> >c) it is questionable whether it is really deployable > > > for WiFi > > > > >> networks > > > > >> > > > > > >> >Can you perhaps describe how it fits into the general > > > > Internet model? > > > > >> > > > > > >> >Cheers > > > > >> >James > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > Gabor.Bajko@nokia.com > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > >> >To: ecrit@ietf.org > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > >> > > > > > >> >I was requested to send my observations regarding this > > > > requirement: > > > > >> > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > location options > > > > >> > [RFC4776] and [RFC3825], HELD > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > LLDP-MED [LLDP-MED]. > > > > >> > > > > > >> > > > > > >> >I believe we should come up with a list of LCPs which > > > > are likely > > > > >> to be > > > > >> >supported in devices in a not so distant future. Since > > > > I have no > > > > >> seen or > > > > >> >heard about LLDP support yet, at least that should be > > > replaced > > > > >> with what > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > mechanism, with the > > > > >> >condition that this MUST only be supported if there > > is a wifi > > > > >> interface > > > > >> >available on the device. > > > > >> > > > > > >> >- Gabor > > > > >> > > > > > >> > > > > > >> > > > > > >> >________________________________ > > > > >> > > > > > >> >From: ext Tschofenig, Hannes > > > > >> > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); marc.linsner@cisco.com > > > > >> >Subject: Location Protocols in Phone BCP > > > > >> > > > > > >> > > > > > >> > > > > > >> >Gabor, > > > > >> > > > > > >> >Could you please raise your question about location > > > > protocols in > > > > >> Phone > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > >> > > > > > >> >Ciao > > > > >> >Hannes > > > > >> > > > > > >> > > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >This message is for the designated recipient only and may > > > > >> >contain privileged, proprietary, or otherwise private > > > > information. > > > > >> >If you have received it in error, please notify the sender > > > > >> >immediately and delete the original. Any > > unauthorized use of > > > > >> >this email is prohibited. > > > > >> > > > > >>> > > > > > > -------------------------------------------------------------------- > > > > >>> --- > > > > >> -- > > > > >> >----------------------- > > > > >> >[mf2] > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > message may > > > be privileged and/or confidential. If you are not the intended > > > recipient, or responsible for delivering this message to > > the intended > > > recipient, any review, forwarding, dissemination, distribution or > > > copying of this communication or any attachment(s) is strictly > > > prohibited. If you have received this message in error, > > please notify > > > the sender immediately, and delete it and all attachments > from your > > > computer and network. > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > > to which it is addressed and may contain confidential, > proprietary, > > > and/or privileged material. Any review, retransmission, > > dissemination > > > or other use of, or taking of any action in reliance upon this > > > information by persons or entities other than the intended > > recipient > > > is prohibited. If you received this in error, please contact the > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > _______________________________________________ > 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 ecrit-bounces@ietf.org Fri Nov 21 07:30:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D8D3A6908; Fri, 21 Nov 2008 07:30:10 -0800 (PST) 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 367903A6908 for ; Fri, 21 Nov 2008 07:30:09 -0800 (PST) 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 jLzpn+LXTP6e for ; Fri, 21 Nov 2008 07:30:07 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id D74973A688F for ; Fri, 21 Nov 2008 07:30:06 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 21 Nov 2008 07:30:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 07:28:48 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> From: "Roger Marshall" To: "DRAGE, Keith (Keith)" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Keith: I agree completely with the first part of what you said, and want to clarify my intent of highlighting differences in general: We've already got different requirements by access 'type' (i.e., 'wireless' and 'mobile' mentioned by name), so for some other requirements - certainly, I would think those that mention the term 'wire database' - those imply their application to a fixed type of network access (it wouldn't work to well for mobile). What I was asking for, (and to my understanding, it was agreed to in the ecrit meeting), was that since these requirements already mention different access types, that there should be some additional text that acknowledges the existance of these different access types, as background for their respective requirements. -roger. > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Thursday, November 20, 2008 9:22 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > We are moving towards a state where devices support multiple > of these, and in some cases where they may be active at the same time. > > We certainly already have devices that may be simultaneously > registered in WLAN and 3GPP access. > > As soon as you start distinguishing any type of phone by > access technology, you will end up with these devices having > to support multiple different requirements. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, November 20, 2008 9:07 PM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > > makes clear what that the requirements apply (without > > bias) to both fixed and mobile end devices (and their associated > > network deployment types)? > > > > Below is some keyword sampling to show some implications > with regard > > to fixed vs. mobile, but which isn't as crisp as it could be > > (depending on the scope). > > > > A search of phonebcp for the following terms yields the associated > > references: > > > > Fixed: > > (none); > > > > Wireline: > > (none); > > > > Mobile: > > AN-11; > > ED-35/AN-19; > > ED-35; > > > > Wireless: > > AN-7/INT-6; > > AN-9; > > AN-7; > > INT-6; > > > > From the toc, it is listed... > > > > 6.2.2. Access network "wire database" location > information . > > 7 > > 6.2.3. End-system measured location information . . . > > . . . . 7 > > 6.2.4. Network-measured location information . . . . > > . . . . 8 > > > > -roger. > > > > > > No mention of fixed, wireline, wireless, or mobile in any > of the text > > sections (Intro, etc.) > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:32 PM > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > we need to > > > parse more carefully, SUPL isn't very suitable for > wiremap forms of > > > location determination. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Thursday, November 20, 2008 3:22 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that don't use GPS or some form of measured location. > > > > > > [rsm - measured only - really? - surely you aren't > > suggesting that OMA > > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > > location' via CellID, are you? > > > > > > Wiremap location - given (manually input)] CellID > location - given > > > Terrestial trilateration - measured Celestial trilateration > > - measured > > > Geocoded/reverse geocoded - derived > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > to 'given' > > > location scenarios, aka wiremap, etc. that are more > > Wireline oriented, > > > rather than mobile. For the future, wireline devices reduce in > > > number, mobile (or even nomadic) devices will continue in their > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > difference between how the IETF looks at things vs. these > mentioned > > > other fora. I contend that if we solve this for mobile - > > then we can > > > begin communicating better with OMA/3GPP/3GPP2, and... > > Solving fixed > > > will be easier. > > > /] > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > has its own > > > > version of that. > > > > > > > > All 3GPP networks I know of support a raw packet service. > > On that > > > > service will run applications like MSN or AOL instant messaging. > > > > Those services > > > > will need to be able to make emergency chats. To route > > > > properly, they need > > > > location. That means that EVERY handset must deploy some > > LCP, and > > > > must be able to get location suitable for emergency call > > > routing and > > > > dispatch per -phonebcp. The RV example is yet another > > case of the > > > > same thing. The mistake is assuming that all emergency > > calls will > > > > come through the E-CSCF. > > > > They won't, and the 3GPP access network must conform to all the > > > > -phonebcp requirements. > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > networks that > > > > don't use GPS or some form of measured location. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > computers (and > > > > related operating systems, SIP soft clients), analog terminal > > > > adaptors, or other similar devices that are intended > for use in a > > > > wireline environment. I think that organizations that can drive > > > > requirements for devices intended to be use in an > > environment where > > > > SUPL would actually work, should be responsible for > having device > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > absolutely > > > > in a position to require SUPL support for devices that > > > operate in an > > > > environment where SUPL works. This is a perfect example of the > > > > "closed" network that Brian describes somewhere (framework, > > > I think). > > > > > > > > Phonebcp is about requirements for devices in access > environments > > > > where the operators of the access environment cannot be > > assumed to > > > > have any control over the type or nature of devices that > > > connect to or > > > > through it. Phonebcp needs to continue to have that as > > its purpose. > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > SUPL, or > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > To: Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > requiring PhoneBCP > > > > suppport of SUPL, then my vote is to NOT prevent! I > would prefer > > > > 'require' since *most* of the location-aware 3G compatible > > > > handsets/aircards over the next several years will (I > > > predict) have a > > > > SUPL stack included. In the same time frame, many of those > > > will also > > > > have WiFi support, others will have LTE or WiMAX support > > as hybrids. > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > open-minded, and there is movement afoot to expand > > OMA/SUPL (as we > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > proposals > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > there will be > > > > fewer protocol, location representation, and privacy > > > discontinuities - > > > > things that too often get cited - yet are seldom well > understood. > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > - not block > > > > its use altogether. This is a case where we need to be > > > inclusive, not > > > > exclusive. > > > > > > > > As to the mobile RV sample case, the solution is also > > forseeable - > > > > especially given that the location of the 3G aircard in the > > > router is > > > > good enough for routing. The scenario given needs some > > > integration, > > > > but is doable. Given that the aircard acts as a logical > > > SET, with a > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > combination > > > > *WILL* (I believe) interoperate with a number of end client > > > > applications to initiate and complete a location-routed, > > 3261 style > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > To: 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > is that the > > > > > clients are generally not very L2 aware. It's the clients > > > > that have > > > > > the problem. > > > > > You can do things like interwork an L2 specific LCP to a > > > > common LCP so > > > > > that non L2 aware devices can work, but you have to do > > that, and > > > > > usually, that's impractical. Use my example. Suppose > > > that the L2 > > > > > used SUPL. It's possible for the PC Card that is plugged > > > into the > > > > > router could implement a SUPL client and a HELD server and > > > > interwork > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > Ethernet VoIP > > > > > phone could get location via HELD. Possible, but not > practical. > > > > > There are all sorts of these kinds of problems. That's why > > > > > L2 specific LCPs don't work. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > standards for > > > > > every access technology that's out there. What we can say > > > > is that the > > > > > paradigm for those protocols should be the same as at the > > > IP layer: > > > > > Clients MUST implement all, networks MUST implement at > > least one. > > > > > > > > > > (This is a little different from the text I sent before, > > > > and clearer, > > > > > I > > > > > think.) > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > the possible > > > > > protocols at lower layers, we should just state the general > > > > rule. It > > > > > seems to me that this achieves the same level of > > > > interoperability at > > > > > all layers. > > > > > > > > > > --Richard > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > any number > > > > > > of optional ones, then every network has to implement at > > > > > least one of > > > > > > those > > > > > two > > > > > > LCPs, and any number of optional ones. That means that > > > > > "any number of > > > > > > optional ones" is useless for both parties. > > > > > > If the network can limit UAs to ONLY those that implement > > > > > one of the > > > > > > optional protocols, then it works, but in practice, it > > > is usually > > > > > impossible > > > > > > to do that. My example is the wired, Ethernet connected > > > > > phone in an > > > > > > RV traveling down the road with wireless data card in a > > > > > router. These > > > > > > EXIST, now. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > for an RFC to > > > > > > try to list all of the location protocols out there, if for > > > > > no other > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > we should > > > > > > say something like the following: > > > > > > > > > > > > " > > > > > > INT-12 Devices MUST support the DHCP location options > > > > [RFC4776] and > > > > > > [RFC3825] and HELD > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > SHOULD support all location protocols supported at lower > > > > layers by > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > >> The problem with SUPL is that the majority of networks > > > > where SUPL > > > > > >> would > > > > > be > > > > > >> available have a proxy (E-CSCF) insert location. It > > > also has an > > > > > >> incompatible location representation, and an incompatible > > > > > privacy model. > > > > > >> That makes it very hard to interwork with any of the rest > > > > > of the IETF > > > > > > work. > > > > > >> I will say this. For quite some time, the IETF has been > > > > trying to > > > > > > interest > > > > > >> OMA into cooperation on location so that we have > > > > > interoperability at > > > > > >> the protocol, location representation and privacy > > > > levels. So far, > > > > > >> that has > > > > > > not > > > > > >> happened. If, as part of a comprehensive agreement to > > > > accomplish > > > > > >> such a goal, SUPL became one of the LCPs, I would > not object. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Is the intent to list the LCPs which are access-type > > > > > agnostic but not > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > are highly > > > > > >> probable to produce the intended result? > > > > > >> > > > > > >> There are restrictions everywhere, things come at a cost > > > > > even in the > > > > > >> general Internet model. The reality is that most of the > > > > > devices with > > > > > >> internet access have a home network already. > > > > > >> > > > > > >> - Gabor > > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Winterbottom, James > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > - FI/Espoo) > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >Hi Gabor, > > > > > >> > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > list, and is > > > > > >> access- > > > > > >> >type agnostic. > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > given that: > > > > > >> >a) it requires a home network in order to operate > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > >> >c) it is questionable whether it is really deployable > > > > for WiFi > > > > > >> networks > > > > > >> > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > Internet model? > > > > > >> > > > > > > >> >Cheers > > > > > >> >James > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > Gabor.Bajko@nokia.com > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > >> >To: ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >I was requested to send my observations regarding this > > > > > requirement: > > > > > >> > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > location options > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > LLDP-MED [LLDP-MED]. > > > > > >> > > > > > > >> > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > are likely > > > > > >> to be > > > > > >> >supported in devices in a not so distant future. Since > > > > > I have no > > > > > >> seen or > > > > > >> >heard about LLDP support yet, at least that should be > > > > replaced > > > > > >> with what > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > mechanism, with the > > > > > >> >condition that this MUST only be supported if there > > > is a wifi > > > > > >> interface > > > > > >> >available on the device. > > > > > >> > > > > > > >> >- Gabor > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >________________________________ > > > > > >> > > > > > > >> >From: ext Tschofenig, Hannes > > > > > >> > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > marc.linsner@cisco.com > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >Gabor, > > > > > >> > > > > > > >> >Could you please raise your question about location > > > > > protocols in > > > > > >> Phone > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > >> > > > > > > >> >Ciao > > > > > >> >Hannes > > > > > >> > > > > > > >> > > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >This message is for the designated recipient > only and may > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > information. > > > > > >> >If you have received it in error, please notify > the sender > > > > > >> >immediately and delete the original. Any > > > unauthorized use of > > > > > >> >this email is prohibited. > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >[mf2] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please > contact the > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Fri Nov 21 07:32:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28873A68DA; Fri, 21 Nov 2008 07:32:09 -0800 (PST) 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 C8F023A6802 for ; Fri, 21 Nov 2008 07:32:07 -0800 (PST) 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 Y7JyoXeOPPWA for ; Fri, 21 Nov 2008 07:32:05 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 652EF3A67E2 for ; Fri, 21 Nov 2008 07:32:05 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 21 Nov 2008 07:32:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 07:30:45 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533C25@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAABa/3QAAHvRyAAAMac8AACEELQACGfBkA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533985@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B533AD2@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Winterbottom, James" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James: My scenario was the non-IMS one (no P-CSCFs, etc.) -roger. > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, November 20, 2008 3:30 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Hi Roger, > > You and I have a different understanding then on how SUPL is > invoked for emergency calling. > > It is my understanding that a SET has N x E-SLP certificates > configured into it. > > When an emergency call is made, the network (P-CSCF) > determines that an emergency call is being made, and proceeds > to contact the local E-SLP. > At that point, the E-SLP contacts the device, and IF the > device has the cert for that E-SLP, then it will initiate > communication back to the E-SLP for SUPL to continue. > > This is not really device discovery of the LCP-server in the > same way that is done for HELD or DHCP. > > Cheers > James > > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Friday, 21 November 2008 10:10 AM > > To: Winterbottom, James; Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Wait on... not the case for non-IMS emergency calls in SUPL. > > > > While it is true that SUPL goes to its home network for commercial > > location and for any IMS call, it is not specified to do so with > non-IMS > > Emergency Roaming in SUPL 2.0 (Section 5.1.15.3). For that, an > > emergency call uses the local (visited) E-SLP (and lesser-tiered > V-SLP). > > Both are assumed to be in the visited network. The device discovers > the > > E-SLP via MNC/MCC (network & country codes) supplied. > > > > -roger. > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Thursday, November 20, 2008 2:07 PM > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Only if the device is connected to its home network, else you > > > require a world in a database solution. Inter-carrier > roaming with > > > SUPL is problematic to say the least. > > > > > > Cheers > > > James > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf Of > > > > Roger Marshall > > > > Sent: Friday, 21 November 2008 8:13 AM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > No objection to saying that SUPL in its present form is > not a good > > > > choice for wire-map, but would object to saying the > same for other > > > types > > > > of 'non-measured' location. > > > > > > > > Rather, SUPL is in fact an excellent choice for > > > non-endpoint measured > > > > location such as 'CellID'. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. > > > If we need > > > > > to parse more carefully, SUPL isn't very suitable for > > > wiremap forms > > > > > of location determination. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > networks that don't use GPS or some form of > measured location. > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > suggesting that > > > > > OMA (and therefore 3GPP, 3GPP2) throw away their reliance > > > on 'rough > > > > > location' via CellID, are you? > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > location - given > > > > > Terrestial trilateration - measured Celestial trilateration - > > > > > measured Geocoded/reverse geocoded - derived > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > to 'given' > > > > > location scenarios, aka wiremap, etc. that are more Wireline > > > > > oriented, rather than mobile. For the future, > wireline devices > > > > > reduce in number, mobile (or even nomadic) devices will > > > continue in > > > > > their distribution bias. Fixed vs. Mobile has been the > > > fundamental > > > > > difference between how the IETF looks at things vs. these > > > mentioned > > > > > other fora. I contend that if we solve this for mobile - then > we > > > > > can begin communicating better with OMA/3GPP/3GPP2, > > > and... Solving > > > > > fixed will be easier. > > > > > /] > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > has its own > > > > > > version of that. > > > > > > > > > > > > All 3GPP networks I know of support a raw packet > > > service. On that > > > > > > service will run applications like MSN or AOL instant > messaging. > > > > > > Those services > > > > > > will need to be able to make emergency chats. To route > > > > > > properly, they need > > > > > > location. That means that EVERY handset must deploy > > > some LCP, and > > > > > > must be able to get location suitable for emergency call > > > > > routing and > > > > > > dispatch per -phonebcp. The RV example is yet another > > > case of the > > > > > > same thing. The mistake is assuming that all emergency > > > calls will > > > > > > come through the E-CSCF. > > > > > > They won't, and the 3GPP access network must conform to all > the > > > > > > -phonebcp requirements. > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for > access networks > > > that > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > computers (and > > > > > > related operating systems, SIP soft clients), > analog terminal > > > > > > adaptors, or other similar devices that are intended > > > for use in a > > > > > > wireline environment. I think that organizations that can > drive > > > > > > requirements for devices intended to be use in an > environment > > > where > > > > > > SUPL would actually work, should be responsible for > > > having device > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > > absolutely > > > > > > in a position to require SUPL support for devices that > > > > > operate in an > > > > > > environment where SUPL works. This is a perfect > example of the > > > > > > "closed" network that Brian describes somewhere (framework, > > > > > I think). > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > environments > > > > > > where the operators of the access environment cannot be > > > assumed to > > > > > > have any control over the type or nature of devices that > > > > > connect to or > > > > > > through it. Phonebcp needs to continue to have that as its > > > purpose. > > > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > > SUPL, or > > > > > > be incompatible with the use of SUPL. And I don't think it > does. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Roger Marshall > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > To: Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > requiring PhoneBCP > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > would prefer > > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > > handsets/aircards over the next several years will (I > > > > > predict) have a > > > > > > SUPL stack included. In the same time frame, many of those > > > > > will also > > > > > > have WiFi support, others will have LTE or WiMAX support as > > > hybrids. > > > > > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it > is > > > > > > open-minded, and there is movement afoot to expand > > > OMA/SUPL (as we > > > > > > heard in the geopriv mtg. on Tuesday) w/respect > > > expected proposals > > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > > there will be > > > > > > fewer protocol, location representation, and privacy > > > > > discontinuities - > > > > > > things that too often get cited - yet are seldom well > > > understood. > > > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > > - not block > > > > > > its use altogether. This is a case where we need to be > > > > > inclusive, not > > > > > > exclusive. > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > forseeable - > > > > > > especially given that the location of the 3G aircard in the > > > > > router is > > > > > > good enough for routing. The scenario given needs some > > > > > integration, > > > > > > but is doable. Given that the aircard acts as a logical > > > > > SET, with a > > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > > combination > > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > > applications to initiate and complete a > location-routed, 3261 > > > style > > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > > > -roger. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Brian Rosen > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > To: 'Richard Barnes' > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem is > that > > > the > > > > > > > clients are generally not very L2 aware. It's the clients > > > > > > that have > > > > > > > the problem. > > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > > common LCP so > > > > > > > that non L2 aware devices can work, but you have to > > > do that, and > > > > > > > usually, that's impractical. Use my example. Suppose > > > > > that the L2 > > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > > into the > > > > > > > router could implement a SUPL client and a HELD server and > > > > > > interwork > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > Ethernet VoIP > > > > > > > phone could get location via HELD. Possible, but not > > > practical. > > > > > > > There are all sorts of these kinds of problems. > That's why > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > standards for > > > > > > > every access technology that's out there. What we can say > > > > > > is that the > > > > > > > paradigm for those protocols should be the same as at the > > > > > IP layer: > > > > > > > Clients MUST implement all, networks MUST > implement at least > > > one. > > > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > > and clearer, > > > > > > > I > > > > > > > think.) > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > > the possible > > > > > > > protocols at lower layers, we should just state > the general > > > > > > rule. It > > > > > > > seems to me that this achieves the same level of > > > > > > interoperability at > > > > > > > all layers. > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > implement, and > > > > > > > any number > > > > > > > > of optional ones, then every network has to implement at > > > > > > > least one of > > > > > > > > those > > > > > > > two > > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > > "any number of > > > > > > > > optional ones" is useless for both parties. > > > > > > > > If the network can limit UAs to ONLY those that > implement > > > > > > > one of the > > > > > > > > optional protocols, then it works, but in practice, it > > > > > is usually > > > > > > > impossible > > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > > phone in an > > > > > > > > RV traveling down the road with wireless data card in a > > > > > > > router. These > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > To: Brian Rosen > > > > > > > > Cc: Gabor.Bajko@nokia.com; > James.Winterbottom@andrew.com; > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > > for an RFC to > > > > > > > > try to list all of the location protocols out there, if > for > > > > > > > no other > > > > > > > > reason than that it will rapidly become obsolete. > Instead, > > > > > > > we should > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > " > > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > > [RFC4776] and > > > > > > > > [RFC3825] and HELD > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > SHOULD support all location protocols supported at lower > > > > > > layers by > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > >> The problem with SUPL is that the majority of networks > > > > > > where SUPL > > > > > > > >> would > > > > > > > be > > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > > also has an > > > > > > > >> incompatible location representation, and an > incompatible > > > > > > > privacy model. > > > > > > > >> That makes it very hard to interwork with any > of the rest > > > > > > > of the IETF > > > > > > > > work. > > > > > > > >> I will say this. For quite some time, the > IETF has been > > > > > > trying to > > > > > > > > interest > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > interoperability at > > > > > > > >> the protocol, location representation and privacy > > > > > > levels. So far, > > > > > > > >> that has > > > > > > > > not > > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > > accomplish > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > not object. > > > > > > > >> > > > > > > > >> Brian > > > > > > > >> > > > > > > > >> -----Original Message----- > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > > agnostic but not > > > > > > > >> supported anywhere, or instead have a list of > LCPs which > > > > > > > are highly > > > > > > > >> probable to produce the intended result? > > > > > > > >> > > > > > > > >> There are restrictions everywhere, things come > at a cost > > > > > > > even in the > > > > > > > >> general Internet model. The reality is that most of the > > > > > > > devices with > > > > > > > >> internet access have a home network already. > > > > > > > >> > > > > > > > >> - Gabor > > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ext Winterbottom, James > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > > - FI/Espoo) > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >Hi Gabor, > > > > > > > >> > > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > > list, and is > > > > > > > >> access- > > > > > > > >> >type agnostic. > > > > > > > >> >I am curious that you say that SUPL is a > MUST support > > > > > > > given that: > > > > > > > >> >a) it requires a home network in order to operate > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > >> >c) it is questionable whether it is really > deployable > > > > > > for WiFi > > > > > > > >> networks > > > > > > > >> > > > > > > > > >> >Can you perhaps describe how it fits into > the general > > > > > > > Internet model? > > > > > > > >> > > > > > > > > >> >Cheers > > > > > > > >> >James > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > Gabor.Bajko@nokia.com > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > >> >To: ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >I was requested to send my observations > regarding this > > > > > > > requirement: > > > > > > > >> > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > > location options > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >I believe we should come up with a list of > LCPs which > > > > > > > are likely > > > > > > > >> to be > > > > > > > >> >supported in devices in a not so distant > future. Since > > > > > > > I have no > > > > > > > >> seen or > > > > > > > >> >heard about LLDP support yet, at least that > should be > > > > > > replaced > > > > > > > >> with what > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > mechanism, with the > > > > > > > >> >condition that this MUST only be supported if there > > > > > is a wifi > > > > > > > >> interface > > > > > > > >> >available on the device. > > > > > > > >> > > > > > > > > >> >- Gabor > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >________________________________ > > > > > > > >> > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > >> > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > marc.linsner@cisco.com > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >Gabor, > > > > > > > >> > > > > > > > > >> >Could you please raise your question about location > > > > > > > protocols in > > > > > > > >> Phone > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > > >> > > > > > > > > >> >Ciao > > > > > > > >> >Hannes > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >This message is for the designated recipient > > > only and may > > > > > > > >> >contain privileged, proprietary, or > otherwise private > > > > > > > information. > > > > > > > >> >If you have received it in error, please notify > > > the sender > > > > > > > >> >immediately and delete the original. Any > > > > > unauthorized use of > > > > > > > >> >this email is prohibited. > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >[mf2] > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > > message may > > > > > > be privileged and/or confidential. If you are not > the intended > > > > > > recipient, or responsible for delivering this message to > > > > > the intended > > > > > > recipient, any review, forwarding, dissemination, > > > distribution or > > > > > > copying of this communication or any attachment(s) > is strictly > > > > > > prohibited. If you have received this message in error, > > > > > please notify > > > > > > the sender immediately, and delete it and all > attachments from > > > your > > > > > > computer and network. > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > > to which it is addressed and may contain confidential, > > > proprietary, > > > > > > and/or privileged material. Any review, retransmission, > > > > > dissemination > > > > > > or other use of, or taking of any action in > reliance upon this > > > > > > information by persons or entities other than the intended > > > > > recipient > > > > > > is prohibited. If you received this in error, please > > > contact the > > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 07:43:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC993A696B; Fri, 21 Nov 2008 07:43:35 -0800 (PST) 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 169EB3A696B for ; Fri, 21 Nov 2008 07:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fegpeseb8xPM for ; Fri, 21 Nov 2008 07:43:31 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4EEDC3A67E2 for ; Fri, 21 Nov 2008 07:43:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,644,1220227200"; d="scan'208";a="107706808" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2008 15:43:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mALFhUo3032503; Fri, 21 Nov 2008 07:43:30 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mALFhOKU008161; Fri, 21 Nov 2008 15:43:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 10:43:22 -0500 Received: from jmpolk-wxp01.cisco.com ([10.82.208.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 10:43:22 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Nov 2008 09:43:20 -0600 To: "Roger Marshall" , "DRAGE, Keith (Keith)" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.tele comsys.com> References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 21 Nov 2008 15:43:22.0460 (UTC) FILETIME=[E26979C0:01C94BEF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25370; t=1227282210; x=1228146210; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20Protocols=20in=20P hone=20BCP |Sender:=20; bh=o9JfJQ+vKyL3niJmhnpLu+RlpL8fX2j9nqTqM6dr5/U=; b=Ui436GdE8eesfHZ8Lxgzr1qYKX0kyh8LfdqMgP0P6s7WS1YKeaIIhwbJRZ KPQYwZtsL5dTU7wFAq23k8qSTnmVf+u45B5Cb7uKZ4YKARf1lHPDYswBfYxh /sx++QhncY; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:28 AM 11/21/2008, Roger Marshall wrote: >Keith: >I agree completely with the first part of what you said, and want to >clarify my intent of highlighting differences in general: > >We've already got different requirements by access 'type' (i.e., >'wireless' and 'mobile' mentioned by name), so for some other >requirements - certainly, I would think those that mention the term >'wire database' - those imply their application to a fixed type of >network access (it wouldn't work to well for mobile). I'm not trying to be flippant - but what about APs that do not triangulate, in which any location will be based on the wiremap DB off a specific Ethernet switch port? This has a specific learned tag already. >What I was asking for, (and to my understanding, it was agreed to in the >ecrit meeting), was that since these requirements already mention >different access types, that there should be some additional text that >acknowledges the existance of these different access types, as >background for their respective requirements. > >-roger. > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Thursday, November 20, 2008 9:22 PM > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > We are moving towards a state where devices support multiple > > of these, and in some cases where they may be active at the same time. > > > > We certainly already have devices that may be simultaneously > > registered in WLAN and 3GPP access. > > > > As soon as you start distinguishing any type of phone by > > access technology, you will end up with these devices having > > to support multiple different requirements. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 9:07 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > > > makes clear what that the requirements apply (without > > > bias) to both fixed and mobile end devices (and their associated > > > network deployment types)? > > > > > > Below is some keyword sampling to show some implications > > with regard > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > (depending on the scope). > > > > > > A search of phonebcp for the following terms yields the associated > > > references: > > > > > > Fixed: > > > (none); > > > > > > Wireline: > > > (none); > > > > > > Mobile: > > > AN-11; > > > ED-35/AN-19; > > > ED-35; > > > > > > Wireless: > > > AN-7/INT-6; > > > AN-9; > > > AN-7; > > > INT-6; > > > > > > From the toc, it is listed... > > > > > > 6.2.2. Access network "wire database" location > > information . > > > 7 > > > 6.2.3. End-system measured location information . . . > > > . . . . 7 > > > 6.2.4. Network-measured location information . . . . > > > . . . . 8 > > > > > > -roger. > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > of the text > > > sections (Intro, etc.) > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > we need to > > > > parse more carefully, SUPL isn't very suitable for > > wiremap forms of > > > > location determination. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > networks that don't use GPS or some form of measured location. > > > > > > > > [rsm - measured only - really? - surely you aren't > > > suggesting that OMA > > > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > > > location' via CellID, are you? > > > > > > > > Wiremap location - given (manually input)] CellID > > location - given > > > > Terrestial trilateration - measured Celestial trilateration > > > - measured > > > > Geocoded/reverse geocoded - derived > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > to 'given' > > > > location scenarios, aka wiremap, etc. that are more > > > Wireline oriented, > > > > rather than mobile. For the future, wireline devices reduce in > > > > number, mobile (or even nomadic) devices will continue in their > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > difference between how the IETF looks at things vs. these > > mentioned > > > > other fora. I contend that if we solve this for mobile - > > > then we can > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > Solving fixed > > > > will be easier. > > > > /] > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > has its own > > > > > version of that. > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > On that > > > > > service will run applications like MSN or AOL instant messaging. > > > > > Those services > > > > > will need to be able to make emergency chats. To route > > > > > properly, they need > > > > > location. That means that EVERY handset must deploy some > > > LCP, and > > > > > must be able to get location suitable for emergency call > > > > routing and > > > > > dispatch per -phonebcp. The RV example is yet another > > > case of the > > > > > same thing. The mistake is assuming that all emergency > > > calls will > > > > > come through the E-CSCF. > > > > > They won't, and the 3GPP access network must conform to all the > > > > > -phonebcp requirements. > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that > > > > > don't use GPS or some form of measured location. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > computers (and > > > > > related operating systems, SIP soft clients), analog terminal > > > > > adaptors, or other similar devices that are intended > > for use in a > > > > > wireline environment. I think that organizations that can drive > > > > > requirements for devices intended to be use in an > > > environment where > > > > > SUPL would actually work, should be responsible for > > having device > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > absolutely > > > > > in a position to require SUPL support for devices that > > > > operate in an > > > > > environment where SUPL works. This is a perfect example of the > > > > > "closed" network that Brian describes somewhere (framework, > > > > I think). > > > > > > > > > > Phonebcp is about requirements for devices in access > > environments > > > > > where the operators of the access environment cannot be > > > assumed to > > > > > have any control over the type or nature of devices that > > > > connect to or > > > > > through it. Phonebcp needs to continue to have that as > > > its purpose. > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > SUPL, or > > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > To: Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > requiring PhoneBCP > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > would prefer > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > handsets/aircards over the next several years will (I > > > > predict) have a > > > > > SUPL stack included. In the same time frame, many of those > > > > will also > > > > > have WiFi support, others will have LTE or WiMAX support > > > as hybrids. > > > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > > open-minded, and there is movement afoot to expand > > > OMA/SUPL (as we > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > proposals > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > there will be > > > > > fewer protocol, location representation, and privacy > > > > discontinuities - > > > > > things that too often get cited - yet are seldom well > > understood. > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > - not block > > > > > its use altogether. This is a case where we need to be > > > > inclusive, not > > > > > exclusive. > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > forseeable - > > > > > especially given that the location of the 3G aircard in the > > > > router is > > > > > good enough for routing. The scenario given needs some > > > > integration, > > > > > but is doable. Given that the aircard acts as a logical > > > > SET, with a > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > combination > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > applications to initiate and complete a location-routed, > > > 3261 style > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > -roger. > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > To: 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > is that the > > > > > > clients are generally not very L2 aware. It's the clients > > > > > that have > > > > > > the problem. > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > common LCP so > > > > > > that non L2 aware devices can work, but you have to do > > > that, and > > > > > > usually, that's impractical. Use my example. Suppose > > > > that the L2 > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > into the > > > > > > router could implement a SUPL client and a HELD server and > > > > > interwork > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > Ethernet VoIP > > > > > > phone could get location via HELD. Possible, but not > > practical. > > > > > > There are all sorts of these kinds of problems. That's why > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > standards for > > > > > > every access technology that's out there. What we can say > > > > > is that the > > > > > > paradigm for those protocols should be the same as at the > > > > IP layer: > > > > > > Clients MUST implement all, networks MUST implement at > > > least one. > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > and clearer, > > > > > > I > > > > > > think.) > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > the possible > > > > > > protocols at lower layers, we should just state the general > > > > > rule. It > > > > > > seems to me that this achieves the same level of > > > > > interoperability at > > > > > > all layers. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > > any number > > > > > > > of optional ones, then every network has to implement at > > > > > > least one of > > > > > > > those > > > > > > two > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > "any number of > > > > > > > optional ones" is useless for both parties. > > > > > > > If the network can limit UAs to ONLY those that implement > > > > > > one of the > > > > > > > optional protocols, then it works, but in practice, it > > > > is usually > > > > > > impossible > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > phone in an > > > > > > > RV traveling down the road with wireless data card in a > > > > > > router. These > > > > > > > EXIST, now. > > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > for an RFC to > > > > > > > try to list all of the location protocols out there, if for > > > > > > no other > > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > > we should > > > > > > > say something like the following: > > > > > > > > > > > > > > " > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > [RFC4776] and > > > > > > > [RFC3825] and HELD > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > SHOULD support all location protocols supported at lower > > > > > layers by > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > >> The problem with SUPL is that the majority of networks > > > > > where SUPL > > > > > > >> would > > > > > > be > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > also has an > > > > > > >> incompatible location representation, and an incompatible > > > > > > privacy model. > > > > > > >> That makes it very hard to interwork with any of the rest > > > > > > of the IETF > > > > > > > work. > > > > > > >> I will say this. For quite some time, the IETF has been > > > > > trying to > > > > > > > interest > > > > > > >> OMA into cooperation on location so that we have > > > > > > interoperability at > > > > > > >> the protocol, location representation and privacy > > > > > levels. So far, > > > > > > >> that has > > > > > > > not > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > accomplish > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > not object. > > > > > > >> > > > > > > >> Brian > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > >> Hi, > > > > > > >> > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > agnostic but not > > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > > are highly > > > > > > >> probable to produce the intended result? > > > > > > >> > > > > > > >> There are restrictions everywhere, things come at a cost > > > > > > even in the > > > > > > >> general Internet model. The reality is that most of the > > > > > > devices with > > > > > > >> internet access have a home network already. > > > > > > >> > > > > > > >> - Gabor > > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > > >> >From: ext Winterbottom, James > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > - FI/Espoo) > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >Hi Gabor, > > > > > > >> > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > list, and is > > > > > > >> access- > > > > > > >> >type agnostic. > > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > > given that: > > > > > > >> >a) it requires a home network in order to operate > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > >> >c) it is questionable whether it is really deployable > > > > > for WiFi > > > > > > >> networks > > > > > > >> > > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > > Internet model? > > > > > > >> > > > > > > > >> >Cheers > > > > > > >> >James > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > Gabor.Bajko@nokia.com > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > >> >To: ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >I was requested to send my observations regarding this > > > > > > requirement: > > > > > > >> > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > location options > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > LLDP-MED [LLDP-MED]. > > > > > > >> > > > > > > > >> > > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > > are likely > > > > > > >> to be > > > > > > >> >supported in devices in a not so distant future. Since > > > > > > I have no > > > > > > >> seen or > > > > > > >> >heard about LLDP support yet, at least that should be > > > > > replaced > > > > > > >> with what > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > mechanism, with the > > > > > > >> >condition that this MUST only be supported if there > > > > is a wifi > > > > > > >> interface > > > > > > >> >available on the device. > > > > > > >> > > > > > > > >> >- Gabor > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >________________________________ > > > > > > >> > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > >> > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > marc.linsner@cisco.com > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >Gabor, > > > > > > >> > > > > > > > >> >Could you please raise your question about location > > > > > > protocols in > > > > > > >> Phone > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > >> > > > > > > > >> >Ciao > > > > > > >> >Hannes > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >This message is for the designated recipient > > only and may > > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > > information. > > > > > > >> >If you have received it in error, please notify > > the sender > > > > > > >> >immediately and delete the original. Any > > > > unauthorized use of > > > > > > >> >this email is prohibited. > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >[mf2] > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 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 > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > message may > > > > > be privileged and/or confidential. If you are not the intended > > > > > recipient, or responsible for delivering this message to > > > > the intended > > > > > recipient, any review, forwarding, dissemination, > > distribution or > > > > > copying of this communication or any attachment(s) is strictly > > > > > prohibited. If you have received this message in error, > > > > please notify > > > > > the sender immediately, and delete it and all attachments > > > from your > > > > > computer and network. > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person > > > > or entity > > > > > to which it is addressed and may contain confidential, > > > proprietary, > > > > > and/or privileged material. Any review, retransmission, > > > > dissemination > > > > > or other use of, or taking of any action in reliance upon this > > > > > information by persons or entities other than the intended > > > > recipient > > > > > is prohibited. If you received this in error, please > > contact the > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 ecrit-bounces@ietf.org Fri Nov 21 07:44:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71A03A69B0; Fri, 21 Nov 2008 07:44:36 -0800 (PST) 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 5B2933A69D4 for ; Fri, 21 Nov 2008 07:44:35 -0800 (PST) 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 879aqMIDdzrX for ; Fri, 21 Nov 2008 07:44:33 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 09EEF3A69B0 for ; Fri, 21 Nov 2008 07:44:33 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3YBD-000332-VH; Fri, 21 Nov 2008 09:44:24 -0600 From: "Brian Rosen" To: "'Roger Marshall'" , "'DRAGE, Keith \(Keith\)'" , "'Stark, Barbara'" , "'Richard Barnes'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> Date: Fri, 21 Nov 2008 10:44:23 -0500 Message-ID: <03b001c94bf0$08c85230$1a58f690$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAABA6fg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: Gabor.Bajko@nokia.com, marc.linsner@cisco.com, hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Roger Please send text. Note that probably this text goes in -framework, so look there first. If you think specific statements in -phonebcp need to be changed, please suggest the precise change you want. Note that I plan to release a new version within a week. Brian -----Original Message----- From: Roger Marshall [mailto:RMarshall@telecomsys.com] Sent: Friday, November 21, 2008 10:29 AM To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; Richard Barnes Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; marc.linsner@cisco.com; ecrit@ietf.org Subject: RE: [Ecrit] Location Protocols in Phone BCP Keith: I agree completely with the first part of what you said, and want to clarify my intent of highlighting differences in general: We've already got different requirements by access 'type' (i.e., 'wireless' and 'mobile' mentioned by name), so for some other requirements - certainly, I would think those that mention the term 'wire database' - those imply their application to a fixed type of network access (it wouldn't work to well for mobile). What I was asking for, (and to my understanding, it was agreed to in the ecrit meeting), was that since these requirements already mention different access types, that there should be some additional text that acknowledges the existance of these different access types, as background for their respective requirements. -roger. > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Thursday, November 20, 2008 9:22 PM > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > marc.linsner@cisco.com; ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > We are moving towards a state where devices support multiple > of these, and in some cases where they may be active at the same time. > > We certainly already have devices that may be simultaneously > registered in WLAN and 3GPP access. > > As soon as you start distinguishing any type of phone by > access technology, you will end up with these devices having > to support multiple different requirements. > > regards > > Keith > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Thursday, November 20, 2008 9:07 PM > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > > makes clear what that the requirements apply (without > > bias) to both fixed and mobile end devices (and their associated > > network deployment types)? > > > > Below is some keyword sampling to show some implications > with regard > > to fixed vs. mobile, but which isn't as crisp as it could be > > (depending on the scope). > > > > A search of phonebcp for the following terms yields the associated > > references: > > > > Fixed: > > (none); > > > > Wireline: > > (none); > > > > Mobile: > > AN-11; > > ED-35/AN-19; > > ED-35; > > > > Wireless: > > AN-7/INT-6; > > AN-9; > > AN-7; > > INT-6; > > > > From the toc, it is listed... > > > > 6.2.2. Access network "wire database" location > information . > > 7 > > 6.2.3. End-system measured location information . . . > > . . . . 7 > > 6.2.4. Network-measured location information . . . . > > . . . . 8 > > > > -roger. > > > > > > No mention of fixed, wireline, wireless, or mobile in any > of the text > > sections (Intro, etc.) > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 20, 2008 12:32 PM > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > we need to > > > parse more carefully, SUPL isn't very suitable for > wiremap forms of > > > location determination. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Thursday, November 20, 2008 3:22 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that don't use GPS or some form of measured location. > > > > > > [rsm - measured only - really? - surely you aren't > > suggesting that OMA > > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > > location' via CellID, are you? > > > > > > Wiremap location - given (manually input)] CellID > location - given > > > Terrestial trilateration - measured Celestial trilateration > > - measured > > > Geocoded/reverse geocoded - derived > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > to 'given' > > > location scenarios, aka wiremap, etc. that are more > > Wireline oriented, > > > rather than mobile. For the future, wireline devices reduce in > > > number, mobile (or even nomadic) devices will continue in their > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > difference between how the IETF looks at things vs. these > mentioned > > > other fora. I contend that if we solve this for mobile - > > then we can > > > begin communicating better with OMA/3GPP/3GPP2, and... > > Solving fixed > > > will be easier. > > > /] > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > has its own > > > > version of that. > > > > > > > > All 3GPP networks I know of support a raw packet service. > > On that > > > > service will run applications like MSN or AOL instant messaging. > > > > Those services > > > > will need to be able to make emergency chats. To route > > > > properly, they need > > > > location. That means that EVERY handset must deploy some > > LCP, and > > > > must be able to get location suitable for emergency call > > > routing and > > > > dispatch per -phonebcp. The RV example is yet another > > case of the > > > > same thing. The mistake is assuming that all emergency > > calls will > > > > come through the E-CSCF. > > > > They won't, and the 3GPP access network must conform to all the > > > > -phonebcp requirements. > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > networks that > > > > don't use GPS or some form of measured location. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > computers (and > > > > related operating systems, SIP soft clients), analog terminal > > > > adaptors, or other similar devices that are intended > for use in a > > > > wireline environment. I think that organizations that can drive > > > > requirements for devices intended to be use in an > > environment where > > > > SUPL would actually work, should be responsible for > having device > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > absolutely > > > > in a position to require SUPL support for devices that > > > operate in an > > > > environment where SUPL works. This is a perfect example of the > > > > "closed" network that Brian describes somewhere (framework, > > > I think). > > > > > > > > Phonebcp is about requirements for devices in access > environments > > > > where the operators of the access environment cannot be > > assumed to > > > > have any control over the type or nature of devices that > > > connect to or > > > > through it. Phonebcp needs to continue to have that as > > its purpose. > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > SUPL, or > > > > be incompatible with the use of SUPL. And I don't think it does. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > To: Brian Rosen; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > requiring PhoneBCP > > > > suppport of SUPL, then my vote is to NOT prevent! I > would prefer > > > > 'require' since *most* of the location-aware 3G compatible > > > > handsets/aircards over the next several years will (I > > > predict) have a > > > > SUPL stack included. In the same time frame, many of those > > > will also > > > > have WiFi support, others will have LTE or WiMAX support > > as hybrids. > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > open-minded, and there is movement afoot to expand > > OMA/SUPL (as we > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > proposals > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > there will be > > > > fewer protocol, location representation, and privacy > > > discontinuities - > > > > things that too often get cited - yet are seldom well > understood. > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > - not block > > > > its use altogether. This is a case where we need to be > > > inclusive, not > > > > exclusive. > > > > > > > > As to the mobile RV sample case, the solution is also > > forseeable - > > > > especially given that the location of the 3G aircard in the > > > router is > > > > good enough for routing. The scenario given needs some > > > integration, > > > > but is doable. Given that the aircard acts as a logical > > > SET, with a > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > combination > > > > *WILL* (I believe) interoperate with a number of end client > > > > applications to initiate and complete a location-routed, > > 3261 style > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > -roger. > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Brian Rosen > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > To: 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > is that the > > > > > clients are generally not very L2 aware. It's the clients > > > > that have > > > > > the problem. > > > > > You can do things like interwork an L2 specific LCP to a > > > > common LCP so > > > > > that non L2 aware devices can work, but you have to do > > that, and > > > > > usually, that's impractical. Use my example. Suppose > > > that the L2 > > > > > used SUPL. It's possible for the PC Card that is plugged > > > into the > > > > > router could implement a SUPL client and a HELD server and > > > > interwork > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > Ethernet VoIP > > > > > phone could get location via HELD. Possible, but not > practical. > > > > > There are all sorts of these kinds of problems. That's why > > > > > L2 specific LCPs don't work. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > To: Brian Rosen > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > standards for > > > > > every access technology that's out there. What we can say > > > > is that the > > > > > paradigm for those protocols should be the same as at the > > > IP layer: > > > > > Clients MUST implement all, networks MUST implement at > > least one. > > > > > > > > > > (This is a little different from the text I sent before, > > > > and clearer, > > > > > I > > > > > think.) > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > the possible > > > > > protocols at lower layers, we should just state the general > > > > rule. It > > > > > seems to me that this achieves the same level of > > > > interoperability at > > > > > all layers. > > > > > > > > > > --Richard > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > any number > > > > > > of optional ones, then every network has to implement at > > > > > least one of > > > > > > those > > > > > two > > > > > > LCPs, and any number of optional ones. That means that > > > > > "any number of > > > > > > optional ones" is useless for both parties. > > > > > > If the network can limit UAs to ONLY those that implement > > > > > one of the > > > > > > optional protocols, then it works, but in practice, it > > > is usually > > > > > impossible > > > > > > to do that. My example is the wired, Ethernet connected > > > > > phone in an > > > > > > RV traveling down the road with wireless data card in a > > > > > router. These > > > > > > EXIST, now. > > > > > > > > > > > > Brian > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > for an RFC to > > > > > > try to list all of the location protocols out there, if for > > > > > no other > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > we should > > > > > > say something like the following: > > > > > > > > > > > > " > > > > > > INT-12 Devices MUST support the DHCP location options > > > > [RFC4776] and > > > > > > [RFC3825] and HELD > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > SHOULD support all location protocols supported at lower > > > > layers by > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > >> The problem with SUPL is that the majority of networks > > > > where SUPL > > > > > >> would > > > > > be > > > > > >> available have a proxy (E-CSCF) insert location. It > > > also has an > > > > > >> incompatible location representation, and an incompatible > > > > > privacy model. > > > > > >> That makes it very hard to interwork with any of the rest > > > > > of the IETF > > > > > > work. > > > > > >> I will say this. For quite some time, the IETF has been > > > > trying to > > > > > > interest > > > > > >> OMA into cooperation on location so that we have > > > > > interoperability at > > > > > >> the protocol, location representation and privacy > > > > levels. So far, > > > > > >> that has > > > > > > not > > > > > >> happened. If, as part of a comprehensive agreement to > > > > accomplish > > > > > >> such a goal, SUPL became one of the LCPs, I would > not object. > > > > > >> > > > > > >> Brian > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Is the intent to list the LCPs which are access-type > > > > > agnostic but not > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > are highly > > > > > >> probable to produce the intended result? > > > > > >> > > > > > >> There are restrictions everywhere, things come at a cost > > > > > even in the > > > > > >> general Internet model. The reality is that most of the > > > > > devices with > > > > > >> internet access have a home network already. > > > > > >> > > > > > >> - Gabor > > > > > >> > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Winterbottom, James > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > - FI/Espoo) > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >Hi Gabor, > > > > > >> > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > list, and is > > > > > >> access- > > > > > >> >type agnostic. > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > given that: > > > > > >> >a) it requires a home network in order to operate > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > >> >c) it is questionable whether it is really deployable > > > > for WiFi > > > > > >> networks > > > > > >> > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > Internet model? > > > > > >> > > > > > > >> >Cheers > > > > > >> >James > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > Gabor.Bajko@nokia.com > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > >> >To: ecrit@ietf.org > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > >> > > > > > > >> >I was requested to send my observations regarding this > > > > > requirement: > > > > > >> > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > location options > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > LLDP-MED [LLDP-MED]. > > > > > >> > > > > > > >> > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > are likely > > > > > >> to be > > > > > >> >supported in devices in a not so distant future. Since > > > > > I have no > > > > > >> seen or > > > > > >> >heard about LLDP support yet, at least that should be > > > > replaced > > > > > >> with what > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > mechanism, with the > > > > > >> >condition that this MUST only be supported if there > > > is a wifi > > > > > >> interface > > > > > >> >available on the device. > > > > > >> > > > > > > >> >- Gabor > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >________________________________ > > > > > >> > > > > > > >> >From: ext Tschofenig, Hannes > > > > > >> > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > marc.linsner@cisco.com > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >Gabor, > > > > > >> > > > > > > >> >Could you please raise your question about location > > > > > protocols in > > > > > >> Phone > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > >> > > > > > > >> >Ciao > > > > > >> >Hannes > > > > > >> > > > > > > >> > > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >This message is for the designated recipient > only and may > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > information. > > > > > >> >If you have received it in error, please notify > the sender > > > > > >> >immediately and delete the original. Any > > > unauthorized use of > > > > > >> >this email is prohibited. > > > > > >> > > > > > >>> > > > > > > > > > -------------------------------------------------------------------- > > > > > >>> --- > > > > > >> -- > > > > > >> >----------------------- > > > > > >> >[mf2] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > message may > > > > be privileged and/or confidential. If you are not the intended > > > > recipient, or responsible for delivering this message to > > > the intended > > > > recipient, any review, forwarding, dissemination, > distribution or > > > > copying of this communication or any attachment(s) is strictly > > > > prohibited. If you have received this message in error, > > > please notify > > > > the sender immediately, and delete it and all attachments > > from your > > > > computer and network. > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please > contact the > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 ecrit-bounces@ietf.org Fri Nov 21 08:42:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DA03A6A60; Fri, 21 Nov 2008 08:42:45 -0800 (PST) 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 2E50C3A6A75 for ; Fri, 21 Nov 2008 08:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 y6UMHyJMkSUq for ; Fri, 21 Nov 2008 08:42:39 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 878DE3A6A57 for ; Fri, 21 Nov 2008 08:42:38 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_21_11_00_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 21 Nov 2008 11:00:18 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 10:42:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 10:42:35 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTg References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Roger Marshall" X-OriginalArrivalTime: 21 Nov 2008 16:42:36.0942 (UTC) FILETIME=[290C62E0:01C94BF8] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I strongly disagree with this from a philosophical standpoint. Type of access should only affect protocol design where attributes of that access affect the protocol. For instance, we design protocols for networks with long delays, which happen to be applicable to inter-planetary communication. This means that when someone uses that protocol for shipping data on reindeer, it doesn't break because someone assumes that it a radio link in space. So, what we need to do is identify attributes of the network that are relevant to the protocol design. As far as the document is currently specified, the attribute that we're interested in is mobility - that is, the fact that location changes. Do not mistakenly assign this attribute to wireless networks. For an example of how this is harmful, imagine that it is possible that a wired connection on a plane (now, why don't they do that...seems logical). If we had a client that was on a wire, there is the risk that they continue this assumption to detrimental effect. Cheers, Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Roger Marshall > Sent: Friday, 21 November 2008 9:29 AM > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Keith: > I agree completely with the first part of what you said, and want to > clarify my intent of highlighting differences in general: > > We've already got different requirements by access 'type' (i.e., > 'wireless' and 'mobile' mentioned by name), so for some other > requirements - certainly, I would think those that mention the term > 'wire database' - those imply their application to a fixed type of > network access (it wouldn't work to well for mobile). > > What I was asking for, (and to my understanding, it was agreed to in > the > ecrit meeting), was that since these requirements already mention > different access types, that there should be some additional text that > acknowledges the existance of these different access types, as > background for their respective requirements. > > -roger. > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Thursday, November 20, 2008 9:22 PM > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > We are moving towards a state where devices support multiple > > of these, and in some cases where they may be active at the same > time. > > > > We certainly already have devices that may be simultaneously > > registered in WLAN and 3GPP access. > > > > As soon as you start distinguishing any type of phone by > > access technology, you will end up with these devices having > > to support multiple different requirements. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 9:07 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > > > makes clear what that the requirements apply (without > > > bias) to both fixed and mobile end devices (and their associated > > > network deployment types)? > > > > > > Below is some keyword sampling to show some implications > > with regard > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > (depending on the scope). > > > > > > A search of phonebcp for the following terms yields the associated > > > references: > > > > > > Fixed: > > > (none); > > > > > > Wireline: > > > (none); > > > > > > Mobile: > > > AN-11; > > > ED-35/AN-19; > > > ED-35; > > > > > > Wireless: > > > AN-7/INT-6; > > > AN-9; > > > AN-7; > > > INT-6; > > > > > > From the toc, it is listed... > > > > > > 6.2.2. Access network "wire database" location > > information . > > > 7 > > > 6.2.3. End-system measured location information . . . > > > . . . . 7 > > > 6.2.4. Network-measured location information . . . . > > > . . . . 8 > > > > > > -roger. > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > of the text > > > sections (Intro, etc.) > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > we need to > > > > parse more carefully, SUPL isn't very suitable for > > wiremap forms of > > > > location determination. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > networks that don't use GPS or some form of measured location. > > > > > > > > [rsm - measured only - really? - surely you aren't > > > suggesting that OMA > > > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > > > location' via CellID, are you? > > > > > > > > Wiremap location - given (manually input)] CellID > > location - given > > > > Terrestial trilateration - measured Celestial trilateration > > > - measured > > > > Geocoded/reverse geocoded - derived > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > to 'given' > > > > location scenarios, aka wiremap, etc. that are more > > > Wireline oriented, > > > > rather than mobile. For the future, wireline devices reduce in > > > > number, mobile (or even nomadic) devices will continue in their > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > difference between how the IETF looks at things vs. these > > mentioned > > > > other fora. I contend that if we solve this for mobile - > > > then we can > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > Solving fixed > > > > will be easier. > > > > /] > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > has its own > > > > > version of that. > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > On that > > > > > service will run applications like MSN or AOL instant > messaging. > > > > > Those services > > > > > will need to be able to make emergency chats. To route > > > > > properly, they need > > > > > location. That means that EVERY handset must deploy some > > > LCP, and > > > > > must be able to get location suitable for emergency call > > > > routing and > > > > > dispatch per -phonebcp. The RV example is yet another > > > case of the > > > > > same thing. The mistake is assuming that all emergency > > > calls will > > > > > come through the E-CSCF. > > > > > They won't, and the 3GPP access network must conform to all the > > > > > -phonebcp requirements. > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that > > > > > don't use GPS or some form of measured location. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > computers (and > > > > > related operating systems, SIP soft clients), analog terminal > > > > > adaptors, or other similar devices that are intended > > for use in a > > > > > wireline environment. I think that organizations that can drive > > > > > requirements for devices intended to be use in an > > > environment where > > > > > SUPL would actually work, should be responsible for > > having device > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > absolutely > > > > > in a position to require SUPL support for devices that > > > > operate in an > > > > > environment where SUPL works. This is a perfect example of the > > > > > "closed" network that Brian describes somewhere (framework, > > > > I think). > > > > > > > > > > Phonebcp is about requirements for devices in access > > environments > > > > > where the operators of the access environment cannot be > > > assumed to > > > > > have any control over the type or nature of devices that > > > > connect to or > > > > > through it. Phonebcp needs to continue to have that as > > > its purpose. > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > SUPL, or > > > > > be incompatible with the use of SUPL. And I don't think it > does. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > To: Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > requiring PhoneBCP > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > would prefer > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > handsets/aircards over the next several years will (I > > > > predict) have a > > > > > SUPL stack included. In the same time frame, many of those > > > > will also > > > > > have WiFi support, others will have LTE or WiMAX support > > > as hybrids. > > > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > > open-minded, and there is movement afoot to expand > > > OMA/SUPL (as we > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > proposals > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > there will be > > > > > fewer protocol, location representation, and privacy > > > > discontinuities - > > > > > things that too often get cited - yet are seldom well > > understood. > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > - not block > > > > > its use altogether. This is a case where we need to be > > > > inclusive, not > > > > > exclusive. > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > forseeable - > > > > > especially given that the location of the 3G aircard in the > > > > router is > > > > > good enough for routing. The scenario given needs some > > > > integration, > > > > > but is doable. Given that the aircard acts as a logical > > > > SET, with a > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > combination > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > applications to initiate and complete a location-routed, > > > 3261 style > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > -roger. > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > To: 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > is that the > > > > > > clients are generally not very L2 aware. It's the clients > > > > > that have > > > > > > the problem. > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > common LCP so > > > > > > that non L2 aware devices can work, but you have to do > > > that, and > > > > > > usually, that's impractical. Use my example. Suppose > > > > that the L2 > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > into the > > > > > > router could implement a SUPL client and a HELD server and > > > > > interwork > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > Ethernet VoIP > > > > > > phone could get location via HELD. Possible, but not > > practical. > > > > > > There are all sorts of these kinds of problems. That's why > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > standards for > > > > > > every access technology that's out there. What we can say > > > > > is that the > > > > > > paradigm for those protocols should be the same as at the > > > > IP layer: > > > > > > Clients MUST implement all, networks MUST implement at > > > least one. > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > and clearer, > > > > > > I > > > > > > think.) > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > the possible > > > > > > protocols at lower layers, we should just state the general > > > > > rule. It > > > > > > seems to me that this achieves the same level of > > > > > interoperability at > > > > > > all layers. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > > any number > > > > > > > of optional ones, then every network has to implement at > > > > > > least one of > > > > > > > those > > > > > > two > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > "any number of > > > > > > > optional ones" is useless for both parties. > > > > > > > If the network can limit UAs to ONLY those that implement > > > > > > one of the > > > > > > > optional protocols, then it works, but in practice, it > > > > is usually > > > > > > impossible > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > phone in an > > > > > > > RV traveling down the road with wireless data card in a > > > > > > router. These > > > > > > > EXIST, now. > > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > for an RFC to > > > > > > > try to list all of the location protocols out there, if for > > > > > > no other > > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > > we should > > > > > > > say something like the following: > > > > > > > > > > > > > > " > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > [RFC4776] and > > > > > > > [RFC3825] and HELD > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > SHOULD support all location protocols supported at lower > > > > > layers by > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > >> The problem with SUPL is that the majority of networks > > > > > where SUPL > > > > > > >> would > > > > > > be > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > also has an > > > > > > >> incompatible location representation, and an incompatible > > > > > > privacy model. > > > > > > >> That makes it very hard to interwork with any of the rest > > > > > > of the IETF > > > > > > > work. > > > > > > >> I will say this. For quite some time, the IETF has been > > > > > trying to > > > > > > > interest > > > > > > >> OMA into cooperation on location so that we have > > > > > > interoperability at > > > > > > >> the protocol, location representation and privacy > > > > > levels. So far, > > > > > > >> that has > > > > > > > not > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > accomplish > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > not object. > > > > > > >> > > > > > > >> Brian > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > >> Hi, > > > > > > >> > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > agnostic but not > > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > > are highly > > > > > > >> probable to produce the intended result? > > > > > > >> > > > > > > >> There are restrictions everywhere, things come at a cost > > > > > > even in the > > > > > > >> general Internet model. The reality is that most of the > > > > > > devices with > > > > > > >> internet access have a home network already. > > > > > > >> > > > > > > >> - Gabor > > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > > >> >From: ext Winterbottom, James > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > - FI/Espoo) > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >Hi Gabor, > > > > > > >> > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > list, and is > > > > > > >> access- > > > > > > >> >type agnostic. > > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > > given that: > > > > > > >> >a) it requires a home network in order to operate > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > >> >c) it is questionable whether it is really deployable > > > > > for WiFi > > > > > > >> networks > > > > > > >> > > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > > Internet model? > > > > > > >> > > > > > > > >> >Cheers > > > > > > >> >James > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > Gabor.Bajko@nokia.com > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > >> >To: ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >I was requested to send my observations regarding this > > > > > > requirement: > > > > > > >> > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > location options > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > LLDP-MED [LLDP-MED]. > > > > > > >> > > > > > > > >> > > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > > are likely > > > > > > >> to be > > > > > > >> >supported in devices in a not so distant future. Since > > > > > > I have no > > > > > > >> seen or > > > > > > >> >heard about LLDP support yet, at least that should be > > > > > replaced > > > > > > >> with what > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > mechanism, with the > > > > > > >> >condition that this MUST only be supported if there > > > > is a wifi > > > > > > >> interface > > > > > > >> >available on the device. > > > > > > >> > > > > > > > >> >- Gabor > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >________________________________ > > > > > > >> > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > >> > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > marc.linsner@cisco.com > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >Gabor, > > > > > > >> > > > > > > > >> >Could you please raise your question about location > > > > > > protocols in > > > > > > >> Phone > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > >> > > > > > > > >> >Ciao > > > > > > >> >Hannes > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >This message is for the designated recipient > > only and may > > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > > information. > > > > > > >> >If you have received it in error, please notify > > the sender > > > > > > >> >immediately and delete the original. Any > > > > unauthorized use of > > > > > > >> >this email is prohibited. > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >[mf2] > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 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 > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > message may > > > > > be privileged and/or confidential. If you are not the intended > > > > > recipient, or responsible for delivering this message to > > > > the intended > > > > > recipient, any review, forwarding, dissemination, > > distribution or > > > > > copying of this communication or any attachment(s) is strictly > > > > > prohibited. If you have received this message in error, > > > > please notify > > > > > the sender immediately, and delete it and all attachments > > > from your > > > > > computer and network. > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person > > > > or entity > > > > > to which it is addressed and may contain confidential, > > > proprietary, > > > > > and/or privileged material. Any review, retransmission, > > > > dissemination > > > > > or other use of, or taking of any action in reliance upon this > > > > > information by persons or entities other than the intended > > > > recipient > > > > > is prohibited. If you received this in error, please > > contact the > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 08:52:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF0728C0F8; Fri, 21 Nov 2008 08:52:52 -0800 (PST) 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 A0B5928C0F8 for ; Fri, 21 Nov 2008 08:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kHnUWIxCJxW8 for ; Fri, 21 Nov 2008 08:52:49 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0018828C0F5 for ; Fri, 21 Nov 2008 08:52:48 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1L3ZFJ-0007nX-3k; Fri, 21 Nov 2008 10:52:42 -0600 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Roger Marshall'" References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: Date: Fri, 21 Nov 2008 11:52:30 -0500 Message-ID: <03cd01c94bf9$8d599cd0$a80cd670$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTgAACEi+A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The plane is a great example of an indirect connection to a network. My RV was another. You can't make assumptions about mobility or anything else of relevance to the group from the characteristics of the device placing the emergency call, or it's first hop connection. It's another example of how difficult it is to make use of layer 2 specific LCPs. Generally, assuming that bridging devices will bridge LCPs is a losing proposition. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Thomson, Martin Sent: Friday, November 21, 2008 11:43 AM To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP I strongly disagree with this from a philosophical standpoint. Type of access should only affect protocol design where attributes of that access affect the protocol. For instance, we design protocols for networks with long delays, which happen to be applicable to inter-planetary communication. This means that when someone uses that protocol for shipping data on reindeer, it doesn't break because someone assumes that it a radio link in space. So, what we need to do is identify attributes of the network that are relevant to the protocol design. As far as the document is currently specified, the attribute that we're interested in is mobility - that is, the fact that location changes. Do not mistakenly assign this attribute to wireless networks. For an example of how this is harmful, imagine that it is possible that a wired connection on a plane (now, why don't they do that...seems logical). If we had a client that was on a wire, there is the risk that they continue this assumption to detrimental effect. Cheers, Martin > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Roger Marshall > Sent: Friday, 21 November 2008 9:29 AM > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > Keith: > I agree completely with the first part of what you said, and want to > clarify my intent of highlighting differences in general: > > We've already got different requirements by access 'type' (i.e., > 'wireless' and 'mobile' mentioned by name), so for some other > requirements - certainly, I would think those that mention the term > 'wire database' - those imply their application to a fixed type of > network access (it wouldn't work to well for mobile). > > What I was asking for, (and to my understanding, it was agreed to in > the > ecrit meeting), was that since these requirements already mention > different access types, that there should be some additional text that > acknowledges the existance of these different access types, as > background for their respective requirements. > > -roger. > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Thursday, November 20, 2008 9:22 PM > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com; ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > We are moving towards a state where devices support multiple > > of these, and in some cases where they may be active at the same > time. > > > > We certainly already have devices that may be simultaneously > > registered in WLAN and 3GPP access. > > > > As soon as you start distinguishing any type of phone by > > access technology, you will end up with these devices having > > to support multiple different requirements. > > > > regards > > > > Keith > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Thursday, November 20, 2008 9:07 PM > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > Isn't there a need to set the scope [text] of phonebcp, so that it > > > makes clear what that the requirements apply (without > > > bias) to both fixed and mobile end devices (and their associated > > > network deployment types)? > > > > > > Below is some keyword sampling to show some implications > > with regard > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > (depending on the scope). > > > > > > A search of phonebcp for the following terms yields the associated > > > references: > > > > > > Fixed: > > > (none); > > > > > > Wireline: > > > (none); > > > > > > Mobile: > > > AN-11; > > > ED-35/AN-19; > > > ED-35; > > > > > > Wireless: > > > AN-7/INT-6; > > > AN-9; > > > AN-7; > > > INT-6; > > > > > > From the toc, it is listed... > > > > > > 6.2.2. Access network "wire database" location > > information . > > > 7 > > > 6.2.3. End-system measured location information . . . > > > . . . . 7 > > > 6.2.4. Network-measured location information . . . . > > > . . . . 8 > > > > > > -roger. > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > of the text > > > sections (Intro, etc.) > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > we need to > > > > parse more carefully, SUPL isn't very suitable for > > wiremap forms of > > > > location determination. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > networks that don't use GPS or some form of measured location. > > > > > > > > [rsm - measured only - really? - surely you aren't > > > suggesting that OMA > > > > (and therefore 3GPP, 3GPP2) throw away their reliance on 'rough > > > > location' via CellID, are you? > > > > > > > > Wiremap location - given (manually input)] CellID > > location - given > > > > Terrestial trilateration - measured Celestial trilateration > > > - measured > > > > Geocoded/reverse geocoded - derived > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > to 'given' > > > > location scenarios, aka wiremap, etc. that are more > > > Wireline oriented, > > > > rather than mobile. For the future, wireline devices reduce in > > > > number, mobile (or even nomadic) devices will continue in their > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > difference between how the IETF looks at things vs. these > > mentioned > > > > other fora. I contend that if we solve this for mobile - > > > then we can > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > Solving fixed > > > > will be easier. > > > > /] > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > has its own > > > > > version of that. > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > On that > > > > > service will run applications like MSN or AOL instant > messaging. > > > > > Those services > > > > > will need to be able to make emergency chats. To route > > > > > properly, they need > > > > > location. That means that EVERY handset must deploy some > > > LCP, and > > > > > must be able to get location suitable for emergency call > > > > routing and > > > > > dispatch per -phonebcp. The RV example is yet another > > > case of the > > > > > same thing. The mistake is assuming that all emergency > > > calls will > > > > > come through the E-CSCF. > > > > > They won't, and the 3GPP access network must conform to all the > > > > > -phonebcp requirements. > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > networks that > > > > > don't use GPS or some form of measured location. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > computers (and > > > > > related operating systems, SIP soft clients), analog terminal > > > > > adaptors, or other similar devices that are intended > > for use in a > > > > > wireline environment. I think that organizations that can drive > > > > > requirements for devices intended to be use in an > > > environment where > > > > > SUPL would actually work, should be responsible for > > having device > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > absolutely > > > > > in a position to require SUPL support for devices that > > > > operate in an > > > > > environment where SUPL works. This is a perfect example of the > > > > > "closed" network that Brian describes somewhere (framework, > > > > I think). > > > > > > > > > > Phonebcp is about requirements for devices in access > > environments > > > > > where the operators of the access environment cannot be > > > assumed to > > > > > have any control over the type or nature of devices that > > > > connect to or > > > > > through it. Phonebcp needs to continue to have that as > > > its purpose. > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > SUPL, or > > > > > be incompatible with the use of SUPL. And I don't think it > does. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > To: Brian Rosen; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > requiring PhoneBCP > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > would prefer > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > handsets/aircards over the next several years will (I > > > > predict) have a > > > > > SUPL stack included. In the same time frame, many of those > > > > will also > > > > > have WiFi support, others will have LTE or WiMAX support > > > as hybrids. > > > > > > > > > > SUPL will be common-place. OMA may not be 'Open-Source', it is > > > > > open-minded, and there is movement afoot to expand > > > OMA/SUPL (as we > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > proposals > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > there will be > > > > > fewer protocol, location representation, and privacy > > > > discontinuities - > > > > > things that too often get cited - yet are seldom well > > understood. > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > - not block > > > > > its use altogether. This is a case where we need to be > > > > inclusive, not > > > > > exclusive. > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > forseeable - > > > > > especially given that the location of the 3G aircard in the > > > > router is > > > > > good enough for routing. The scenario given needs some > > > > integration, > > > > > but is doable. Given that the aircard acts as a logical > > > > SET, with a > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > combination > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > applications to initiate and complete a location-routed, > > > 3261 style > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > -roger. > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > To: 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > is that the > > > > > > clients are generally not very L2 aware. It's the clients > > > > > that have > > > > > > the problem. > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > common LCP so > > > > > > that non L2 aware devices can work, but you have to do > > > that, and > > > > > > usually, that's impractical. Use my example. Suppose > > > > that the L2 > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > into the > > > > > > router could implement a SUPL client and a HELD server and > > > > > interwork > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > Ethernet VoIP > > > > > > phone could get location via HELD. Possible, but not > > practical. > > > > > > There are all sorts of these kinds of problems. That's why > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > To: Brian Rosen > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > standards for > > > > > > every access technology that's out there. What we can say > > > > > is that the > > > > > > paradigm for those protocols should be the same as at the > > > > IP layer: > > > > > > Clients MUST implement all, networks MUST implement at > > > least one. > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > and clearer, > > > > > > I > > > > > > think.) > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > the possible > > > > > > protocols at lower layers, we should just state the general > > > > > rule. It > > > > > > seems to me that this achieves the same level of > > > > > interoperability at > > > > > > all layers. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > If there are exactly two LCPs all UAs must implement, and > > > > > > any number > > > > > > > of optional ones, then every network has to implement at > > > > > > least one of > > > > > > > those > > > > > > two > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > "any number of > > > > > > > optional ones" is useless for both parties. > > > > > > > If the network can limit UAs to ONLY those that implement > > > > > > one of the > > > > > > > optional protocols, then it works, but in practice, it > > > > is usually > > > > > > impossible > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > phone in an > > > > > > > RV traveling down the road with wireless data card in a > > > > > > router. These > > > > > > > EXIST, now. > > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > for an RFC to > > > > > > > try to list all of the location protocols out there, if for > > > > > > no other > > > > > > > reason than that it will rapidly become obsolete. Instead, > > > > > > we should > > > > > > > say something like the following: > > > > > > > > > > > > > > " > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > [RFC4776] and > > > > > > > [RFC3825] and HELD > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > SHOULD support all location protocols supported at lower > > > > > layers by > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > >> The problem with SUPL is that the majority of networks > > > > > where SUPL > > > > > > >> would > > > > > > be > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > also has an > > > > > > >> incompatible location representation, and an incompatible > > > > > > privacy model. > > > > > > >> That makes it very hard to interwork with any of the rest > > > > > > of the IETF > > > > > > > work. > > > > > > >> I will say this. For quite some time, the IETF has been > > > > > trying to > > > > > > > interest > > > > > > >> OMA into cooperation on location so that we have > > > > > > interoperability at > > > > > > >> the protocol, location representation and privacy > > > > > levels. So far, > > > > > > >> that has > > > > > > > not > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > accomplish > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > not object. > > > > > > >> > > > > > > >> Brian > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > >> Hi, > > > > > > >> > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > agnostic but not > > > > > > >> supported anywhere, or instead have a list of LCPs which > > > > > > are highly > > > > > > >> probable to produce the intended result? > > > > > > >> > > > > > > >> There are restrictions everywhere, things come at a cost > > > > > > even in the > > > > > > >> general Internet model. The reality is that most of the > > > > > > devices with > > > > > > >> internet access have a home network already. > > > > > > >> > > > > > > >> - Gabor > > > > > > >> > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > > >> >From: ext Winterbottom, James > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > - FI/Espoo) > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >Hi Gabor, > > > > > > >> > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > list, and is > > > > > > >> access- > > > > > > >> >type agnostic. > > > > > > >> >I am curious that you say that SUPL is a MUST support > > > > > > given that: > > > > > > >> >a) it requires a home network in order to operate > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > >> >c) it is questionable whether it is really deployable > > > > > for WiFi > > > > > > >> networks > > > > > > >> > > > > > > > >> >Can you perhaps describe how it fits into the general > > > > > > Internet model? > > > > > > >> > > > > > > > >> >Cheers > > > > > > >> >James > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > Gabor.Bajko@nokia.com > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > >> >To: ecrit@ietf.org > > > > > > >> >Cc: marc.linsner@cisco.com; hannes.tschofenig@nsn.com > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> >I was requested to send my observations regarding this > > > > > > requirement: > > > > > > >> > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > location options > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > LLDP-MED [LLDP-MED]. > > > > > > >> > > > > > > > >> > > > > > > > >> >I believe we should come up with a list of LCPs which > > > > > > are likely > > > > > > >> to be > > > > > > >> >supported in devices in a not so distant future. Since > > > > > > I have no > > > > > > >> seen or > > > > > > >> >heard about LLDP support yet, at least that should be > > > > > replaced > > > > > > >> with what > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > mechanism, with the > > > > > > >> >condition that this MUST only be supported if there > > > > is a wifi > > > > > > >> interface > > > > > > >> >available on the device. > > > > > > >> > > > > > > > >> >- Gabor > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >________________________________ > > > > > > >> > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > >> > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > marc.linsner@cisco.com > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> >Gabor, > > > > > > >> > > > > > > > >> >Could you please raise your question about location > > > > > > protocols in > > > > > > >> Phone > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > >> > > > > > > > >> >Ciao > > > > > > >> >Hannes > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >This message is for the designated recipient > > only and may > > > > > > >> >contain privileged, proprietary, or otherwise private > > > > > > information. > > > > > > >> >If you have received it in error, please notify > > the sender > > > > > > >> >immediately and delete the original. Any > > > > unauthorized use of > > > > > > >> >this email is prohibited. > > > > > > >> > > > > > > >>> > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > >>> --- > > > > > > >> -- > > > > > > >> >----------------------- > > > > > > >> >[mf2] > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 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 > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > message may > > > > > be privileged and/or confidential. If you are not the intended > > > > > recipient, or responsible for delivering this message to > > > > the intended > > > > > recipient, any review, forwarding, dissemination, > > distribution or > > > > > copying of this communication or any attachment(s) is strictly > > > > > prohibited. If you have received this message in error, > > > > please notify > > > > > the sender immediately, and delete it and all attachments > > > from your > > > > > computer and network. > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > ***** > > > > > > > > > > The information transmitted is intended only for the person > > > > or entity > > > > > to which it is addressed and may contain confidential, > > > proprietary, > > > > > and/or privileged material. Any review, retransmission, > > > > dissemination > > > > > or other use of, or taking of any action in reliance upon this > > > > > information by persons or entities other than the intended > > > > recipient > > > > > is prohibited. If you received this in error, please > > contact the > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ 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 ecrit-bounces@ietf.org Fri Nov 21 10:55:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFD33A68A4; Fri, 21 Nov 2008 10:55:43 -0800 (PST) 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 601D03A68A4 for ; Fri, 21 Nov 2008 10:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wyptE+TfQ988 for ; Fri, 21 Nov 2008 10:55:39 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id C74EA3A6452 for ; Fri, 21 Nov 2008 10:55:38 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 21 Nov 2008 10:55:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 10:54:17 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <03cd01c94bf9$8d599cd0$a80cd670$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTgAACEi+AABB9PkA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80c d670$@ne t> From: "Roger Marshall" To: "Brian Rosen" , "Thomson, Martin" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with the differentiation of protocol requirement which differentiate between mobile and non-mobile (use whatever term you like), but I do not support terms such as 'wireless' (as is in the draft) for the reasons you reasonably cite. The airplane example provides two notions of location. One may relative to a wired database, which is inside a closed system, which can only provide a relative location (e.g., you're in seat 34C). The other view is that of being mobile, in this case, best given by some 3space datum coordinate set (it could either represent the plane's position or the end device location - you pick). The two forms have different levels of importance, but each is relevant. The question is, is the end device fixed or mobile? -roger. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, November 21, 2008 8:53 AM > To: 'Thomson, Martin'; Roger Marshall > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > The plane is a great example of an indirect connection to a > network. My RV was another. You can't make assumptions about > mobility or anything else of relevance to the group from the > characteristics of the device placing the emergency call, or > it's first hop connection. It's another example of how > difficult it is to make use of layer 2 specific LCPs. > Generally, assuming that bridging devices will bridge LCPs is > a losing proposition. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Thomson, Martin > Sent: Friday, November 21, 2008 11:43 AM > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > I strongly disagree with this from a philosophical > standpoint. Type of access should only affect protocol > design where attributes of that access affect the protocol. > > For instance, we design protocols for networks with long > delays, which happen to be applicable to inter-planetary > communication. This means that when someone uses that > protocol for shipping data on reindeer, it doesn't break > because someone assumes that it a radio link in space. > > So, what we need to do is identify attributes of the network > that are relevant to the protocol design. As far as the > document is currently specified, the attribute that we're > interested in is mobility - that is, the fact that location > changes. Do not mistakenly assign this attribute to wireless > networks. > > For an example of how this is harmful, imagine that it is > possible that a wired connection on a plane (now, why don't > they do that...seems logical). > If we had a client that was on a wire, there is the risk that > they continue this assumption to detrimental effect. > > Cheers, > Martin > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Friday, 21 November 2008 9:29 AM > > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; > Richard Barnes > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > Keith: > > I agree completely with the first part of what you said, > and want to > > clarify my intent of highlighting differences in general: > > > > We've already got different requirements by access 'type' (i.e., > > 'wireless' and 'mobile' mentioned by name), so for some other > > requirements - certainly, I would think those that mention the term > > 'wire database' - those imply their application to a fixed type of > > network access (it wouldn't work to well for mobile). > > > > What I was asking for, (and to my understanding, it was > agreed to in > > the ecrit meeting), was that since these requirements > already mention > > different access types, that there should be some > additional text that > > acknowledges the existance of these different access types, as > > background for their respective requirements. > > > > -roger. > > > > > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: Thursday, November 20, 2008 9:22 PM > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > We are moving towards a state where devices support multiple of > > > these, and in some cases where they may be active at the same > > time. > > > > > > We certainly already have devices that may be simultaneously > > > registered in WLAN and 3GPP access. > > > > > > As soon as you start distinguishing any type of phone by access > > > technology, you will end up with these devices having to support > > > multiple different requirements. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 9:07 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Isn't there a need to set the scope [text] of phonebcp, > so that it > > > > makes clear what that the requirements apply (without > > > > bias) to both fixed and mobile end devices (and their > associated > > > > network deployment types)? > > > > > > > > Below is some keyword sampling to show some implications > > > with regard > > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > > (depending on the scope). > > > > > > > > A search of phonebcp for the following terms yields the > associated > > > > references: > > > > > > > > Fixed: > > > > (none); > > > > > > > > Wireline: > > > > (none); > > > > > > > > Mobile: > > > > AN-11; > > > > ED-35/AN-19; > > > > ED-35; > > > > > > > > Wireless: > > > > AN-7/INT-6; > > > > AN-9; > > > > AN-7; > > > > INT-6; > > > > > > > > From the toc, it is listed... > > > > > > > > 6.2.2. Access network "wire database" location > > > information . > > > > 7 > > > > 6.2.3. End-system measured location information . . . > > > > . . . . 7 > > > > 6.2.4. Network-measured location information . . . . > > > > . . . . 8 > > > > > > > > -roger. > > > > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > > of the text > > > > sections (Intro, etc.) > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > > we need to > > > > > parse more carefully, SUPL isn't very suitable for > > > wiremap forms of > > > > > location determination. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > networks that don't use GPS or some form of > measured location. > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > > suggesting that OMA > > > > > (and therefore 3GPP, 3GPP2) throw away their reliance > on 'rough > > > > > location' via CellID, are you? > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > location - given > > > > > Terrestial trilateration - measured Celestial trilateration > > > > - measured > > > > > Geocoded/reverse geocoded - derived > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > to 'given' > > > > > location scenarios, aka wiremap, etc. that are more > > > > Wireline oriented, > > > > > rather than mobile. For the future, wireline devices > reduce in > > > > > number, mobile (or even nomadic) devices will > continue in their > > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > > difference between how the IETF looks at things vs. these > > > mentioned > > > > > other fora. I contend that if we solve this for mobile - > > > > then we can > > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > > Solving fixed > > > > > will be easier. > > > > > /] > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > has its own > > > > > > version of that. > > > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > > On that > > > > > > service will run applications like MSN or AOL instant > > messaging. > > > > > > Those services > > > > > > will need to be able to make emergency chats. To route > > > > > > properly, they need > > > > > > location. That means that EVERY handset must deploy some > > > > LCP, and > > > > > > must be able to get location suitable for emergency call > > > > > routing and > > > > > > dispatch per -phonebcp. The RV example is yet another > > > > case of the > > > > > > same thing. The mistake is assuming that all emergency > > > > calls will > > > > > > come through the E-CSCF. > > > > > > They won't, and the 3GPP access network must conform to all > > > > > > the -phonebcp requirements. > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > computers (and > > > > > > related operating systems, SIP soft clients), > analog terminal > > > > > > adaptors, or other similar devices that are intended > > > for use in a > > > > > > wireline environment. I think that organizations that can > > > > > > drive requirements for devices intended to be use in an > > > > environment where > > > > > > SUPL would actually work, should be responsible for > > > having device > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > > absolutely > > > > > > in a position to require SUPL support for devices that > > > > > operate in an > > > > > > environment where SUPL works. This is a perfect > example of the > > > > > > "closed" network that Brian describes somewhere (framework, > > > > > I think). > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > environments > > > > > > where the operators of the access environment cannot be > > > > assumed to > > > > > > have any control over the type or nature of devices that > > > > > connect to or > > > > > > through it. Phonebcp needs to continue to have that as > > > > its purpose. > > > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > > SUPL, or > > > > > > be incompatible with the use of SUPL. And I don't think it > > does. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Roger Marshall > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > To: Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > requiring PhoneBCP > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > would prefer > > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > > handsets/aircards over the next several years will (I > > > > > predict) have a > > > > > > SUPL stack included. In the same time frame, many of those > > > > > will also > > > > > > have WiFi support, others will have LTE or WiMAX support > > > > as hybrids. > > > > > > > > > > > > SUPL will be common-place. OMA may not be > 'Open-Source', it > > > > > > is open-minded, and there is movement afoot to expand > > > > OMA/SUPL (as we > > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > > proposals > > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > > there will be > > > > > > fewer protocol, location representation, and privacy > > > > > discontinuities - > > > > > > things that too often get cited - yet are seldom well > > > understood. > > > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > > - not block > > > > > > its use altogether. This is a case where we need to be > > > > > inclusive, not > > > > > > exclusive. > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > > forseeable - > > > > > > especially given that the location of the 3G aircard in the > > > > > router is > > > > > > good enough for routing. The scenario given needs some > > > > > integration, > > > > > > but is doable. Given that the aircard acts as a logical > > > > > SET, with a > > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > > combination > > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > > applications to initiate and complete a location-routed, > > > > 3261 style > > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > > > -roger. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Brian Rosen > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > To: 'Richard Barnes' > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > > is that the > > > > > > > clients are generally not very L2 aware. It's the clients > > > > > > that have > > > > > > > the problem. > > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > > common LCP so > > > > > > > that non L2 aware devices can work, but you have to do > > > > that, and > > > > > > > usually, that's impractical. Use my example. Suppose > > > > > that the L2 > > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > > into the > > > > > > > router could implement a SUPL client and a HELD server and > > > > > > interwork > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > Ethernet VoIP > > > > > > > phone could get location via HELD. Possible, but not > > > practical. > > > > > > > There are all sorts of these kinds of problems. > That's why > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > standards for > > > > > > > every access technology that's out there. What we can say > > > > > > is that the > > > > > > > paradigm for those protocols should be the same as at the > > > > > IP layer: > > > > > > > Clients MUST implement all, networks MUST implement at > > > > least one. > > > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > > and clearer, > > > > > > > I > > > > > > > think.) > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > > the possible > > > > > > > protocols at lower layers, we should just state > the general > > > > > > rule. It > > > > > > > seems to me that this achieves the same level of > > > > > > interoperability at > > > > > > > all layers. > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > implement, and > > > > > > > any number > > > > > > > > of optional ones, then every network has to implement at > > > > > > > least one of > > > > > > > > those > > > > > > > two > > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > > "any number of > > > > > > > > optional ones" is useless for both parties. > > > > > > > > If the network can limit UAs to ONLY those that > implement > > > > > > > one of the > > > > > > > > optional protocols, then it works, but in practice, it > > > > > is usually > > > > > > > impossible > > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > > phone in an > > > > > > > > RV traveling down the road with wireless data card in a > > > > > > > router. These > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > To: Brian Rosen > > > > > > > > Cc: Gabor.Bajko@nokia.com; > James.Winterbottom@andrew.com; > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > > for an RFC to > > > > > > > > try to list all of the location protocols out there, if > > > > > > > > for > > > > > > > no other > > > > > > > > reason than that it will rapidly become obsolete. > > > > > > > > Instead, > > > > > > > we should > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > " > > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > > [RFC4776] and > > > > > > > > [RFC3825] and HELD > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > SHOULD support all location protocols supported at lower > > > > > > layers by > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > >> The problem with SUPL is that the majority of networks > > > > > > where SUPL > > > > > > > >> would > > > > > > > be > > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > > also has an > > > > > > > >> incompatible location representation, and an > incompatible > > > > > > > privacy model. > > > > > > > >> That makes it very hard to interwork with any > of the rest > > > > > > > of the IETF > > > > > > > > work. > > > > > > > >> I will say this. For quite some time, the > IETF has been > > > > > > trying to > > > > > > > > interest > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > interoperability at > > > > > > > >> the protocol, location representation and privacy > > > > > > levels. So far, > > > > > > > >> that has > > > > > > > > not > > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > > accomplish > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > not object. > > > > > > > >> > > > > > > > >> Brian > > > > > > > >> > > > > > > > >> -----Original Message----- > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > > agnostic but not > > > > > > > >> supported anywhere, or instead have a list of > LCPs which > > > > > > > are highly > > > > > > > >> probable to produce the intended result? > > > > > > > >> > > > > > > > >> There are restrictions everywhere, things come > at a cost > > > > > > > even in the > > > > > > > >> general Internet model. The reality is that most of the > > > > > > > devices with > > > > > > > >> internet access have a home network already. > > > > > > > >> > > > > > > > >> - Gabor > > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ext Winterbottom, James > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > > - FI/Espoo) > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >Hi Gabor, > > > > > > > >> > > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > > list, and is > > > > > > > >> access- > > > > > > > >> >type agnostic. > > > > > > > >> >I am curious that you say that SUPL is a > MUST support > > > > > > > given that: > > > > > > > >> >a) it requires a home network in order to operate > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > >> >c) it is questionable whether it is really > deployable > > > > > > for WiFi > > > > > > > >> networks > > > > > > > >> > > > > > > > > >> >Can you perhaps describe how it fits into > the general > > > > > > > Internet model? > > > > > > > >> > > > > > > > > >> >Cheers > > > > > > > >> >James > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > Gabor.Bajko@nokia.com > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > >> >To: ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >I was requested to send my observations > regarding this > > > > > > > requirement: > > > > > > > >> > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > > location options > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >I believe we should come up with a list of > LCPs which > > > > > > > are likely > > > > > > > >> to be > > > > > > > >> >supported in devices in a not so distant > future. Since > > > > > > > I have no > > > > > > > >> seen or > > > > > > > >> >heard about LLDP support yet, at least that > should be > > > > > > replaced > > > > > > > >> with what > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > mechanism, with the > > > > > > > >> >condition that this MUST only be supported if there > > > > > is a wifi > > > > > > > >> interface > > > > > > > >> >available on the device. > > > > > > > >> > > > > > > > > >> >- Gabor > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >________________________________ > > > > > > > >> > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > >> > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > marc.linsner@cisco.com > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >Gabor, > > > > > > > >> > > > > > > > > >> >Could you please raise your question about location > > > > > > > protocols in > > > > > > > >> Phone > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > > >> > > > > > > > > >> >Ciao > > > > > > > >> >Hannes > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >This message is for the designated recipient > > > only and may > > > > > > > >> >contain privileged, proprietary, or > otherwise private > > > > > > > information. > > > > > > > >> >If you have received it in error, please notify > > > the sender > > > > > > > >> >immediately and delete the original. Any > > > > > unauthorized use of > > > > > > > >> >this email is prohibited. > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >[mf2] > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > > message may > > > > > > be privileged and/or confidential. If you are not > the intended > > > > > > recipient, or responsible for delivering this message to > > > > > the intended > > > > > > recipient, any review, forwarding, dissemination, > > > distribution or > > > > > > copying of this communication or any attachment(s) > is strictly > > > > > > prohibited. If you have received this message in error, > > > > > please notify > > > > > > the sender immediately, and delete it and all attachments > > > > from your > > > > > > computer and network. > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > > to which it is addressed and may contain confidential, > > > > proprietary, > > > > > > and/or privileged material. Any review, retransmission, > > > > > dissemination > > > > > > or other use of, or taking of any action in > reliance upon this > > > > > > information by persons or entities other than the intended > > > > > recipient > > > > > > is prohibited. If you received this in error, please > > > contact the > > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > -------------------------------------------------------------- > -------------- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > -------------- > -------------------- > [mf2] > _______________________________________________ > 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 ecrit-bounces@ietf.org Fri Nov 21 11:29:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749633A68CE; Fri, 21 Nov 2008 11:29:43 -0800 (PST) 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 E82023A68CE for ; Fri, 21 Nov 2008 11:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 9oBcgTMQ2z9F for ; Fri, 21 Nov 2008 11:29:40 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id EEB303A6407 for ; Fri, 21 Nov 2008 11:29:39 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_21_13_47_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 21 Nov 2008 13:47:18 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 13:29:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 13:29:36 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTgAACEi+AABB9PkAABGfKw References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80c d670$@ne t> <8C837214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Roger Marshall" X-OriginalArrivalTime: 21 Nov 2008 19:29:37.0585 (UTC) FILETIME=[7DD12A10:01C94C0F] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, To answer this question, you have to first answer the question: how many reference frames exist? My answer is one. It helps to only have a single reference frame for this purpose. That is, earth-centred, earth-fixed is the single reference frame we use to determine movement. Anything moving in that reference frame is moving. Establishing ad hoc reference frames increases the complexity of any solution that we develop. In the plane example, you might use a complex of the geodetic location of the plane with uncertainty, plus a civic address with SEAT=34C. However, this would be considered to be moving at 3500m/s. Thanks, Martin > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, 21 November 2008 12:54 PM > To: Brian Rosen; Thomson, Martin > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > I agree with the differentiation of protocol requirement which > differentiate between mobile and non-mobile (use whatever term you > like), but I do not support terms such as 'wireless' (as is in the > draft) for the reasons you reasonably cite. > > The airplane example provides two notions of location. One may > relative > to a wired database, which is inside a closed system, which can only > provide a relative location (e.g., you're in seat 34C). The other view > is that of being mobile, in this case, best given by some 3space datum > coordinate set (it could either represent the plane's position or the > end device location - you pick). The two forms have different levels > of > importance, but each is relevant. > > The question is, is the end device fixed or mobile? > > -roger. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, November 21, 2008 8:53 AM > > To: 'Thomson, Martin'; Roger Marshall > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > The plane is a great example of an indirect connection to a > > network. My RV was another. You can't make assumptions about > > mobility or anything else of relevance to the group from the > > characteristics of the device placing the emergency call, or > > it's first hop connection. It's another example of how > > difficult it is to make use of layer 2 specific LCPs. > > Generally, assuming that bridging devices will bridge LCPs is > > a losing proposition. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf Of Thomson, Martin > > Sent: Friday, November 21, 2008 11:43 AM > > To: Roger Marshall > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > I strongly disagree with this from a philosophical > > standpoint. Type of access should only affect protocol > > design where attributes of that access affect the protocol. > > > > For instance, we design protocols for networks with long > > delays, which happen to be applicable to inter-planetary > > communication. This means that when someone uses that > > protocol for shipping data on reindeer, it doesn't break > > because someone assumes that it a radio link in space. > > > > So, what we need to do is identify attributes of the network > > that are relevant to the protocol design. As far as the > > document is currently specified, the attribute that we're > > interested in is mobility - that is, the fact that location > > changes. Do not mistakenly assign this attribute to wireless > > networks. > > > > For an example of how this is harmful, imagine that it is > > possible that a wired connection on a plane (now, why don't > > they do that...seems logical). > > If we had a client that was on a wire, there is the risk that > > they continue this assumption to detrimental effect. > > > > Cheers, > > Martin > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Roger Marshall > > > Sent: Friday, 21 November 2008 9:29 AM > > > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; > > Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > Keith: > > > I agree completely with the first part of what you said, > > and want to > > > clarify my intent of highlighting differences in general: > > > > > > We've already got different requirements by access 'type' (i.e., > > > 'wireless' and 'mobile' mentioned by name), so for some other > > > requirements - certainly, I would think those that mention the term > > > 'wire database' - those imply their application to a fixed type of > > > network access (it wouldn't work to well for mobile). > > > > > > What I was asking for, (and to my understanding, it was > > agreed to in > > > the ecrit meeting), was that since these requirements > > already mention > > > different access types, that there should be some > > additional text that > > > acknowledges the existance of these different access types, as > > > background for their respective requirements. > > > > > > -roger. > > > > > > > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: Thursday, November 20, 2008 9:22 PM > > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > We are moving towards a state where devices support multiple of > > > > these, and in some cases where they may be active at the same > > > time. > > > > > > > > We certainly already have devices that may be simultaneously > > > > registered in WLAN and 3GPP access. > > > > > > > > As soon as you start distinguishing any type of phone by access > > > > technology, you will end up with these devices having to support > > > > multiple different requirements. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Thursday, November 20, 2008 9:07 PM > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Isn't there a need to set the scope [text] of phonebcp, > > so that it > > > > > makes clear what that the requirements apply (without > > > > > bias) to both fixed and mobile end devices (and their > > associated > > > > > network deployment types)? > > > > > > > > > > Below is some keyword sampling to show some implications > > > > with regard > > > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > > > (depending on the scope). > > > > > > > > > > A search of phonebcp for the following terms yields the > > associated > > > > > references: > > > > > > > > > > Fixed: > > > > > (none); > > > > > > > > > > Wireline: > > > > > (none); > > > > > > > > > > Mobile: > > > > > AN-11; > > > > > ED-35/AN-19; > > > > > ED-35; > > > > > > > > > > Wireless: > > > > > AN-7/INT-6; > > > > > AN-9; > > > > > AN-7; > > > > > INT-6; > > > > > > > > > > From the toc, it is listed... > > > > > > > > > > 6.2.2. Access network "wire database" location > > > > information . > > > > > 7 > > > > > 6.2.3. End-system measured location information . . . > > > > > . . . . 7 > > > > > 6.2.4. Network-measured location information . . . . > > > > > . . . . 8 > > > > > > > > > > -roger. > > > > > > > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > > > of the text > > > > > sections (Intro, etc.) > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > > > we need to > > > > > > parse more carefully, SUPL isn't very suitable for > > > > wiremap forms of > > > > > > location determination. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > > networks that don't use GPS or some form of > > measured location. > > > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > > > suggesting that OMA > > > > > > (and therefore 3GPP, 3GPP2) throw away their reliance > > on 'rough > > > > > > location' via CellID, are you? > > > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > > location - given > > > > > > Terrestial trilateration - measured Celestial trilateration > > > > > - measured > > > > > > Geocoded/reverse geocoded - derived > > > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > > to 'given' > > > > > > location scenarios, aka wiremap, etc. that are more > > > > > Wireline oriented, > > > > > > rather than mobile. For the future, wireline devices > > reduce in > > > > > > number, mobile (or even nomadic) devices will > > continue in their > > > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > > > difference between how the IETF looks at things vs. these > > > > mentioned > > > > > > other fora. I contend that if we solve this for mobile - > > > > > then we can > > > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > > > Solving fixed > > > > > > will be easier. > > > > > > /] > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > > has its own > > > > > > > version of that. > > > > > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > > > On that > > > > > > > service will run applications like MSN or AOL instant > > > messaging. > > > > > > > Those services > > > > > > > will need to be able to make emergency chats. To route > > > > > > > properly, they need > > > > > > > location. That means that EVERY handset must deploy some > > > > > LCP, and > > > > > > > must be able to get location suitable for emergency call > > > > > > routing and > > > > > > > dispatch per -phonebcp. The RV example is yet another > > > > > case of the > > > > > > > same thing. The mistake is assuming that all emergency > > > > > calls will > > > > > > > come through the E-CSCF. > > > > > > > They won't, and the 3GPP access network must conform to all > > > > > > > the -phonebcp requirements. > > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > networks that > > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > > computers (and > > > > > > > related operating systems, SIP soft clients), > > analog terminal > > > > > > > adaptors, or other similar devices that are intended > > > > for use in a > > > > > > > wireline environment. I think that organizations that can > > > > > > > drive requirements for devices intended to be use in an > > > > > environment where > > > > > > > SUPL would actually work, should be responsible for > > > > having device > > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > > > absolutely > > > > > > > in a position to require SUPL support for devices that > > > > > > operate in an > > > > > > > environment where SUPL works. This is a perfect > > example of the > > > > > > > "closed" network that Brian describes somewhere (framework, > > > > > > I think). > > > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > > environments > > > > > > > where the operators of the access environment cannot be > > > > > assumed to > > > > > > > have any control over the type or nature of devices that > > > > > > connect to or > > > > > > > through it. Phonebcp needs to continue to have that as > > > > > its purpose. > > > > > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > > > SUPL, or > > > > > > > be incompatible with the use of SUPL. And I don't think it > > > does. > > > > > > > Barbara > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Roger Marshall > > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > > To: Brian Rosen; Richard Barnes > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > > requiring PhoneBCP > > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > > would prefer > > > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > > > handsets/aircards over the next several years will (I > > > > > > predict) have a > > > > > > > SUPL stack included. In the same time frame, many of those > > > > > > will also > > > > > > > have WiFi support, others will have LTE or WiMAX support > > > > > as hybrids. > > > > > > > > > > > > > > SUPL will be common-place. OMA may not be > > 'Open-Source', it > > > > > > > is open-minded, and there is movement afoot to expand > > > > > OMA/SUPL (as we > > > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > > > proposals > > > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > > > there will be > > > > > > > fewer protocol, location representation, and privacy > > > > > > discontinuities - > > > > > > > things that too often get cited - yet are seldom well > > > > understood. > > > > > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > > > - not block > > > > > > > its use altogether. This is a case where we need to be > > > > > > inclusive, not > > > > > > > exclusive. > > > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > > > forseeable - > > > > > > > especially given that the location of the 3G aircard in the > > > > > > router is > > > > > > > good enough for routing. The scenario given needs some > > > > > > integration, > > > > > > > but is doable. Given that the aircard acts as a logical > > > > > > SET, with a > > > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > > > combination > > > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > > > applications to initiate and complete a location-routed, > > > > > 3261 style > > > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > > > > > -roger. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Brian Rosen > > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > > To: 'Richard Barnes' > > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > > > is that the > > > > > > > > clients are generally not very L2 aware. It's the > clients > > > > > > > that have > > > > > > > > the problem. > > > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > > > common LCP so > > > > > > > > that non L2 aware devices can work, but you have to do > > > > > that, and > > > > > > > > usually, that's impractical. Use my example. Suppose > > > > > > that the L2 > > > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > > > into the > > > > > > > > router could implement a SUPL client and a HELD server > and > > > > > > > interwork > > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > > Ethernet VoIP > > > > > > > > phone could get location via HELD. Possible, but not > > > > practical. > > > > > > > > There are all sorts of these kinds of problems. > > That's why > > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > > To: Brian Rosen > > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > > standards for > > > > > > > > every access technology that's out there. What we can > say > > > > > > > is that the > > > > > > > > paradigm for those protocols should be the same as at the > > > > > > IP layer: > > > > > > > > Clients MUST implement all, networks MUST implement at > > > > > least one. > > > > > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > > > and clearer, > > > > > > > > I > > > > > > > > think.) > > > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > > > the possible > > > > > > > > protocols at lower layers, we should just state > > the general > > > > > > > rule. It > > > > > > > > seems to me that this achieves the same level of > > > > > > > interoperability at > > > > > > > > all layers. > > > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > > implement, and > > > > > > > > any number > > > > > > > > > of optional ones, then every network has to implement > at > > > > > > > > least one of > > > > > > > > > those > > > > > > > > two > > > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > > > "any number of > > > > > > > > > optional ones" is useless for both parties. > > > > > > > > > If the network can limit UAs to ONLY those that > > implement > > > > > > > > one of the > > > > > > > > > optional protocols, then it works, but in practice, it > > > > > > is usually > > > > > > > > impossible > > > > > > > > > to do that. My example is the wired, Ethernet > connected > > > > > > > > phone in an > > > > > > > > > RV traveling down the road with wireless data card in a > > > > > > > > router. These > > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > > To: Brian Rosen > > > > > > > > > Cc: Gabor.Bajko@nokia.com; > > James.Winterbottom@andrew.com; > > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not > reasonable > > > > > > > > for an RFC to > > > > > > > > > try to list all of the location protocols out there, if > > > > > > > > > for > > > > > > > > no other > > > > > > > > > reason than that it will rapidly become obsolete. > > > > > > > > > Instead, > > > > > > > > we should > > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > > > " > > > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > > > [RFC4776] and > > > > > > > > > [RFC3825] and HELD > > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > > SHOULD support all location protocols supported at > lower > > > > > > > layers by > > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > > >> The problem with SUPL is that the majority of networks > > > > > > > where SUPL > > > > > > > > >> would > > > > > > > > be > > > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > > > also has an > > > > > > > > >> incompatible location representation, and an > > incompatible > > > > > > > > privacy model. > > > > > > > > >> That makes it very hard to interwork with any > > of the rest > > > > > > > > of the IETF > > > > > > > > > work. > > > > > > > > >> I will say this. For quite some time, the > > IETF has been > > > > > > > trying to > > > > > > > > > interest > > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > > interoperability at > > > > > > > > >> the protocol, location representation and privacy > > > > > > > levels. So far, > > > > > > > > >> that has > > > > > > > > > not > > > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > > > accomplish > > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > > not object. > > > > > > > > >> > > > > > > > > >> Brian > > > > > > > > >> > > > > > > > > >> -----Original Message----- > > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > >> > > > > > > > > >> Hi, > > > > > > > > >> > > > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > > > agnostic but not > > > > > > > > >> supported anywhere, or instead have a list of > > LCPs which > > > > > > > > are highly > > > > > > > > >> probable to produce the intended result? > > > > > > > > >> > > > > > > > > >> There are restrictions everywhere, things come > > at a cost > > > > > > > > even in the > > > > > > > > >> general Internet model. The reality is that most of > the > > > > > > > > devices with > > > > > > > > >> internet access have a home network already. > > > > > > > > >> > > > > > > > > >> - Gabor > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >-----Original Message----- > > > > > > > > >> >From: ext Winterbottom, James > > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > > > - FI/Espoo) > > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone > BCP > > > > > > > > >> > > > > > > > > > >> >Hi Gabor, > > > > > > > > >> > > > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > > > list, and is > > > > > > > > >> access- > > > > > > > > >> >type agnostic. > > > > > > > > >> >I am curious that you say that SUPL is a > > MUST support > > > > > > > > given that: > > > > > > > > >> >a) it requires a home network in order to operate > > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > > >> >c) it is questionable whether it is really > > deployable > > > > > > > for WiFi > > > > > > > > >> networks > > > > > > > > >> > > > > > > > > > >> >Can you perhaps describe how it fits into > > the general > > > > > > > > Internet model? > > > > > > > > >> > > > > > > > > > >> >Cheers > > > > > > > > >> >James > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> >-----Original Message----- > > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > > Gabor.Bajko@nokia.com > > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > > >> >To: ecrit@ietf.org > > > > > > > > >> >Cc: marc.linsner@cisco.com; > > hannes.tschofenig@nsn.com > > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone > BCP > > > > > > > > >> > > > > > > > > > >> >I was requested to send my observations > > regarding this > > > > > > > > requirement: > > > > > > > > >> > > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > > > location options > > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> >I believe we should come up with a list of > > LCPs which > > > > > > > > are likely > > > > > > > > >> to be > > > > > > > > >> >supported in devices in a not so distant > > future. Since > > > > > > > > I have no > > > > > > > > >> seen or > > > > > > > > >> >heard about LLDP support yet, at least that > > should be > > > > > > > replaced > > > > > > > > >> with what > > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > > mechanism, with the > > > > > > > > >> >condition that this MUST only be supported if there > > > > > > is a wifi > > > > > > > > >> interface > > > > > > > > >> >available on the device. > > > > > > > > >> > > > > > > > > > >> >- Gabor > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> >________________________________ > > > > > > > > >> > > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > > >> > > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > > marc.linsner@cisco.com > > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> >Gabor, > > > > > > > > >> > > > > > > > > > >> >Could you please raise your question about location > > > > > > > > protocols in > > > > > > > > >> Phone > > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session > again? > > > > > > > > >> > > > > > > > > > >> >Ciao > > > > > > > > >> >Hannes > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > >>> --- > > > > > > > > >> -- > > > > > > > > >> >----------------------- > > > > > > > > >> >This message is for the designated recipient > > > > only and may > > > > > > > > >> >contain privileged, proprietary, or > > otherwise private > > > > > > > > information. > > > > > > > > >> >If you have received it in error, please notify > > > > the sender > > > > > > > > >> >immediately and delete the original. Any > > > > > > unauthorized use of > > > > > > > > >> >this email is prohibited. > > > > > > > > >> > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > >>> --- > > > > > > > > >> -- > > > > > > > > >> >----------------------- > > > > > > > > >> >[mf2] > > > > > > > > >> > > > > > > > > >> _______________________________________________ > > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > > > message may > > > > > > > be privileged and/or confidential. If you are not > > the intended > > > > > > > recipient, or responsible for delivering this message to > > > > > > the intended > > > > > > > recipient, any review, forwarding, dissemination, > > > > distribution or > > > > > > > copying of this communication or any attachment(s) > > is strictly > > > > > > > prohibited. If you have received this message in error, > > > > > > please notify > > > > > > > the sender immediately, and delete it and all attachments > > > > > from your > > > > > > > computer and network. > > > > > > > _______________________________________________ > > > > > > > Ecrit mailing list > > > > > > > Ecrit@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > ***** > > > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > > or entity > > > > > > > to which it is addressed and may contain confidential, > > > > > proprietary, > > > > > > > and/or privileged material. Any review, retransmission, > > > > > > dissemination > > > > > > > or other use of, or taking of any action in > > reliance upon this > > > > > > > information by persons or entities other than the intended > > > > > > recipient > > > > > > > is prohibited. If you received this in error, please > > > > contact the > > > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > -------------------------------------------------------------- > > -------------- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > -------------- > > -------------------- > > [mf2] > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 11:29:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45A43A6919; Fri, 21 Nov 2008 11:29:46 -0800 (PST) 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 3B8823A6A01 for ; Fri, 21 Nov 2008 11:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Q+LVZHnwJ3k4 for ; Fri, 21 Nov 2008 11:29:42 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 775913A68A4 for ; Fri, 21 Nov 2008 11:29:42 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 21 Nov 2008 11:29:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:28:22 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533E2D@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclL7+e1ikVPkqpWSFaVOljKhp1vjQAGRLig References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com> <00ff01c94b1d$a5d11e50$f1735af0$@net> <49257DF1.2000205@bbn.com> <011b01c94b24$d8d78a80$8a869f80$@net> <49258C15.2070303@bbn.com> <015401c94b2c$374c6ed0$a5e54c70$@net> <8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com> <7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p> <01e701c94b4b$813eb290$83bc17b0$@net> <8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com> <020601c94b4f$101d8740$305895c0$@net> <8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com> <5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "James M. Polk" , "DRAGE, Keith (Keith)" , "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" Cc: Gabor.Bajko@nokia.com, hannes.tschofenig@nsn.com, marc.linsner@cisco.com, ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > I'm not trying to be flippant - but what about APs that do > not triangulate, in which any location will be based on the > wiremap DB off a specific Ethernet switch port? Phonebcp has requirements that rightly distinguish between 'wireless' access networks and 'mobile' end devices which communicate over them. If the end device 'inherits' an AP's location that is pre-provisioned into a wire database, (i.e., given), then the location were talking about is that of the AP - only roughly associated with the actual location of the radio connected end device, and in a sense, has nothing to do with the end device being mobile or not. Mobile device classification, according to the draft, requires location updates to be possible, something that is separate from the initial above scenario, since a radio connected end device (e.g., cordless DECT phone) might not be 'mobile' in terms of the following requirement. ED-35/AN-19 Mobile devices MUST be provided with a mechanism to get repeated location updates to track the motion of the device during the complete processing of the call. Again, I don't see any problems with above, or other mobile device or access network requirements in phonebcp. -roger. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, November 21, 2008 7:43 AM > To: Roger Marshall; DRAGE, Keith (Keith); Brian Rosen; Stark, > Barbara; Richard Barnes > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > hannes.tschofenig@nsn.com; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > At 09:28 AM 11/21/2008, Roger Marshall wrote: > >Keith: > >I agree completely with the first part of what you said, and want to > >clarify my intent of highlighting differences in general: > > > >We've already got different requirements by access 'type' (i.e., > >'wireless' and 'mobile' mentioned by name), so for some other > >requirements - certainly, I would think those that mention the term > >'wire database' - those imply their application to a fixed type of > >network access (it wouldn't work to well for mobile). > > I'm not trying to be flippant - but what about APs that do > not triangulate, in which any location will be based on the > wiremap DB off a specific Ethernet switch port? > > This has a specific learned tag already. > > > >What I was asking for, (and to my understanding, it was agreed to in > >the ecrit meeting), was that since these requirements > already mention > >different access types, that there should be some additional > text that > >acknowledges the existance of these different access types, as > >background for their respective requirements. > > > >-roger. > > > > > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: Thursday, November 20, 2008 9:22 PM > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; Richard Barnes > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > marc.linsner@cisco.com; ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > We are moving towards a state where devices support multiple of > > > these, and in some cases where they may be active at the > same time. > > > > > > We certainly already have devices that may be simultaneously > > > registered in WLAN and 3GPP access. > > > > > > As soon as you start distinguishing any type of phone by access > > > technology, you will end up with these devices having to support > > > multiple different requirements. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Thursday, November 20, 2008 9:07 PM > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Isn't there a need to set the scope [text] of phonebcp, > so that it > > > > makes clear what that the requirements apply (without > > > > bias) to both fixed and mobile end devices (and their > associated > > > > network deployment types)? > > > > > > > > Below is some keyword sampling to show some implications > > > with regard > > > > to fixed vs. mobile, but which isn't as crisp as it could be > > > > (depending on the scope). > > > > > > > > A search of phonebcp for the following terms yields the > associated > > > > references: > > > > > > > > Fixed: > > > > (none); > > > > > > > > Wireline: > > > > (none); > > > > > > > > Mobile: > > > > AN-11; > > > > ED-35/AN-19; > > > > ED-35; > > > > > > > > Wireless: > > > > AN-7/INT-6; > > > > AN-9; > > > > AN-7; > > > > INT-6; > > > > > > > > From the toc, it is listed... > > > > > > > > 6.2.2. Access network "wire database" location > > > information . > > > > 7 > > > > 6.2.3. End-system measured location information . . . > > > > . . . . 7 > > > > 6.2.4. Network-measured location information . . . . > > > > . . . . 8 > > > > > > > > -roger. > > > > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > > of the text > > > > sections (Intro, etc.) > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's neutral. If > > > > we need to > > > > > parse more carefully, SUPL isn't very suitable for > > > wiremap forms of > > > > > location determination. > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > networks that don't use GPS or some form of > measured location. > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > > suggesting that OMA > > > > > (and therefore 3GPP, 3GPP2) throw away their reliance > on 'rough > > > > > location' via CellID, are you? > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > location - given > > > > > Terrestial trilateration - measured Celestial trilateration > > > > - measured > > > > > Geocoded/reverse geocoded - derived > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > to 'given' > > > > > location scenarios, aka wiremap, etc. that are more > > > > Wireline oriented, > > > > > rather than mobile. For the future, wireline devices > reduce in > > > > > number, mobile (or even nomadic) devices will > continue in their > > > > > distribution bias. Fixed vs. Mobile has been the fundamental > > > > > difference between how the IETF looks at things vs. these > > > mentioned > > > > > other fora. I contend that if we solve this for mobile - > > > > then we can > > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > > Solving fixed > > > > > will be easier. > > > > > /] > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > has its own > > > > > > version of that. > > > > > > > > > > > > All 3GPP networks I know of support a raw packet service. > > > > On that > > > > > > service will run applications like MSN or AOL > instant messaging. > > > > > > Those services > > > > > > will need to be able to make emergency chats. To route > > > > > > properly, they need > > > > > > location. That means that EVERY handset must deploy some > > > > LCP, and > > > > > > must be able to get location suitable for emergency call > > > > > routing and > > > > > > dispatch per -phonebcp. The RV example is yet another > > > > case of the > > > > > > same thing. The mistake is assuming that all emergency > > > > calls will > > > > > > come through the E-CSCF. > > > > > > They won't, and the 3GPP access network must conform to all > > > > > > the -phonebcp requirements. > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > networks that > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > computers (and > > > > > > related operating systems, SIP soft clients), > analog terminal > > > > > > adaptors, or other similar devices that are intended > > > for use in a > > > > > > wireline environment. I think that organizations that can > > > > > > drive requirements for devices intended to be use in an > > > > environment where > > > > > > SUPL would actually work, should be responsible for > > > having device > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 are > > > > > absolutely > > > > > > in a position to require SUPL support for devices that > > > > > operate in an > > > > > > environment where SUPL works. This is a perfect > example of the > > > > > > "closed" network that Brian describes somewhere (framework, > > > > > I think). > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > environments > > > > > > where the operators of the access environment cannot be > > > > assumed to > > > > > > have any control over the type or nature of devices that > > > > > connect to or > > > > > > through it. Phonebcp needs to continue to have that as > > > > its purpose. > > > > > > > > > > > > I agree that nothing in phonebcp should preclude the use of > > > > > SUPL, or > > > > > > be incompatible with the use of SUPL. And I don't > think it does. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Roger Marshall > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > To: Brian Rosen; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > requiring PhoneBCP > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > would prefer > > > > > > 'require' since *most* of the location-aware 3G compatible > > > > > > handsets/aircards over the next several years will (I > > > > > predict) have a > > > > > > SUPL stack included. In the same time frame, many of those > > > > > will also > > > > > > have WiFi support, others will have LTE or WiMAX support > > > > as hybrids. > > > > > > > > > > > > SUPL will be common-place. OMA may not be > 'Open-Source', it > > > > > > is open-minded, and there is movement afoot to expand > > > > OMA/SUPL (as we > > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > > proposals > > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > > there will be > > > > > > fewer protocol, location representation, and privacy > > > > > discontinuities - > > > > > > things that too often get cited - yet are seldom well > > > understood. > > > > > > > > > > > > Let's encourage continued IETF communication with OMA/SUPL > > > > > - not block > > > > > > its use altogether. This is a case where we need to be > > > > > inclusive, not > > > > > > exclusive. > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > > forseeable - > > > > > > especially given that the location of the 3G aircard in the > > > > > router is > > > > > > good enough for routing. The scenario given needs some > > > > > integration, > > > > > > but is doable. Given that the aircard acts as a logical > > > > > SET, with a > > > > > > SUPL stack on board, and a GPS/AGPS chipset inside. This > > > > > combination > > > > > > *WILL* (I believe) interoperate with a number of end client > > > > > > applications to initiate and complete a location-routed, > > > > 3261 style > > > > > > SIP, emergency call through the core, and into an ESInet. > > > > > > > > > > > > -roger. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Brian Rosen > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > To: 'Richard Barnes' > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > > is that the > > > > > > > clients are generally not very L2 aware. It's the clients > > > > > > that have > > > > > > > the problem. > > > > > > > You can do things like interwork an L2 specific LCP to a > > > > > > common LCP so > > > > > > > that non L2 aware devices can work, but you have to do > > > > that, and > > > > > > > usually, that's impractical. Use my example. Suppose > > > > > that the L2 > > > > > > > used SUPL. It's possible for the PC Card that is plugged > > > > > into the > > > > > > > router could implement a SUPL client and a HELD server and > > > > > > interwork > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > Ethernet VoIP > > > > > > > phone could get location via HELD. Possible, but not > > > practical. > > > > > > > There are all sorts of these kinds of problems. > That's why > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > To: Brian Rosen > > > > > > > Cc: Gabor.Bajko@nokia.com; James.Winterbottom@andrew.com; > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > standards for > > > > > > > every access technology that's out there. What we can say > > > > > > is that the > > > > > > > paradigm for those protocols should be the same as at the > > > > > IP layer: > > > > > > > Clients MUST implement all, networks MUST implement at > > > > least one. > > > > > > > > > > > > > > (This is a little different from the text I sent before, > > > > > > and clearer, > > > > > > > I > > > > > > > think.) > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to enumerate all > > > > > > the possible > > > > > > > protocols at lower layers, we should just state > the general > > > > > > rule. It > > > > > > > seems to me that this achieves the same level of > > > > > > interoperability at > > > > > > > all layers. > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > implement, and > > > > > > > any number > > > > > > > > of optional ones, then every network has to implement at > > > > > > > least one of > > > > > > > > those > > > > > > > two > > > > > > > > LCPs, and any number of optional ones. That means that > > > > > > > "any number of > > > > > > > > optional ones" is useless for both parties. > > > > > > > > If the network can limit UAs to ONLY those that > implement > > > > > > > one of the > > > > > > > > optional protocols, then it works, but in practice, it > > > > > is usually > > > > > > > impossible > > > > > > > > to do that. My example is the wired, Ethernet connected > > > > > > > phone in an > > > > > > > > RV traveling down the road with wireless data card in a > > > > > > > router. These > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > To: Brian Rosen > > > > > > > > Cc: Gabor.Bajko@nokia.com; > James.Winterbottom@andrew.com; > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not reasonable > > > > > > > for an RFC to > > > > > > > > try to list all of the location protocols out there, if > > > > > > > > for > > > > > > > no other > > > > > > > > reason than that it will rapidly become obsolete. > > > > > > > > Instead, > > > > > > > we should > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > " > > > > > > > > INT-12 Devices MUST support the DHCP location options > > > > > > [RFC4776] and > > > > > > > > [RFC3825] and HELD > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > SHOULD support all location protocols supported at lower > > > > > > layers by > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > >> The problem with SUPL is that the majority of networks > > > > > > where SUPL > > > > > > > >> would > > > > > > > be > > > > > > > >> available have a proxy (E-CSCF) insert location. It > > > > > also has an > > > > > > > >> incompatible location representation, and an > incompatible > > > > > > > privacy model. > > > > > > > >> That makes it very hard to interwork with any > of the rest > > > > > > > of the IETF > > > > > > > > work. > > > > > > > >> I will say this. For quite some time, the > IETF has been > > > > > > trying to > > > > > > > > interest > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > interoperability at > > > > > > > >> the protocol, location representation and privacy > > > > > > levels. So far, > > > > > > > >> that has > > > > > > > > not > > > > > > > >> happened. If, as part of a comprehensive agreement to > > > > > > accomplish > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > not object. > > > > > > > >> > > > > > > > >> Brian > > > > > > > >> > > > > > > > >> -----Original Message----- > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > >> Cc: hannes.tschofenig@nsn.com; marc.linsner@cisco.com > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> Is the intent to list the LCPs which are access-type > > > > > > > agnostic but not > > > > > > > >> supported anywhere, or instead have a list of > LCPs which > > > > > > > are highly > > > > > > > >> probable to produce the intended result? > > > > > > > >> > > > > > > > >> There are restrictions everywhere, things come > at a cost > > > > > > > even in the > > > > > > > >> general Internet model. The reality is that most of the > > > > > > > devices with > > > > > > > >> internet access have a home network already. > > > > > > > >> > > > > > > > >> - Gabor > > > > > > > >> > > > > > > > >> > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ext Winterbottom, James > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig Hannes (NSN > > > > > - FI/Espoo) > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >Hi Gabor, > > > > > > > >> > > > > > > > > >> >The list of LCPs in the phone BCP is a must support > > > > > > list, and is > > > > > > > >> access- > > > > > > > >> >type agnostic. > > > > > > > >> >I am curious that you say that SUPL is a > MUST support > > > > > > > given that: > > > > > > > >> >a) it requires a home network in order to operate > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > >> >c) it is questionable whether it is really > deployable > > > > > > for WiFi > > > > > > > >> networks > > > > > > > >> > > > > > > > > >> >Can you perhaps describe how it fits into > the general > > > > > > > Internet model? > > > > > > > >> > > > > > > > > >> >Cheers > > > > > > > >> >James > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >-----Original Message----- > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > Gabor.Bajko@nokia.com > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > >> >To: ecrit@ietf.org > > > > > > > >> >Cc: marc.linsner@cisco.com; > hannes.tschofenig@nsn.com > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> >I was requested to send my observations > regarding this > > > > > > > requirement: > > > > > > > >> > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > > location options > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >I believe we should come up with a list of > LCPs which > > > > > > > are likely > > > > > > > >> to be > > > > > > > >> >supported in devices in a not so distant > future. Since > > > > > > > I have no > > > > > > > >> seen or > > > > > > > >> >heard about LLDP support yet, at least that > should be > > > > > > replaced > > > > > > > >> with what > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > mechanism, with the > > > > > > > >> >condition that this MUST only be supported if there > > > > > is a wifi > > > > > > > >> interface > > > > > > > >> >available on the device. > > > > > > > >> > > > > > > > > >> >- Gabor > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >________________________________ > > > > > > > >> > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > >> > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > marc.linsner@cisco.com > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> >Gabor, > > > > > > > >> > > > > > > > > >> >Could you please raise your question about location > > > > > > > protocols in > > > > > > > >> Phone > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session again? > > > > > > > >> > > > > > > > > >> >Ciao > > > > > > > >> >Hannes > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >This message is for the designated recipient > > > only and may > > > > > > > >> >contain privileged, proprietary, or > otherwise private > > > > > > > information. > > > > > > > >> >If you have received it in error, please notify > > > the sender > > > > > > > >> >immediately and delete the original. Any > > > > > unauthorized use of > > > > > > > >> >this email is prohibited. > > > > > > > >> > > > > > > > >>> > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > >>> --- > > > > > > > >> -- > > > > > > > >> >----------------------- > > > > > > > >> >[mf2] > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information contained in this > > > > > message may > > > > > > be privileged and/or confidential. If you are not > the intended > > > > > > recipient, or responsible for delivering this message to > > > > > the intended > > > > > > recipient, any review, forwarding, dissemination, > > > distribution or > > > > > > copying of this communication or any attachment(s) > is strictly > > > > > > prohibited. If you have received this message in error, > > > > > please notify > > > > > > the sender immediately, and delete it and all attachments > > > > from your > > > > > > computer and network. > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ***** > > > > > > > > > > > > The information transmitted is intended only for the person > > > > > or entity > > > > > > to which it is addressed and may contain confidential, > > > > proprietary, > > > > > > and/or privileged material. Any review, retransmission, > > > > > dissemination > > > > > > or other use of, or taking of any action in > reliance upon this > > > > > > information by persons or entities other than the intended > > > > > recipient > > > > > > is prohibited. If you received this in error, please > > > contact the > > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 ecrit-bounces@ietf.org Fri Nov 21 11:40:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3049A3A68CE; Fri, 21 Nov 2008 11:40:44 -0800 (PST) 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 9CB3C3A688B for ; Fri, 21 Nov 2008 11:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 d4JTPiNshU-j for ; Fri, 21 Nov 2008 11:40:39 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 2303F3A67A7 for ; Fri, 21 Nov 2008 11:40:38 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 21 Nov 2008 11:40:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:39:18 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B533E47@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTgAACEi+AABB9PkAABGfKwAAB2jkA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80c d670$@ne t> <8C837214 C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Thomson, Martin" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Martin: I agree with your excellent reference frame explanation, and would support additional documentation/discussion around how we assemble and use the location 'complex' you've mentioned - since phonebcp requirements provide for these kinds of location information by which a complex could be formed. -roger. > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Friday, November 21, 2008 11:30 AM > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Hi Roger, > > To answer this question, you have to first answer the > question: how many reference frames exist? My answer is one. > > It helps to only have a single reference frame for this > purpose. That is, earth-centred, earth-fixed is the single > reference frame we use to determine movement. Anything > moving in that reference frame is moving. Establishing ad > hoc reference frames increases the complexity of any solution > that we develop. > > In the plane example, you might use a complex of the geodetic > location of the plane with uncertainty, plus a civic address > with SEAT=34C. However, this would be considered to be > moving at 3500m/s. > > Thanks, > Martin > > > -----Original Message----- > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > Sent: Friday, 21 November 2008 12:54 PM > > To: Brian Rosen; Thomson, Martin > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > I agree with the differentiation of protocol requirement which > > differentiate between mobile and non-mobile (use whatever term you > > like), but I do not support terms such as 'wireless' (as is in the > > draft) for the reasons you reasonably cite. > > > > The airplane example provides two notions of location. One may > > relative to a wired database, which is inside a closed > system, which > > can only provide a relative location (e.g., you're in seat > 34C). The > > other view is that of being mobile, in this case, best > given by some > > 3space datum coordinate set (it could either represent the plane's > > position or the end device location - you pick). The two > forms have > > different levels of importance, but each is relevant. > > > > The question is, is the end device fixed or mobile? > > > > -roger. > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, November 21, 2008 8:53 AM > > > To: 'Thomson, Martin'; Roger Marshall > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > The plane is a great example of an indirect connection to > a network. > > > My RV was another. You can't make assumptions about mobility or > > > anything else of relevance to the group from the > characteristics of > > > the device placing the emergency call, or it's first hop > connection. > > > It's another example of how difficult it is to make use > of layer 2 > > > specific LCPs. > > > Generally, assuming that bridging devices will bridge LCPs is a > > > losing proposition. > > > > > > Brian > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > Behalf Of Thomson, Martin > > > Sent: Friday, November 21, 2008 11:43 AM > > > To: Roger Marshall > > > Cc: ecrit@ietf.org > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > I strongly disagree with this from a philosophical > standpoint. Type > > > of access should only affect protocol design where attributes of > > > that access affect the protocol. > > > > > > For instance, we design protocols for networks with long delays, > > > which happen to be applicable to inter-planetary communication. > > > This means that when someone uses that protocol for > shipping data on > > > reindeer, it doesn't break because someone assumes that > it a radio > > > link in space. > > > > > > So, what we need to do is identify attributes of the network that > > > are relevant to the protocol design. As far as the document is > > > currently specified, the attribute that we're interested in is > > > mobility - that is, the fact that location changes. Do not > > > mistakenly assign this attribute to wireless networks. > > > > > > For an example of how this is harmful, imagine that it is > possible > > > that a wired connection on a plane (now, why don't they do > > > that...seems logical). > > > If we had a client that was on a wire, there is the risk > that they > > > continue this assumption to detrimental effect. > > > > > > Cheers, > > > Martin > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > Of Roger Marshall > > > > Sent: Friday, 21 November 2008 9:29 AM > > > > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; > > > Richard Barnes > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > Keith: > > > > I agree completely with the first part of what you said, > > > and want to > > > > clarify my intent of highlighting differences in general: > > > > > > > > We've already got different requirements by access > 'type' (i.e., > > > > 'wireless' and 'mobile' mentioned by name), so for some other > > > > requirements - certainly, I would think those that mention the > > > > term 'wire database' - those imply their application to a fixed > > > > type of network access (it wouldn't work to well for mobile). > > > > > > > > What I was asking for, (and to my understanding, it was > > > agreed to in > > > > the ecrit meeting), was that since these requirements > > > already mention > > > > different access types, that there should be some > > > additional text that > > > > acknowledges the existance of these different access types, as > > > > background for their respective requirements. > > > > > > > > -roger. > > > > > > > > > > > > > -----Original Message----- > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > Sent: Thursday, November 20, 2008 9:22 PM > > > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; > Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > We are moving towards a state where devices support > multiple of > > > > > these, and in some cases where they may be active at the same > > > > time. > > > > > > > > > > We certainly already have devices that may be simultaneously > > > > > registered in WLAN and 3GPP access. > > > > > > > > > > As soon as you start distinguishing any type of phone > by access > > > > > technology, you will end up with these devices having > to support > > > > > multiple different requirements. > > > > > > > > > > regards > > > > > > > > > > Keith > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > Of Roger Marshall > > > > > > Sent: Thursday, November 20, 2008 9:07 PM > > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > Isn't there a need to set the scope [text] of phonebcp, > > > so that it > > > > > > makes clear what that the requirements apply (without > > > > > > bias) to both fixed and mobile end devices (and their > > > associated > > > > > > network deployment types)? > > > > > > > > > > > > Below is some keyword sampling to show some implications > > > > > with regard > > > > > > to fixed vs. mobile, but which isn't as crisp as it > could be > > > > > > (depending on the scope). > > > > > > > > > > > > A search of phonebcp for the following terms yields the > > > associated > > > > > > references: > > > > > > > > > > > > Fixed: > > > > > > (none); > > > > > > > > > > > > Wireline: > > > > > > (none); > > > > > > > > > > > > Mobile: > > > > > > AN-11; > > > > > > ED-35/AN-19; > > > > > > ED-35; > > > > > > > > > > > > Wireless: > > > > > > AN-7/INT-6; > > > > > > AN-9; > > > > > > AN-7; > > > > > > INT-6; > > > > > > > > > > > > From the toc, it is listed... > > > > > > > > > > > > 6.2.2. Access network "wire database" location > > > > > information . > > > > > > 7 > > > > > > 6.2.3. End-system measured location > information . . . > > > > > > . . . . 7 > > > > > > 6.2.4. Network-measured location > information . . . . > > > > > > . . . . 8 > > > > > > > > > > > > -roger. > > > > > > > > > > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > > > > of the text > > > > > > sections (Intro, etc.) > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's > neutral. If > > > > > > we need to > > > > > > > parse more carefully, SUPL isn't very suitable for > > > > > wiremap forms of > > > > > > > location determination. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > > > networks that don't use GPS or some form of > > > measured location. > > > > > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > > > > suggesting that OMA > > > > > > > (and therefore 3GPP, 3GPP2) throw away their reliance > > > on 'rough > > > > > > > location' via CellID, are you? > > > > > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > > > location - given > > > > > > > Terrestial trilateration - measured Celestial > trilateration > > > > > > - measured > > > > > > > Geocoded/reverse geocoded - derived > > > > > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > > > to 'given' > > > > > > > location scenarios, aka wiremap, etc. that are more > > > > > > Wireline oriented, > > > > > > > rather than mobile. For the future, wireline devices > > > reduce in > > > > > > > number, mobile (or even nomadic) devices will > > > continue in their > > > > > > > distribution bias. Fixed vs. Mobile has been the > > > > > > > fundamental difference between how the IETF looks > at things > > > > > > > vs. these > > > > > mentioned > > > > > > > other fora. I contend that if we solve this for mobile - > > > > > > then we can > > > > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > > > > Solving fixed > > > > > > > will be easier. > > > > > > > /] > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > > > has its own > > > > > > > > version of that. > > > > > > > > > > > > > > > > All 3GPP networks I know of support a raw > packet service. > > > > > > On that > > > > > > > > service will run applications like MSN or AOL instant > > > > messaging. > > > > > > > > Those services > > > > > > > > will need to be able to make emergency chats. To route > > > > > > > > properly, they need > > > > > > > > location. That means that EVERY handset must > deploy some > > > > > > LCP, and > > > > > > > > must be able to get location suitable for emergency call > > > > > > > routing and > > > > > > > > dispatch per -phonebcp. The RV example is yet another > > > > > > case of the > > > > > > > > same thing. The mistake is assuming that all emergency > > > > > > calls will > > > > > > > > come through the E-CSCF. > > > > > > > > They won't, and the 3GPP access network must conform to > > > > > > > > all the -phonebcp requirements. > > > > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > networks that > > > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > > > computers (and > > > > > > > > related operating systems, SIP soft clients), > > > analog terminal > > > > > > > > adaptors, or other similar devices that are intended > > > > > for use in a > > > > > > > > wireline environment. I think that > organizations that can > > > > > > > > drive requirements for devices intended to be use in an > > > > > > environment where > > > > > > > > SUPL would actually work, should be responsible for > > > > > having device > > > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 > > > > > > > > are > > > > > > > absolutely > > > > > > > > in a position to require SUPL support for devices that > > > > > > > operate in an > > > > > > > > environment where SUPL works. This is a perfect > > > example of the > > > > > > > > "closed" network that Brian describes somewhere > > > > > > > > (framework, > > > > > > > I think). > > > > > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > > > environments > > > > > > > > where the operators of the access environment cannot be > > > > > > assumed to > > > > > > > > have any control over the type or nature of devices that > > > > > > > connect to or > > > > > > > > through it. Phonebcp needs to continue to have that as > > > > > > its purpose. > > > > > > > > > > > > > > > > I agree that nothing in phonebcp should > preclude the use > > > > > > > > of > > > > > > > SUPL, or > > > > > > > > be incompatible with the use of SUPL. And I > don't think it > > > > does. > > > > > > > > Barbara > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > Of Roger Marshall > > > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > > > To: Brian Rosen; Richard Barnes > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > > > requiring PhoneBCP > > > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > > > would prefer > > > > > > > > 'require' since *most* of the location-aware 3G > compatible > > > > > > > > handsets/aircards over the next several years will (I > > > > > > > predict) have a > > > > > > > > SUPL stack included. In the same time frame, many of > > > > > > > > those > > > > > > > will also > > > > > > > > have WiFi support, others will have LTE or WiMAX support > > > > > > as hybrids. > > > > > > > > > > > > > > > > SUPL will be common-place. OMA may not be > > > 'Open-Source', it > > > > > > > > is open-minded, and there is movement afoot to expand > > > > > > OMA/SUPL (as we > > > > > > > > heard in the geopriv mtg. on Tuesday) w/respect expected > > > > > > proposals > > > > > > > > such as LocSIP, etc. Over the fairly near-term, I think > > > > > > > there will be > > > > > > > > fewer protocol, location representation, and privacy > > > > > > > discontinuities - > > > > > > > > things that too often get cited - yet are seldom well > > > > > understood. > > > > > > > > > > > > > > > > Let's encourage continued IETF communication > with OMA/SUPL > > > > > > > - not block > > > > > > > > its use altogether. This is a case where we need to be > > > > > > > inclusive, not > > > > > > > > exclusive. > > > > > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > > > > forseeable - > > > > > > > > especially given that the location of the 3G aircard in > > > > > > > > the > > > > > > > router is > > > > > > > > good enough for routing. The scenario given needs some > > > > > > > integration, > > > > > > > > but is doable. Given that the aircard acts as a logical > > > > > > > SET, with a > > > > > > > > SUPL stack on board, and a GPS/AGPS chipset > inside. This > > > > > > > combination > > > > > > > > *WILL* (I believe) interoperate with a number of end > > > > > > > > client applications to initiate and complete a > > > > > > > > location-routed, > > > > > > 3261 style > > > > > > > > SIP, emergency call through the core, and into > an ESInet. > > > > > > > > > > > > > > > > -roger. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of Brian Rosen > > > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > > > To: 'Richard Barnes' > > > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > > > > is that the > > > > > > > > > clients are generally not very L2 aware. It's the > > clients > > > > > > > > that have > > > > > > > > > the problem. > > > > > > > > > You can do things like interwork an L2 > specific LCP to a > > > > > > > > common LCP so > > > > > > > > > that non L2 aware devices can work, but you have to do > > > > > > that, and > > > > > > > > > usually, that's impractical. Use my example. Suppose > > > > > > > that the L2 > > > > > > > > > used SUPL. It's possible for the PC Card that is > > > > > > > > > plugged > > > > > > > into the > > > > > > > > > router could implement a SUPL client and a HELD server > > and > > > > > > > > interwork > > > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > > > Ethernet VoIP > > > > > > > > > phone could get location via HELD. Possible, but not > > > > > practical. > > > > > > > > > There are all sorts of these kinds of problems. > > > That's why > > > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > > > To: Brian Rosen > > > > > > > > > Cc: Gabor.Bajko@nokia.com; > > > > > > > > > James.Winterbottom@andrew.com; ecrit@ietf.org; > > > > > > > > > marc.linsner@cisco.com; > > > > > > hannes.tschofenig@nsn.com > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > > > standards for > > > > > > > > > every access technology that's out there. What we can > > say > > > > > > > > is that the > > > > > > > > > paradigm for those protocols should be the same as at > > > > > > > > > the > > > > > > > IP layer: > > > > > > > > > Clients MUST implement all, networks MUST implement at > > > > > > least one. > > > > > > > > > > > > > > > > > > (This is a little different from the text I > sent before, > > > > > > > > and clearer, > > > > > > > > > I > > > > > > > > > think.) > > > > > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to > enumerate all > > > > > > > > the possible > > > > > > > > > protocols at lower layers, we should just state > > > the general > > > > > > > > rule. It > > > > > > > > > seems to me that this achieves the same level of > > > > > > > > interoperability at > > > > > > > > > all layers. > > > > > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > > > implement, and > > > > > > > > > any number > > > > > > > > > > of optional ones, then every network has to > implement > > at > > > > > > > > > least one of > > > > > > > > > > those > > > > > > > > > two > > > > > > > > > > LCPs, and any number of optional ones. That means > > > > > > > > > > that > > > > > > > > > "any number of > > > > > > > > > > optional ones" is useless for both parties. > > > > > > > > > > If the network can limit UAs to ONLY those that > > > implement > > > > > > > > > one of the > > > > > > > > > > optional protocols, then it works, but in > practice, it > > > > > > > is usually > > > > > > > > > impossible > > > > > > > > > > to do that. My example is the wired, Ethernet > > connected > > > > > > > > > phone in an > > > > > > > > > > RV traveling down the road with wireless > data card in > > > > > > > > > > a > > > > > > > > > router. These > > > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > > > To: Brian Rosen > > > > > > > > > > Cc: Gabor.Bajko@nokia.com; > > > James.Winterbottom@andrew.com; > > > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com > > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not > > reasonable > > > > > > > > > for an RFC to > > > > > > > > > > try to list all of the location protocols > out there, > > > > > > > > > > if for > > > > > > > > > no other > > > > > > > > > > reason than that it will rapidly become obsolete. > > > > > > > > > > Instead, > > > > > > > > > we should > > > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > INT-12 Devices MUST support the DHCP > location options > > > > > > > > [RFC4776] and > > > > > > > > > > [RFC3825] and HELD > > > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > > > SHOULD support all location protocols supported at > > lower > > > > > > > > layers by > > > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > > > >> The problem with SUPL is that the majority of > > > > > > > > > >> networks > > > > > > > > where SUPL > > > > > > > > > >> would > > > > > > > > > be > > > > > > > > > >> available have a proxy (E-CSCF) insert > location. It > > > > > > > also has an > > > > > > > > > >> incompatible location representation, and an > > > incompatible > > > > > > > > > privacy model. > > > > > > > > > >> That makes it very hard to interwork with any > > > of the rest > > > > > > > > > of the IETF > > > > > > > > > > work. > > > > > > > > > >> I will say this. For quite some time, the > > > IETF has been > > > > > > > > trying to > > > > > > > > > > interest > > > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > > > interoperability at > > > > > > > > > >> the protocol, location representation and privacy > > > > > > > > levels. So far, > > > > > > > > > >> that has > > > > > > > > > > not > > > > > > > > > >> happened. If, as part of a comprehensive > agreement > > > > > > > > > >> to > > > > > > > > accomplish > > > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > > > not object. > > > > > > > > > >> > > > > > > > > > >> Brian > > > > > > > > > >> > > > > > > > > > >> -----Original Message----- > > > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > > > >> Cc: hannes.tschofenig@nsn.com; > marc.linsner@cisco.com > > > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in > Phone BCP > > > > > > > > > >> > > > > > > > > > >> Hi, > > > > > > > > > >> > > > > > > > > > >> Is the intent to list the LCPs which are > access-type > > > > > > > > > agnostic but not > > > > > > > > > >> supported anywhere, or instead have a list of > > > LCPs which > > > > > > > > > are highly > > > > > > > > > >> probable to produce the intended result? > > > > > > > > > >> > > > > > > > > > >> There are restrictions everywhere, things come > > > at a cost > > > > > > > > > even in the > > > > > > > > > >> general Internet model. The reality is that most of > > the > > > > > > > > > devices with > > > > > > > > > >> internet access have a home network already. > > > > > > > > > >> > > > > > > > > > >> - Gabor > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> >-----Original Message----- > > > > > > > > > >> >From: ext Winterbottom, James > > > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > ecrit@ietf.org > > > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig > Hannes (NSN > > > > > > > - FI/Espoo) > > > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in Phone > > BCP > > > > > > > > > >> > > > > > > > > > > >> >Hi Gabor, > > > > > > > > > >> > > > > > > > > > > >> >The list of LCPs in the phone BCP is a must > > > > > > > > > >> support > > > > > > > > list, and is > > > > > > > > > >> access- > > > > > > > > > >> >type agnostic. > > > > > > > > > >> >I am curious that you say that SUPL is a > > > MUST support > > > > > > > > > given that: > > > > > > > > > >> >a) it requires a home network in order > to operate > > > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > > > >> >c) it is questionable whether it is really > > > deployable > > > > > > > > for WiFi > > > > > > > > > >> networks > > > > > > > > > >> > > > > > > > > > > >> >Can you perhaps describe how it fits into > > > the general > > > > > > > > > Internet model? > > > > > > > > > >> > > > > > > > > > > >> >Cheers > > > > > > > > > >> >James > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> >-----Original Message----- > > > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > > > Gabor.Bajko@nokia.com > > > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > > > >> >To: ecrit@ietf.org > > > > > > > > > >> >Cc: marc.linsner@cisco.com; > > > hannes.tschofenig@nsn.com > > > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in Phone > > BCP > > > > > > > > > >> > > > > > > > > > > >> >I was requested to send my observations > > > regarding this > > > > > > > > > requirement: > > > > > > > > > >> > > > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: DHCP > > > > > > > > > location options > > > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] and > > > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> >I believe we should come up with a list of > > > LCPs which > > > > > > > > > are likely > > > > > > > > > >> to be > > > > > > > > > >> >supported in devices in a not so distant > > > future. Since > > > > > > > > > I have no > > > > > > > > > >> seen or > > > > > > > > > >> >heard about LLDP support yet, at least that > > > should be > > > > > > > > replaced > > > > > > > > > >> with what > > > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > > > mechanism, with the > > > > > > > > > >> >condition that this MUST only be supported if > > > > > > > > > >> there > > > > > > > is a wifi > > > > > > > > > >> interface > > > > > > > > > >> >available on the device. > > > > > > > > > >> > > > > > > > > > > >> >- Gabor > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> >________________________________ > > > > > > > > > >> > > > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > > > >> > > > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > > > marc.linsner@cisco.com > > > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> >Gabor, > > > > > > > > > >> > > > > > > > > > > >> >Could you please raise your question about > > > > > > > > > >> location > > > > > > > > > protocols in > > > > > > > > > >> Phone > > > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session > > again? > > > > > > > > > >> > > > > > > > > > > >> >Ciao > > > > > > > > > >> >Hannes > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > >>> --- > > > > > > > > > >> -- > > > > > > > > > >> >----------------------- > > > > > > > > > >> >This message is for the designated recipient > > > > > only and may > > > > > > > > > >> >contain privileged, proprietary, or > > > otherwise private > > > > > > > > > information. > > > > > > > > > >> >If you have received it in error, please notify > > > > > the sender > > > > > > > > > >> >immediately and delete the original. Any > > > > > > > unauthorized use of > > > > > > > > > >> >this email is prohibited. > > > > > > > > > >> > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > >>> --- > > > > > > > > > >> -- > > > > > > > > > >> >----------------------- > > > > > > > > > >> >[mf2] > > > > > > > > > >> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information > contained in this > > > > > > > message may > > > > > > > > be privileged and/or confidential. If you are not > > > the intended > > > > > > > > recipient, or responsible for delivering this message to > > > > > > > the intended > > > > > > > > recipient, any review, forwarding, dissemination, > > > > > distribution or > > > > > > > > copying of this communication or any attachment(s) > > > is strictly > > > > > > > > prohibited. If you have received this message in error, > > > > > > > please notify > > > > > > > > the sender immediately, and delete it and all > attachments > > > > > > from your > > > > > > > > computer and network. > > > > > > > > _______________________________________________ > > > > > > > > Ecrit mailing list > > > > > > > > Ecrit@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > > > > > The information transmitted is intended only for the > > > > > > > > person > > > > > > > or entity > > > > > > > > to which it is addressed and may contain confidential, > > > > > > proprietary, > > > > > > > > and/or privileged material. Any review, retransmission, > > > > > > > dissemination > > > > > > > > or other use of, or taking of any action in > > > reliance upon this > > > > > > > > information by persons or entities other than > the intended > > > > > > > recipient > > > > > > > > is prohibited. If you received this in error, please > > > > > contact the > > > > > > > > sender and delete the material from all computers. GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > -------------------------------------------------------------- > > > -------------- > > > -------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > -------------------------------------------------------------- > > > -------------- > > > -------------------- > > > [mf2] > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 11:49:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287483A688B; Fri, 21 Nov 2008 11:49:59 -0800 (PST) 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 35BD53A6407 for ; Fri, 21 Nov 2008 11:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 9kHiaiEgm3Ch for ; Fri, 21 Nov 2008 11:49:52 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 879943A688B for ; Fri, 21 Nov 2008 11:49:51 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_21_14_07_31 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 21 Nov 2008 14:07:31 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 13:49:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 13:49:49 -0600 Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A65750B533E47@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclLKpbzAikBg8HFQTqZY6XD32Ac3QAANldwAAWp0DAAAYlv4AAAlTtgAABeemAAAKzpQAAAKTGQABJUYVAAFMMssAACzKTgAACEi+AABB9PkAABGfKwAAB2jkAAAJX4oA== References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80c d670$@ne t> <8C837214 C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> <8C837214C95C864C9F34F3635C2A65750B533E47@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Roger Marshall" X-OriginalArrivalTime: 21 Nov 2008 19:49:50.0014 (UTC) FILETIME=[507B25E0:01C94C12] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org PIDF-LO profile already discusses forming a complex. In my opinion, that's all we can sensibly do. I don't think that enumerating all the alternatives would be productive. > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, 21 November 2008 1:39 PM > To: Thomson, Martin > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > Martin: > I agree with your excellent reference frame explanation, and would > support additional documentation/discussion around how we assemble and > use the location 'complex' you've mentioned - since phonebcp > requirements provide for these kinds of location information by which a > complex could be formed. > > -roger. > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Friday, November 21, 2008 11:30 AM > > To: Roger Marshall > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > Hi Roger, > > > > To answer this question, you have to first answer the > > question: how many reference frames exist? My answer is one. > > > > It helps to only have a single reference frame for this > > purpose. That is, earth-centred, earth-fixed is the single > > reference frame we use to determine movement. Anything > > moving in that reference frame is moving. Establishing ad > > hoc reference frames increases the complexity of any solution > > that we develop. > > > > In the plane example, you might use a complex of the geodetic > > location of the plane with uncertainty, plus a civic address > > with SEAT=34C. However, this would be considered to be > > moving at 3500m/s. > > > > Thanks, > > Martin > > > > > -----Original Message----- > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > Sent: Friday, 21 November 2008 12:54 PM > > > To: Brian Rosen; Thomson, Martin > > > Cc: ecrit@ietf.org > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > I agree with the differentiation of protocol requirement which > > > differentiate between mobile and non-mobile (use whatever term you > > > like), but I do not support terms such as 'wireless' (as is in the > > > draft) for the reasons you reasonably cite. > > > > > > The airplane example provides two notions of location. One may > > > relative to a wired database, which is inside a closed > > system, which > > > can only provide a relative location (e.g., you're in seat > > 34C). The > > > other view is that of being mobile, in this case, best > > given by some > > > 3space datum coordinate set (it could either represent the plane's > > > position or the end device location - you pick). The two > > forms have > > > different levels of importance, but each is relevant. > > > > > > The question is, is the end device fixed or mobile? > > > > > > -roger. > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, November 21, 2008 8:53 AM > > > > To: 'Thomson, Martin'; Roger Marshall > > > > Cc: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > The plane is a great example of an indirect connection to > > a network. > > > > My RV was another. You can't make assumptions about mobility or > > > > anything else of relevance to the group from the > > characteristics of > > > > the device placing the emergency call, or it's first hop > > connection. > > > > It's another example of how difficult it is to make use > > of layer 2 > > > > specific LCPs. > > > > Generally, assuming that bridging devices will bridge LCPs is a > > > > losing proposition. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > > > Behalf Of Thomson, Martin > > > > Sent: Friday, November 21, 2008 11:43 AM > > > > To: Roger Marshall > > > > Cc: ecrit@ietf.org > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > I strongly disagree with this from a philosophical > > standpoint. Type > > > > of access should only affect protocol design where attributes of > > > > that access affect the protocol. > > > > > > > > For instance, we design protocols for networks with long delays, > > > > which happen to be applicable to inter-planetary communication. > > > > This means that when someone uses that protocol for > > shipping data on > > > > reindeer, it doesn't break because someone assumes that > > it a radio > > > > link in space. > > > > > > > > So, what we need to do is identify attributes of the network that > > > > are relevant to the protocol design. As far as the document is > > > > currently specified, the attribute that we're interested in is > > > > mobility - that is, the fact that location changes. Do not > > > > mistakenly assign this attribute to wireless networks. > > > > > > > > For an example of how this is harmful, imagine that it is > > possible > > > > that a wired connection on a plane (now, why don't they do > > > > that...seems logical). > > > > If we had a client that was on a wire, there is the risk > > that they > > > > continue this assumption to detrimental effect. > > > > > > > > Cheers, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: ecrit-bounces@ietf.org > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > Of Roger Marshall > > > > > Sent: Friday, 21 November 2008 9:29 AM > > > > > To: DRAGE, Keith (Keith); Brian Rosen; Stark, Barbara; > > > > Richard Barnes > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > Keith: > > > > > I agree completely with the first part of what you said, > > > > and want to > > > > > clarify my intent of highlighting differences in general: > > > > > > > > > > We've already got different requirements by access > > 'type' (i.e., > > > > > 'wireless' and 'mobile' mentioned by name), so for some other > > > > > requirements - certainly, I would think those that mention the > > > > > term 'wire database' - those imply their application to a fixed > > > > > type of network access (it wouldn't work to well for mobile). > > > > > > > > > > What I was asking for, (and to my understanding, it was > > > > agreed to in > > > > > the ecrit meeting), was that since these requirements > > > > already mention > > > > > different access types, that there should be some > > > > additional text that > > > > > acknowledges the existance of these different access types, as > > > > > background for their respective requirements. > > > > > > > > > > -roger. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > > Sent: Thursday, November 20, 2008 9:22 PM > > > > > > To: Roger Marshall; Brian Rosen; Stark, Barbara; > > Richard Barnes > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > We are moving towards a state where devices support > > multiple of > > > > > > these, and in some cases where they may be active at the same > > > > > time. > > > > > > > > > > > > We certainly already have devices that may be simultaneously > > > > > > registered in WLAN and 3GPP access. > > > > > > > > > > > > As soon as you start distinguishing any type of phone > > by access > > > > > > technology, you will end up with these devices having > > to support > > > > > > multiple different requirements. > > > > > > > > > > > > regards > > > > > > > > > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ecrit-bounces@ietf.org > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > Of Roger Marshall > > > > > > > Sent: Thursday, November 20, 2008 9:07 PM > > > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > Isn't there a need to set the scope [text] of phonebcp, > > > > so that it > > > > > > > makes clear what that the requirements apply (without > > > > > > > bias) to both fixed and mobile end devices (and their > > > > associated > > > > > > > network deployment types)? > > > > > > > > > > > > > > Below is some keyword sampling to show some implications > > > > > > with regard > > > > > > > to fixed vs. mobile, but which isn't as crisp as it > > could be > > > > > > > (depending on the scope). > > > > > > > > > > > > > > A search of phonebcp for the following terms yields the > > > > associated > > > > > > > references: > > > > > > > > > > > > > > Fixed: > > > > > > > (none); > > > > > > > > > > > > > > Wireline: > > > > > > > (none); > > > > > > > > > > > > > > Mobile: > > > > > > > AN-11; > > > > > > > ED-35/AN-19; > > > > > > > ED-35; > > > > > > > > > > > > > > Wireless: > > > > > > > AN-7/INT-6; > > > > > > > AN-9; > > > > > > > AN-7; > > > > > > > INT-6; > > > > > > > > > > > > > > From the toc, it is listed... > > > > > > > > > > > > > > 6.2.2. Access network "wire database" location > > > > > > information . > > > > > > > 7 > > > > > > > 6.2.3. End-system measured location > > information . . . > > > > > > > . . . . 7 > > > > > > > 6.2.4. Network-measured location > > information . . . . > > > > > > > . . . . 8 > > > > > > > > > > > > > > -roger. > > > > > > > > > > > > > > > > > > > > > No mention of fixed, wireline, wireless, or mobile in any > > > > > > of the text > > > > > > > sections (Intro, etc.) > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > Sent: Thursday, November 20, 2008 12:32 PM > > > > > > > > To: Roger Marshall; 'Stark, Barbara'; 'Richard Barnes' > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > Phonebcp doesn't have a pre-disposition. It's > > neutral. If > > > > > > > we need to > > > > > > > > parse more carefully, SUPL isn't very suitable for > > > > > > wiremap forms of > > > > > > > > location determination. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > > > > > > > > Sent: Thursday, November 20, 2008 3:22 PM > > > > > > > > To: Brian Rosen; Stark, Barbara; Richard Barnes > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > > > > networks that don't use GPS or some form of > > > > measured location. > > > > > > > > > > > > > > > > [rsm - measured only - really? - surely you aren't > > > > > > > suggesting that OMA > > > > > > > > (and therefore 3GPP, 3GPP2) throw away their reliance > > > > on 'rough > > > > > > > > location' via CellID, are you? > > > > > > > > > > > > > > > > Wiremap location - given (manually input)] CellID > > > > > > location - given > > > > > > > > Terrestial trilateration - measured Celestial > > trilateration > > > > > > > - measured > > > > > > > > Geocoded/reverse geocoded - derived > > > > > > > > > > > > > > > > I would hope that PhoneBCP doesn't show a pre-disposition > > > > > > to 'given' > > > > > > > > location scenarios, aka wiremap, etc. that are more > > > > > > > Wireline oriented, > > > > > > > > rather than mobile. For the future, wireline devices > > > > reduce in > > > > > > > > number, mobile (or even nomadic) devices will > > > > continue in their > > > > > > > > distribution bias. Fixed vs. Mobile has been the > > > > > > > > fundamental difference between how the IETF looks > > at things > > > > > > > > vs. these > > > > > > mentioned > > > > > > > > other fora. I contend that if we solve this for mobile - > > > > > > > then we can > > > > > > > > begin communicating better with OMA/3GPP/3GPP2, and... > > > > > > > Solving fixed > > > > > > > > will be easier. > > > > > > > > /] > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > > Sent: Thursday, November 20, 2008 12:07 PM > > > > > > > > > To: 'Stark, Barbara'; Roger Marshall; 'Richard Barnes' > > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > Gabor accuses us of ignoring reality. The 3GPP crowd > > > > > > has its own > > > > > > > > > version of that. > > > > > > > > > > > > > > > > > > All 3GPP networks I know of support a raw > > packet service. > > > > > > > On that > > > > > > > > > service will run applications like MSN or AOL instant > > > > > messaging. > > > > > > > > > Those services > > > > > > > > > will need to be able to make emergency chats. To > route > > > > > > > > > properly, they need > > > > > > > > > location. That means that EVERY handset must > > deploy some > > > > > > > LCP, and > > > > > > > > > must be able to get location suitable for emergency > call > > > > > > > > routing and > > > > > > > > > dispatch per -phonebcp. The RV example is yet another > > > > > > > case of the > > > > > > > > > same thing. The mistake is assuming that all emergency > > > > > > > calls will > > > > > > > > > come through the E-CSCF. > > > > > > > > > They won't, and the 3GPP access network must conform to > > > > > > > > > all the -phonebcp requirements. > > > > > > > > > > > > > > > > > > Generally, I agree that SUPL is unsuitable for access > > > > > > > networks that > > > > > > > > > don't use GPS or some form of measured location. > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > > > > Sent: Thursday, November 20, 2008 2:54 PM > > > > > > > > > To: Roger Marshall; Brian Rosen; Richard Barnes > > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > > Subject: RE: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > I cannot support requiring SUPL in DSL routers, desktop > > > > > > > > computers (and > > > > > > > > > related operating systems, SIP soft clients), > > > > analog terminal > > > > > > > > > adaptors, or other similar devices that are intended > > > > > > for use in a > > > > > > > > > wireline environment. I think that > > organizations that can > > > > > > > > > drive requirements for devices intended to be use in an > > > > > > > environment where > > > > > > > > > SUPL would actually work, should be responsible for > > > > > > having device > > > > > > > > > requirements requiring SUPL. In other words, 3GPP/3GPP2 > > > > > > > > > are > > > > > > > > absolutely > > > > > > > > > in a position to require SUPL support for devices that > > > > > > > > operate in an > > > > > > > > > environment where SUPL works. This is a perfect > > > > example of the > > > > > > > > > "closed" network that Brian describes somewhere > > > > > > > > > (framework, > > > > > > > > I think). > > > > > > > > > > > > > > > > > > Phonebcp is about requirements for devices in access > > > > > > environments > > > > > > > > > where the operators of the access environment cannot be > > > > > > > assumed to > > > > > > > > > have any control over the type or nature of devices > that > > > > > > > > connect to or > > > > > > > > > through it. Phonebcp needs to continue to have that as > > > > > > > its purpose. > > > > > > > > > > > > > > > > > > I agree that nothing in phonebcp should > > preclude the use > > > > > > > > > of > > > > > > > > SUPL, or > > > > > > > > > be incompatible with the use of SUPL. And I > > don't think it > > > > > does. > > > > > > > > > Barbara > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > Of Roger Marshall > > > > > > > > > Sent: Thursday, November 20, 2008 2:36 PM > > > > > > > > > To: Brian Rosen; Richard Barnes > > > > > > > > > Cc: Gabor.Bajko@nokia.com; marc.linsner@cisco.com; > > > > > > > > > hannes.tschofenig@nsn.com; ecrit@ietf.org > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > > > > > > > > If the choice is between preventing, allowing, or > > > > > > > > requiring PhoneBCP > > > > > > > > > suppport of SUPL, then my vote is to NOT prevent! I > > > > > > would prefer > > > > > > > > > 'require' since *most* of the location-aware 3G > > compatible > > > > > > > > > handsets/aircards over the next several years will (I > > > > > > > > predict) have a > > > > > > > > > SUPL stack included. In the same time frame, many of > > > > > > > > > those > > > > > > > > will also > > > > > > > > > have WiFi support, others will have LTE or WiMAX > support > > > > > > > as hybrids. > > > > > > > > > > > > > > > > > > SUPL will be common-place. OMA may not be > > > > 'Open-Source', it > > > > > > > > > is open-minded, and there is movement afoot to expand > > > > > > > OMA/SUPL (as we > > > > > > > > > heard in the geopriv mtg. on Tuesday) w/respect > expected > > > > > > > proposals > > > > > > > > > such as LocSIP, etc. Over the fairly near-term, I > think > > > > > > > > there will be > > > > > > > > > fewer protocol, location representation, and privacy > > > > > > > > discontinuities - > > > > > > > > > things that too often get cited - yet are seldom well > > > > > > understood. > > > > > > > > > > > > > > > > > > Let's encourage continued IETF communication > > with OMA/SUPL > > > > > > > > - not block > > > > > > > > > its use altogether. This is a case where we need to be > > > > > > > > inclusive, not > > > > > > > > > exclusive. > > > > > > > > > > > > > > > > > > As to the mobile RV sample case, the solution is also > > > > > > > forseeable - > > > > > > > > > especially given that the location of the 3G aircard in > > > > > > > > > the > > > > > > > > router is > > > > > > > > > good enough for routing. The scenario given needs some > > > > > > > > integration, > > > > > > > > > but is doable. Given that the aircard acts as a > logical > > > > > > > > SET, with a > > > > > > > > > SUPL stack on board, and a GPS/AGPS chipset > > inside. This > > > > > > > > combination > > > > > > > > > *WILL* (I believe) interoperate with a number of end > > > > > > > > > client applications to initiate and complete a > > > > > > > > > location-routed, > > > > > > > 3261 style > > > > > > > > > SIP, emergency call through the core, and into > > an ESInet. > > > > > > > > > > > > > > > > > > -roger. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ecrit-bounces@ietf.org > > > > > > > > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > > > > > > > > Of Brian Rosen > > > > > > > > > > Sent: Thursday, November 20, 2008 8:23 AM > > > > > > > > > > To: 'Richard Barnes' > > > > > > > > > > Cc: Gabor.Bajko@nokia.com; hannes.tschofenig@nsn.com; > > > > > > > > > > marc.linsner@cisco.com; ecrit@ietf.org > > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > It's very hard to have L2 specific LCPs. The problem > > > > > > > is that the > > > > > > > > > > clients are generally not very L2 aware. It's the > > > clients > > > > > > > > > that have > > > > > > > > > > the problem. > > > > > > > > > > You can do things like interwork an L2 > > specific LCP to a > > > > > > > > > common LCP so > > > > > > > > > > that non L2 aware devices can work, but you have to > do > > > > > > > that, and > > > > > > > > > > usually, that's impractical. Use my example. > Suppose > > > > > > > > that the L2 > > > > > > > > > > used SUPL. It's possible for the PC Card that is > > > > > > > > > > plugged > > > > > > > > into the > > > > > > > > > > router could implement a SUPL client and a HELD > server > > > and > > > > > > > > > interwork > > > > > > > > > > SUPL in the GSM system to HELD on the Ethernet so the > > > > > > > > Ethernet VoIP > > > > > > > > > > phone could get location via HELD. Possible, but not > > > > > > practical. > > > > > > > > > > There are all sorts of these kinds of problems. > > > > That's why > > > > > > > > > > L2 specific LCPs don't work. > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > > > Sent: Thursday, November 20, 2008 11:11 AM > > > > > > > > > > To: Brian Rosen > > > > > > > > > > Cc: Gabor.Bajko@nokia.com; > > > > > > > > > > James.Winterbottom@andrew.com; ecrit@ietf.org; > > > > > > > > > > marc.linsner@cisco.com; > > > > > > > hannes.tschofenig@nsn.com > > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > > > > > > > > > > > > > > > > > > > The IETF can't (and shouldn't) try to make particular > > > > > > > > standards for > > > > > > > > > > every access technology that's out there. What we > can > > > say > > > > > > > > > is that the > > > > > > > > > > paradigm for those protocols should be the same as at > > > > > > > > > > the > > > > > > > > IP layer: > > > > > > > > > > Clients MUST implement all, networks MUST implement > at > > > > > > > least one. > > > > > > > > > > > > > > > > > > > > (This is a little different from the text I > > sent before, > > > > > > > > > and clearer, > > > > > > > > > > I > > > > > > > > > > think.) > > > > > > > > > > > > > > > > > > > > All I'm saying is that we shouldn't try to > > enumerate all > > > > > > > > > the possible > > > > > > > > > > protocols at lower layers, we should just state > > > > the general > > > > > > > > > rule. It > > > > > > > > > > seems to me that this achieves the same level of > > > > > > > > > interoperability at > > > > > > > > > > all layers. > > > > > > > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > If there are exactly two LCPs all UAs must > > > > implement, and > > > > > > > > > > any number > > > > > > > > > > > of optional ones, then every network has to > > implement > > > at > > > > > > > > > > least one of > > > > > > > > > > > those > > > > > > > > > > two > > > > > > > > > > > LCPs, and any number of optional ones. That means > > > > > > > > > > > that > > > > > > > > > > "any number of > > > > > > > > > > > optional ones" is useless for both parties. > > > > > > > > > > > If the network can limit UAs to ONLY those that > > > > implement > > > > > > > > > > one of the > > > > > > > > > > > optional protocols, then it works, but in > > practice, it > > > > > > > > is usually > > > > > > > > > > impossible > > > > > > > > > > > to do that. My example is the wired, Ethernet > > > connected > > > > > > > > > > phone in an > > > > > > > > > > > RV traveling down the road with wireless > > data card in > > > > > > > > > > > a > > > > > > > > > > router. These > > > > > > > > > > > EXIST, now. > > > > > > > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > > > > > Sent: Thursday, November 20, 2008 10:11 AM > > > > > > > > > > > To: Brian Rosen > > > > > > > > > > > Cc: Gabor.Bajko@nokia.com; > > > > James.Winterbottom@andrew.com; > > > > > > > > > > > ecrit@ietf.org; marc.linsner@cisco.com; > > > > > > > > hannes.tschofenig@nsn.com > > > > > > > > > > > Subject: Re: [Ecrit] Location Protocols in Phone > BCP > > > > > > > > > > > > > > > > > > > > > > I think we need to pull up a level. It's not > > > reasonable > > > > > > > > > > for an RFC to > > > > > > > > > > > try to list all of the location protocols > > out there, > > > > > > > > > > > if for > > > > > > > > > > no other > > > > > > > > > > > reason than that it will rapidly become obsolete. > > > > > > > > > > > Instead, > > > > > > > > > > we should > > > > > > > > > > > say something like the following: > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > > > > INT-12 Devices MUST support the DHCP > > location options > > > > > > > > > [RFC4776] and > > > > > > > > > > > [RFC3825] and HELD > > > > > > > > > > [I-D.ietf-geopriv-http-location-delivery]. Devices > > > > > > > > > > > SHOULD support all location protocols supported at > > > lower > > > > > > > > > layers by > > > > > > > > > > > their interfaces (e.g., LLDP-MED [LLDP-MED]). > > > > > > > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brian Rosen wrote: > > > > > > > > > > >> The problem with SUPL is that the majority of > > > > > > > > > > >> networks > > > > > > > > > where SUPL > > > > > > > > > > >> would > > > > > > > > > > be > > > > > > > > > > >> available have a proxy (E-CSCF) insert > > location. It > > > > > > > > also has an > > > > > > > > > > >> incompatible location representation, and an > > > > incompatible > > > > > > > > > > privacy model. > > > > > > > > > > >> That makes it very hard to interwork with any > > > > of the rest > > > > > > > > > > of the IETF > > > > > > > > > > > work. > > > > > > > > > > >> I will say this. For quite some time, the > > > > IETF has been > > > > > > > > > trying to > > > > > > > > > > > interest > > > > > > > > > > >> OMA into cooperation on location so that we have > > > > > > > > > > interoperability at > > > > > > > > > > >> the protocol, location representation and privacy > > > > > > > > > levels. So far, > > > > > > > > > > >> that has > > > > > > > > > > > not > > > > > > > > > > >> happened. If, as part of a comprehensive > > agreement > > > > > > > > > > >> to > > > > > > > > > accomplish > > > > > > > > > > >> such a goal, SUPL became one of the LCPs, I would > > > > > > not object. > > > > > > > > > > >> > > > > > > > > > > >> Brian > > > > > > > > > > >> > > > > > > > > > > >> -----Original Message----- > > > > > > > > > > >> From: ecrit-bounces@ietf.org > > > > > > > > [mailto:ecrit-bounces@ietf.org] On > > > > > > > > > > >> Behalf Of Gabor.Bajko@nokia.com > > > > > > > > > > >> Sent: Thursday, November 20, 2008 9:26 AM > > > > > > > > > > >> To: James.Winterbottom@andrew.com; ecrit@ietf.org > > > > > > > > > > >> Cc: hannes.tschofenig@nsn.com; > > marc.linsner@cisco.com > > > > > > > > > > >> Subject: Re: [Ecrit] Location Protocols in > > Phone BCP > > > > > > > > > > >> > > > > > > > > > > >> Hi, > > > > > > > > > > >> > > > > > > > > > > >> Is the intent to list the LCPs which are > > access-type > > > > > > > > > > agnostic but not > > > > > > > > > > >> supported anywhere, or instead have a list of > > > > LCPs which > > > > > > > > > > are highly > > > > > > > > > > >> probable to produce the intended result? > > > > > > > > > > >> > > > > > > > > > > >> There are restrictions everywhere, things come > > > > at a cost > > > > > > > > > > even in the > > > > > > > > > > >> general Internet model. The reality is that most > of > > > the > > > > > > > > > > devices with > > > > > > > > > > >> internet access have a home network already. > > > > > > > > > > >> > > > > > > > > > > >> - Gabor > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> >-----Original Message----- > > > > > > > > > > >> >From: ext Winterbottom, James > > > > > > > > > > [mailto:James.Winterbottom@andrew.com] > > > > > > > > > > >> >Sent: Thursday, November 20, 2008 12:06 AM > > > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > ecrit@ietf.org > > > > > > > > > > >> >Cc: marc.linsner@cisco.com; Tschofenig > > Hannes (NSN > > > > > > > > - FI/Espoo) > > > > > > > > > > >> >Subject: RE: [Ecrit] Location Protocols in > Phone > > > BCP > > > > > > > > > > >> > > > > > > > > > > > >> >Hi Gabor, > > > > > > > > > > >> > > > > > > > > > > > >> >The list of LCPs in the phone BCP is a must > > > > > > > > > > >> support > > > > > > > > > list, and is > > > > > > > > > > >> access- > > > > > > > > > > >> >type agnostic. > > > > > > > > > > >> >I am curious that you say that SUPL is a > > > > MUST support > > > > > > > > > > given that: > > > > > > > > > > >> >a) it requires a home network in order > > to operate > > > > > > > > > > >> >b) it simply doesn't work for DSL or Cable > > > > > > > > > > >> >c) it is questionable whether it is really > > > > deployable > > > > > > > > > for WiFi > > > > > > > > > > >> networks > > > > > > > > > > >> > > > > > > > > > > > >> >Can you perhaps describe how it fits into > > > > the general > > > > > > > > > > Internet model? > > > > > > > > > > >> > > > > > > > > > > > >> >Cheers > > > > > > > > > > >> >James > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> >-----Original Message----- > > > > > > > > > > >> >From: ecrit-bounces@ietf.org on behalf of > > > > > > > > > Gabor.Bajko@nokia.com > > > > > > > > > > >> >Sent: Thu 11/20/2008 12:48 AM > > > > > > > > > > >> >To: ecrit@ietf.org > > > > > > > > > > >> >Cc: marc.linsner@cisco.com; > > > > hannes.tschofenig@nsn.com > > > > > > > > > > >> >Subject: Re: [Ecrit] Location Protocols in > Phone > > > BCP > > > > > > > > > > >> > > > > > > > > > > > >> >I was requested to send my observations > > > > regarding this > > > > > > > > > > requirement: > > > > > > > > > > >> > > > > > > > > > > > >> > ED-21/INT-12 Devices MUST support all of: > DHCP > > > > > > > > > > location options > > > > > > > > > > >> > [RFC4776] and [RFC3825], HELD > > > > > > > > > > >> > [I-D.ietf-geopriv-http-location-delivery] > and > > > > > > > > > > LLDP-MED [LLDP-MED]. > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> >I believe we should come up with a list of > > > > LCPs which > > > > > > > > > > are likely > > > > > > > > > > >> to be > > > > > > > > > > >> >supported in devices in a not so distant > > > > future. Since > > > > > > > > > > I have no > > > > > > > > > > >> seen or > > > > > > > > > > >> >heard about LLDP support yet, at least that > > > > should be > > > > > > > > > replaced > > > > > > > > > > >> with what > > > > > > > > > > >> >is mostly used today (OMA SUPL) and the 802.11 > > > > > > > > > > mechanism, with the > > > > > > > > > > >> >condition that this MUST only be supported if > > > > > > > > > > >> there > > > > > > > > is a wifi > > > > > > > > > > >> interface > > > > > > > > > > >> >available on the device. > > > > > > > > > > >> > > > > > > > > > > > >> >- Gabor > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> >________________________________ > > > > > > > > > > >> > > > > > > > > > > > >> >From: ext Tschofenig, Hannes > > > > > > > > > > >> > > > > > > > > > > > >> >Sent: Tuesday, November 18, 2008 12:49 PM > > > > > > > > > > >> >To: Bajko Gabor (Nokia-CIC/MtView); > > > > > > marc.linsner@cisco.com > > > > > > > > > > >> >Subject: Location Protocols in Phone BCP > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> >Gabor, > > > > > > > > > > >> > > > > > > > > > > > >> >Could you please raise your question about > > > > > > > > > > >> location > > > > > > > > > > protocols in > > > > > > > > > > >> Phone > > > > > > > > > > >> >BCP mentioned at ESW5 in the ECRIT WG session > > > again? > > > > > > > > > > >> > > > > > > > > > > > >> >Ciao > > > > > > > > > > >> >Hannes > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > >>> --- > > > > > > > > > > >> -- > > > > > > > > > > >> >----------------------- > > > > > > > > > > >> >This message is for the designated recipient > > > > > > only and may > > > > > > > > > > >> >contain privileged, proprietary, or > > > > otherwise private > > > > > > > > > > information. > > > > > > > > > > >> >If you have received it in error, please notify > > > > > > the sender > > > > > > > > > > >> >immediately and delete the original. Any > > > > > > > > unauthorized use of > > > > > > > > > > >> >this email is prohibited. > > > > > > > > > > >> > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > >>> --- > > > > > > > > > > >> -- > > > > > > > > > > >> >----------------------- > > > > > > > > > > >> >[mf2] > > > > > > > > > > >> > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: The information > > contained in this > > > > > > > > message may > > > > > > > > > be privileged and/or confidential. If you are not > > > > the intended > > > > > > > > > recipient, or responsible for delivering this message > to > > > > > > > > the intended > > > > > > > > > recipient, any review, forwarding, dissemination, > > > > > > distribution or > > > > > > > > > copying of this communication or any attachment(s) > > > > is strictly > > > > > > > > > prohibited. If you have received this message in error, > > > > > > > > please notify > > > > > > > > > the sender immediately, and delete it and all > > attachments > > > > > > > from your > > > > > > > > > computer and network. > > > > > > > > > _______________________________________________ > > > > > > > > > Ecrit mailing list > > > > > > > > > Ecrit@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > ***** > > > > > > > > > > > > > > > > > > The information transmitted is intended only for the > > > > > > > > > person > > > > > > > > or entity > > > > > > > > > to which it is addressed and may contain confidential, > > > > > > > proprietary, > > > > > > > > > and/or privileged material. Any review, retransmission, > > > > > > > > dissemination > > > > > > > > > or other use of, or taking of any action in > > > > reliance upon this > > > > > > > > > information by persons or entities other than > > the intended > > > > > > > > recipient > > > > > > > > > is prohibited. If you received this in error, please > > > > > > contact the > > > > > > > > > sender and delete the material from all computers. > GA621 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > -------------------------------------------------------------- > > > > -------------- > > > > -------------------- > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > -------------------------------------------------------------- > > > > -------------- > > > > -------------------- > > > > [mf2] > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 11:57:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1B83A6939; Fri, 21 Nov 2008 11:57:49 -0800 (PST) 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 40D7F3A6939 for ; Fri, 21 Nov 2008 11:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.716 X-Spam-Level: X-Spam-Status: No, score=-104.716 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, 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 PjAomDRA-3Bb for ; Fri, 21 Nov 2008 11:57:48 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6A4323A6977 for ; Fri, 21 Nov 2008 11:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1227297467; x=1258833467; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<49260CD7.4020005@bbn.co m>|References:=20<49260CD7.4020005@bbn.com>|Date:=20Fri, =2021=20Nov=202008=2013:57:09=20-0600|To:=20Richard=20Bar nes=20,=20ECRIT=20|From: =20Ted=20Hardie=20|Subject:=20Re:=20 [Ecrit]=20Emergency=20calling=20without=20endpoint/VSP=20 location=0D=0A=20support|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5441"=3B=20a=3D"13374072"; bh=hhfJS4GHWiM0u/K9rrepDegpb/pnpZ5GWypx8dUPWD8=; b=A4wDLb5j/+0x5Er/KP+L/+zkKhqFdu/uo44hAYS/tXvS4uB0/MvUen0Q 0+gTvEAUly3vwARRl20+37zReeSX6lHzooK/vq8IencbU3hK0zzMTYX14 hZeoMVZE39aZ7r1XSGUaIykEcTgpPZZ/t2E49WctnAVHEeWTtvDTtsHFP M=; X-IronPort-AV: E=McAfee;i="5300,2777,5441"; a="13374072" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2008 11:57:17 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mALJvGmq014527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Nov 2008 11:57:16 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mALJvBoD009935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Nov 2008 11:57:16 -0800 (PST) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 21 Nov 2008 11:57:11 -0800 Received: from [130.129.78.55] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 21 Nov 2008 11:57:11 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <49260CD7.4020005@bbn.com> References: <49260CD7.4020005@bbn.com> Date: Fri, 21 Nov 2008 13:57:09 -0600 To: Richard Barnes , ECRIT From: Ted Hardie Subject: Re: [Ecrit] Emergency calling without endpoint/VSP location support 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 5:20 PM -0800 11/20/08, Richard Barnes wrote: > >The solution above is *obviously* a hack, because step 2 involves a lot >of uncertainty on any reasonable scale. However, the problem it >addresses is real, especially in the short term: How should a VSP route >a call if endpoints don't support location? (Likewise, how should a >PSAP get location if VSPs and endpoints don't support location?) > >In order to address this problem, some sort of IP-to-location mapping >will be required. Is there a reason this requires an IETF standard, though? There are existing solutions for this, many of the commercial. Without standardized access to the *data* mapping IP to Location, a protocol developed here looks to be a complete no-op, as it runs parallel to the providers' own access protocol into the proprietary database. Is there anyone suggesting that the folks actually doing this work want to have access to multiple data sources in some standardized way? Maybe more to the point, is there anybody claiming that the people who develop databases in this arena are willing to support this? I know I was pretty blunt at the mic about this, and I don't want to appear rude. But I really don't see the need for this to be an ECRIT/IETF effort, even if these interim systems are being deployed. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 12:28:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666803A6933; Fri, 21 Nov 2008 12:28:59 -0800 (PST) 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 CDF3F3A6814 for ; Fri, 21 Nov 2008 12:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.28 X-Spam-Level: X-Spam-Status: No, score=-5.28 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 1uOfNUj5BAow for ; Fri, 21 Nov 2008 12:28:57 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CCFCC3A67A7 for ; Fri, 21 Nov 2008 12:28:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,645,1220227200"; d="scan'208";a="28693865" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2008 20:28:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mALKSsF5012874 for ; Fri, 21 Nov 2008 15:28:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mALKSsVN012045 for ; Fri, 21 Nov 2008 20:28:54 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 15:28:54 -0500 Received: from [10.116.195.117] ([10.116.195.117]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 15:27:59 -0500 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 21 Nov 2008 15:27:58 -0500 From: Marc Linsner To: ECRIT Message-ID: Thread-Topic: [Ecrit] Emergency calling without endpoint/VSP location support Thread-Index: AclMF6Q6bxOEcn8ptU6PavmPCZNtkg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 21 Nov 2008 20:27:59.0585 (UTC) FILETIME=[A52BF510:01C94C17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1845; t=1227299334; x=1228163334; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Emergency=20calling=20without =20endpoint/VSP=20location=20support |Sender:=20 |To:=20ECRIT=20; bh=+mBpRtCn5nUigZeWuf43YqQCUxrrJW3gSkFC/U90Rd8=; b=wpyfJcByBVFfDslI0PE0GVhh+CQDLW/nXKbtKj9RMBngi2ier0z20W5qs9 B2nuWkjBsdFkzr4AhHNB8elAm8aa38f1x7qVaRNY6b/gDgyfPgKf23tJWaI8 pbT7ZoqOrW; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Ecrit] Emergency calling without endpoint/VSP location support 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree with Ted on this, why is this an IETF/ECRIT problem? The IETF has offered a solution, the sooner it's deployed the faster this problem goes away. Let's concentrate on phonebcp, framework, and location conveyance. -Marc- On 11/21/08 2:57 PM, "Ted Hardie" wrote: > At 5:20 PM -0800 11/20/08, Richard Barnes wrote: >> >> The solution above is *obviously* a hack, because step 2 involves a lot >> of uncertainty on any reasonable scale. However, the problem it >> addresses is real, especially in the short term: How should a VSP route >> a call if endpoints don't support location? (Likewise, how should a >> PSAP get location if VSPs and endpoints don't support location?) >> >> In order to address this problem, some sort of IP-to-location mapping >> will be required. > > Is there a reason this requires an IETF standard, though? There are > existing solutions for this, many of the commercial. Without standardized > access > to the *data* mapping IP to Location, a protocol developed here looks > to be a complete no-op, as it runs parallel to the providers' own > access protocol into the proprietary database. > > Is there anyone suggesting that the folks actually doing this work > want to have access to multiple data sources in some standardized > way? Maybe more to the point, is there anybody claiming that the > people who develop databases in this arena are willing to support this? > > I know I was pretty blunt at the mic about this, and I don't want to > appear rude. But I really don't see the need for this to be an ECRIT/IETF > effort, even if these interim systems are being deployed. > regards, > Ted > _______________________________________________ > 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 ecrit-bounces@ietf.org Fri Nov 21 12:51:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE483A6933; Fri, 21 Nov 2008 12:51:47 -0800 (PST) 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 122BE3A6982 for ; Fri, 21 Nov 2008 12:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 4aWuWM4b9rr1 for ; Fri, 21 Nov 2008 12:51:45 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 289503A6933 for ; Fri, 21 Nov 2008 12:51:45 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mALKpTPA021052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Nov 2008 15:51:30 -0500 (EST) Message-Id: From: Henning Schulzrinne To: "Thomson, Martin" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 15:51:29 -0500 References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$@ne t> <8C837214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> X-Mailer: Apple Mail (2.929.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While I think this is generally true, there are reasonably-common exceptions. For example, on a cruise ship, the fire warden or EMT cares about the cabin the emergency is in, not the current longitude and latitude the cabin happens to be located at, which would be utterly useless. Same is probably true for other "closed" systems, such as large buildings or an underground mine. Even on a plane, the flight attendant finds you by seat number when you press that orange button, not by longitude and latitude, so it doesn't matter whether you can determine the latter. Henning On Nov 21, 2008, at 2:29 PM, Thomson, Martin wrote: > Hi Roger, > > To answer this question, you have to first answer the question: how > many reference frames exist? My answer is one. > > It helps to only have a single reference frame for this purpose. > That is, earth-centred, earth-fixed is the single reference frame we > use to determine movement. Anything moving in that reference frame > is moving. Establishing ad hoc reference frames increases the > complexity of any solution that we develop. > > In the plane example, you might use a complex of the geodetic > location of the plane with uncertainty, plus a civic address with > SEAT=34C. However, this would be considered to be moving at 3500m/s. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 21 13:10:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EDB3A68A4; Fri, 21 Nov 2008 13:10:27 -0800 (PST) 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 977A53A68A4 for ; Fri, 21 Nov 2008 13:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 zm8+vI50Yk1V for ; Fri, 21 Nov 2008 13:10:24 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 7FD8A3A6840 for ; Fri, 21 Nov 2008 13:10:24 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_11_21_15_28_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 21 Nov 2008 15:28:04 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 15:10:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 15:10:22 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Protocols in Phone BCP Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeA References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> From: "Thomson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 21 Nov 2008 21:10:23.0044 (UTC) FILETIME=[91310040:01C94C1D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Location Protocols in Phone BCP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Good point. In general, it might not even be necessary to assume a single reference frame. To the extent possible, we should try to avoid making unsafe assumptions either way. However, when it is unavoidable we need to be clear. >From the perspective of general advice to device manufacturers (the original topic), I believe that the only necessary advice is to note that location might change and the device MUST allow for that possibility. While urn:service:sos.fire on the cruise ship might not perceive movement; urn:service:sos.terrorist might [1]. Better avoid the assumptions on the device end altogether. The consumer of location information might define their own means of handling these special cases. Within such closed systems, conventions are possible. On the plane, the filter rules might ignore lat/long. Ta, Martin [1] Speed 2 was two hours of my life that I want back. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 21 November 2008 2:51 PM > To: Thomson, Martin > Cc: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] Location Protocols in Phone BCP > > While I think this is generally true, there are reasonably-common > exceptions. For example, on a cruise ship, the fire warden or EMT > cares about the cabin the emergency is in, not the current longitude > and latitude the cabin happens to be located at, which would be > utterly useless. Same is probably true for other "closed" systems, > such as large buildings or an underground mine. Even on a plane, the > flight attendant finds you by seat number when you press that orange > button, not by longitude and latitude, so it doesn't matter whether > you can determine the latter. > > Henning > > On Nov 21, 2008, at 2:29 PM, Thomson, Martin wrote: > > > Hi Roger, > > > > To answer this question, you have to first answer the question: how > > many reference frames exist? My answer is one. > > > > It helps to only have a single reference frame for this purpose. > > That is, earth-centred, earth-fixed is the single reference frame we > > use to determine movement. Anything moving in that reference frame > > is moving. Establishing ad hoc reference frames increases the > > complexity of any solution that we develop. > > > > In the plane example, you might use a complex of the geodetic > > location of the plane with uncertainty, plus a civic address with > > SEAT=34C. However, this would be considered to be moving at 3500m/s. > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 28 14:36:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A653A6994; Fri, 28 Nov 2008 14:36:54 -0800 (PST) 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 D8C8D3A6824 for ; Fri, 28 Nov 2008 14:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EXQlRKUcyxDq for ; Fri, 28 Nov 2008 14:36:52 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 104993A685C for ; Fri, 28 Nov 2008 14:36:52 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 28 Nov 2008 14:36:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Nov 2008 14:35:24 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750B5B6C89@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional text - location mech - wireless & mobility support Thread-Index: AclMGvVEfWp8KLJwSQWgXrQcHJA+0wAAaLeAAWLualA= References: <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE87B@esebe111.NOE.Nokia.com> <7A1F5E234FF3DC46A6E6D05D4F1FEE744EE999@esebe111.NOE.Nokia.com><00ff01c94b1d$a5d11e50$f1735af0$@net><49257DF1.2000205@bbn.com><011b01c94b24$d8d78a80$8a869f80$@net><49258C15.2070303@bbn.com><015401c94b2c$374c6ed0$a5e54c70$@net><8C837214C95C864C9F34F3635C2A65750B53380E@SEA-EXCHVS-2.telecomsys.com><7582BC68E4994F4ABF0BD4723975C3FA0BD4C5F6@crexc41p><01e701c94b4b$813eb290$83bc17b0$@net><8C837214C95C864C9F34F3635C2A65750B5338CB@SEA-EXCHVS-2.telecomsys.com><020601c94b4f$101d8740$305895c0$@net><8C837214C95C864C9F34F3635C2A65750B533975@SEA-EXCHVS-2.telecomsys.com><5D1A7985295922448D5550C94DE2918002513278@DEEXC1U01.de.lucent.com> <8C837214C95C864C9F34F3635C2A65750B533C20@SEA-EXCHVS-2.telecomsys.com> <03cd01c94bf9$8d599cd0$a80! c d670$ @ne t> <8C83 7214C95C864C9F34F3635C2A65750B533DE5@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "Rosen, Brian" Cc: ecrit@ietf.org Subject: [Ecrit] Additional text - location mech - wireless & mobility support 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian: Below is a proposed change in text to the current phonebcp-06 that adds some background for various requirements later in the draft that specify "wireless" and "mobile", per remarks made in the 11/20 ECRIT wg meeting. 1. Section 6. Location and its role in emergency calls change from: In Internet emergency calling, where the endpoint is located is "determined" using a variety of measurement or wiretracing methods. Endpoints may be "configured" with their own location by the access network. change to: In Internet emergency calling, the endpoint location is "determined" using a variety of measurement or wiretracing methods. Requirements for endpoint location determination vary, depending on whether an endpoint's resulting location is based on internal (device-based) or external (network-based) measurements, or by manual provisioning - for mobile capable, or fixed environment endpoints, respectively. Once location has been determined, endpoints may then be "configured" with their own location by the access network via some Location Configuration Protocol (LCP). -roger marshall. CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit