From ietf-ipr@ietf.org Thu Sep 5 07:58:46 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D5D21E810A; Thu, 5 Sep 2013 07:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UzHbSR7Ymgk; Thu, 5 Sep 2013 07:58:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65011E80EC; Thu, 5 Sep 2013 07:58:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: Hannes.Tschofenig@gmx.net,hgs@cs.columbia.edu,Bernard_Aboba@hotmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130905145845.25275.39796.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 07:58:45 -0700 Cc: marc.linsner@cisco.com, ecrit@ietf.org, ipr-announce@ietf.org Subject: [Ecrit] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-ecrit-trustworthy-location-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 14:58:46 -0000 Dear Hannes Tschofenig, Henning Schulzrinne, Dr. Bernard D. Aboba Ph.D.: An IPR disclosure that pertains to your Internet-Draft entitled "Trustwort= hy Location" (draft-ietf-ecrit-trustworthy-location) was submitted to the IETF Secretariat on 2013-09-04 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2181/). The = title of the IPR disclosure is "Qualcomm Incorporated's Statement about IPR relat= ed to draft-ietf-ecrit-trustworthy-location-07.""); The IETF Secretariat From ivo.sedlacek@ericsson.com Wed Sep 11 04:49:19 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15AA11E8197 for ; Wed, 11 Sep 2013 04:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrZPg5Cv81i1 for ; Wed, 11 Sep 2013 04:49:14 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4786721E80B8 for ; Wed, 11 Sep 2013 04:49:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-2e-523058b744a8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A2.24.22048.7B850325; Wed, 11 Sep 2013 13:49:11 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Wed, 11 Sep 2013 13:49:11 +0200 From: Ivo Sedlacek To: Brian Rosen Thread-Topic: issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05) Thread-Index: AQHOg7VmdEODvcAym0aNkVJ0+Et/Y5nAwWfQ Date: Wed, 11 Sep 2013 11:49:10 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610113A826@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010F7E49@ESESSMB301.ericsson.se> <670140B0-DC31-4922-82EF-45CAF73772F8@brianrosen.net> In-Reply-To: <670140B0-DC31-4922-82EF-45CAF73772F8@brianrosen.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje72CIMgg63TLS2e3p/GZtG46Cmr A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxdNJhloLHlRXLdrazNzCuT+xi5OSQEDCR 6N7/jAXCFpO4cG89WxcjF4eQwGFGibVzPkE5Sxgljky8yQRSxSagJzFxyxFWEFtEQFli561O dhCbWUBV4lzjYxaQBmGBxYwSzc8esYM4IiDdn9veMkN0GEl0fuoC62YB6ug/9BtsN6+At8Tf 2bMYIdY1M0rsf3GTESTBKeAksfHPBzYQm1FAVuLqn15GiHXiEreezGeCOFxAYsme88wQtqjE y8f/WCFsRYmPr/ZB1etJPDs1iwXC1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKA kWUVI3tuYmZOern5JkZgrBzc8ttgB+Om+2KHGKU5WJTEeTfrnQkUEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwGgp3GCrOJNFw32NK4vrfKljd25x+JiuvqG0e7PeQ3smqbBHfKZ1Hk9/Zu3n 4BS25OGTKY8xvXnnR9XlWbPMpRuO/N7pIPF3wSdfN7f5xv35NS8vrPolyuemwvLyvVj2q+Vz pC+8bXBvX6zTcDXun/PG3Su33+JZeS8lgUEiLp3HL2+unT37GyWW4oxEQy3mouJEACGaB+Bj AgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: Question to draft-ietf-ecrit-data-only-ea-05) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 11:49:19 -0000 Hello Brian, you stated below that you were going to note the limitations in ISSUE 1 and= ISSUE 2 in the next edition of the draft. Has this already been done? Thanks for clarification. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 18. =E8ervence 2013 14:51 To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecr= it-addldata-subnot-00 (was RE: [Ecrit] Question to draft-ietf-ecrit-data-on= ly-ea-05) Hi Ivo I will note this limitations in the next edition of the draft. The working group can decide if they think they are more important than I t= hink they are. I will raise the issue when I discuss the draft in Berlin. Brian On Jul 18, 2013, at 3:12 AM, Ivo Sedlacek wrote= : > Hello Brian, >=20 > my conclusions of the discussion: >=20 > ISSUE 1: > -------------------------- > if the UA and the PSAP wish to provide updates, the solution in the draft= s requires UA to provide a URI which PSAP uses to send out-of-dialog SUBSC= RIBE request to the UA. This URI needs to be a globally routable URI.=20 > Since UAs are normally behind SBG/firewall and do not have globally routa= ble URI, this requires UA to be registered to get a globally routable URI.= =20 > If the UA does not have valid credentials, the registration will fail. >=20 > In contrast, INFO based solution would not suffer from this problem as ev= erything is sent within dialog of emergency call. > --------------------------=09 >=20 > PROPOSAL 1: > -------------------------- > Record in the drafts that if the UA and the PSAP wish to provide updates,= when the UA does not have a globally routable URI (e.g. due to not having = valid credentials which would enable registration providing GRUU to the UA)= , then solution in the drafts does not work. > -------------------------- >=20 >=20 > ISSUE 2: > -------------------------- > The drafts do not solve how the UA is able to detect whether the subscrib= er is an authorized entity or man-in-the-middle intercepting the MESSAGE or= the previous SUBSCRIBE. Roaming UAs (e.g. in cars) are not aware of identi= ties of PSAPs or responders in visited country. >=20 > In contrast, INFO based solution would not suffer from this problem as ev= erything is sent within dialog of emergency call. > --------------------------=09 >=20 > PROPOSAL 2: > -------------------------- > Record this security issue in the drafts. > -------------------------- >=20 >=20 > On: >=20 >> What I'm proposing doesn't require trust between networks, it requires t= rust between the device that sent the alert and the PSAP or responders that= get it.=20 >=20 > The UA, particularly UA roaming to a different country (common for UAs in= cars), does not know the PSAP or responder identity. >=20 >> And will INFO pass through IMS networks? Or will it be blocked by those = SBCs? >=20 > INFO is an in-dialog request. Moreover, it would be sent within an emerge= ncy call. It would be passed. >=20 >> SUBSCRIBE is like any other SIP transaction. If you want to send them a= ll the way through the same path, you can. =20 >> I think that is more fragile, but you can do it. =20 >> The PSAP sends the SUBSCRIBE to the visited network that sent it the ale= rt, which sends it to any transit networks enroute to the home network that= originated the alert. >=20 > The visited network does not provide globally routable URI to the UA. It = is the registrar in the home network which provides GRUU during registratio= n. >=20 > So, the SUBSCRIBE from PSAP will traverse: PSAP (African country) - netwo= rk serving PSAP (African country) - transit network (any country) - home op= erator (US) - visited network (African country) - UA.=20 >=20 > In comparison, emergency requests sent by UA or exchanged in the=20 > emergency dialogs initiated by UA will traverse: UA - visited network=20 > (African country) - PSAP (African country) >=20 > In the latter case, it is much easier to ensure trust for the "this-is-se= nt-by-PSAP" information or resource priority as one regulatory body governs= the whole signalling path.=20 >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on=20 > the basis of the terms set out at www.ericsson.com/email_disclaimer >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 17. =E8ervence 2013 20:21 > To: Ivo Sedlacek > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 >=20 > Hi Ivo >=20 > See inline. >=20 > On Jul 17, 2013, at 11:13 AM, Ivo Sedlacek wr= ote: >=20 >> please see below. Kind regards Ivo Sedlacek >>=20 >> This Communication is Confidential. We only send and receive email on=20 >> the basis of the terms set out at www.ericsson.com/email_disclaimer >>=20 >>>>>> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subs= criber and the UA is the notifier, this would require reachability of UA fo= r initial request for dialog (i.e. SUBSCRIBE). However, when the UA is not = registered e.g. due to missing credentials, the UA is normally not reachabl= e for SIP requests other than those sent within the dialog of the emergency= call. >>>>>=20 >>>>> I think the combination of missing credentials, and data updates is s= o unlikely that the problem of PSAP control of updates dwarfs it. >>=20 >> The issue above was related to UA not being reachable for incoming reque= sts due to __UA__ not having its credentials.=20 >>=20 >> Networks (like 3GPP IMS) enable UA without valid credentials to only sen= d emergency requests and requests sent within dialogs created by emergency = request.=20 >> To receive requests sent outside of dialog created by emergency requests= , the UA needs to be registered. >> To be registered, the UA needs to have valid credentials. > I misunderstood >>=20 >> Note that some countries require UAs to be able to make voice emergency = call even if the UA does not valid credentials.=20 > Yeah, but none of them require devices to be able to send data updates if= they are not registered. >=20 >>=20 >> Why should that be not be required as well for data only emergency reque= sts? > Personal opinion - because it's a DDoS attack opening towards a PSAP. I = would prohibit it. All the PSAPs I am in discussion with are afraid of suc= h problems. As an example, in the U.S., in most cases, alarm systems are= not permitted to connect directly to a PSAP - they must connect through a = "Central Alarm Monitoring" service. We hope to change that, but only if we= can guarantee that the PSAP is protected, and they believe they are protec= ted. >=20 >>=20 >>> Because PSAPs will have credentials, and most sensor based devices wher= e it's the device making the call don't update fast enough to be interestin= g. I also think in most cases, devices will publish to a server, and the s= erver will send the alert. >>=20 >> The above describes some particular architecture where SIP and non SIP s= ignalling is mixed, or perhaps server acts as SIP B2BUA, not sure. Which en= tity is the SIP UA - the "server" or the "device" or both? > The above assumes the device is registered to a service that aids it. Mo= st devices that have this kind of capability do that, but not all. > If there is a service, the service has a server, the UA publishes updates= to the server, the PSAP subscribes to the server. >=20 > If there is no service, the device UA is the server, and the PSAP subscri= bes to it. >=20 >>=20 >> Why would the UA not be able to provide updates fast enough? Even if the= UAs are not able to do it today, why shouldn't they be able to do it in fu= ture? > Not a matter of able to, it's just that the data on such devices doesn't = change enough over the course of a call to be interesting. Once a car cras= hes, it has crash data, but it doesn't change. If a fire starts, the fire = could go out on it's own, but usually the fire brigade goes out anyway - up= dates aren't interesting. >=20 > Same with burglar alarms. >=20 > It's only a device like a heart monitor that would have updates that woul= d be interesting, but in my experience, such devices have services that int= erpret the raw data from the sensor into more useful data for responders. >=20 >=20 >>=20 >>>> If PSAP accepts unauthenticated one short emergency requests, the PSAP= will likely be interested in any data updates which the UA is able to prov= ide. E.g. fire detection sensor could provide updates of the temperature in= the building. >>> Poor example. The way we intend to determine temperatures in a buildin= g is the "additional location data" mechanism, which would probably (no det= ails have been worked out yet) have a portal access to the building control= system. >>=20 >> Abstract of draft-ietf-ecrit-data-only-ea-06 states:=20 >>=20 >> Examples of such environments include a __temperature sensors=20 >> issuing alerts__, or vehicles sending crash data. > I can change the example. Issuing the alert is one thing, monitoring the= HVAC system is another. >=20 >>=20 >> Is the Abstract is wrong? > It's just that a typical building has a wide variety of sensors and actua= tors that are of interest to a responder. A good example is the state of t= he water system or the air handing equipment, the elevators and the door se= nsors. None of those are the ones that trigger the alert. We're thinking = about a portal to the building monitoring system that let's a responder con= nect to the portal and get all the data, and maybe even control aspects of = it, if building management lets them. >=20 > You also typically have more than one call about an incident, and you nee= d the same data whether you got a data-only alert or a telephone call. >=20 >>=20 >>> The usual case where it is a device that has updates is that it uses th= e credentials of the PSAP to allow subscription. Since the URL is somethin= g it supplies, it can include a token, good for a small window around the M= ESSAGE it sends. =20 >>=20 >> The UA normally do not know the identity of the PSAP and cannot authenti= cate PSAP. This was discussed quite a lot in draft-ietf-ecrit-psap-callback= . The result is that just indication is provided and UA needs to rely on ne= twork to assert it.=20 >>=20 >>> We want to ALLOW direct from the device messages, and we have a way to = do that. A way the PSAP controls, which I think is important. >>=20 >> I understand the PSAP control is wished. This could be provided in INFO = package mechanism as well. >>=20 >>> If the UA doesn't intend to provide updates, it doesn't offer a SUBSCRI= BE URI. If one is offered, and the PSAP wants updates, it will subscribe. >>=20 >> The point is that UA may be able and may want to allow PSAP to request t= he updates in every single request.=20 >> Similarly, PSAP may want to decide that it wants the updates for every s= ingle request.=20 >> If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is subop= timal. > First of all, I think this is an uncommon case. The common cases I know = about have a service and it's not the device that the emergency authorities= connect to. >=20 > Second of all, the MESSAGE goes to the PSAP, which usually only cares abo= ut dispatching a responder. It is the responder who cares about the data a= fter that. Updates nearly always are of interest to responders and not PSA= Ps. By sending a URI, we allow the responder to subscribe, not just the PS= AP. If we create a session, it's with the PSAP, not the responder. We wou= ld have to transfer the session to the responder. >=20 >>=20 >>> For one thing devices that do this tend to move. MESSAGE does not crea= te a session. Sending updates requires a session where the routing wouldn'= t change within the session. You can't send individual MESSAGE transaction= s, because each one may route differently. That means we would need for th= e initial alert to be in an INVITE, create a session with no media, then se= nd INFOs. Not a whole lot different. >>=20 >> Updates sent using subscription will require dialog as well so there is = really no difference related to UE movement. > Agree, no difference. But we have a mechanism much better suited to asyn= chronous notification in SUB/NOT vs INVITE/INFO. >=20 >>=20 >> IMO, the solution using INVITE (containing the 1st shot) followed by INF= Os would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY solutio= n): >> 1) would enable updates sent by UA without credentials >> 2) would not need to rely on trust between networks to preserve informat= ion that SUBSCRIBE is sent by PSAP. > As above, I don't think allowing devices without credentials to send aler= ts is a good idea at all. I would prohibit it. > What I'm proposing doesn't require trust between networks, it requires tr= ust between the device that sent the alert and the PSAP or responders that = get it. MITM is an issue if the signaling is observable however. >=20 >>=20 >>=20 >>>> Thus the risk of missing trust between the networks is high - e.g. whe= n UA with US subscription is an african country, sends emergency request to= african PSAP, will the US home network of the UA trust the african network= claiming that SUBSCRIBE comes from PSAP? >>> No network is involved. The question you are asking is will a US devic= e visiting Africa trust an African PSAP. When the MESSAGE is sent the URI = for the subscribe is that of the device, not the home or visited network of= the device. >>=20 >> 1) In normal SIP environment (like 3GPP IMS), PSAP will need to involve = some network to reach UA. If UA includes IP address and port in the URI inc= luded in the MESSAGE, and PSAP sends SUBSCRIBE directly to that IP address = and port, the SUBSCRIBE will likely be blocked by a firewall/SBC. > And will INFO pass through IMS networks? Or will it be blocked by those S= BCs? >=20 >>=20 >> 2) US device trusts that the emergency message/call is delivered to afri= can PSAP since the UA set the Request-URI to the emergency URN. But when SU= BSCRIBE is received, how does the UA know that that SUBSCRIBE was really se= nt by PSAP and not by malicious UE? Normally, the UA trusts its home networ= k to assert this, and its home network trusts the transit networks, and the= transit networks checks that message comes from PSAP. So, there is chain o= f trust which is however difficult to achive if several countries are invol= ved. > SUBSCRIBE is like any other SIP transaction. If you want to send them al= l the way through the same path, you can. I think that is more fragile, bu= t you can do it. The PSAP sends the SUBSCRIBE to the visited network that = sent it the alert, which sends it to any transit networks enroute to the ho= me network that originated the alert. >=20 >>=20 >>> So you propose to recreate RFC6446 and 6447 in an INFO package? >>=20 >> Not sure if all of that is needed, but possibly.=20 > It would be necessary I think. >=20 >=20 From rlb@ipv.sx Thu Sep 12 20:39:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3421E804D for ; Thu, 12 Sep 2013 20:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKdnsbiEOhGY for ; Thu, 12 Sep 2013 20:39:41 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F311E80E0 for ; Thu, 12 Sep 2013 20:39:41 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id f4so698415oah.11 for ; Thu, 12 Sep 2013 20:39:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4CUPXyc0rNnxAgbSjlkfZPmdsCsOZlkg96wbqFh2+PE=; b=AmzcvUSMa7dFDB7RsaMt6ELa3s5EZAx+OT7WpxePRNy5iEliMJvZ7oLB7gYD3vTUv9 irE9DPUAz8WTjdEr4kbVXPtWHx2PaCMTaGvPGGUjlhwHl/MsEWW5Fu4feIW3ni9nk8op t8wunQqf5h64wtqlcBJroBwQVJw3Rk639LRYS5zrhHdWu9I9nhXMCd8vcnvui6rg1bM/ lIC2B9yHV29Mb3N7+KcAbsQ1EWunVmY+35L/SIdItRncBI8ZFUGmGXV2xz5PuZfxk/vt bQ5mZHoclhBXgXqfA6ZgGwizBnaVjL24t0fQ+HaBWBJaYiM7qN+amqJMP4n5VvrVo7d2 GEAw== X-Gm-Message-State: ALoCoQllxlszzYYKw4PSPVBE0LJwvdwwWatYfXOMaJyU7GbVwmBpBqOwquZ5nb0Mj1tF8KF2n9II MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr10058432oer.8.1379043580638; Thu, 12 Sep 2013 20:39:40 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Thu, 12 Sep 2013 20:39:40 -0700 (PDT) Date: Thu, 12 Sep 2013 23:39:40 -0400 Message-ID: From: Richard Barnes To: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary=089e0149d0aec10ce904e63b9a26 Subject: [Ecrit] AD review: draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 03:39:47 -0000 --089e0149d0aec10ce904e63b9a26 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document, and think it looks good. I have requested an IETF LC. Thanks to the authors and WG, --Richard --089e0149d0aec10ce904e63b9a26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document, and think it looks good. = =A0I have requested an IETF LC.

Thanks to the authors an= d WG,
--Richard
--089e0149d0aec10ce904e63b9a26-- From rlb@ipv.sx Thu Sep 12 20:53:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D7421E80A5 for ; Thu, 12 Sep 2013 20:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oESkzHeyGkU0 for ; Thu, 12 Sep 2013 20:53:18 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id E286621F9E43 for ; Thu, 12 Sep 2013 20:53:17 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j10so690349oah.41 for ; Thu, 12 Sep 2013 20:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=or9W79oPr+nIki0QroAp16GbQIhE/H6UIs/6ljf5WWE=; b=EBBZIHoE8sPcsigf49Boi88+2mP97r1W1oEaDovqxOFm/Jwb52qyr780tv1gr1RBeU Y883uUanQwEFlXDYHj+WX/Bdig1hnUUgZ0RbAniDQ3XjMh65VrzLTx2I+tkYA7WDGFrO o2HRx+aVmtMfImt8yHgqN+kk6E0xIEYyhEtWhkugdnTnWO7fEiIsuWJFXu2jUtqhhRO4 BdKnziRUWm11+f2ZCt6R0Zo6lpVyOeD/fVdjopX4j3LsUy8oM0x4n2zseI1giMJjfqaM AxtCDjgCFb+mDDTYi+BoMzZIVQLJGCOx8+PzOPwzX9WuOAFuGOys+9aps30f5odBkE3x nirw== X-Gm-Message-State: ALoCoQnfS7B2zYETpfo/CW9eUbpyTrZ35iyTH6Fdm/sKInJXwcXX/n6s3KP+F9Wa55C0Nd81Lln6 MIME-Version: 1.0 X-Received: by 10.182.242.37 with SMTP id wn5mr10129478obc.56.1379044397397; Thu, 12 Sep 2013 20:53:17 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Thu, 12 Sep 2013 20:53:17 -0700 (PDT) Date: Thu, 12 Sep 2013 23:53:17 -0400 Message-ID: From: Richard Barnes To: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff1cd666fcfda04e63bcbe3 Subject: [Ecrit] AD review: draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 03:53:23 -0000 --e89a8ff1cd666fcfda04e63bcbe3 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document and requested an IETF LC. I have a few minor comments, which can be handled along with the IETF LC comments. -- In the Abstract and Introduction: It might be helpful to mention the precedent in the PSTN for context. The analogy to SIMless or zero-balance emergency calls could help people understand the feature that this document is trying to enable. -- In Section 5: Since these steps are performed in sequence, they should be numbers. Also, it would be helpful if you could highlight which of these steps might be different from the normal PhoneBCP behavior -- namely, steps 4 (UA does LoST instead of VSP) and 5 (INVITE to ESRP instead of VSP). -- In a few places, the phrase "mandated" is used. Should this be "REQUIRED"? -- In Section 5.3.3., it seems like it would be helpful to emphasize that if a PSAP wants to support NASP calls, then it MUST NOT restrict incoming calls to a particular set of ASPs. This seems kind of obvious, but I expect it will be tempting for PSAPs to impose those sorts of limitations, so it's important to remind them that it breaks this use case. -- In Section 6: s/radio networks/networks/. A note at the top to set context would be helpful, noting that the NAA case is inherently a layer 2 problem, and the general form of the solution is to provide an "emergency only" access type, with appropriate limits/monitoring to prevent abuse. It would be helpful to have references where specific link-layer technologies are referenced. Thanks, --Richard --e89a8ff1cd666fcfda04e63bcbe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document and requested an IETF LC. = =A0I have a few minor comments, which can be handled along with the IETF LC= comments.

-- In the Abstract and Introduction: It might= be helpful to mention the precedent in the PSTN for context. =A0The analog= y to SIMless or zero-balance emergency calls could help people understand t= he feature that this document is trying to enable.

-- In Section 5: Since these steps are performed in seq= uence, they should be numbers. =A0Also, it would be helpful if you could hi= ghlight which of these steps might be different from the normal PhoneBCP be= havior -- namely, steps 4 (UA does LoST instead of VSP) and 5 (INVITE to ES= RP instead of VSP).

-- In a few places, the phrase "mandated" is = used. =A0Should this be "REQUIRED"?

-- I= n Section 5.3.3., it seems like it would be helpful to emphasize that if a = PSAP wants to support NASP calls, then it MUST NOT restrict incoming calls = to a particular set of ASPs. =A0This seems kind of obvious, but I expect it= will be tempting for PSAPs to impose those sorts of limitations, so it'= ;s important to remind them that it breaks this use case.

-- In Section 6: s/radio networks/networks/. =A0A note = at the top to set context would be helpful, noting that the NAA case is inh= erently a layer 2 problem, and the general form of the solution is to provi= de an "emergency only" access type, with appropriate limits/monit= oring to prevent abuse. =A0It would be helpful to have references where spe= cific link-layer technologies are referenced.


Thanks,
--Richard=A0
--e89a8ff1cd666fcfda04e63bcbe3-- From hannes.tschofenig@gmx.net Fri Sep 13 00:52:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BF911E8179 for ; Fri, 13 Sep 2013 00:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C02fRgEvfQ35 for ; Fri, 13 Sep 2013 00:52:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8611E815C for ; Fri, 13 Sep 2013 00:52:21 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MRkhB-1VVdev1SSv-00SxNK for ; Fri, 13 Sep 2013 09:52:20 +0200 Message-ID: <5232C42A.7090806@gmx.net> Date: Fri, 13 Sep 2013 10:52:10 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Richard Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:euify1kC+0cCDIQ1xpjNOeBf4p++bkzwHmvpy3miz6znnc7hzCs fldEZrPUsh7IxHaZYhePJb22FUIiiAaF0bo2zAaVxXg+cTsbCiLKcw1EdByU8pL3PhKOsac PadGe+ohQQE4frEeXzbRo/VAHeFpzAwLlHOAVURxf0YjvpFyaVVbvTlpy/Ts8Ft5vcEjzE9 RTSXmLAb4WpbaEDSfdnHw== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-psap-callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:52:32 -0000 Thanks, Richard! On 13.09.2013 06:39, Richard Barnes wrote: > I have reviewed this document, and think it looks good. I have > requested an IETF LC. > > Thanks to the authors and WG, > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Fri Sep 13 01:03:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC95911E8179 for ; Fri, 13 Sep 2013 01:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpVdWTYoPVl7 for ; Fri, 13 Sep 2013 01:03:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1D11E812C for ; Fri, 13 Sep 2013 01:03:49 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1VOm372tuK-00UrBD for ; Fri, 13 Sep 2013 10:03:46 +0200 Message-ID: <5232C6D7.9060509@gmx.net> Date: Fri, 13 Sep 2013 11:03:35 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Richard Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ImfIg3AzmEp0Ku/r+WKUuR55ZzP6xwkz1JFNLwedm9kpzHUiYG/ aWZELfMPpeqmVG9weC6m3XujZeBwnRxQnakwX/cBiqOUuvELBs6FpWg8ZPWbUfpskMOBJJX g3jWYrt7j9XLb4kKGd3CeURofVJ9aMnILSs8nN7GlHrSzgJbqfriv9g0GoI+TmTu0eC8Uni TmADufPgPSD5ngbJGIK0g== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-unauthenticated-access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:03:54 -0000 Hi Richard, thanks for the review. On 13.09.2013 06:53, Richard Barnes wrote: > I have reviewed this document and requested an IETF LC. I have a few > minor comments, which can be handled along with the IETF LC comments. > > -- In the Abstract and Introduction: It might be helpful to mention the > precedent in the PSTN for context. The analogy to SIMless or > zero-balance emergency calls could help people understand the feature > that this document is trying to enable. Good idea. > > -- In Section 5: Since these steps are performed in sequence, they > should be numbers. Also, it would be helpful if you could highlight > which of these steps might be different from the normal PhoneBCP > behavior -- namely, steps 4 (UA does LoST instead of VSP) and 5 (INVITE > to ESRP instead of VSP). The problem with the number is that there are different paths taken depending on the scenario you are in. Hence, the numbers are a bit misleading unless we replicate the diagram several times for the different scenarios. This would also allow us to illustrate the difference with the normal PhoneBCP procedure more easily. Overloading everything into one diagram might be tough -- we are talking about ASCII art here rather than YouTube videos. > > -- In a few places, the phrase "mandated" is used. Should this be > "REQUIRED"? Yes, that would be better. > > -- In Section 5.3.3., it seems like it would be helpful to emphasize > that if a PSAP wants to support NASP calls, then it MUST NOT restrict > incoming calls to a particular set of ASPs. This seems kind of obvious, > but I expect it will be tempting for PSAPs to impose those sorts of > limitations, so it's important to remind them that it breaks this use case. Certainly makes sense. I will update that part. > > -- In Section 6: s/radio networks/networks/. A note at the top to set > context would be helpful, noting that the NAA case is inherently a layer > 2 problem, and the general form of the solution is to provide an > "emergency only" access type, with appropriate limits/monitoring to > prevent abuse. It would be helpful to have references where specific > link-layer technologies are referenced. OK. Ciao Hannes > > > Thanks, > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From iesg-secretary@ietf.org Fri Sep 13 07:50:48 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98E611E820A; Fri, 13 Sep 2013 07:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVATsz+EGlw8; Fri, 13 Sep 2013 07:50:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD9411E8205; Fri, 13 Sep 2013 07:50:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130913145037.12878.47965.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 07:50:37 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (Public Safety Answering Point (PSAP) Callback) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:50:49 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Public Safety Answering Point (PSAP) Callback' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2180/ From iesg-secretary@ietf.org Fri Sep 13 07:53:01 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40A111E8217; Fri, 13 Sep 2013 07:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gQOfmYk-bNa; Fri, 13 Sep 2013 07:53:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 471F911E8220; Fri, 13 Sep 2013 07:52:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130913145212.24713.83016.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 07:52:12 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:53:01 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ballot/ No IPR declarations have been submitted directly on this I-D. From hannes.tschofenig@gmx.net Thu Sep 26 06:23:20 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6356821F9AB4 for ; Thu, 26 Sep 2013 06:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.161 X-Spam-Level: X-Spam-Status: No, score=-101.161 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKWo8ysIS4uk for ; Thu, 26 Sep 2013 06:23:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6621F8E97 for ; Thu, 26 Sep 2013 06:23:03 -0700 (PDT) Received: from [10.255.129.59] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MJSLz-1VSDfL2RVj-0034OR for ; Thu, 26 Sep 2013 15:22:52 +0200 Message-ID: <52443519.5020502@gmx.net> Date: Thu, 26 Sep 2013 16:22:33 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <523C783A.6070502@bell-labs.com> In-Reply-To: <523C783A.6070502@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qg0J+a5jngtBJ/h+shyI8uWye+ksbpfaNe3xuadOvzNLm/qARK0 uH3eIjZQvbRvhwt/FOevDP3ZjrMihX9p4CQ/XeJ5v6A82iyh57+SfLqbAb8NQN3Mi0Ep19H HrDKKYq9UF0/PWcXZ19sM0UovBWJfgE46MlNymYFB0qyihOEcv7ie0DOtSahm6cEzNkt0wx AzkrX8E7bRCk5AnPHfLoQ== Cc: marc.linsner@cisco.com, "ecrit@ietf.org" , General Area Review Team , draft-ietf-ecrit-psap-callback@tools.ietf.org, marshall@telecomsys.com Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-psap-callback-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 13:23:20 -0000 Hi Vijay, thanks for reviewing the document. I have a few remarks below: On 20.09.2013 19:30, Vijay K. Gurbani wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-ecrit-psap-callback-10 > Reviewer: Vijay K. Gurbani > Review Date: Sep-20-2013 > IETF LC End Date: Sep-27-2013 > IESG Telechat date: Unknown > > This draft is basically ready for publication, but has a couple of > minor issues that should be fixed (or at least looked at) before > publication. > > Major: 0 > Minor: 2 > Nits: 4 (to improve readability) > > Minor: > - S5.2: Maybe I am missing something here, but I did not see any > proposed requirement as I read the text until this point. At least I > do not see a explicit requirement. > > The text in S5.1 constitutes an implicit requirement in that it asks > the SIP UA to override user interface configurations when an incoming > call has "Priority: psap-callback" header AND the SIP UA has recently > placed a call to an emergency service. Is this the requirement you > allude to in the first sentence of S5.2? If so, may be better to > explicitly pose this as a requirement. Section 5.1 describes the security threat. It is actually quite simple: Imagine you have a mechanism that allows you to bypass blacklists. The psap-callback is such a mechanism. So, the threat is that someone could misuse the psap-callback procedure to bypass blacklists (etc.) to send you unwanted traffic. The first requirement says that the developed mechanism has to provide some protection against it. > > The second paragraph of S5.2 constitutes a separate requirement. Yup. Note that both requirements aren't written with RFC 2119 requirements language but I believe that's fine in this case. > > Is it worth spelling these out explicitly as requirements? I don't think it will get any easier to read. > > - S5.3, last paragraph: It seems to me that the SIP UA is the authority > insofar as it can maintain state that an emergency call was made a > short while ago. Consequently, it would seem beneficial to couple the > presence of the callback marking with this state and override local UA > behaviour. This works at the UA and only if the callback reaches the same UA. However, as the scenarios outline in the beginning of the draft we are also talking about intermediaries and we have to consider more complex deployments where the signaling path of the original emergency call is not the same as the reversed signaling path of the callback. > > At least, this alleviates the eventuality that somehow the VoIP > provider forgot to scrub the marking AND the UA never made an emergency > call (thereby allowing spam through). > > Now, if it is your intent to keep the UA as stateless as possible, then > overriding local UA behaviour based on solely the callback marking is > fine. But I do not know what your assumptions are here with respect to > state maintained in the UA. So please determine if this approach of > asking UA to couple state information with the marking makes sense or > not. If not, feel free to disregard, but I did want to point it out. Keeping state information for this purpose is already part of the referenced PhoneBCP solution and does not require any new functionality in this document. We mention this specific procedure in Section 1. Unfortunately, it does not work in all scenarios (as Section 3 explains). Have a look at Section 1 (and maybe Section 3) again to double-check whether the story gets across. > > Nits: > - S3, first paragraph: "As explained in Section 1 a SIP entity examines > an incoming PSAP callback by comparing the domain of the PSAP with the > destination domain of the emergency call." > > Here, I would suggest adding a small phrase as follows: > > s/destination domain of the emergency call./destination domain of the > outbound emergency call placed earlier./ > Fixed. > - S3.1: s/synchronized as to state/synchronized,/ > This improves readability since the text as it currently stand is hard > to parse. OK. > > - S3.3, second paragraph: s/Similarly to/Similar to/ OK. > > - S3.5, first paragraph: s/later does leave/later leaves/ Ok. Thanks for the feedback. Ciao Hannes > > Thanks, > > - vijay From internet-drafts@ietf.org Thu Sep 26 06:29:35 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0CD21F9DA8; Thu, 26 Sep 2013 06:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrhUhFXSd8Qj; Thu, 26 Sep 2013 06:29:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C39FC21E8093; Thu, 26 Sep 2013 06:28:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926132855.29653.37280.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 06:28:55 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-11.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 13:29:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-11.txt Pages : 14 Date : 2013-09-26 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Sep 26 07:21:40 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528A811E8101 for ; Thu, 26 Sep 2013 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.177 X-Spam-Level: X-Spam-Status: No, score=-101.177 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7W2Aq-UYwWU for ; Thu, 26 Sep 2013 07:21:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5699911E80D2 for ; Thu, 26 Sep 2013 07:21:32 -0700 (PDT) Received: from [10.255.129.59] ([194.251.119.201]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1VY28H39ns-008vjU for ; Thu, 26 Sep 2013 16:21:30 +0200 Message-ID: <524442DE.3080302@gmx.net> Date: Thu, 26 Sep 2013 17:21:18 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Y8T4dMrPXRm0Dhz5b4MzY88Km2ZH5xA04Tob5s67SdIJAeij00x xDyX3HdKzjd8Wb2RkJHmx4flqaVytBRW8sCxZV0trqJD/49NCkNq+3pVNyhD88ugZN7Qqov TZF9q5o5xd7Dwn/VVjnGtMuCaankSZ5Gf+mzJk0xKCiapJacjrL44dPVuz50t2fJjZnyEO6 UQfhnvUh+DJYHop7eKZGw== Subject: [Ecrit] draft-ietf-ecrit-psap-callback-11.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:21:40 -0000 Hi all, I have just submitted version -11 of the PSAP callback. With this update I have incorporated feedback from the general area review provided by Vijay. The updated version is here: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-11 The diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ecrit-psap-callback-11.txt Ciao Hannes From hannes.tschofenig@gmx.net Thu Sep 26 07:24:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2F21F9BD8 for ; Thu, 26 Sep 2013 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.193 X-Spam-Level: X-Spam-Status: No, score=-101.193 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PSLe64tHfCa for ; Thu, 26 Sep 2013 07:24:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8598621F968B for ; Thu, 26 Sep 2013 07:24:25 -0700 (PDT) Received: from [10.255.129.59] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MYtId-1VLbcC28Dz-00Vegs for ; Thu, 26 Sep 2013 16:24:17 +0200 Message-ID: <52444384.7040204@gmx.net> Date: Thu, 26 Sep 2013 17:24:04 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roger Marshall References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WFiXQFUghRXozrv97XcbIVaeV/8TU9IIA2iGQ31fHRvzxb7dcgM Hp+UE6MFpLtTuFK43XFyGSk5U9R7cu864ZpUB7MlyAlkcNxTLrD7bqc9W688zVexxRjdoNN hoZBhvlBhBwKaRagCTGRFUIcjEoftR0xn1JLUSK7F3pg68N4qCKC6Bs+Z/QWrm+fAXIiEaQ XHvJEaVGGoBp34TzBtZJw== Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] WGLC announce - draft-ietf-ecrit-trustworthy-location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:24:43 -0000 Hi Roger, no further comments had been received and Bernard provided an update based on the remaining open issue. I believe this document is ready for the IESG. Ciao Hannes On 16.07.2013 00:05, Roger Marshall wrote: > This starts WGLC for draft-ietf-ecrit-trustworthy-location. > > The draft can be found at: > > http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ > > Please review the draft and provide comments to the list before our > ECRIT meeting in Berlin, 2 weeks from today, July 29, 2013. > > Thanks, > > Marc & Roger > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > From hannes.tschofenig@gmx.net Fri Sep 27 11:49:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB0921F992A for ; Fri, 27 Sep 2013 11:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crn3AHP-J0r0 for ; Fri, 27 Sep 2013 11:48:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC79D21F9994 for ; Fri, 27 Sep 2013 11:48:57 -0700 (PDT) Received: from [192.168.1.62] ([88.114.26.32]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6wWn-1Vk29t01WH-00wmGD for ; Fri, 27 Sep 2013 20:48:56 +0200 Message-ID: <5245D30A.8090406@gmx.net> Date: Fri, 27 Sep 2013 21:48:42 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <523C783A.6070502@bell-labs.com> <52443519.5020502@gmx.net> <52445E66.2080805@bell-labs.com> In-Reply-To: <52445E66.2080805@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6v8HCF5GEwN0PDGdOlOdZ2/v9gDQVk5v98agbMNKl9agpmTqL1k CWgdGmaoPI3GmMTsDFjUi9KXO2Km+sUhCFpFbIOL7rHDTJhx/R0A+KYUmKahp9hQcZR9/Fs gqBhjZTVr9CpvdGqNn1Dyn3aJx2v36W91N4XnKrSPiohwMuRuXZG3gJ1qspTlgdCaN6Jyle cGze8EFYn9DOzx1dqXTYg== Cc: marc.linsner@cisco.com, "ecrit@ietf.org" , General Area Review Team , draft-ietf-ecrit-psap-callback@tools.ietf.org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-psap-callback-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:49:03 -0000 Hi Vijay, I updated the draft to take your remarks into account. I liked the security requirements text to the security threats section, as you suggested. I believe you have a point regarding the remark about the security solution. The current description focuses on the PSAP but not on the UA. I assumed that we essentially inherit the functionality from the PhoneBCP document but that should be expressed somewhere. So, I added the following section to the draft: ---- The approach for dealing with implementing the security requirements described in Section 5.2 can be differentiated between the behavior applied by the UA and by SIP proxies. A UA that has made an emergency call will keep state information so that it can recognize and accepted a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed, as described in Section 13 of [RFC6443]. Since UA considerations are described already in [RFC6443] as well as in [RFC6881] the rest of this section focuses on the behavior of SIP proxies. ----- What do you think about that addition? Do you think it addresses your concern? Ciao Hannes On 26.09.2013 19:18, Vijay K. Gurbani wrote: > On 09/26/2013 08:22 AM, Hannes Tschofenig wrote: >> Hi Vijay, >> >> thanks for reviewing the document. > > Hannes: No problem, thanks for considering my comments. > > Please see inline. > >> Section 5.1 describes the security threat. It is actually quite simple: >> Imagine you have a mechanism that allows you to bypass blacklists. >> >> The psap-callback is such a mechanism. >> >> So, the threat is that someone could misuse the psap-callback procedure >> to bypass blacklists (etc.) to send you unwanted traffic. >> >> The first requirement says that the developed mechanism has to provide >> some protection against it. > > I understand the threat implicit in S5.1, but that threat and the > opening paragraph of S5.2 do not correlate for me when I read the draft. > The opening paragraph of S5.2 starts with, > > "The requirement is to ...", > > I am unable to tell exactly *which* requirement are you talking about > by using the definite article ("The"). One way to fix this is to simply > start S5.2 by saying "The security threat discussed in Section 5.1 leads > to the requirement to ensure that ..." > > Phrased as such, the cause and effect between S5.1 and first paragraph > of S5.2 are much more clear. > >>> The second paragraph of S5.2 constitutes a separate requirement. >> >> Yup. >> >> Note that both requirements aren't written with RFC 2119 requirements >> language but I believe that's fine in this case. >>> >>> Is it worth spelling these out explicitly as requirements? >> >> I don't think it will get any easier to read. > > I am not as much worried about phrasing these using rfc2119-type > language as much as I am worried about ensuring that the intent of > what you write shows through. And the small modification I proposed > above allows you do not spell out these as normative requirements > but still impart to the reader the gravity of them. > >>> - S5.3, last paragraph: It seems to me that the SIP UA is the authority >>> insofar as it can maintain state that an emergency call was made a >>> short while ago. Consequently, it would seem beneficial to couple the >>> presence of the callback marking with this state and override local UA >>> behaviour. >> >> This works at the UA and only if the callback reaches the same UA. > > I don't think we are on the same page. > > S5.3 is attempting to use the identity of the PSAP to determine whether > to honor the callback marking. I have no problem with this. > > The point I am trying to make is to allow the UA itself to be the judge > on whether or not to honor the callback marking (i.e., endpoint > intelligence). A UA knows it made an SOS call, therefore, it seems > that *it* should be allowed a role in the decision making on whether to > accept an incoming call that has callback marking. > > If the UA made an SOS call and hung up (for whatever reason), AND it > gets an incoming call with the callback marking, it overrides local > filters and behaviour to simply accept the call. > > If the UA gets an incoming call with callback marking, AND the UA has > not made an outgoing SOS call, then clearly this incoming call is spam. > >> However, as the scenarios outline in the beginning of the draft we are >> also talking about intermediaries and we have to consider more complex >> deployments where the signaling path of the original emergency call is >> not the same as the reversed signaling path of the callback. > > Except for the PSTN interworking case (S3.5), I don't see that the > remaining complex deployments hinder you in delivering the call from > the PSAP to the same UA that originated the call. > > From my analysis, in Section 3.1 when the ESRP makes a call back to the > UA and this call goes through the inbound proxy, the GRUU in the call > will ensure that the same UA receives the inbound call. > > In Section 3.2, the callback from psap@town.com may get normal treatment > from the VoIP provider's inbound proxy, but assuming that the inbound > proxy preserves the callback markings (which it should), then the UA > can uses the knowledge that it made an outbound SOS call to receive the > incoming call. Here, even a malicious actor (spammer) in the VoIP > provider's network somehow manages to inject calls with the "Priority: > psap-callback" header then the UA can reject these calls as spam since > it knows that it never made an SOS call. > > In Section 3.3, the callback originates from police-town.org and the > intermediaries/caller's UA have saved state.org. Again, assuming that > the intermediaries are able to deliver the callback to the UA, the UA > can accept the call simply based on the fact that it made an outbound > SOS call! > > Same logic applies in Section 3.4. The UA knows it made an SOS call, > therefore, at a later time if it gets a incoming call with the callback > marking, it can accept it. > > In short, what I am arguing for is for the UA be allowed to be an actor > in the decision on accepting an incoming call with callback markings > simply because the UA has the authoritative answer on whether it made an > outgoing emergency call. Assuming that the intermediaries are able to > deliver the callback from the PSAP to the UA, it is easy for the UA to > decide to accept it or not: If the UA never made an outgoing emergency > call, then any incoming call with callback marking is treated as spam. > If the UA made an outgoing emergency call, then an incoming call with > callback marking is accepted. > > Please let me know what you think. > > Thanks, > > - vijay From christer.holmberg@ericsson.com Fri Sep 27 12:16:06 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8220421F9EE5; Fri, 27 Sep 2013 12:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdF9Mm7zvwXG; Fri, 27 Sep 2013 12:16:02 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 57EDB21F9DA3; Fri, 27 Sep 2013 12:16:01 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-a1-5245d9709de4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id EA.D5.25272.079D5425; Fri, 27 Sep 2013 21:16:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 21:15:59 +0200 From: Christer Holmberg To: "Vijay K. Gurbani" , Hannes Tschofenig Thread-Topic: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10 Thread-Index: AQHOth4a125StD9tqE6gCEgjpUzg2ZnX6SeAgAAxPACAAbw5AIAAB/+AgAAhDPaAAAAekg== Date: Fri, 27 Sep 2013 19:15:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AE0EC@ESESSMB209.ericsson.se> References: <523C783A.6070502@bell-labs.com> <52443519.5020502@gmx.net> <52445E66.2080805@bell-labs.com> <5245D30A.8090406@gmx.net>,<5245D9BF.6090408@bell-labs.com> In-Reply-To: <5245D9BF.6090408@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE0ECESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM+JvrW7BTdcgg1PNghZ/Hy1lt2hc9JTV 4uqrzywWS3feY7XYcOobi8XUPluLw1eXMlk0rJFz4PDou+ziMeX3RlaPxZv2s3ksWfKTyWPy xlksHhu2nmL2+HL5M1sAexSXTUpqTmZZapG+XQJXxo79VxkLbppWvLndxdTAuF+3i5GTQ0LA ROLRrHusELaYxIV769m6GLk4hASOMkp0Ht7DBOEsYZT4+fwuUIaDg03AQqL7nzZIg4hAtMSH dVtYQWqYBQ4xSRztPg42SVjAS+L14UVMEEXeEj/O/GEG6RURCJN4clgMJMwioCrRfeMgO4jN K+Ar8fvYfKjFKxglVq1fCjaHU0BXYvbNY2BzGIGu+35qDZjNLCAucevJfCaIqwUkluw5zwxh i0q8fPwP6htFiavTl0PV50ts37qIDWKZoMTJmU9YJjCKzkIyahaSsllIyiDiehI3pk5hg7C1 JZYtfM0MYetKzPh3CKiGA8i2lvg8Pw9ZyQJGjlWMHMWpxUm56UYGmxiBUX1wy2+LHYyX/9oc YpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OObtmKJ/NWvTrsMffJ4sQT x2OMi+YEfdxT3GQnclhlf/QtrkuOX/fJqLdsXeq8+Xefp1iL2pNvPw9cZ1s4U3j33MyzCcxm 3iFNl9uXLXq0WmnXFamtrb+OXnkheu9zve9spQ87HuQ+ES58rXF84oe5zhdeu7f+eDJjdqzR QaneZhahxB8uHrIRSizFGYmGWsxFxYkAB58SMLgCAAA= Cc: "marc.linsner@cisco.com" , "ecrit@ietf.org" , General Area Review Team , "draft-ietf-ecrit-psap-callback@tools.ietf.org" Subject: Re: [Ecrit] [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:16:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AE0ECESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your comments, Vijay! Regards, Christer ________________________________ From: gen-art-bounces@ietf.org [gen-art-bounces@ietf.org] on behalf of Vija= y K. Gurbani [vkg@bell-labs.com] Sent: Friday, 27 September 2013 10:17 PM To: Hannes Tschofenig Cc: rmarshall@telecomsys.com; marc.linsner@cisco.com; ecrit@ietf.org; Richa= rd Barnes; General Area Review Team; draft-ietf-ecrit-psap-callback@tools.i= etf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10 Hannes: I am happy with the changes outlined below. I am convinced they make the document better. Thank you for attending to my comments. On 09/27/2013 01:48 PM, Hannes Tschofenig wrote: > Hi Vijay, > > I updated the draft to take your remarks into account. > > I liked the security requirements text to the security threats section, > as you suggested. > > I believe you have a point regarding the remark about the security > solution. The current description focuses on the PSAP but not on the UA. > I assumed that we essentially inherit the functionality from the > PhoneBCP document but that should be expressed somewhere. > > So, I added the following section to the draft: > > ---- > > The approach for dealing with implementing the security requirements > described in Section 5.2 can be differentiated between the behavior > applied by the UA and by SIP proxies. A UA that has made an > emergency call will keep state information so that it can recognize > and accepted a callback from the PSAP if it occurs within a > reasonable time after an emergency call was placed, as described in > Section 13 of [RFC6443]. Since UA considerations are described > already in [RFC6443] as well as in [RFC6881] the rest of this section > focuses on the behavior of SIP proxies. > > ----- > > What do you think about that addition? Do you think it addresses your > concern? Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art --_000_7594FB04B1934943A5C02806D1A2204B1C4AE0ECESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5920B8978055704D99811F07F5E103EC@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks for your comments, Vijay!

 

Regards,

 

Christer

 

 

From: gen-art-bounces@ietf.org [gen-art-bounces@ietf.org] on beh= alf of Vijay K. Gurbani [vkg@bell-labs.com]
Sent: Friday, 27 September 2013 10:17 PM
To: Hannes Tschofenig
Cc: rmarshall@telecomsys.com; marc.linsner@cisco.com; ecrit@ietf.org= ; Richard Barnes; General Area Review Team; draft-ietf-ecrit-psap-callback@= tools.ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callb= ack-10

Hannes:

I am happy with the changes outlined below.  I am convinced they
make the document better.  Thank you for attending to my comments.

On 09/27/2013 01:48 PM, Hannes Tschofenig wrote:
> Hi Vijay,
>
> I updated the draft to take your remarks into account.
>
> I liked the security requirements text to the security threats section= ,
> as you suggested.
>
> I believe you have a point regarding the remark about the security
> solution. The current description focuses on the PSAP but not on the U= A.
> I assumed that we essentially inherit the functionality from the
> PhoneBCP document but that should be expressed somewhere.
>
> So, I added the following section to the draft:
>
> ----
>
>     The approach for dealing with implementing the= security requirements
>     described in Section 5.2 can be differentiated= between the behavior
>     applied by the UA and by SIP proxies.  A = UA that has made an
>     emergency call will keep state information so = that it can recognize
>     and accepted a callback from the PSAP if it oc= curs within a
>     reasonable time after an emergency call was pl= aced, as described in
>     Section 13 of [RFC6443].  Since UA consid= erations are described
>     already in [RFC6443] as well as in [RFC6881] t= he rest of this section
>     focuses on the behavior of SIP proxies.
>
> -----
>
> What do you think about that addition? Do you think it addresses your<= br> > concern?

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http:/= /ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq _______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
--_000_7594FB04B1934943A5C02806D1A2204B1C4AE0ECESESSMB209erics_-- From a.james.winterbottom@gmail.com Fri Sep 27 18:20:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11B221E809B for ; Fri, 27 Sep 2013 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3O6Owl1LYW7 for ; Fri, 27 Sep 2013 18:20:32 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0821E8097 for ; Fri, 27 Sep 2013 18:20:31 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so3296511pdi.14 for ; Fri, 27 Sep 2013 18:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J+DeyQduTSyOaj7he+QvQ7LCUwo7Cr1zQUq+wVRLvt8=; b=sdvIEZ/O5YZMPYYdvVGtKiRIDkasAYbd1svXwNfaT/bjDcMk41T32zmKXvabo4Zkve fC103KLKbz3/kRoDdvgQtGf1sgaWpWsq9imhRmFtum6mNnUuHzYiS2gqDktM++sOajmt Tr4+VCFxnEsBziwWne+h/ny8MnjUrxAW2pQaAxDExEuMOaiY36BQg6eb4joIeNrMk9i1 Tgx+5sJJF7jIEisPB/nUF+yermIy7DvCV3T3XZHfbNDyLpSKu7LeZ1pmXOwizmpZ9EE2 s/GSFhL7K/CatBVW618+LYiYFQ+sb9IQE+iIvK+vJ5zMIJrmcYwUO91osyG0az8uRbA/ kxTg== X-Received: by 10.67.14.67 with SMTP id fe3mr14908794pad.134.1380331230810; Fri, 27 Sep 2013 18:20:30 -0700 (PDT) Received: from [192.168.1.100] ([120.153.220.62]) by mx.google.com with ESMTPSA id py4sm11508603pbb.33.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 18:20:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E2391E8-ADD9-47F9-87FE-9AB167CB6F4C" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Sat, 28 Sep 2013 11:20:24 +1000 Message-Id: <27FF2042-14CF-4B65-8FB4-B1D1E9EE7111@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1510) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: comments on data provider elements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 01:20:33 -0000 --Apple-Mail=_1E2391E8-ADD9-47F9-87FE-9AB167CB6F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Barbara, Please see comments inline. Cheers James On 01/08/2013, at 3:06 AM, "STARK, BARBARA H" wrote: > I finished my review of draft-ietf-ecrit-additional-data-10. I'm = sending my comments divided among 5 emails. These are miscellaneous = comments on data provider elements. > Barbara > ------------------- > 3.1. Data Provider Information >=20 > This block is intended to be provided by any service provider in the > path of the call or the access network provider. It includes > identification and contact information. This block SHOULD be > provided by every service provider in the call path, and by the > access network provider . Devices MAY use this block to provide > identifying information. The MIME subtype is "application/ > emergencyCall.ProviderInfo+xml". >=20 > Comment 1: > How are you expecting an access provider to know to include this = block? What is the trigger? This could be a problematic recommendation = as some access providers are explicitly forbidden from altering anything = in the IP payloads of the packets they transport/route. If IP payload is = encrypted, then it can't be done. But if the expectation is that this = would happen when providing location (so it's in the Reference/Value = Provided-By of supplied location), then that's ok but it might be useful = to mention this. [AJW] I was certainly envisioning that the access provider would include = a URI in the Provided-By section of any PIDF-LO it provides. This URI = can then be dereferenced by authorised parities to obtain the associated = access provider information. I will include a note to this effect. > ------------------- > 3.1.2. Data Provider ID >=20 > Data Element: Data Provider ID >=20 > Use : Conditional. Must be provided if the service provider is > located in a jurisdiction that maintains such ids . Devices are > not required to provide it. >=20 > Description: A jurisdiction specific code for the provider shown = in > the element that created the structure of the > call. This data SHOULD be provided if the local jurisdiction > maintains such an ID list. For example, in North America, this > would be a "NENA Company ID". Devices SHOULD NOT use this > element. >=20 > Comment 2: Needs to say something about access provider use. [AJW] Not sure why they need explicit call out. If they have an ID then = they fill out this chunk of data. > Comment 3: I don't think this sort of condition (dependency on whether = some undefined organization in undefined jurisdictions do or don't do = something) belongs in a RFC. Compliance is difficult to ascertain. My = opinion is that this information would be better as guidance rather than = normative. [AJW] I am okay with "Recommended" rather than SHOULD. > Comment 4: The first use of "provider" in Description may need to be = more specific. "Provider" as a stand-alone term is undefined, but it may = be that only service providers will have jurisdiction specific codes, = and not necessarily an access network provider. [AJW] I will add something to make it clearer that it applies to any = provider that has such a code. > -------------------- > 3.1.5. Data Provider Contact URI > Use: Required > Description: For a service provider the contact SHOULD be a = contact > URI. This MUST be a SIP URI. If a telephone number is the > contact address it should be provided in the form of > sip:telephonenumber@serviceprovider:user=3Dphone. If the call is > from a device, this would reflect the contact information of the > owner of the device. When provided by a service provider, this > would be a URI to a 24/7 support organization tasked to provide > PSAP support for this emergency call. >=20 > Comment 5: This is confusing. A ContactURI *should* be a ContactURI? = What else could it be? [AJW] This is not referring to the SIP header, it is referring to a way = in which to contact the service provider potentially even using an old = rotary phone. > Comment 6: What is the antecedent of "This" (This MUST be a SIP URI)? = Is "This" the optional contact URI from the previous sentence (if = contact is ContactURI then it MUST be a SIP URI)? [AJW] The sentence is actually wrong. The contact information must be in = URI form. It may be a tel uri or a SIP URI. If it is a telephone number = expressed as a SIP URI then it has to have the user=3Dphone parameter. > Comment 7: Is the 2nd should a normative SHOULD? Or is this more of = "will" or non-normative "may"? [AJW] I will update the normative language when I update the tel uri = text. > -------------------- > 3.1.6. Data Provider Languages(s) Supported > How Used by Call Taker: If call taker cannot speak language(s) > supported by the service provider, a translation service will = need > to be added to the conversation. >=20 > Comment 8: Is this really the call taker or maybe also someone else at = PSAP? [AJW] for the service provider it will likely be someone else. I will = update the text to say something like: "If the person contacting the service provider cannot speak the = language(s) supported by the service provider then a translation service = can be added to the conversation. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_1E2391E8-ADD9-47F9-87FE-9AB167CB6F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Barbara,

Please see comments = inline.

Cheers
James

On 01/08/2013, at 3:06 AM, "STARK, BARBARA H" <bs7652@att.com> wrote:

I finished = my review of draft-ietf-ecrit-additional-data-10. I'm sending my = comments divided among 5 emails. These are miscellaneous comments on = data provider elements.
Barbara
-------------------
3.1. =  Data Provider Information

  This block is = intended to be provided by any service provider in the
=   path of the call or the access network provider.  It = includes
  identification and contact information. =  This block SHOULD be
  provided by every service = provider in the call path, and by the
  access network = provider .  Devices MAY use this block to provide
=   identifying information.  The MIME subtype is = "application/
=   emergencyCall.ProviderInfo+xml".

Comment 1:
How = are you expecting an access provider to know to include this block? What = is the trigger? This could be a problematic recommendation as some = access providers are explicitly forbidden from altering anything in the = IP payloads of the packets they transport/route. If IP payload is = encrypted, then it can't be done. But if the expectation is that this = would happen when providing location (so it's in the Reference/Value = Provided-By of supplied location), then that's ok but it might be useful = to mention this.
[AJW] I was certainly envisioning = that the access provider would include a URI in the Provided-By section = of any PIDF-LO it provides. This URI can then be dereferenced = by authorised parities to obtain the associa= ted access provider information. I will include a note to this = effect.
-------------------
3.1.2. =  Data Provider ID

  Data Element:  Data = Provider ID

  Use :  Conditional.  Must be = provided if the service provider is
=      located in a jurisdiction that maintains = such ids .  Devices are
     not = required to provide it.

  Description:  A = jurisdiction specific code for the provider  shown in
=      the <DataProvidedBy> element that = created the structure of the
     call. =  This data SHOULD be provided if the local jurisdiction
=      maintains such an ID list.  For = example, in North America, this
     would = be a "NENA Company ID".  Devices SHOULD NOT use this
=      element.

Comment 2: Needs to say = something about access provider use.
[AJW] Not sure = why they need explicit call out. If they have an ID then they fill out = this chunk of data.

Comment 3: I don't think this sort of condition = (dependency on whether some undefined organization in undefined = jurisdictions do or don't do something) belongs in a RFC. Compliance is = difficult to ascertain. My opinion is that this information would be = better as guidance rather than normative.
[AJW] = I am okay with "Recommended" rather than = SHOULD.

Comment 4: The first use = of "provider" in Description may need to be more specific. "Provider" as = a stand-alone term is undefined, but it may be that only service = providers will have jurisdiction specific codes, and not necessarily an = access network provider.
[AJW] I will add something = to make it clearer that it applies to any provider that has such a = code.
--------------------
3.1.5. =  Data Provider Contact URI
  Use:  Required
=   Description:  For a service provider the contact SHOULD =  be a contact
     URI.  This =  MUST be a SIP URI.  If a telephone number is the
=      contact address it should  be = provided in the form of
     sip:telephonenum= ber@serviceprovider:user=3Dphone.  If the call is
=      from a device, this would reflect the = contact information of the
     owner of = the device.  When provided by a service provider, this
=      would be a URI to a 24/7 support = organization tasked to provide
     PSAP = support for this emergency call.

Comment 5: This is confusing. A = ContactURI *should* be a ContactURI? What else could it = be?
[AJW] This is not referring to the SIP = header, it is referring to a way in which to contact the service = provider potentially even using an old rotary = phone.

Comment 6: = What is the antecedent of "This" (This MUST be a SIP URI)? Is "This" the = optional contact URI from the previous sentence (if contact is = ContactURI then it MUST be a SIP URI)?
[AJW] The = sentence is actually wrong. The contact information must be in URI form. = It may be a tel uri or a SIP URI. If it is a telephone number expressed = as a SIP URI then it has to have the user=3Dphone = parameter.

Comment 7: = Is the 2nd should a normative SHOULD? Or is this more of "will" or = non-normative "may"?
[AJW] I will update the = normative language when I update the tel uri = text.

--------------------
3.1.6.  Data Provider = Languages(s) Supported
  How Used by Call Taker:  If = call taker  cannot speak language(s)
=      supported by the service provider, a = translation service will need
     to be = added to the conversation.

Comment 8: Is this really the call = taker or maybe also someone else at PSAP?
[AJW] = for the service provider it will likely be someone else. I will = update the text to say something like:
"If = the person contacting the service provider cannot speak the = language(s) supported by the service provider then a translation service = can be added to the conversation.

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

= --Apple-Mail=_1E2391E8-ADD9-47F9-87FE-9AB167CB6F4C-- From internet-drafts@ietf.org Sun Sep 29 08:13:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4415111E80E6; Sun, 29 Sep 2013 08:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBy-zYURH7CN; Sun, 29 Sep 2013 08:13:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A590821F9F74; Sun, 29 Sep 2013 08:12:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130929151258.9676.4485.idtracker@ietfa.amsl.com> Date: Sun, 29 Sep 2013 08:12:58 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-12.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 15:13:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-12.txt Pages : 14 Date : 2013-09-29 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sun Sep 29 08:16:53 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D252021F9DCE for ; Sun, 29 Sep 2013 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBqGsfXTI8IE for ; Sun, 29 Sep 2013 08:16:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 273BC21F92B5 for ; Sun, 29 Sep 2013 08:16:46 -0700 (PDT) Received: from [192.168.1.62] ([88.114.26.32]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LedVG-1WCLP12YcI-00qOud for ; Sun, 29 Sep 2013 17:16:45 +0200 Message-ID: <5248445C.1000105@gmx.net> Date: Sun, 29 Sep 2013 18:16:44 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <523C783A.6070502@bell-labs.com> <52443519.5020502@gmx.net> <52445E66.2080805@bell-labs.com> <5245D30A.8090406@gmx.net> <5245D9BF.6090408@bell-labs.com> In-Reply-To: <5245D9BF.6090408@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/wNJEsd/drhGP6ziRZe4dRxQJ2Qvb7fupYv3OGX6SdIQLEt7SbO QRI13HwS8z20W2wpj3OhnNnwvnokpiWEUFRcVlt0DdHTyykrFHd7+FVGQ3pd0HCP6M+7ht0 ySErmRAkZq3LpSFh4UlW/3m/fpQKYX9ix/LMJ3IxLsui57iP00Z9JNZHoaiJjC3Mq7i91Ys gZHJ+EuuUYIHwYS3o3TUw== Cc: marc.linsner@cisco.com, "ecrit@ietf.org" , General Area Review Team , draft-ietf-ecrit-psap-callback@tools.ietf.org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-psap-callback-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 15:16:54 -0000 Hi Vijay, thanks for the time to review the document so carefully. I have just submitted an updated version and I indeed think that your review feedback has improved the quality of the document. Ciao Hannes On 27.09.2013 22:17, Vijay K. Gurbani wrote: > Hannes: > > I am happy with the changes outlined below. I am convinced they > make the document better. Thank you for attending to my comments. > > On 09/27/2013 01:48 PM, Hannes Tschofenig wrote: >> Hi Vijay, >> >> I updated the draft to take your remarks into account. >> >> I liked the security requirements text to the security threats section, >> as you suggested. >> >> I believe you have a point regarding the remark about the security >> solution. The current description focuses on the PSAP but not on the UA. >> I assumed that we essentially inherit the functionality from the >> PhoneBCP document but that should be expressed somewhere. >> >> So, I added the following section to the draft: >> >> ---- >> >> The approach for dealing with implementing the security requirements >> described in Section 5.2 can be differentiated between the behavior >> applied by the UA and by SIP proxies. A UA that has made an >> emergency call will keep state information so that it can recognize >> and accepted a callback from the PSAP if it occurs within a >> reasonable time after an emergency call was placed, as described in >> Section 13 of [RFC6443]. Since UA considerations are described >> already in [RFC6443] as well as in [RFC6881] the rest of this section >> focuses on the behavior of SIP proxies. >> >> ----- >> >> What do you think about that addition? Do you think it addresses your >> concern? > > Cheers, > > - vijay From a.james.winterbottom@gmail.com Sun Sep 29 18:58:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7CE21F9BC1 for ; Sun, 29 Sep 2013 18:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgSkPwL4PIMu for ; Sun, 29 Sep 2013 18:58:50 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DFB1A21F9AF8 for ; Sun, 29 Sep 2013 18:58:49 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so4976687pdj.17 for ; Sun, 29 Sep 2013 18:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/8MUsJO87IyTr/HmkyAlIgPyf0qnGzpRmJSJnbsfdpI=; b=0mUWegs0kRtj4IpZgXMb8IgAl5I8zYEu8roOzRnD8osn4ZwOizi+xdjbTj46eXrM/k ybvWKN+A8W2a5oyiq5zRBNBsNWsQXSyDNRWL+MIWXZ5ZbqTL/umWBNUd/pls4EX3I3MJ QxEu151oDXhMBAcTCkGu5ogPpwq8ExIoHHNaoBjtg2fKfQvxdwZFKUzc/7PclV6KK7Uz QcHqaRU9HOFzyCZLmIfj2zIpcQy6kpg1dS0phS9rTQj6a/l0OmKuGIuXQsToJ8grOGae R164tv3sDYrV9mORmeEtDxLBPHPhCoWbaEwFOXiHOpHQaoZEItINpORzbHU+bx3oezC2 Tcmw== X-Received: by 10.66.142.230 with SMTP id rz6mr25551629pab.117.1380506328697; Sun, 29 Sep 2013 18:58:48 -0700 (PDT) Received: from [192.168.1.100] ([110.151.44.97]) by mx.google.com with ESMTPSA id fa4sm29244525pab.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 18:58:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E39AE0B6-1963-44A4-B8A7-C27F91AF1F05" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317CDF@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Mon, 30 Sep 2013 11:58:43 +1000 Message-Id: <0D15D37C-E5ED-45B6-A222-E66CF13A0C64@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E61130317CDF@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1510) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: mandatory elements in blocks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 01:58:51 -0000 --Apple-Mail=_E39AE0B6-1963-44A4-B8A7-C27F91AF1F05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 01/08/2013, at 3:09 AM, "STARK, BARBARA H" wrote: > Comments related to blocks with no mandatory elements. > The Use statements for an element should not be considered a statement = as to whether the block itself is mandatory or optional. Bock = usage/inclusion Use statements need to be elsewhere. So Use of an = element is restricted to use of that element within a block that exists. > ------------- > 3.3. Device Information >=20 > Comment 20: It's sort of weird that there's not a single required = element for this block. But, ok. Does this mean it's possible to have = the block present with nothing in it? [AJW] Yes, but that isn't very useful.. *8) > -------------- > 3.4.1. xCard for Subscriber's Data > Use: Conditional : Some services (e.g., prepaid phones, initialized > phones, etc.) may not have this information. >=20 > Comment 21: What's the condition? Or is it really just Optional? [AJW] I think that the condition is that if the information is available = then it should provided. I will update to make this more clear. > As with DeviceInfo block, there are no required elements. But in this = case, this is the only possible element. So it seems that if a = Subscriber block exists, then this SubscriberData element is Required. = Otherwise it makes no sense for the Subscriber block to exist. [AJW] Again, if there is no data to provide then there is no point in = providing the block. > -------------- > 3.5.1. Comment >=20 > Data Element: EmergencyCall.Comment >=20 > Use: Optional >=20 > Comment 22: Again, it makes no sense for the one possible element of a = block to be optional when that block is present. This is a statement = about the existence of this element in the block and not about the block = itself. All blocks are effectively optional. [AJW] Same as before. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_E39AE0B6-1963-44A4-B8A7-C27F91AF1F05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bs7652@att.com> wrote:
Comments = related to blocks with no mandatory elements.
The Use statements for = an element should not be considered a statement as to whether the block = itself is mandatory or optional. Bock usage/inclusion Use statements = need to be elsewhere. So Use of an element is restricted to use of that = element within a block that exists.
-------------
3.3. =  Device Information

Comment 20: It's sort of weird that = there's not a single required element for this block. But, ok. Does this = mean it's possible to have the block present with nothing in = it?
[AJW] Yes, but that isn't very useful.. = *8)
--------------
3.4.1. =  xCard for Subscriber's Data
  Use:  Conditional = : Some services (e.g., prepaid phones, initialized
=      phones, etc.) may not have this = information.

Comment 21: What's the condition? Or is it really = just Optional?
[AJW] I think that the condition is = that if the information is available then it should provided. I = will update to make this more clear.
As = with DeviceInfo block, there are no required elements. But in this case, = this is the only possible element. So it seems that if a Subscriber = block exists, then this SubscriberData element is Required. Otherwise it = makes no sense for the Subscriber block to = exist.
[AJW] Again, if there is no data to provide = then there is no point in providing the block.
--------------
3.5.1.  Comment

=   Data Element:  EmergencyCall.Comment

=   Use:  Optional

Comment 22: Again, it makes no = sense for the one possible element of a block to be optional when that = block is present. This is a statement about the existence of this = element in the block and not about the block itself. All blocks are = effectively optional.
[AJW] Same as = before.
_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail=_E39AE0B6-1963-44A4-B8A7-C27F91AF1F05-- From hannes.tschofenig@gmx.net Mon Sep 30 06:18:59 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8480D21F86BE for ; Mon, 30 Sep 2013 06:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.249 X-Spam-Level: X-Spam-Status: No, score=-101.249 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mSO2-bjJ0i7 for ; Mon, 30 Sep 2013 06:18:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF1421F84F9 for ; Mon, 30 Sep 2013 06:18:53 -0700 (PDT) Received: from [10.255.137.144] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MQu9K-1VHAvK0kuc-00UNch for ; Mon, 30 Sep 2013 15:18:52 +0200 Message-ID: <52497A31.809@gmx.net> Date: Mon, 30 Sep 2013 16:18:41 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kCVFuxGZ07DklLHs0oCNrBsluKF3W/JZxmnG0z3i65yJcu0HMhr 3cXX93WPuQZxQVGC0fdLdCsRbeJDr+0hjeI6tRsZaP78M6NI5kTzCllW0m+ZoFN4YPhxY8G s0kmg6jz2miQZZWHRg8H9FyVbl6S/sNRg56keesS6gf8OEb5nU4TPnod9bJyk3/0ZmHtBSy NgnfWNvWjE+8ScID74lVA== Subject: [Ecrit] Rechartering of ECRIT to include the eCall Work? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 13:18:59 -0000 Hi all, at the last IETF meeting there was agreement to recharter ECRIT to include the eCall document(s), as the meeting minutes capture nicely. I haven't seen any actions so far. What's the status? Ciao Hannes From RMarshall@telecomsys.com Mon Sep 30 16:49:46 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F35E21F8B35 for ; Mon, 30 Sep 2013 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tzMd5dwXk4H for ; Mon, 30 Sep 2013 16:49:42 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 095F921F85BB for ; Mon, 30 Sep 2013 16:49:41 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id r8UNnTBD002710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 30 Sep 2013 16:49:29 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.66]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 30 Sep 2013 16:49:29 -0700 From: Roger Marshall To: "'Hannes Tschofenig'" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Rechartering of ECRIT to include the eCall Work? Thread-Index: AQHOvd+lwbnYPSYvAEuh4OIFzerFeZne8xrQ Date: Mon, 30 Sep 2013 23:49:28 +0000 Message-ID: References: <52497A31.809@gmx.net> In-Reply-To: <52497A31.809@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Rechartering of ECRIT to include the eCall Work? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 23:49:46 -0000 Hannes: You're right, the notes were clear on this. It's in the works. It has bee= n submitted by the chairs to the AD's - and they are looking at it. -roger. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Monday, September 30, 2013 6:19 AM To: ecrit@ietf.org Subject: [Ecrit] Rechartering of ECRIT to include the eCall Work? Hi all, at the last IETF meeting there was agreement to recharter ECRIT to include = the eCall document(s), as the meeting minutes capture nicely. I haven't seen any actions so far. What's the status? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network.