From christer.holmberg@ericsson.com Thu Mar 1 02:57:57 2012 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 A7B3E21F8673 for ; Thu, 1 Mar 2012 02:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 v8bppD072JwK for ; Thu, 1 Mar 2012 02:57:56 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED3721F866B for ; Thu, 1 Mar 2012 02:57:55 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e6-4f4f5632fd54 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.47.27041.2365F4F4; Thu, 1 Mar 2012 11:57:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 1 Mar 2012 11:57:55 +0100 From: Christer Holmberg To: John-Luc Bakker , Paul Kyzivat , Brian Rosen Date: Thu, 1 Mar 2012 11:57:54 +0100 Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AQHM78PyDHznfkKTnk62En7ZjB3JuJZHeJgAgAAYsYCAABfRgIAAALeAgAAIA4CAAASJgIAAASqAgAAjLYCAAAD8gIACnWccgAB0kICAADbGAIAAB6CAgAAFHYCACSKhwIAA/6wQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADCD@ESESSCMS0356.eemea.ericsson.se> References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> <4F468077.3060600@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 01 Mar 2012 10:57:57 -0000 Hi John-Luc, I think some of your issues would be solved if the nonce was generated by t= he registrar. In that case, it can be provided when the phone you dropped re-registers, a= nd the same value could be given to every phone that may receive the callba= ck (in case it is another phone than the one who made the emergency call). Regards, Christer =20 -----Original Message----- From: John-Luc Bakker [mailto:jbakker@rim.com]=20 Sent: 1. maaliskuuta 2012 0:40 To: Paul Kyzivat; Brian Rosen Cc: Christer Holmberg; ecrit@ietf.org; Nick Russell Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Hi, I have some further questions regarding the nonce approach. In this e-mail I consider two types of emergency calls: UA detected and non= -UA-detected. A succfully completed non-UA-detected emergency call is less = likely to occur, but can happen. A call back from a PSAP needs to be identified as such in order to allow fo= r special handling to be applied. If we consider the nonce approach, the UA generating the nonce for a UA det= ected emergency call can compare the nonce if it gets one back (i.e. if the= PSAP makes a call back and the nonce is included). This assumes the UE has= "not forgotten" about the nonce (i.e. the device fell out of the user's ha= nd while making the emergency call, dropping both a battery as well as the = emergency call prematurely). In case the UA notices the call back header fi= eld/parameter, yet fails to match the nonce, the presence of the call back = header field/parameter will not cause the UA to handle the call different f= rom a normal call. This makes sense as in IMS multiple UAs can share the same public user iden= tity. So, assuming no GRUU was used, a UA having registered the same identi= ty may receive the emergency call back. This receiving UA didn't make the e= mergency call that triggered the callback so it also fails to match the non= ce, the presence of the call back header field/parameter will not cause the= UA to handle the call different from a normal call. (To prevent the wrong = UA from terminating the PSAP call back, a GRUU must be used by the PSAP.) In case a non-UA-detected emergency call was accepted by the PSAP and the P= SAP follows up with a PSAP call back, the PSAP need not have a nonce to inc= lude (unless the PSAP has received a nonce while the original emergency cal= l was in progress). At any rate, the PSAP still includes the header/paramet= er to enable special treatment to be applied by intermediaries. Again, the = UA (making the non-UA-detected emergency call) may fail the match, yet the = presence of the call back header field/parameter will not cause the UA to h= andle the call different from a normal call. The inclusion of the header/parameter parameter already causes special hand= ling by intermediaries, nonce or not. The intermediaries are to "trust" the= indication given by the header/parameter. Note that the intermediaries on = the path of the PSAP call back are unlikely be the same intermediaries that= were on the path of the original emergency call. An intermediary may resta= rt and forget about the nonces. Even if the intermediaries are the same and= didn't restart, is it likely that intermediaries will store the nonce for = comparison reasons, and how long? This makes me wonder if we really need the nonce. Above is shown that the a= bsence or presence of the nonce may cause a UA that made an emergency call = to fail to recognize the terminating call as an emergency call back from th= e PSAP. Furthermore, any intermediaries likely also modify the behavior app= lied to the emergency call back without looking at the nonce. The protection against abuse of the mechanism should be at the intermediari= es (nonce or not). Intermediaries are bound to not like it if the services = they provide on behalf of the user are being bypassed. Users also become un= happy when calls that should have been diverted, aren't, due to malicious p= resence of the header/parameter.=20 The UA can protect itself by remembering it did make an emergency call, rec= ently. If the UA has no knowledge of having made an emergency call, it can = treat the header/parameter with some skepticism? Kind regards, John-Luc -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Thursday, February 23, 2012 12:08 PM To: Brian Rosen Cc: John-Luc Bakker; christer.holmberg@ericsson.com; ecrit@ietf.org Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning On 2/23/12 12:49 PM, Brian Rosen wrote: > That's a privacy attack: > > I want to know your location, so I force you to send an emergency call. = Then I observe it. > > I actually like it, but it has this problem. Well, the calling UA must recognize the URN in the 3xx as an emergency call= URN. And then it does call that address, so the attack is only useful to s= omeone that can observer the subsequent call. But it is an attack to that e= xtent. It could be mitigated by the UA querying the user before retrying the call = as an emergency call. But I suppose some might consider that too much of a = delay. OTOH it would only occur when calling a number the phone doesn't *kn= ow* to be an emergency number. There is also the attack of sending a fake configuration to the phone, givi= ng it an emergency dial string that is something the user is likely to call= . Thanks, Paul > Brian > > On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: > >> On 2/23/12 9:06 AM, Brian Rosen wrote: >>> To support emergency calls, the UA pretty much has to know it's an emer= gency call unless the access network and the origination network are the sa= me entity, or have some kind of relationship. We have a number of tools th= at make this possible. For example, LoST returns the local dial string(s) = for emergency calls in the area where the UA is located. Phonebcp states t= he UA queries its access network for its own location, then uses that to qu= ery LoST for the PSAP URI(s) and local dial string(s). >>> >>> In a case where there is a lot of knowledge, a proxy server can add the= nonce and the origination network can also arrange for the Contact to be c= onstructed correctly. IMS actually does have the UE recognizing local emer= gency dial strings. >> >> It always seemed to me that the "best" way to do this would be for the l= ocal server that first recognizes this as an emergency call would do a 3xx = to urn:sos... Then the calling device would know that it should treat this= as an emergency call. >> >> I suppose, in order to cope with devices that wouldn't handle that grace= fully, there could be an option that the caller announces support for that = would indicate it is ready to do this. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>> >>>> Hi, >>>> >>>> Was the scenario considered where a UA is unaware it is making an emer= gency call? For example the user reads the local emergency number (applicab= le in that region) (I believe the fire brigade in France can be reached by = dialing "18") on a sign (then observes an emergency), enters the local numb= er, and the request with that number is sent by the UA. >>>> >>>> Does the nonce solution recommend a UA to include the nonce in every S= IP request on the off change it turns out to be a request for emergency? >>>> >>>> Regards, >>>> >>>> John-Luc >>>> --- >>>> John-Luc Bakker >>>> Standards Manager >>>> Research In Motion Corporation >>>> Mobile +1 (908) 463 7321 >>>> Office +1 (972) 373-1761 >>>> Internal (820) 63761 >>>> E-mail jbakker@rim.com >>>> >>>> Sent from my BlackBerry Torch (9810) >>>> >>>> ----- Original Message ----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Tuesday, February 21, 2012 09:13 AM >>>> To: Paul Kyzivat;=20 >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New=20 >>>> Beginning >>>> >>>> >>>> Hi, >>>> >>>>> Ignoring the problem of callback from a PSTN-based psap (which I comm= ented on in earlier message), why isn't the following sufficient: >>>>> >>>>> - the caller uses callerprefs to indicate that it doesn't want to >>>>> talk to an automaton. >>>>> >>>>> - the original emergency caller encodes its contact for the=20 >>>>> emergency call with something *it* understands (e.g. a nonce) that it= will subsequently treat as granting priority to an incoming call carrying = it. >>>>> >>>>> In this way nobody but the calling UA need know the nonce=20 >>>>> mechanism. It need not be standardized. (And it need not be used at a= ll if the caller is willing to tolerate some priority spit.) The callerpref= s will prevent the rest of the infrastructure from diverting the call. This= would then be understood to be a mechanism that anybody can use, not just = emergency calls. >>>>> >>>>> Of course this would require widespread support for callerprefs. But = any solution here is going to require widespread support of something. >>>> >>>> It is not only the calling UA that needs to know. Intermediaries also = need to identify a callback, in order to give special treatment. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU=20 >>>>>> is still the preferred way of routing to the UA. >>>>>> >>>>>> I am just saying that a "side effect" of a feature tag based=20 >>>>>> indicator is that it CAN also be used for routing. I am not=20 >>>>>> saying that we shall mandate support of feature tag based=20 >>>>>> routing. The main purpose of the feature tag is still as indicator. >>>>> >>>>> But wouldn't it then be sufficient to have just a SIP header field=20 >>>>> set by the PSAP when it sends the callback that says "callback"? >>>>> >>>>> Anything else would just be replicating existing functionality. >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> ------------------------------------------------------------------- >>>> -- This transmission (including any attachments) may contain=20 >>>> confidential information, privileged material (including material prot= ected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this transmissio= n in error, please immediately reply to the sender and delete this informat= ion from your system. Use, dissemination, distribution, or reproduction of = this transmission by unintended recipients is not authorized and may be unl= awful. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Thu Mar 1 09:20:57 2012 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 F17C321E8061 for ; Thu, 1 Mar 2012 09:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 oXmqRLt9Umi2 for ; Thu, 1 Mar 2012 09:20:55 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7D021E803C for ; Thu, 1 Mar 2012 09:20:55 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id gGx41i00C27AodY5CHLvkQ; Thu, 01 Mar 2012 17:20:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id gHLu1i00T07duvL3fHLueP; Thu, 01 Mar 2012 17:20:55 +0000 Message-ID: <4F4FAFF5.2080000@alum.mit.edu> Date: Thu, 01 Mar 2012 12:20:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John-Luc Bakker References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> <4F468077.3060600@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 01 Mar 2012 17:20:57 -0000 ISTM that the trouble in figuring this out is lack of clarity about what special treatment is supposed to provided in the PSAP callback, or maybe this can better be described as what special treatment needs to be worked around during the PSAP callback. Suppose there was *no* special treatment of the callback. Then what things might prevent the callback from working? - an intermediary might divert or reject the call, preventing it from reaching the original endpoint, for a variety of reasons: * policy controlled by the end user, such as a black/white list or unconditional diversion, or time based diversion * policy controlled by the intermediary provider, such as limitation to one call at a time. * a billing limitation such as call block due to unpaid status * a resource limitation, such as lack of bandwidth for another call * the UA is unreachable - the UA might reject or divert the call for a variety of reasons * policy controlled by the end user, such as disabled alerting, unconditional or based on black/white list * belief that an emergency call is in progress and other calls should be rejected, coupled with inability to recognize the new call as a PSAP callback * inability or unwillingness to handle concurrent calls coupled with belief that the original call (unknown to be an emergency call) is still in progress * lack of resources to handle the call, such as low battery The problems at the UA are probably easier to deal with. If the UA just remembers that it has made an emergency call recently, and the PSAP callback is simply marked, based on the honor system, as an emergency callback, then the UA can have policies to deal with this reasonably. There is then a risk of "fraud" - of someone impersonating a PSAP callback - but they can only work during the period that the UA thinks it has made an emergency call. Confusion about whether the existing emergency call has dropped or not can be handled via huristics, such as assuming the callback is to replace the existing call, or switching to the callback but still retaining the state of the prior call and allowing the user to switch back to it. But the UA can only do this if it is aware that it was in an emergency call. My prior suggestion for an intermediary to send a 3xx with an sos URN when it decides a called number is an emergency call could help with that. (Though would need to resolve the issues Brian raised.) Otherwise the intermediaries will have to deal with it. But it can still be a problem if the UA once knew it was in an emergency call, but then forgot. But probably every sip UA today that is likely to be making emergency calls will have some non-volatile storage. So I don't think that is a problem that needs solving. To an extent the intermediaries might be able to address this the same way by remembering that an emergency call is in progress and adjusting policies to take that into account. Use of a nonce, rather than just using honor system to identify PSAP callbacks, would potentially eliminate some fraud. Whether this is important depends on whether there are practical ways to exploit fraud. If we assume that the intermediaries can know that an emergency call is in progress, then its fairly hard to exploit fraud. Unless someone can come up with something interesting here maybe that can be considered insignificant. But there has been some concern that the PSAP callback might take a different path than the original emergency call and the intermediaries on the callback path then might not know that an emergency call is in progress. But the nonce is a solution to that only if the intermediaries on the callback path can validate the nonce. One solution to that is for there to be some shared state between the intermediaries that handled the original emergency call and those that handle the callback. This could be knowledge that an emergency call is in progress to a particular UA, or the nonce of such an emergency call. The only other solution I have heard is some sort of shared secret between the PSAP UA making the callback (or an intermediary operating on its behalf) and the intermediary making a policy or resource decision about the call. AFAIK this is still considered "hard" to deploy in a reliable way. Based on all that, I am inclined to prefer an honor system indication of an emergency callback coupled with depending on the intermediaries and the called UA remembering that an emergency call is in progress. That includes expecting the intermediaries that make policy decisions consulting some sort of shared state, and UAs that knowingly make emergency calls remembering that status in a reliable way. For those cases when the UA made a call without knowing that it was an emergency call, I still think its preferable for the intermediary that realizes this to inform the UA (probably via 3xx). If that is infeasible, then the intermediary will have to do all it can to expedite the PSAP callback at the UA. But there may be little it can do. Thanks, Paul On 2/29/12 5:40 PM, John-Luc Bakker wrote: > Hi, > > I have some further questions regarding the nonce approach. > > In this e-mail I consider two types of emergency calls: UA detected and non-UA-detected. A succfully completed non-UA-detected emergency call is less likely to occur, but can happen. > > A call back from a PSAP needs to be identified as such in order to allow for special handling to be applied. > > If we consider the nonce approach, the UA generating the nonce for a UA detected emergency call can compare the nonce if it gets one back (i.e. if the PSAP makes a call back and the nonce is included). This assumes the UE has "not forgotten" about the nonce (i.e. the device fell out of the user's hand while making the emergency call, dropping both a battery as well as the emergency call prematurely). In case the UA notices the call back header field/parameter, yet fails to match the nonce, the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call. > > This makes sense as in IMS multiple UAs can share the same public user identity. So, assuming no GRUU was used, a UA having registered the same identity may receive the emergency call back. This receiving UA didn't make the emergency call that triggered the callback so it also fails to match the nonce, the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call. (To prevent the wrong UA from terminating the PSAP call back, a GRUU must be used by the PSAP.) > > In case a non-UA-detected emergency call was accepted by the PSAP and the PSAP follows up with a PSAP call back, the PSAP need not have a nonce to include (unless the PSAP has received a nonce while the original emergency call was in progress). At any rate, the PSAP still includes the header/parameter to enable special treatment to be applied by intermediaries. Again, the UA (making the non-UA-detected emergency call) may fail the match, yet the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call. > > The inclusion of the header/parameter parameter already causes special handling by intermediaries, nonce or not. The intermediaries are to "trust" the indication given by the header/parameter. Note that the intermediaries on the path of the PSAP call back are unlikely be the same intermediaries that were on the path of the original emergency call. An intermediary may restart and forget about the nonces. Even if the intermediaries are the same and didn't restart, is it likely that intermediaries will store the nonce for comparison reasons, and how long? > > This makes me wonder if we really need the nonce. Above is shown that the absence or presence of the nonce may cause a UA that made an emergency call to fail to recognize the terminating call as an emergency call back from the PSAP. Furthermore, any intermediaries likely also modify the behavior applied to the emergency call back without looking at the nonce. > > The protection against abuse of the mechanism should be at the intermediaries (nonce or not). Intermediaries are bound to not like it if the services they provide on behalf of the user are being bypassed. Users also become unhappy when calls that should have been diverted, aren't, due to malicious presence of the header/parameter. > The UA can protect itself by remembering it did make an emergency call, recently. If the UA has no knowledge of having made an emergency call, it can treat the header/parameter with some skepticism? > > Kind regards, > > John-Luc > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, February 23, 2012 12:08 PM > To: Brian Rosen > Cc: John-Luc Bakker; christer.holmberg@ericsson.com; ecrit@ietf.org > Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning > > On 2/23/12 12:49 PM, Brian Rosen wrote: >> That's a privacy attack: >> >> I want to know your location, so I force you to send an emergency call. Then I observe it. >> >> I actually like it, but it has this problem. > > Well, the calling UA must recognize the URN in the 3xx as an emergency > call URN. And then it does call that address, so the attack is only > useful to someone that can observer the subsequent call. But it is an > attack to that extent. > > It could be mitigated by the UA querying the user before retrying the > call as an emergency call. But I suppose some might consider that too > much of a delay. OTOH it would only occur when calling a number the > phone doesn't *know* to be an emergency number. > > There is also the attack of sending a fake configuration to the phone, > giving it an emergency dial string that is something the user is likely > to call. > > Thanks, > Paul > >> Brian >> >> On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: >> >>> On 2/23/12 9:06 AM, Brian Rosen wrote: >>>> To support emergency calls, the UA pretty much has to know it's an emergency call unless the access network and the origination network are the same entity, or have some kind of relationship. We have a number of tools that make this possible. For example, LoST returns the local dial string(s) for emergency calls in the area where the UA is located. Phonebcp states the UA queries its access network for its own location, then uses that to query LoST for the PSAP URI(s) and local dial string(s). >>>> >>>> In a case where there is a lot of knowledge, a proxy server can add the nonce and the origination network can also arrange for the Contact to be constructed correctly. IMS actually does have the UE recognizing local emergency dial strings. >>> >>> It always seemed to me that the "best" way to do this would be for the local server that first recognizes this as an emergency call would do a 3xx to urn:sos... Then the calling device would know that it should treat this as an emergency call. >>> >>> I suppose, in order to cope with devices that wouldn't handle that gracefully, there could be an option that the caller announces support for that would indicate it is ready to do this. >>> >>> Thanks, >>> Paul >>> >>>> Brian >>>> >>>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>>> >>>>> Hi, >>>>> >>>>> Was the scenario considered where a UA is unaware it is making an emergency call? For example the user reads the local emergency number (applicable in that region) (I believe the fire brigade in France can be reached by dialing "18") on a sign (then observes an emergency), enters the local number, and the request with that number is sent by the UA. >>>>> >>>>> Does the nonce solution recommend a UA to include the nonce in every SIP request on the off change it turns out to be a request for emergency? >>>>> >>>>> Regards, >>>>> >>>>> John-Luc >>>>> --- >>>>> John-Luc Bakker >>>>> Standards Manager >>>>> Research In Motion Corporation >>>>> Mobile +1 (908) 463 7321 >>>>> Office +1 (972) 373-1761 >>>>> Internal (820) 63761 >>>>> E-mail jbakker@rim.com >>>>> >>>>> Sent from my BlackBerry Torch (9810) >>>>> >>>>> ----- Original Message ----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Tuesday, February 21, 2012 09:13 AM >>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning >>>>> >>>>> >>>>> Hi, >>>>> >>>>>> Ignoring the problem of callback from a PSTN-based psap (which I commented on in earlier message), why isn't the following sufficient: >>>>>> >>>>>> - the caller uses callerprefs to indicate that it doesn't want to >>>>>> talk to an automaton. >>>>>> >>>>>> - the original emergency caller encodes its contact for the emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming >>>>>> call carrying it. >>>>>> >>>>>> In this way nobody but the calling UA need know the nonce mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The >>>>>> callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls. >>>>>> >>>>>> Of course this would require widespread support for callerprefs. But any solution here is going to require widespread support of something. >>>>> >>>>> It is not only the calling UA that needs to know. Intermediaries also need to identify a callback, in order to give special treatment. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU is >>>>>>> still the preferred way of routing to the UA. >>>>>>> >>>>>>> I am just saying that a "side effect" of a feature tag based >>>>>>> indicator is that it CAN also be used for routing. I am not saying >>>>>>> that we shall mandate support of feature tag based routing. The main >>>>>>> purpose of the feature tag is still as indicator. >>>>>> >>>>>> But wouldn't it then be sufficient to have just a SIP header field set >>>>>> by the PSAP when it sends the callback that says "callback"? >>>>>> >>>>>> Anything else would just be replicating existing functionality. >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >> >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > From jbakker@rim.com Thu Mar 1 13:09:56 2012 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 1954F21E8194 for ; Thu, 1 Mar 2012 13:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.893 X-Spam-Level: X-Spam-Status: No, score=-4.893 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 apwaHBoD1OgM for ; Thu, 1 Mar 2012 13:09:54 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2F421E8013 for ; Thu, 1 Mar 2012 13:09:47 -0800 (PST) X-AuditID: 0a41282f-b7f0e6d000007c4d-c9-4f4fe59ab2c8 Received: from XHT110CNC.rim.net (xht110cnc.rim.net [10.65.22.55]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 1D.9D.31821.A95EF4F4; Thu, 1 Mar 2012 21:09:46 +0000 (GMT) Received: from XCT102ADS.rim.net (10.67.111.43) by XHT110CNC.rim.net (10.65.22.55) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 1 Mar 2012 16:09:46 -0500 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0339.001; Thu, 1 Mar 2012 15:09:45 -0600 From: John-Luc Bakker To: Christer Holmberg , Paul Kyzivat , Brian Rosen Thread-Topic: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Thread-Index: AQHM78PyDHznfkKTnk62En7ZjB3JuJZHeJgAgAAYsYCAABfRgIAAALeAgAAIA4CAAASJgIAAASqAgAAjLYCAAAD8gIACnWccgAB0kICAADbGAIAAB6CAgAAFHYCACSKhwIAA/6wQgACp+OA= Date: Thu, 1 Mar 2012 21:09:44 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA350FC41D@XMB104ADS.rim.net> References: <155970D1DA8E174F9E46039E10E2AA350EF737@XMB104ADS.rim.net> <4F4675C8.8060700@alum.mit.edu> <4F468077.3060600@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA350FA4AF@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADCD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADCD@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGKsWRmVeSWpSXmKPExsXC5Shmrjvrqb+/weavWhZP709js7gw8zCj ReOip6wWKzYcYHVg8fj7/gOTx/1vf9k9fn29yuaxZMlPpgCWqAZGm8S8vPySxJJUhZTU4mRb JZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsu BQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp4sEEv5xZ5xraWEs+J5WMW9dL1sD497g LkZODgkBE4kpN18yQdhiEhfurWfrYuTiEBLoYZLombUJylnCKPH+aS8zSJWQwCZGia1z6kBs NgF1ia0rtoPFRQTqJZo33GIBsZkF3CSWXPoHFhcW8JA4vv0F0CAOoBpPif6/QiAzRQTmMUoc mtTNAhJnEVCRWLHKHaScF6j13PGHLBB7W5klfnbuZwRJcApESPzdehvsUkYBWYndZ68zQewS l7j1ZD7UBwISS/acZ4awRSVePv7HCmErSjxp3Ax1m47Egt2f2CBsbYllC18zQywWlDg58wkL xI8yEq1tu9gmMErMQrJiFpL2WUjaZyFpX8DIsopRMDej2MDMIDkvWa8oM1cvL7VkEyM4AWno 72Ds26t1iFGAg1GJh/ftQ39/IdbEsuLK3EOMEhzMSiK83HeBQrwpiZVVqUX58UWlOanFhxgt gCE0kVmKOzkfmBzzSuKNDQxQOErivItXavkLCaQDU1h2ampBahFMKxMHp1QDY2u2m1fTfq// 2+cGZZ42r+ubV64cy/hq7Z/7IeHztxnF5k/b6+F6UShpzpJtSq89Hh7NPtjc2cgRKJDPtUhk c5GX5s8ItU/u+tM6mad5z2C/GiDz8O1aZab285+8Zr06+vyk44MlN2VXqu1W32d09bSVXMSW 6Phlv7923krfvyG9aMWhKzX7nyuxFGckGmoxFxUnAgC+UwAdWQMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning 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, 01 Mar 2012 21:09:56 -0000 Hi Christer, To go a along with your scenario where a user e.g. removes the U/SIM from on= e phone and puts it in another phone after making an emergency call on the f= irst phone. If the registrar creates the NONCE, is the same NONCE made avail= able to all UAs sharing the same public user identity? Is the same nonce ret= urned each time a UE with the same public user identity registers? Or, assum= ing a deployment where emergency registration is supported, is the same nonc= e returned each time a UE with the same public user identity performs an eme= rgency registration? Regards, John-Luc -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, March 01, 2012 4:58 AM To: John-Luc Bakker; Paul Kyzivat; Brian Rosen Cc: ecrit@ietf.org; Nick Russell Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Hi John-Luc, I think some of your issues would be solved if the nonce was generated by th= e registrar. In that case, it can be provided when the phone you dropped re-registers, an= d the same value could be given to every phone that may receive the callback= (in case it is another phone than the one who made the emergency call). Regards, Christer -----Original Message----- From: John-Luc Bakker [mailto:jbakker@rim.com] Sent: 1. maaliskuuta 2012 0:40 To: Paul Kyzivat; Brian Rosen Cc: Christer Holmberg; ecrit@ietf.org; Nick Russell Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning Hi, I have some further questions regarding the nonce approach. In this e-mail I consider two types of emergency calls: UA detected and non-= UA-detected. A succfully completed non-UA-detected emergency call is less li= kely to occur, but can happen. A call back from a PSAP needs to be identified as such in order to allow for= special handling to be applied. If we consider the nonce approach, the UA generating the nonce for a UA dete= cted emergency call can compare the nonce if it gets one back (i.e. if the P= SAP makes a call back and the nonce is included). This assumes the UE has "n= ot forgotten" about the nonce (i.e. the device fell out of the user's hand w= hile making the emergency call, dropping both a battery as well as the emerg= ency call prematurely). In case the UA notices the call back header field/pa= rameter, yet fails to match the nonce, the presence of the call back header= field/parameter will not cause the UA to handle the call different from a n= ormal call. This makes sense as in IMS multiple UAs can share the same public user ident= ity. So, assuming no GRUU was used, a UA having registered the same identity= may receive the emergency call back. This receiving UA didn't make the emer= gency call that triggered the callback so it also fails to match the nonce,= the presence of the call back header field/parameter will not cause the UA= to handle the call different from a normal call. (To prevent the wrong UA f= rom terminating the PSAP call back, a GRUU must be used by the PSAP.) In case a non-UA-detected emergency call was accepted by the PSAP and the PS= AP follows up with a PSAP call back, the PSAP need not have a nonce to inclu= de (unless the PSAP has received a nonce while the original emergency call w= as in progress). At any rate, the PSAP still includes the header/parameter t= o enable special treatment to be applied by intermediaries. Again, the UA (m= aking the non-UA-detected emergency call) may fail the match, yet the presen= ce of the call back header field/parameter will not cause the UA to handle t= he call different from a normal call. The inclusion of the header/parameter parameter already causes special handl= ing by intermediaries, nonce or not. The intermediaries are to "trust" the i= ndication given by the header/parameter. Note that the intermediaries on the= path of the PSAP call back are unlikely be the same intermediaries that wer= e on the path of the original emergency call. An intermediary may restart an= d forget about the nonces. Even if the intermediaries are the same and didn'= t restart, is it likely that intermediaries will store the nonce for compari= son reasons, and how long? This makes me wonder if we really need the nonce. Above is shown that the ab= sence or presence of the nonce may cause a UA that made an emergency call to= fail to recognize the terminating call as an emergency call back from the P= SAP. Furthermore, any intermediaries likely also modify the behavior applied= to the emergency call back without looking at the nonce. The protection against abuse of the mechanism should be at the intermediarie= s (nonce or not). Intermediaries are bound to not like it if the services th= ey provide on behalf of the user are being bypassed. Users also become unhap= py when calls that should have been diverted, aren't, due to malicious prese= nce of the header/parameter. The UA can protect itself by remembering it did make an emergency call, rece= ntly. If the UA has no knowledge of having made an emergency call, it can tr= eat the header/parameter with some skepticism? Kind regards, John-Luc -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Thursday, February 23, 2012 12:08 PM To: Brian Rosen Cc: John-Luc Bakker; christer.holmberg@ericsson.com; ecrit@ietf.org Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning On 2/23/12 12:49 PM, Brian Rosen wrote: > That's a privacy attack: > > I want to know your location, so I force you to send an emergency call. T= hen I observe it. > > I actually like it, but it has this problem. Well, the calling UA must recognize the URN in the 3xx as an emergency call= URN. And then it does call that address, so the attack is only useful to so= meone that can observer the subsequent call. But it is an attack to that ext= ent. It could be mitigated by the UA querying the user before retrying the call a= s an emergency call. But I suppose some might consider that too much of a de= lay. OTOH it would only occur when calling a number the phone doesn't *know*= to be an emergency number. There is also the attack of sending a fake configuration to the phone, givin= g it an emergency dial string that is something the user is likely to call. Thanks, Paul > Brian > > On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote: > >> On 2/23/12 9:06 AM, Brian Rosen wrote: >>> To support emergency calls, the UA pretty much has to know it's an emerg= ency call unless the access network and the origination network are the same= entity, or have some kind of relationship. We have a number of tools that= make this possible. For example, LoST returns the local dial string(s) for= emergency calls in the area where the UA is located. Phonebcp states the U= A queries its access network for its own location, then uses that to query L= oST for the PSAP URI(s) and local dial string(s). >>> >>> In a case where there is a lot of knowledge, a proxy server can add the= nonce and the origination network can also arrange for the Contact to be co= nstructed correctly. IMS actually does have the UE recognizing local emerge= ncy dial strings. >> >> It always seemed to me that the "best" way to do this would be for the lo= cal server that first recognizes this as an emergency call would do a 3xx to= urn:sos... Then the calling device would know that it should treat this as= an emergency call. >> >> I suppose, in order to cope with devices that wouldn't handle that gracef= ully, there could be an option that the caller announces support for that wo= uld indicate it is ready to do this. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote: >>> >>>> Hi, >>>> >>>> Was the scenario considered where a UA is unaware it is making an emerg= ency call? For example the user reads the local emergency number (applicable= in that region) (I believe the fire brigade in France can be reached by dia= ling "18") on a sign (then observes an emergency), enters the local number,= and the request with that number is sent by the UA. >>>> >>>> Does the nonce solution recommend a UA to include the nonce in every SI= P request on the off change it turns out to be a request for emergency? >>>> >>>> Regards, >>>> >>>> John-Luc >>>> --- >>>> John-Luc Bakker >>>> Standards Manager >>>> Research In Motion Corporation >>>> Mobile +1 (908) 463 7321 >>>> Office +1 (972) 373-1761 >>>> Internal (820) 63761 >>>> E-mail jbakker@rim.com >>>> >>>> Sent from my BlackBerry Torch (9810) >>>> >>>> ----- Original Message ----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Tuesday, February 21, 2012 09:13 AM >>>> To: Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New >>>> Beginning >>>> >>>> >>>> Hi, >>>> >>>>> Ignoring the problem of callback from a PSTN-based psap (which I comme= nted on in earlier message), why isn't the following sufficient: >>>>> >>>>> - the caller uses callerprefs to indicate that it doesn't want to >>>>> talk to an automaton. >>>>> >>>>> - the original emergency caller encodes its contact for the >>>>> emergency call with something *it* understands (e.g. a nonce) that it= will subsequently treat as granting priority to an incoming call carrying i= t. >>>>> >>>>> In this way nobody but the calling UA need know the nonce >>>>> mechanism. It need not be standardized. (And it need not be used at al= l if the caller is willing to tolerate some priority spit.) The callerprefs= will prevent the rest of the infrastructure from diverting the call. This w= ould then be understood to be a mechanism that anybody can use, not just eme= rgency calls. >>>>> >>>>> Of course this would require widespread support for callerprefs. But a= ny solution here is going to require widespread support of something. >>>> >>>> It is not only the calling UA that needs to know. Intermediaries also n= eed to identify a callback, in order to give special treatment. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU >>>>>> is still the preferred way of routing to the UA. >>>>>> >>>>>> I am just saying that a "side effect" of a feature tag based >>>>>> indicator is that it CAN also be used for routing. I am not >>>>>> saying that we shall mandate support of feature tag based >>>>>> routing. The main purpose of the feature tag is still as indicator. >>>>> >>>>> But wouldn't it then be sufficient to have just a SIP header field >>>>> set by the PSAP when it sends the callback that says "callback"? >>>>> >>>>> Anything else would just be replicating existing functionality. >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> ------------------------------------------------------------------- >>>> -- This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material prote= cted by the solicitor-client or other applicable privileges), or constitute= non-public information. Any use of this information by anyone other than th= e intended recipient is prohibited. If you have received this transmission i= n error, please immediately reply to the sender and delete this information= from your system. Use, dissemination, distribution, or reproduction of this= transmission by unintended recipients is not authorized and may be unlawful= . >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From rjsparks@nostrum.com Mon Mar 5 14:05:29 2012 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 97CED21F8881 for ; Mon, 5 Mar 2012 14:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 4BczNipBw+qS for ; Mon, 5 Mar 2012 14:05:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C85F721F8880 for ; Mon, 5 Mar 2012 14:05:28 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25M5QQP052835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:05:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F5538AF.7010509@nostrum.com> Date: Mon, 05 Mar 2012 16:05:35 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> In-Reply-To: <4F461734.4050306@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: ecrit@ietf.org, "apps-discuss@ietf.org" , hgs+ecrit@cs.columbia.edu, Peter Saint-Andre Subject: Re: [Ecrit] review of draft-ietf-ecrit-lost-sync-12 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, 05 Mar 2012 22:05:29 -0000 There's an aspect of this document that I want to make sure folks aren't missing. The things lostsync1 are adding are not things that something that speaks lost will every say. It's not an iteration of the lost vocabulary in that sense. It is something spoken by things that talk about lost speakers. This is not an extension of Lost. It is a different protocol that replicates the data used to answer Lost queries. It reuses the format that Lost uses when talking about that data. Does that make a difference in whether a new namespace is appropriate? (No is an OK answer - I don't have a strong opinion, but my instinct says that the separate namespace is likely to introduce fewer problems because of a bad assumption an implementer could make if the values were in the same namespace). RjS On 2/23/12 4:38 AM, "Martin J. Dürst" wrote: > Hello Peter, others, > > On 2012/02/23 6:55, Peter Saint-Andre wrote: >> Robert Sparks asked me to think about the namespaces issue... >> >>> -------- Original Message -------- Subject: Re: review of >>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 11:17:10 +0200 >>> From: Hannes Tschofenig To: >>> "Martin J. >>> Dürst" CC: Hannes Tschofenig >>> , Henning Schulzrinne >>> , Marc Linsner, >>> Robert Sparks, "apps-review@ietf.org" >>> , ecrit@ietf.org >>> >>> >>>> From Martin: >>> >>>> Namespaces: It is overkill to define new namespaces for each spec. >>>> It's a well-known secret in the XML community that it's easily >>>> possible to add a number of new elements to an existing namespace. >>>> This would be very appropriate in this case, because the number of >>>> reused elements and attributes is quite large, and the number of >>>> new elements is low. This would simplify most of the examples. >>> >>> I guess you refer to the namespace registration in the IANA >>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>> >>> In the RAI area we have (to my knowledge) always created new >>> namespaces for new schemas. But I am pleased to hear that this is not >>> needed. >>> >>> Could you explain what we should be doing instead? > > Rather than define a new namespace lostsync1, just add the few > elements you defined anew to the lost1 namespace. It will make the > format simpler, and it won't hurt. > >> I don't see a problem with defining a new namespace for each iteration >> of an XML format (lostsync1, lostsync2, etc.), > > There's no 'problem' with defining a separate namespace for each > element. Correct software should still work. But it's not really > necessary, it's tedious for human users and just overkill. > >> because I don't think >> there's a general case here -- backward compatibility can depend on the >> community of interest. One community might be doing strict schema >> checking, so that any new elements or attributes would be problematic. >> By contrast, another community might be more lax in its processing >> because they specify that applications must ignore unknown elements and >> attributes, even those qualified by an existing namespace. > > Validation is largely independent of namespaces. There are some > problems with validating documents with more than one namespace, > depending on the technology (I'd have to look up the details), but > there are NO issues, with any of the validating technologies around > (DTDs, XML Schema, Relaxing, Schematron), when having only one > namespace and validating against subsets thereof. > > W3C technologies regularly do that (XHTML and SVG are the examples I > know best). Way, way back there was a heated discussion in the XML > community about whether a new namespace would make sense for a new > version of XHTML, and this was strongly and utterly rejected. The way > it was put most prominently was "a

is a

is a

". > > Validation is not only different for versions, but as you have > explained also for various other purposes. Some applications may use > validation to introduce further restrictions (e.g. for security > reasons in certain places), and so on. > > A new namespace for a new version only make sense if the old and the > new version are something completely different, with essentially no > common elements and no documents that would be acceptable in both > versions. For other cases, using separate namespaces just increases > clutter without contributing anything. > > The same is the case here. The proposed "lostsync1" namespace doesn't > contain many elements, and is only useful together with the "lost1" > namespace. That's of course unless the people in charge of the LOST > protocol and the people who came up with LOSTSYNC totally distrust > each other, but I was just assuming that's not the case :-). > > Regards, Martin. From rjsparks@nostrum.com Mon Mar 5 14:15:02 2012 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 83EB021F87D3; Mon, 5 Mar 2012 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 S7tmro8avpjg; Mon, 5 Mar 2012 14:15:01 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17721F844F; Mon, 5 Mar 2012 14:14:59 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25MEppd054150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:14:52 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F553AE5.9060602@nostrum.com> Date: Mon, 05 Mar 2012 16:15:01 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> <4F5538AF.7010509@nostrum.com> In-Reply-To: <4F5538AF.7010509@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: hgs+ecrit@cs.columbia.edu, Peter Saint-Andre , ecrit@ietf.org, "apps-discuss@ietf.org" Subject: Re: [Ecrit] review of draft-ietf-ecrit-lost-sync-12 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, 05 Mar 2012 22:15:02 -0000 (One typo correction inline) On 3/5/12 4:05 PM, Robert Sparks wrote: > There's an aspect of this document that I want to make sure folks > aren't missing. > > The things lostsync1 are adding are not things that something that > speaks lost will every say. s/every/ever/ > > It's not an iteration of the lost vocabulary in that sense. > > It is something spoken by things that talk about lost speakers. > > This is not an extension of Lost. It is a different protocol that > replicates the data used to > answer Lost queries. It reuses the format that Lost uses when talking > about that data. > > Does that make a difference in whether a new namespace is appropriate? > > (No is an OK answer - I don't have a strong opinion, but my instinct > says that the separate > namespace is likely to introduce fewer problems because of a bad > assumption an implementer > could make if the values were in the same namespace). > > RjS > > > On 2/23/12 4:38 AM, "Martin J. Dürst" wrote: >> Hello Peter, others, >> >> On 2012/02/23 6:55, Peter Saint-Andre wrote: >>> Robert Sparks asked me to think about the namespaces issue... >>> >>>> -------- Original Message -------- Subject: Re: review of >>>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 11:17:10 >>>> +0200 >>>> From: Hannes Tschofenig To: >>>> "Martin J. >>>> Dürst" CC: Hannes Tschofenig >>>> , Henning Schulzrinne >>>> , Marc Linsner, >>>> Robert Sparks, "apps-review@ietf.org" >>>> , ecrit@ietf.org >>>> >>>> >>>>> From Martin: >>>> >>>>> Namespaces: It is overkill to define new namespaces for each spec. >>>>> It's a well-known secret in the XML community that it's easily >>>>> possible to add a number of new elements to an existing namespace. >>>>> This would be very appropriate in this case, because the number of >>>>> reused elements and attributes is quite large, and the number of >>>>> new elements is low. This would simplify most of the examples. >>>> >>>> I guess you refer to the namespace registration in the IANA >>>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>>> >>>> In the RAI area we have (to my knowledge) always created new >>>> namespaces for new schemas. But I am pleased to hear that this is not >>>> needed. >>>> >>>> Could you explain what we should be doing instead? >> >> Rather than define a new namespace lostsync1, just add the few >> elements you defined anew to the lost1 namespace. It will make the >> format simpler, and it won't hurt. >> >>> I don't see a problem with defining a new namespace for each iteration >>> of an XML format (lostsync1, lostsync2, etc.), >> >> There's no 'problem' with defining a separate namespace for each >> element. Correct software should still work. But it's not really >> necessary, it's tedious for human users and just overkill. >> >>> because I don't think >>> there's a general case here -- backward compatibility can depend on the >>> community of interest. One community might be doing strict schema >>> checking, so that any new elements or attributes would be problematic. >>> By contrast, another community might be more lax in its processing >>> because they specify that applications must ignore unknown elements and >>> attributes, even those qualified by an existing namespace. >> >> Validation is largely independent of namespaces. There are some >> problems with validating documents with more than one namespace, >> depending on the technology (I'd have to look up the details), but >> there are NO issues, with any of the validating technologies around >> (DTDs, XML Schema, Relaxing, Schematron), when having only one >> namespace and validating against subsets thereof. >> >> W3C technologies regularly do that (XHTML and SVG are the examples I >> know best). Way, way back there was a heated discussion in the XML >> community about whether a new namespace would make sense for a new >> version of XHTML, and this was strongly and utterly rejected. The way >> it was put most prominently was "a

is a

is a

". >> >> Validation is not only different for versions, but as you have >> explained also for various other purposes. Some applications may use >> validation to introduce further restrictions (e.g. for security >> reasons in certain places), and so on. >> >> A new namespace for a new version only make sense if the old and the >> new version are something completely different, with essentially no >> common elements and no documents that would be acceptable in both >> versions. For other cases, using separate namespaces just increases >> clutter without contributing anything. >> >> The same is the case here. The proposed "lostsync1" namespace doesn't >> contain many elements, and is only useful together with the "lost1" >> namespace. That's of course unless the people in charge of the LOST >> protocol and the people who came up with LOSTSYNC totally distrust >> each other, but I was just assuming that's not the case :-). >> >> Regards, Martin. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Fri Mar 9 03:26:17 2012 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 93D0421F85FB for ; Fri, 9 Mar 2012 03:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] 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 nR-R3M0z3Uhf for ; Fri, 9 Mar 2012 03:26:16 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 3F78721F85F8 for ; Fri, 9 Mar 2012 03:26:15 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 9 Mar 2012 12:26:08 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id D839B3A1DF for ; Fri, 9 Mar 2012 12:26:07 +0100 (CET) Message-ID: <4F59E8D5.4060902@omnitor.se> Date: Fri, 09 Mar 2012 12:26:13 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ecrit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Phonebcp issues 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, 09 Mar 2012 11:26:17 -0000 The final publication of draft-ietf-ecrit-phonebcp has now been hanging waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized because it is referenced in the test section. The status of the media-loopback draft is that it seems to be less ready now than 7 months ago. This makes in fact even RFC 6443 impossible to implement, because RFC 6443 refers to phonebcp for specification of the testing procedure I wonder if it is time to pull phonebcp loose from the dependency of the media-loopback draft and specify a simple test method of its own instead. I do not think that the current specification in phonebcp is very realistic, with just a loopback. I think the test server could just as well generate some own initial test media and then possibly also mirror some packets when received. The current behavior of the media-loopback to wait for incoming media before it generates any outgoing media is not similar to what will be the scenario in real calls. Both sides in real calls normally take initiative to media transmission after the session is established. The resulting problems for NAT traversal of the current media-loopback draft is one of the issues that has caused its delay. Another small issue: RFC 6443 recommends SRTP to be used for media security, but phonebcp does not mention media security. phonebcp is approved, so I do not think it is appropriate to open it for such additions. Can this gap be covered in some additional draft, or can we rely on implementors to apply both phonebcp and RFC 6443? Gunnar From hannes.tschofenig@nsn.com Fri Mar 9 04:29:23 2012 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 795F221F85E6 for ; Fri, 9 Mar 2012 04:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.208 X-Spam-Level: X-Spam-Status: No, score=-106.208 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 OaHLY2esT0OO for ; Fri, 9 Mar 2012 04:29:22 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4779021F8629 for ; Fri, 9 Mar 2012 04:29:22 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q29CTKuf008418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 13:29:21 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q29CTIJU002020; Fri, 9 Mar 2012 13:29:20 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 13:29:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 14:29:13 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> In-Reply-To: <4F59E8D5.4060902@omnitor.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phonebcp issues Thread-Index: Acz953rpgRTrNNcfQtmbI6AIK4AKRgACITTA References: <4F59E8D5.4060902@omnitor.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: =?iso-8859-1?Q?ext_Gunnar_Hellstr=F6m?= , "Ecrit" X-OriginalArrivalTime: 09 Mar 2012 12:29:14.0394 (UTC) FILETIME=[3CFAA7A0:01CCFDF0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2435 X-purgate-ID: 151667::1331296161-000044A2-092BB47A/0-0/0-0 Subject: Re: [Ecrit] Phonebcp issues 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, 09 Mar 2012 12:29:23 -0000 Hi Gunnar,=20 Hi all,=20 I agree with you regarding the dependency to the media loopback = document.=20 The required functionality for PhoneBCP is actually pretty simple.=20 I would be in favor of untangling the dependency to = draft-ietf-mmusic-media-loopback.=20 For the SRTP media security I would suggest to go for MUST implement = SDES and SHOULD implement DTLS-SRTP.=20 Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Gunnar Hellstr=F6m > Sent: Friday, March 09, 2012 1:26 PM > To: Ecrit > Subject: [Ecrit] Phonebcp issues >=20 > The final publication of draft-ietf-ecrit-phonebcp has now been = hanging > waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized > because it is referenced in the test section. > The status of the media-loopback draft is that it seems to be less > ready > now than 7 months ago. >=20 > This makes in fact even RFC 6443 impossible to implement, because RFC > 6443 refers to phonebcp for specification of the testing procedure >=20 > I wonder if it is time to pull phonebcp loose from the dependency of > the > media-loopback draft and specify a simple test method of its own > instead. I do not think that the current specification in phonebcp is > very realistic, with just a loopback. I think the test server could > just > as well generate some own initial test media and then possibly also > mirror some packets when received. The current behavior of the > media-loopback to wait for incoming media before it generates any > outgoing media is not similar to what will be the scenario in real > calls. Both sides in real calls normally take initiative to media > transmission after the session is established. The resulting problems > for NAT traversal of the current media-loopback draft is one of the > issues that has caused its delay. >=20 > Another small issue: RFC 6443 recommends SRTP to be used for media > security, but phonebcp does not mention media security. > phonebcp is approved, so I do not think it is appropriate to open it > for > such additions. Can this gap be covered in some additional draft, or > can > we rely on implementors to apply both phonebcp and RFC 6443? >=20 > Gunnar > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Fri Mar 9 08:19:22 2012 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 F165D21F8699 for ; Fri, 9 Mar 2012 08:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 9cI30PqQZkYK for ; Fri, 9 Mar 2012 08:19:22 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 6132E21F85D5 for ; Fri, 9 Mar 2012 08:19:19 -0800 (PST) X-ASG-Debug-ID: 1331309958-0491e5108e268a40001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id LRjRg62chHjadUQ0; Fri, 09 Mar 2012 08:19:18 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.41]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S62XF-000zRh-CW; Fri, 09 Mar 2012 08:19:17 -0800 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Phonebcp issues Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> Date: Fri, 9 Mar 2012 11:19:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1331309958 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.90726 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Ecrit Subject: Re: [Ecrit] Phonebcp issues 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, 09 Mar 2012 16:19:23 -0000 To do this, we would have to take the document back into the working = group, make changes, and run through the approval process. I think this is something we should consult with ADs before we do = anything. I don't have a problem with making the changes. I'm just looking for = the path of least resistance. Brian On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Gunnar,=20 > Hi all,=20 >=20 > I agree with you regarding the dependency to the media loopback = document.=20 > The required functionality for PhoneBCP is actually pretty simple.=20 >=20 > I would be in favor of untangling the dependency to = draft-ietf-mmusic-media-loopback.=20 >=20 > For the SRTP media security I would suggest to go for MUST implement = SDES and SHOULD implement DTLS-SRTP.=20 >=20 > Ciao > Hannes >=20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf >> Of ext Gunnar Hellstr=F6m >> Sent: Friday, March 09, 2012 1:26 PM >> To: Ecrit >> Subject: [Ecrit] Phonebcp issues >>=20 >> The final publication of draft-ietf-ecrit-phonebcp has now been = hanging >> waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized >> because it is referenced in the test section. >> The status of the media-loopback draft is that it seems to be less >> ready >> now than 7 months ago. >>=20 >> This makes in fact even RFC 6443 impossible to implement, because RFC >> 6443 refers to phonebcp for specification of the testing procedure >>=20 >> I wonder if it is time to pull phonebcp loose from the dependency of >> the >> media-loopback draft and specify a simple test method of its own >> instead. I do not think that the current specification in phonebcp is >> very realistic, with just a loopback. I think the test server could >> just >> as well generate some own initial test media and then possibly also >> mirror some packets when received. The current behavior of the >> media-loopback to wait for incoming media before it generates any >> outgoing media is not similar to what will be the scenario in real >> calls. Both sides in real calls normally take initiative to media >> transmission after the session is established. The resulting problems >> for NAT traversal of the current media-loopback draft is one of the >> issues that has caused its delay. >>=20 >> Another small issue: RFC 6443 recommends SRTP to be used for media >> security, but phonebcp does not mention media security. >> phonebcp is approved, so I do not think it is appropriate to open it >> for >> such additions. Can this gap be covered in some additional draft, or >> can >> we rely on implementors to apply both phonebcp and RFC 6443? >>=20 >> Gunnar >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Hannes.Tschofenig@gmx.net Sun Mar 11 04:27:05 2012 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 A4ACB21F8657 for ; Sun, 11 Mar 2012 04:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ixPqwvMcTZ3g for ; Sun, 11 Mar 2012 04:27:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9D8F821F865A for ; Sun, 11 Mar 2012 04:27:04 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 11:27:02 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp072) with SMTP; 11 Mar 2012 12:27:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181ZVN7HZA1GcsdkHcRW1Opin0qtIcyrs/AX2xslD 7cHZ/rGmETizJc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <4F461734.4050306@it.aoyama.ac.jp> Date: Sun, 11 Mar 2012 13:26:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2E64D9-9809-4D75-ABEC-3540F51F30CE@gmx.net> References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org, "apps-discuss@ietf.org" , hgs+ecrit@cs.columbia.edu, Peter Saint-Andre Subject: Re: [Ecrit] review of draft-ietf-ecrit-lost-sync-12 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, 11 Mar 2012 11:27:05 -0000 Hi Martin,=20 I understand the desire for namespace economy. In this specific case we are defining a new protocol that incorporates = elements from * OGC - a different organization who defined the Geography Markup = Langugage. This is used for the geodetic location information. * IETF GEOPRIV working group - this includes the civic location format. * IETF ECRIT working group - this includes the prior work on LoST. We = re-use one element from the LoST protocol (namely the = element). While it is possible to avoid defining a new namespace for this protocol = I believe it will lead to confusion.=20 Of course IANA needs to define a new namespace but this is not a huge = overhead.=20 When extending the LoST Sync protocol with new elements one could think = about the approach you suggest below, namely to just define new elements = without defining a new namespace. Then, the group who defines that = extension needs to take care that they do not define attributes and = elements with colliding names (given that there is no registry defined = either). =20 Ciao Hannes =20 On Feb 23, 2012, at 12:38 PM, Martin J. D=FCrst wrote: > Hello Peter, others, >=20 > On 2012/02/23 6:55, Peter Saint-Andre wrote: >> Robert Sparks asked me to think about the namespaces issue... >>=20 >>> -------- Original Message -------- Subject: Re: review of >>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 = 11:17:10 +0200 >>> From: Hannes Tschofenig To: = "Martin J. >>> D=FCrst" CC: Hannes Tschofenig >>> , Henning Schulzrinne >>> , Marc Linsner, >>> Robert Sparks, "apps-review@ietf.org" >>> , ecrit@ietf.org >>>=20 >>>=20 >>>> =46rom Martin: >>>=20 >>>> Namespaces: It is overkill to define new namespaces for each spec. >>>> It's a well-known secret in the XML community that it's easily >>>> possible to add a number of new elements to an existing namespace. >>>> This would be very appropriate in this case, because the number of >>>> reused elements and attributes is quite large, and the number of >>>> new elements is low. This would simplify most of the examples. >>>=20 >>> I guess you refer to the namespace registration in the IANA >>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>>=20 >>> In the RAI area we have (to my knowledge) always created new >>> namespaces for new schemas. But I am pleased to hear that this is = not >>> needed. >>>=20 >>> Could you explain what we should be doing instead? >=20 > Rather than define a new namespace lostsync1, just add the few = elements you defined anew to the lost1 namespace. It will make the = format simpler, and it won't hurt. >=20 >> I don't see a problem with defining a new namespace for each = iteration >> of an XML format (lostsync1, lostsync2, etc.), >=20 > There's no 'problem' with defining a separate namespace for each = element. Correct software should still work. But it's not really = necessary, it's tedious for human users and just overkill. >=20 >> because I don't think >> there's a general case here -- backward compatibility can depend on = the >> community of interest. One community might be doing strict schema >> checking, so that any new elements or attributes would be = problematic. >> By contrast, another community might be more lax in its processing >> because they specify that applications must ignore unknown elements = and >> attributes, even those qualified by an existing namespace. >=20 > Validation is largely independent of namespaces. There are some = problems with validating documents with more than one namespace, = depending on the technology (I'd have to look up the details), but there = are NO issues, with any of the validating technologies around (DTDs, XML = Schema, Relaxing, Schematron), when having only one namespace and = validating against subsets thereof. >=20 > W3C technologies regularly do that (XHTML and SVG are the examples I = know best). Way, way back there was a heated discussion in the XML = community about whether a new namespace would make sense for a new = version of XHTML, and this was strongly and utterly rejected. The way it = was put most prominently was "a

is a

is a

". >=20 > Validation is not only different for versions, but as you have = explained also for various other purposes. Some applications may use = validation to introduce further restrictions (e.g. for security reasons = in certain places), and so on. >=20 > A new namespace for a new version only make sense if the old and the = new version are something completely different, with essentially no = common elements and no documents that would be acceptable in both = versions. For other cases, using separate namespaces just increases = clutter without contributing anything. >=20 > The same is the case here. The proposed "lostsync1" namespace doesn't = contain many elements, and is only useful together with the "lost1" = namespace. That's of course unless the people in charge of the LOST = protocol and the people who came up with LOSTSYNC totally distrust each = other, but I was just assuming that's not the case :-). >=20 > Regards, Martin. From internet-drafts@ietf.org Sun Mar 11 04:28:42 2012 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 9079C21F8496; Sun, 11 Mar 2012 04:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 RhtllEE4aIrx; Sun, 11 Mar 2012 04:28:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239DA21F845F; Sun, 11 Mar 2012 04:28:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120311112842.25317.5251.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 04:28:42 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-sync-17.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: Sun, 11 Mar 2012 11:28:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Pro= tocol based Service Boundaries and Mapping Elements Author(s) : Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-lost-sync-17.txt Pages : 29 Date : 2012-03-11 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-17.txt From hannes.tschofenig@gmx.net Sun Mar 11 08:13:59 2012 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 F132021F8623 for ; Sun, 11 Mar 2012 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 xUCNKEpouFRV for ; Sun, 11 Mar 2012 08:13:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DED1221F8607 for ; Sun, 11 Mar 2012 08:13:57 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 15:13:53 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 11 Mar 2012 16:13:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19lghAkhLtltvgEU+fawGuJr4YMi7goLPmEDdNxzG 9DabPHN6hOfUsV Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Sun, 11 Mar 2012 17:13:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Ecrit Subject: Re: [Ecrit] Phonebcp issues 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, 11 Mar 2012 15:13:59 -0000 Going back to the working group is indeed a difficult issue. I have = experienced that already within the GEOPRIV working group and it stalled = the work for years. I do, however, wonder whether this is entirely = necessary. Isn't there a shorter route where the working group needs to = approve the change of the issue. I would even be OK with saying that = this entire media loopback functionality is optional and to turn it into = an informative reference.=20 Another option is to "motivate" the authors of = draft-ietf-mmusic-media-loopback to get their work done. There are = unfortunately 6 authors on that document and without knowing the history = I could imagine that nobody feels responsible for pushing it forward.=20 In any case, we need to do something. Just waiting isn't an option.=20 On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: > To do this, we would have to take the document back into the working = group, make changes, and run through the approval process. >=20 > I think this is something we should consult with ADs before we do = anything. >=20 > I don't have a problem with making the changes. I'm just looking for = the path of least resistance. >=20 > Brian >=20 > On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >=20 >> Hi Gunnar,=20 >> Hi all,=20 >>=20 >> I agree with you regarding the dependency to the media loopback = document.=20 >> The required functionality for PhoneBCP is actually pretty simple.=20 >>=20 >> I would be in favor of untangling the dependency to = draft-ietf-mmusic-media-loopback.=20 >>=20 >> For the SRTP media security I would suggest to go for MUST implement = SDES and SHOULD implement DTLS-SRTP.=20 >>=20 >> Ciao >> Hannes >>=20 >>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf >>> Of ext Gunnar Hellstr=F6m >>> Sent: Friday, March 09, 2012 1:26 PM >>> To: Ecrit >>> Subject: [Ecrit] Phonebcp issues >>>=20 >>> The final publication of draft-ietf-ecrit-phonebcp has now been = hanging >>> waiting 7 months for draft-ietf-mmusic-media-loopback to be = finalized >>> because it is referenced in the test section. >>> The status of the media-loopback draft is that it seems to be less >>> ready >>> now than 7 months ago. >>>=20 >>> This makes in fact even RFC 6443 impossible to implement, because = RFC >>> 6443 refers to phonebcp for specification of the testing procedure >>>=20 >>> I wonder if it is time to pull phonebcp loose from the dependency of >>> the >>> media-loopback draft and specify a simple test method of its own >>> instead. I do not think that the current specification in phonebcp = is >>> very realistic, with just a loopback. I think the test server could >>> just >>> as well generate some own initial test media and then possibly also >>> mirror some packets when received. The current behavior of the >>> media-loopback to wait for incoming media before it generates any >>> outgoing media is not similar to what will be the scenario in real >>> calls. Both sides in real calls normally take initiative to media >>> transmission after the session is established. The resulting = problems >>> for NAT traversal of the current media-loopback draft is one of the >>> issues that has caused its delay. >>>=20 >>> Another small issue: RFC 6443 recommends SRTP to be used for media >>> security, but phonebcp does not mention media security. >>> phonebcp is approved, so I do not think it is appropriate to open it >>> for >>> such additions. Can this gap be covered in some additional draft, or >>> can >>> we rely on implementors to apply both phonebcp and RFC 6443? >>>=20 >>> Gunnar >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Sun Mar 11 11:01:18 2012 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 75E4A21F8664; Sun, 11 Mar 2012 11:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Olu-YMEsudPR; Sun, 11 Mar 2012 11:01:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8CB21F85F6; Sun, 11 Mar 2012 11:01:17 -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.00 Message-ID: <20120311180117.25668.7657.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 11:01:17 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-04.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: Sun, 11 Mar 2012 18:01:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-04.txt Pages : 23 Date : 2012-03-11 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. Note that this version of the document does not yet specify a solution due to the lack of the working group participants agreeing on the requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-psap-callback-04.txt From hannes.tschofenig@gmx.net Sun Mar 11 11:22:59 2012 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 1E0D021F8721 for ; Sun, 11 Mar 2012 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 kkqZPG6VxkBj for ; Sun, 11 Mar 2012 11:22:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 025C621F871E for ; Sun, 11 Mar 2012 11:22:57 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 18:22:56 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp012) with SMTP; 11 Mar 2012 19:22:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+iYes+XxOi+VddCchY9uU07d6ParJZBoLxzdWgDF pnX4nYyoftrZa1 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 20:22:55 +0200 Message-Id: To: Ecrit Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] My summary of the PSAP Callback Discussions 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, 11 Mar 2012 18:22:59 -0000 Hi all,=20 I read through the long, long email PSAP callback discussions and I have = to agree with the observation Henning made:=20 The list of requirements and design constraints do not lead to a single = solution.=20 Without going through the list of requirements and scenarios (again) I = thought it would be worthwhile to point out that we have a working group = document that provides all the necessary background, requirements, and = scenarios. Not everyone of you may have been aware of that document.=20 Here is the pointer:=20 http://tools.ietf.org/id/draft-ietf-ecrit-psap-callback-04.txt If you look at the document you will notice that=20 1) there is also a basic solution specified in PhoneBCP. It works in = certain scenarios. 2) there are scenarios in the draft where the currently specified = solution does not work. These include cases with routing asymmetry, = i.e., the PSAP callback messages do not just use the reverse path of the = original emergency call. In such a case sending a nonce (or token, or = however you want to call it) in the initial emergency call will not help = with the callback (since the state is allocated at the wrong entities).=20= Ciao Hannes From br@brianrosen.net Sun Mar 11 11:24:01 2012 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 37CD321F869D for ; Sun, 11 Mar 2012 11:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 fVxKT7qLTRGL for ; Sun, 11 Mar 2012 11:24:00 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDBF21F869A for ; Sun, 11 Mar 2012 11:24:00 -0700 (PDT) X-ASG-Debug-ID: 1331490239-0491e543d5122520001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id Z5xHOrDHe4Snon1M; Sun, 11 Mar 2012 11:23:59 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.11]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S6nR0-002KSr-S5; Sun, 11 Mar 2012 11:23:59 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Phonebcp issues Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> Date: Sun, 11 Mar 2012 14:23:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1331490239 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.90926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Ecrit Subject: Re: [Ecrit] Phonebcp issues 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, 11 Mar 2012 18:24:01 -0000 It's a pretty key capability, given NATs and other middle boxes, to make = sure the media path will work. It's optional, but it's very useful. I don't see how you could make any kind of normative change without WG = consensus to the change, and that would need a review cycle, I sent a query into Hadriel Kaplan, who was appointed by the WG chairs = to get the document out the door. I'll let you know what I find out. Brian On Mar 11, 2012, at 11:13 AM, Hannes Tschofenig wrote: > Going back to the working group is indeed a difficult issue. I have = experienced that already within the GEOPRIV working group and it stalled = the work for years. I do, however, wonder whether this is entirely = necessary. Isn't there a shorter route where the working group needs to = approve the change of the issue. I would even be OK with saying that = this entire media loopback functionality is optional and to turn it into = an informative reference.=20 >=20 > Another option is to "motivate" the authors of = draft-ietf-mmusic-media-loopback to get their work done. There are = unfortunately 6 authors on that document and without knowing the history = I could imagine that nobody feels responsible for pushing it forward.=20 >=20 > In any case, we need to do something. Just waiting isn't an option.=20 >=20 > On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: >=20 >> To do this, we would have to take the document back into the working = group, make changes, and run through the approval process. >>=20 >> I think this is something we should consult with ADs before we do = anything. >>=20 >> I don't have a problem with making the changes. I'm just looking for = the path of least resistance. >>=20 >> Brian >>=20 >> On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: >>=20 >>> Hi Gunnar,=20 >>> Hi all,=20 >>>=20 >>> I agree with you regarding the dependency to the media loopback = document.=20 >>> The required functionality for PhoneBCP is actually pretty simple.=20= >>>=20 >>> I would be in favor of untangling the dependency to = draft-ietf-mmusic-media-loopback.=20 >>>=20 >>> For the SRTP media security I would suggest to go for MUST implement = SDES and SHOULD implement DTLS-SRTP.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf >>>> Of ext Gunnar Hellstr=F6m >>>> Sent: Friday, March 09, 2012 1:26 PM >>>> To: Ecrit >>>> Subject: [Ecrit] Phonebcp issues >>>>=20 >>>> The final publication of draft-ietf-ecrit-phonebcp has now been = hanging >>>> waiting 7 months for draft-ietf-mmusic-media-loopback to be = finalized >>>> because it is referenced in the test section. >>>> The status of the media-loopback draft is that it seems to be less >>>> ready >>>> now than 7 months ago. >>>>=20 >>>> This makes in fact even RFC 6443 impossible to implement, because = RFC >>>> 6443 refers to phonebcp for specification of the testing procedure >>>>=20 >>>> I wonder if it is time to pull phonebcp loose from the dependency = of >>>> the >>>> media-loopback draft and specify a simple test method of its own >>>> instead. I do not think that the current specification in phonebcp = is >>>> very realistic, with just a loopback. I think the test server could >>>> just >>>> as well generate some own initial test media and then possibly also >>>> mirror some packets when received. The current behavior of the >>>> media-loopback to wait for incoming media before it generates any >>>> outgoing media is not similar to what will be the scenario in real >>>> calls. Both sides in real calls normally take initiative to media >>>> transmission after the session is established. The resulting = problems >>>> for NAT traversal of the current media-loopback draft is one of the >>>> issues that has caused its delay. >>>>=20 >>>> Another small issue: RFC 6443 recommends SRTP to be used for media >>>> security, but phonebcp does not mention media security. >>>> phonebcp is approved, so I do not think it is appropriate to open = it >>>> for >>>> such additions. Can this gap be covered in some additional draft, = or >>>> can >>>> we rely on implementors to apply both phonebcp and RFC 6443? >>>>=20 >>>> Gunnar >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From hannes.tschofenig@gmx.net Sun Mar 11 11:28:19 2012 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 BA1D521F86D8 for ; Sun, 11 Mar 2012 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 uJKCOW92WdGi for ; Sun, 11 Mar 2012 11:28:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6396521F86BB for ; Sun, 11 Mar 2012 11:28:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 18:28:16 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp039) with SMTP; 11 Mar 2012 19:28:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/NZgg9n/XNltye8lG4oIUwehAxBRvLCZrziG1H6T LDrq7ekZMVcz86 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 20:28:15 +0200 Message-Id: To: Ecrit Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] My PSAP Callback Observations 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, 11 Mar 2012 18:28:19 -0000 Hi all,=20 A few other observations from my side (based on the discussions): a) Conveying a resource priority header to deal with congestion = situations is largely orthogonal to the discussion of the PSAP callback = solution since RPH may be used with any call.=20 b) GRUU is used independently of the discussed PSAP callback solution. = PhoneBCP also makes use of a GRUU when it is available.=20 c) There are various mechanism to convey a random number that is unique = to a call. Proposals I have seen on the list are: new header specific to = emergency calls, media feature tag, In-Reply-To, etc. All of these = identifiers will have problems with SBCs in some form or the other. d) There is the desire to give preferential treatment for callbacks only = for a certain time. The exact time will be difficult to specify but we = could, for example, suggest a minimum.=20 e) I took a look at = http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 = and thought that it was an interesting idea for those cases where the = "random number that is unique for a call" does not work. I believe it is = a better solution than a pure identity-based authorization attempt since = it will not be bound to an earlier emergency call.=20 Ciao Hannes From Hannes.Tschofenig@gmx.net Sun Mar 11 11:34:23 2012 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 5F85921F862A for ; Sun, 11 Mar 2012 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 cSQXyxkcEv9W for ; Sun, 11 Mar 2012 11:34:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 728A821F8608 for ; Sun, 11 Mar 2012 11:34:22 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 18:34:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 11 Mar 2012 19:34:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Uvu84sAMUyih8GfhKK6/GX3D2bcrFDs8jS3m/XD WKB8OAvxASIaXD From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 20:34:20 +0200 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Ecrit Org Subject: [Ecrit] Status of draft-ietf-mmusic-media-loopback? 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, 11 Mar 2012 18:34:23 -0000 Hey guys,=20 in the ECRIT working group we have a document called PhoneBCP, see = http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/, which has a = normative dependency on draft-ietf-mmusic-media-loopback. It is waiting = for a while already and we are getting nervous.=20 We are wondering what the status of your document is? Are there open = issues? What are the planned next steps to finish it?=20 Ciao Hannes From gunnar.hellstrom@omnitor.se Sun Mar 11 12:07:52 2012 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 3EA9921F86CA for ; Sun, 11 Mar 2012 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 XjJHTeJMu+SD for ; Sun, 11 Mar 2012 12:07:51 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id DF2E621F86C8 for ; Sun, 11 Mar 2012 12:07:50 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 11 Mar 2012 20:07:40 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id EE7953A100 for ; Sun, 11 Mar 2012 20:07:39 +0100 (CET) Message-ID: <4F5CF7F4.9030503@omnitor.se> Date: Sun, 11 Mar 2012 20:07:32 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Phonebcp issues 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, 11 Mar 2012 19:07:52 -0000 I have an initial text proposal for phonebcp, to use to release the media-loopback dependency. I made the media transfer much longer that the three packets originally indicated in the current draft. I think that is needed to make the test usaful, but the use and effect of that may be discussed. Current wording: -------------------------- ED-80 A PSAP accepting a test call SHOULD accept a media loopback test [I-D.ietf-mmusic-media-loopback ] and SHOULD support the "rtp- pkt-loopback" and "rtp-start-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User Agents should expect the PSAP to loop back no more than 3 packets of each media type accepted (which limits the duration of the test), after which the PSAP would normally send BYE. ----------------------------------------- Change proposal _______________________. ED-80 A PSAP accepting a test call SHOULD accept all media in the offer for which it has coresponding codecs. Both the PSAP and the User Agent SHOULD send media contents until 500 ms after the session establishment was completed. From the moment when the PSAP receives media contents from the User Agent, the received media contents shall be looped back to the User Agent. RTCP reports shall be sent before the PSAP ends the test call by sending BYE. If the User Agent does not receive a BYE within 35 seconds after it sent its ACK, then the User Agent SHALL end the call by sending BYE. /Gunnar Brian Rosen skrev 2012-03-11 19:23: > It's a pretty key capability, given NATs and other middle boxes, to make sure the media path will work. It's optional, but it's very useful. > > I don't see how you could make any kind of normative change without WG consensus to the change, and that would need a review cycle, > > I sent a query into Hadriel Kaplan, who was appointed by the WG chairs to get the document out the door. > > I'll let you know what I find out. > > Brian > > On Mar 11, 2012, at 11:13 AM, Hannes Tschofenig wrote: > >> Going back to the working group is indeed a difficult issue. I have experienced that already within the GEOPRIV working group and it stalled the work for years. I do, however, wonder whether this is entirely necessary. Isn't there a shorter route where the working group needs to approve the change of the issue. I would even be OK with saying that this entire media loopback functionality is optional and to turn it into an informative reference. >> >> Another option is to "motivate" the authors of draft-ietf-mmusic-media-loopback to get their work done. There are unfortunately 6 authors on that document and without knowing the history I could imagine that nobody feels responsible for pushing it forward. >> >> In any case, we need to do something. Just waiting isn't an option. >> >> On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: >> >>> To do this, we would have to take the document back into the working group, make changes, and run through the approval process. >>> >>> I think this is something we should consult with ADs before we do anything. >>> >>> I don't have a problem with making the changes. I'm just looking for the path of least resistance. >>> >>> Brian >>> >>> On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> >>>> Hi Gunnar, >>>> Hi all, >>>> >>>> I agree with you regarding the dependency to the media loopback document. >>>> The required functionality for PhoneBCP is actually pretty simple. >>>> >>>> I would be in favor of untangling the dependency to draft-ietf-mmusic-media-loopback. >>>> >>>> For the SRTP media security I would suggest to go for MUST implement SDES and SHOULD implement DTLS-SRTP. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>>> Of ext Gunnar Hellström >>>>> Sent: Friday, March 09, 2012 1:26 PM >>>>> To: Ecrit >>>>> Subject: [Ecrit] Phonebcp issues >>>>> >>>>> The final publication of draft-ietf-ecrit-phonebcp has now been hanging >>>>> waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized >>>>> because it is referenced in the test section. >>>>> The status of the media-loopback draft is that it seems to be less >>>>> ready >>>>> now than 7 months ago. >>>>> >>>>> This makes in fact even RFC 6443 impossible to implement, because RFC >>>>> 6443 refers to phonebcp for specification of the testing procedure >>>>> >>>>> I wonder if it is time to pull phonebcp loose from the dependency of >>>>> the >>>>> media-loopback draft and specify a simple test method of its own >>>>> instead. I do not think that the current specification in phonebcp is >>>>> very realistic, with just a loopback. I think the test server could >>>>> just >>>>> as well generate some own initial test media and then possibly also >>>>> mirror some packets when received. The current behavior of the >>>>> media-loopback to wait for incoming media before it generates any >>>>> outgoing media is not similar to what will be the scenario in real >>>>> calls. Both sides in real calls normally take initiative to media >>>>> transmission after the session is established. The resulting problems >>>>> for NAT traversal of the current media-loopback draft is one of the >>>>> issues that has caused its delay. >>>>> >>>>> Another small issue: RFC 6443 recommends SRTP to be used for media >>>>> security, but phonebcp does not mention media security. >>>>> phonebcp is approved, so I do not think it is appropriate to open it >>>>> for >>>>> such additions. Can this gap be covered in some additional draft, or >>>>> can >>>>> we rely on implementors to apply both phonebcp and RFC 6443? >>>>> >>>>> Gunnar >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Sun Mar 11 13:47:12 2012 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 6396F21F8749 for ; Sun, 11 Mar 2012 13:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.908 X-Spam-Level: X-Spam-Status: No, score=-108.908 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 tRXPsBYTNK4A for ; Sun, 11 Mar 2012 13:47:11 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 740CA21F8748 for ; Sun, 11 Mar 2012 13:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7230; q=dns/txt; s=iport; t=1331498831; x=1332708431; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=Jo9qsF7UtiTqPvbBnuSjXbzvP7UbGQ43LiHHxaspN0Y=; b=BQw3Qf6Muj1AfCu3bN4MOYgqZ9n3MrhSbnlkqQGhiAe5y1zpbg6KnXef h/BxFdy7ncoOOKWoxCerbpmsBjSpSGAPuZxWR5SHPJmzfLrFmfuHMxodK KzhBNIT76UGgy6kuy7sVC/laIMiWytgFkA9wsH0rIoWxCIMoy7wQbv85v k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB8PXU+rRDoJ/2dsb2JhbABBtVKBB4IJAQEBBAEBAQ8BJTYXBAcEEQQBAQEnBxkOHwkIBgEJCSKHZwyfbQGWBQSRAQSIITOdG4MBgTYF X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="33054174" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Mar 2012 20:46:54 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2BKkswf012498; Sun, 11 Mar 2012 20:46:54 GMT Message-Id: <201203112046.q2BKkswf012498@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 11 Mar 2012 15:46:52 -0500 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , ecrit@ietf.org From: "James M. Polk" In-Reply-To: <4F5CF7F4.9030503@omnitor.se> References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> <4F5CF7F4.9030503@omnitor.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Phonebcp issues 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, 11 Mar 2012 20:47:12 -0000 IMO removing a normative dependency from a draft=20 will force going through the WG and IESG again... James (a coauthor of phonebcp) At 02:07 PM 3/11/2012, Gunnar Hellstr=F6m wrote: >I have an initial text proposal for phonebcp, to=20 >use to release the media-loopback dependency. >I made the media transfer much longer that the=20 >three packets originally indicated in the=20 >current draft. I think that is needed to make=20 >the test usaful, but the use and effect of that may be discussed. > >Current wording: >-------------------------- > > > ED-80 A PSAP accepting a test call SHOULD accept a media loopback > test=20 > [I-D.ietf-mmusic-media-loopback=20 >= ]=20 > and SHOULD support the "rtp- > pkt-loopback" and "rtp-start-loopback" options. The user agent would > specify a loopback attribute of "loopback-source", the PSAP being the > mirror. User Agents should expect the PSAP to loop back no more than > 3 packets of each media type accepted (which limits the duration of > the test), after which the PSAP would normally send BYE. > >----------------------------------------- > >Change proposal >_______________________. > >ED-80 A PSAP accepting a test call SHOULD accept=20 >all media in the offer for which it has=20 >coresponding codecs. Both the PSAP and the User=20 >Agent SHOULD send media contents until 500 ms=20 >after the session establishment was completed.=20 > From the moment when the PSAP receives media=20 >contents from the User Agent, the received media=20 >contents shall be looped back to the User Agent.=20 >RTCP reports shall be sent before the PSAP ends=20 >the test call by sending BYE. If the User Agent=20 >does not receive a BYE within 35 seconds after=20 >it sent its ACK, then the User Agent SHALL end the call by sending BYE. > > >/Gunnar > > >Brian Rosen skrev 2012-03-11 19:23: >>It's a pretty key capability, given NATs and=20 >>other middle boxes, to make sure the media path=20 >>will work. It's optional, but it's very useful. >> >>I don't see how you could make any kind of=20 >>normative change without WG consensus to the=20 >>change, and that would need a review cycle, >> >>I sent a query into Hadriel Kaplan, who was=20 >>appointed by the WG chairs to get the document out the door. >> >>I'll let you know what I find out. >> >>Brian >> >>On Mar 11, 2012, at 11:13 AM, Hannes Tschofenig wrote: >> >>>Going back to the working group is indeed a=20 >>>difficult issue. I have experienced that=20 >>>already within the GEOPRIV working group and=20 >>>it stalled the work for years. I do, however,=20 >>>wonder whether this is entirely necessary.=20 >>>Isn't there a shorter route where the working=20 >>>group needs to approve the change of the=20 >>>issue. I would even be OK with saying that=20 >>>this entire media loopback functionality is=20 >>>optional and to turn it into an informative reference. >>> >>>Another option is to "motivate" the authors of=20 >>>draft-ietf-mmusic-media-loopback to get their=20 >>>work done. There are unfortunately 6 authors=20 >>>on that document and without knowing the=20 >>>history I could imagine that nobody feels responsible for pushing it= forward. >>> >>>In any case, we need to do something. Just waiting isn't an option. >>> >>>On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: >>> >>>>To do this, we would have to take the=20 >>>>document back into the working group, make=20 >>>>changes, and run through the approval process. >>>> >>>>I think this is something we should consult with ADs before we do= anything. >>>> >>>>I don't have a problem with making the=20 >>>>changes. I'm just looking for the path of least resistance. >>>> >>>>Brian >>>> >>>>On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>> >>>>>Hi Gunnar, >>>>>Hi all, >>>>> >>>>>I agree with you regarding the dependency to the media loopback= document. >>>>>The required functionality for PhoneBCP is actually pretty simple. >>>>> >>>>>I would be in favor of untangling the=20 >>>>>dependency to draft-ietf-mmusic-media-loopback. >>>>> >>>>>For the SRTP media security I would suggest=20 >>>>>to go for MUST implement SDES and SHOULD implement DTLS-SRTP. >>>>> >>>>>Ciao >>>>>Hannes >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>>>>Of ext Gunnar Hellstr=F6m >>>>>>Sent: Friday, March 09, 2012 1:26 PM >>>>>>To: Ecrit >>>>>>Subject: [Ecrit] Phonebcp issues >>>>>> >>>>>>The final publication of draft-ietf-ecrit-phonebcp has now been= hanging >>>>>>waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized >>>>>>because it is referenced in the test section. >>>>>>The status of the media-loopback draft is that it seems to be less >>>>>>ready >>>>>>now than 7 months ago. >>>>>> >>>>>>This makes in fact even RFC 6443 impossible to implement, because RFC >>>>>>6443 refers to phonebcp for specification of the testing procedure >>>>>> >>>>>>I wonder if it is time to pull phonebcp loose from the dependency of >>>>>>the >>>>>>media-loopback draft and specify a simple test method of its own >>>>>>instead. I do not think that the current specification in phonebcp is >>>>>>very realistic, with just a loopback. I think the test server could >>>>>>just >>>>>>as well generate some own initial test media and then possibly also >>>>>>mirror some packets when received. The current behavior of the >>>>>>media-loopback to wait for incoming media before it generates any >>>>>>outgoing media is not similar to what will be the scenario in real >>>>>>calls. Both sides in real calls normally take initiative to media >>>>>>transmission after the session is established. The resulting problems >>>>>>for NAT traversal of the current media-loopback draft is one of the >>>>>>issues that has caused its delay. >>>>>> >>>>>>Another small issue: RFC 6443 recommends SRTP to be used for media >>>>>>security, but phonebcp does not mention media security. >>>>>>phonebcp is approved, so I do not think it is appropriate to open it >>>>>>for >>>>>>such additions. Can this gap be covered in some additional draft, or >>>>>>can >>>>>>we rely on implementors to apply both phonebcp and RFC 6443? >>>>>> >>>>>>Gunnar >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www.ietf.org/mailman/listinfo/ecrit >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Mon Mar 12 09:13:11 2012 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 1FA3A21F8813 for ; Mon, 12 Mar 2012 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 wUZXmYu+oW1E for ; Mon, 12 Mar 2012 09:13:10 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 103AB21F8810 for ; Mon, 12 Mar 2012 09:13:10 -0700 (PDT) X-ASG-Debug-ID: 1331568788-04d0353fba29ef0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id pgwaJLfWzOdFS27Z; Mon, 12 Mar 2012 09:13:08 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.21]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S77rv-002OFV-NL; Mon, 12 Mar 2012 09:13:08 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Phonebcp issues Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: Date: Mon, 12 Mar 2012 12:13:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> To: Brian Rosen X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1331568788 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91012 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Ecrit Subject: Re: [Ecrit] Phonebcp issues 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, 12 Mar 2012 16:13:11 -0000 Hadriel says there will be a new version of media-loopback today. Brian On Mar 11, 2012, at 2:23 PM, Brian Rosen wrote: > It's a pretty key capability, given NATs and other middle boxes, to = make sure the media path will work. It's optional, but it's very = useful. >=20 > I don't see how you could make any kind of normative change without WG = consensus to the change, and that would need a review cycle, >=20 > I sent a query into Hadriel Kaplan, who was appointed by the WG = chairs to get the document out the door. >=20 > I'll let you know what I find out. >=20 > Brian >=20 > On Mar 11, 2012, at 11:13 AM, Hannes Tschofenig wrote: >=20 >> Going back to the working group is indeed a difficult issue. I have = experienced that already within the GEOPRIV working group and it stalled = the work for years. I do, however, wonder whether this is entirely = necessary. Isn't there a shorter route where the working group needs to = approve the change of the issue. I would even be OK with saying that = this entire media loopback functionality is optional and to turn it into = an informative reference.=20 >>=20 >> Another option is to "motivate" the authors of = draft-ietf-mmusic-media-loopback to get their work done. There are = unfortunately 6 authors on that document and without knowing the history = I could imagine that nobody feels responsible for pushing it forward.=20 >>=20 >> In any case, we need to do something. Just waiting isn't an option.=20= >>=20 >> On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: >>=20 >>> To do this, we would have to take the document back into the working = group, make changes, and run through the approval process. >>>=20 >>> I think this is something we should consult with ADs before we do = anything. >>>=20 >>> I don't have a problem with making the changes. I'm just looking = for the path of least resistance. >>>=20 >>> Brian >>>=20 >>> On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: >>>=20 >>>> Hi Gunnar,=20 >>>> Hi all,=20 >>>>=20 >>>> I agree with you regarding the dependency to the media loopback = document.=20 >>>> The required functionality for PhoneBCP is actually pretty simple.=20= >>>>=20 >>>> I would be in favor of untangling the dependency to = draft-ietf-mmusic-media-loopback.=20 >>>>=20 >>>> For the SRTP media security I would suggest to go for MUST = implement SDES and SHOULD implement DTLS-SRTP.=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf >>>>> Of ext Gunnar Hellstr=F6m >>>>> Sent: Friday, March 09, 2012 1:26 PM >>>>> To: Ecrit >>>>> Subject: [Ecrit] Phonebcp issues >>>>>=20 >>>>> The final publication of draft-ietf-ecrit-phonebcp has now been = hanging >>>>> waiting 7 months for draft-ietf-mmusic-media-loopback to be = finalized >>>>> because it is referenced in the test section. >>>>> The status of the media-loopback draft is that it seems to be less >>>>> ready >>>>> now than 7 months ago. >>>>>=20 >>>>> This makes in fact even RFC 6443 impossible to implement, because = RFC >>>>> 6443 refers to phonebcp for specification of the testing procedure >>>>>=20 >>>>> I wonder if it is time to pull phonebcp loose from the dependency = of >>>>> the >>>>> media-loopback draft and specify a simple test method of its own >>>>> instead. I do not think that the current specification in phonebcp = is >>>>> very realistic, with just a loopback. I think the test server = could >>>>> just >>>>> as well generate some own initial test media and then possibly = also >>>>> mirror some packets when received. The current behavior of the >>>>> media-loopback to wait for incoming media before it generates any >>>>> outgoing media is not similar to what will be the scenario in real >>>>> calls. Both sides in real calls normally take initiative to media >>>>> transmission after the session is established. The resulting = problems >>>>> for NAT traversal of the current media-loopback draft is one of = the >>>>> issues that has caused its delay. >>>>>=20 >>>>> Another small issue: RFC 6443 recommends SRTP to be used for media >>>>> security, but phonebcp does not mention media security. >>>>> phonebcp is approved, so I do not think it is appropriate to open = it >>>>> for >>>>> such additions. Can this gap be covered in some additional draft, = or >>>>> can >>>>> we rely on implementors to apply both phonebcp and RFC 6443? >>>>>=20 >>>>> Gunnar >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Mar 12 13:00:30 2012 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 2C0C421E80CF; Mon, 12 Mar 2012 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 nv70RT4IifNF; Mon, 12 Mar 2012 13:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9407421E80C5; Mon, 12 Mar 2012 13:00:29 -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.00 Message-ID: <20120312200029.13730.58629.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:00:29 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-04.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: Mon, 12 Mar 2012 20:00:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-04.txt Pages : 26 Date : 2012-03-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-access= -04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-access-= 04.txt From internet-drafts@ietf.org Mon Mar 12 13:03:32 2012 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 120CC21E80E8; Mon, 12 Mar 2012 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 yDmRF9988oFJ; Mon, 12 Mar 2012 13:03:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9621E80D7; Mon, 12 Mar 2012 13:03:31 -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.00 Message-ID: <20120312200331.15473.81790.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:03:31 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-03.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: Mon, 12 Mar 2012 20:03:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Author(s) : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-03.txt Pages : 23 Date : 2012-03-12 RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions and in some rare cases they may require a session to be established. These type of interactions are called 'data-only emergency calls'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-data-only-ea-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-data-only-ea-03.txt From internet-drafts@ietf.org Mon Mar 12 16:56:10 2012 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 B705821E82A8; Mon, 12 Mar 2012 16:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 eVJRaDiHSx9S; Mon, 12 Mar 2012 16:56:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABAB21E829E; Mon, 12 Mar 2012 16:56:10 -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.00 Message-ID: <20120312235610.2810.30527.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:56:10 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-03.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: Mon, 12 Mar 2012 23:56:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Int= ernet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Filename : draft-ietf-ecrit-additional-data-03.txt Pages : 46 Date : 2012-03-12 When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-03.txt From br@brianrosen.net Tue Mar 13 06:16:57 2012 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 4528121F8763 for ; Tue, 13 Mar 2012 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 jhigywl9Bbjk for ; Tue, 13 Mar 2012 06:16:56 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8314921F8753 for ; Tue, 13 Mar 2012 06:16:56 -0700 (PDT) X-ASG-Debug-ID: 1331644615-0491e5229cf8840001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id PdYnH4QbXIjfpDs9 for ; Tue, 13 Mar 2012 06:16:55 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.21]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1S7Raw-003HDs-ST for ecrit@ietf.org; Tue, 13 Mar 2012 06:16:55 -0700 From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_9A98FCF3-D603-46AC-ABD0-16B0993B3CAF" Date: Tue, 13 Mar 2012 09:16:45 -0400 X-ASG-Orig-Subj: Fwd: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-03.txt References: <20120312235610.2810.30527.idtracker@ietfa.amsl.com> To: Ecrit Org Message-Id: <1E625CE6-014B-42DA-840B-E4C6C2073D47@brianrosen.net> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1331644615 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-03.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: Tue, 13 Mar 2012 13:16:57 -0000 --Apple-Mail=_9A98FCF3-D603-46AC-ABD0-16B0993B3CAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Authors have updated this draft mostly to address comments posted by = Matt Serra on behalf of NENA. There were no objections to these = comments, and we made most of them as requested. A few require some = more discussion. I particularly draw your attention to the comments = regarding who MUST/SHOULD/MAY send the data. I will raise this issue in = the Paris meeting, but please look at this version, and the comments = Matt sent and provide feedback. We did not quite finish the IANA registries section. There are some new comments that will come from NENA shortly. Authors = plan one more edit pass, which will include addressing all the notes in = the text. We are hopeful that we can request WGLC after the next = version. Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-03.txt > Date: March 12, 2012 7:56:10 PM EDT > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Emergency Context = Resolution with Internet Technologies Working Group of the IETF. >=20 > Title : Additional Data related to an Emergency Call > Author(s) : Brian Rosen > Hannes Tschofenig > Roger Marshall > Filename : draft-ietf-ecrit-additional-data-03.txt > Pages : 46 > Date : 2012-03-12 >=20 > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the device that sends it, as well as any service provider in > the path of the call, or access network may have information about > the call which the PSAP may be able to use. This document describes > an XML data structure that contains this kind of information in a > standardized form. A Uniform Resource Identifier (URI) that points > to the structure can be included in the SIP signaling with the call, > or the data may be included in the body of a SIP message. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-03.tx= t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-03.txt= >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_9A98FCF3-D603-46AC-ABD0-16B0993B3CAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Subject: [Ecrit] I-D Action: = draft-ietf-ecrit-additional-data-03.txt
Date: March 12, 2012 = 7:56:10 PM EDT


A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Emergency Context = Resolution with Internet Technologies Working Group of the = IETF.

= Title =           : Additional = Data related to an Emergency Call
Author(s) =       : Brian Rosen
=             &n= bsp;           &nbs= p;Hannes Tschofenig
=             &n= bsp;           &nbs= p;Roger Marshall
Filename =        : = draft-ietf-ecrit-additional-data-03.txt
Pages =           : = 46
= Date =            : = 2012-03-12

  When an emergency call is sent to a = Public Safety Answering Point
  (PSAP), the device that = sends it, as well as any service provider in
  the path of = the call, or access network may have information about
=   the call which the PSAP may be able to use.  This = document describes
  an XML data structure that contains = this kind of information in a
  standardized form.  A = Uniform Resource Identifier (URI) that points
  to the = structure can be included in the SIP signaling with the call,
=   or the data may be included in the body of a SIP = message.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional= -data-03.txt

Internet-Drafts are also available by anonymous = FTP at:
ftp://ftp.ietf.org/internet-drafts/

This = Internet-Draft can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data= -03.txt

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

= --Apple-Mail=_9A98FCF3-D603-46AC-ABD0-16B0993B3CAF-- From mlinsner@cisco.com Tue Mar 13 07:20:07 2012 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 4E15E21F88B6 for ; Tue, 13 Mar 2012 07:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[AWL=1.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 Kj4XjWv9PXHz for ; Tue, 13 Mar 2012 07:20:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C24A321F88B4 for ; Tue, 13 Mar 2012 07:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=976; q=dns/txt; s=iport; t=1331648406; x=1332858006; h=date:subject:from:to:message-id:mime-version; bh=pfEdhH8Aq3hTyFO5CHzCB48/hHCaIsZQGFGWREDHAoE=; b=ZcOjLdvNCRNPveR1ycAUl/a89FQJkMzXY14FdG5VGvqVtgTbJcua3zar oSC148NkbdueU2FesAEY18rfPXu8tOPVntRi+w9p4defS6MHCQmJUBvJw Ve/j286g8lFHUWnIfgYVQChqLpJaxoWIj6u6d9SY/EavSqSx/addPCnT4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAHNXX0+tJXG8/2dsb2JhbABDgkVEslSBB4IABQsSASpPCwECgR01hSYHgikSnFKBJwGNOJFQkGUElVCFaYo6gwE X-IronPort-AV: E=Sophos;i="4.73,577,1325462400"; d="scan'208,217";a="66050571" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 13 Mar 2012 14:20:06 +0000 Received: from [10.116.195.117] (rtp-mlinsner-8714.cisco.com [10.116.195.117]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DEK5dt025720 for ; Tue, 13 Mar 2012 14:20:05 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 13 Mar 2012 10:20:03 -0400 From: Marc Linsner To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: ECRIT - Paris Agenda Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414478806_317295" Subject: [Ecrit] ECRIT - Paris Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:20:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414478806_317295 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We've received a couple of requests for agenda time in Paris (Brian & Christer). If you expect to need time, let us know asap. -Marc, Richard, Roger- --B_3414478806_317295 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
We've received a couple of r= equests for agenda time in Paris (Brian & Christer).  If you expect= to need time, let us know asap.

-Marc, Richard, Ro= ger-
--B_3414478806_317295-- From hannes.tschofenig@nsn.com Tue Mar 13 07:20:18 2012 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 C3AD521F88D4 for ; Tue, 13 Mar 2012 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.381 X-Spam-Level: X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aEJvla8bC87P for ; Tue, 13 Mar 2012 07:20:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F32BF21F88B6 for ; Tue, 13 Mar 2012 07:20:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2DEKFa1008945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Mar 2012 15:20:16 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2DEK78m032602 for ; Tue, 13 Mar 2012 15:20:15 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 15:20:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 16:20:10 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01343903@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentation Request Thread-Index: Ac0BJGX60nPZM+ZzS7a5436bq/5LgA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Ecrit" X-OriginalArrivalTime: 13 Mar 2012 14:20:15.0210 (UTC) FILETIME=[68C984A0:01CD0124] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1426 X-purgate-ID: 151667::1331648416-000044A2-F5E6E5DD/0-0/0-0 Subject: [Ecrit] Presentation Request X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:20:18 -0000 Hey Chairs,=20 For the upcoming meeting would it be possible to get the following presentation slots: WG documents: * Additional Data (presenter Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/=20 The updated document addresses some of the raised comments. Brian sent a message about that * LoST Sync (presenter Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ I could talk about the changes that have been made in response to the reviews.=20 * PSAP Callback (presenter Christer + Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ There was a fair amount of discussion on the list about this topic and we still have not been closer to a solution. I have updated the document to reflect some of the mailing list comments.=20 * Data-Only Emergency Services (presenter Hannes or Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ =20 Based on the discussions from the last IETF meeting we have updated the document. I hope that the new version clarifies some of the comments and that the open issues are closed. =20 Non-WG document: * XMPP for Emergency Services (presenter Hannes) http://tools.ietf.org/html/draft-tschofenig-ecrit-xmpp-es-00 This document was written in response to the discussions around introducing XMPP support into emergency services organizations.=20 Ciao Hannes From gunnar.hellstrom@omnitor.se Tue Mar 13 23:14:38 2012 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 833A021F85E5 for ; Tue, 13 Mar 2012 23:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 xcsmdV-dhilV for ; Tue, 13 Mar 2012 23:14:37 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 9B02121F85E1 for ; Tue, 13 Mar 2012 23:14:35 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Wed, 14 Mar 2012 07:14:22 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 57F6A3A11B; Wed, 14 Mar 2012 07:14:22 +0100 (CET) Message-ID: <4F603743.7030002@omnitor.se> Date: Wed, 14 Mar 2012 07:14:27 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ecrit , Hannes Tschofenig References: <20120305201639.24006.81528.idtracker@ietfa.amsl.com> In-Reply-To: <20120305201639.24006.81528.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070207020709090400090503" Subject: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comments 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, 14 Mar 2012 06:14:38 -0000 This is a multi-part message in MIME format. --------------070207020709090400090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes and all, It is good that this draft is published. Whatever architecture is decided for handling of XMPP in emergency services, conversion outside or bring it in, it is important to collect information on what factors shall be considered and what problems to solve. I have made some mainly editorial comments that I send in a changemarked copy to you, Hannes. Here, I just want to comment that I suggest to include a section about session handling as well. A starting proposal: --------------------------------------------------------------------------------------------------------------- 4.9 Sessions versus Messaging in EmergencyCommunication Emergency case handling is currently handled in sessions by the call takers. In most cases it is most efficient if the same call taker can handle the call and any subsequent calls back, so that the detailed knowledge of the case is maintained. XMPP messaging sessions are often not ended by any specific signaling indicating the end of a session. This causes a need to artificially create an end of a session, so that human and technical resources can be released. It also creates a need to keep messages together in the session evenwhen the user is travelling and moves between PSAP areas during the session. There is thus a need to create a method for a pseudo-session management of XMPP messages, influencing the routing and linking to emergency case. __________________________________________________________________________ /Gunnar internet-drafts@ietf.org skrev 2012-03-05 21:16: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP) > Author(s) : Hannes Tschofenig > Filename : draft-tschofenig-ecrit-xmpp-es-00.txt > Pages : 17 > Date : 2012-03-05 > > The Extensible Messaging and Presence Protocol (XMPP) is a technology > that enjoys widespread deployment in the instant messaging > application domain. While many features for XMPP had been > standardized in the IETF as well as in the XMPP Standards Foundation > emergency services functionality was not part of it. > > This document aims to initiate a discussion about the necessary > emergency services functionality for XMPP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt --------------070207020709090400090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes and all,
It is good that this draft is published.

Whatever architecture is decided for handling of XMPP in emergency services, conversion outside or bring it in, it is important to collect information on what factors shall be considered and what problems to solve.

I have made some mainly editorial comments that I send in a changemarked copy to you, Hannes.

Here, I just want to comment that I suggest to include a section about session handling as well.

A starting proposal:
---------------------------------------------------------------------------------------------------------------
4.9  Sessions versus Messaging in Emergency Communication
 
Emergency case handling is currently handled in sessions by the call takers.
In most cases it is most efficient if the same call taker can handle the call 
and any subsequent calls back, so that the detailed knowledge of the case is maintained. 
XMPP messaging sessions are often not ended by any specific signaling indicating 
the end of a session. This causes a need to artificially create an end of a session,
 so that human and technical resources can be released.
It also creates a need to keep messages together in the session even when the user
 is travelling and moves between PSAP areas during the session.
 
There is thus a need to create a method for a pseudo-session management of XMPP messages,
 influencing the routing and linking to emergency case.    
__________________________________________________________________________

/Gunnar

internet-drafts@ietf.org skrev 2012-03-05 21:16: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)
	Author(s)       : Hannes Tschofenig
	Filename        : draft-tschofenig-ecrit-xmpp-es-00.txt
	Pages           : 17
	Date            : 2012-03-05

   The Extensible Messaging and Presence Protocol (XMPP) is a technology
   that enjoys widespread deployment in the instant messaging
   application domain.  While many features for XMPP had been
   standardized in the IETF as well as in the XMPP Standards Foundation
   emergency services functionality was not part of it.

   This document aims to initiate a discussion about the necessary
   emergency services functionality for XMPP.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt
--------------070207020709090400090503-- From RMarshall@telecomsys.com Wed Mar 14 16:50:49 2012 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 0CB6B21F87CA for ; Wed, 14 Mar 2012 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.109 X-Spam-Level: X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=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 x-b76luFVHo5 for ; Wed, 14 Mar 2012 16:50:47 -0700 (PDT) Received: from ann-mimesweep-1.telecomsys.com (ann-mimesweep-1.telecomsys.com [205.244.233.171]) by ietfa.amsl.com (Postfix) with ESMTP id BC0B321F87D0 for ; Wed, 14 Mar 2012 16:50:46 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (unverified [10.32.12.186]) by ann-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 14 Mar 2012 19:50:44 -0400 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.99]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 16:50:42 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF83 ECRIT Agenda Thread-Index: Ac0CPUOUu5ejifQjSDez+IHzdD/G7A== Date: Wed, 14 Mar 2012 23:50:42 +0000 Message-ID: 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: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC03EF9DSEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF83 ECRIT Agenda 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, 14 Mar 2012 23:50:49 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC03EF9DSEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ECRIT proposed agenda has been uploaded and can be viewed at: http://ww= w.ietf.org/proceedings/83/agenda/agenda-83-ecrit.txt Please comment ahead of the meeting if you'd like to see any changes made t= o it. Regards, -roger marshall ecrit secretary 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. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC03EF9DSEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ECRIT proposed agenda has been uploaded and can = be viewed at: h= ttp://www.ietf.org/proceedings/83/agenda/agenda-83-ecrit.txt=

 

Please comment ahead of the meeting if you’d l= ike to see any changes made to it.

 

Regards,

 

-roger marshall

ecrit secretary

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC03EF9DSEAEXMB2telecomsy_-- From bernard_aboba@hotmail.com Sat Mar 17 11:54:02 2012 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 6FAB421F853D for ; Sat, 17 Mar 2012 11:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.66 X-Spam-Level: X-Spam-Status: No, score=-101.66 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, HTML_MESSAGE=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 YsPSwitDVrJJ for ; Sat, 17 Mar 2012 11:54:01 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 26C3921F8513 for ; Sat, 17 Mar 2012 11:54:01 -0700 (PDT) Received: from BLU169-W20 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 11:54:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4085dbb0-dc47-4929-81ac-8c6474f19363_" X-Originating-IP: [99.32.177.175] From: Bernard Aboba To: , Date: Sat, 17 Mar 2012 11:54:00 -0700 Importance: Normal In-Reply-To: <4F603743.7030002@omnitor.se> References: <20120305201639.24006.81528.idtracker@ietfa.amsl.com>, <4F603743.7030002@omnitor.se> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2012 18:54:00.0794 (UTC) FILETIME=[50D9BBA0:01CD046F] Subject: Re: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comments 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, 17 Mar 2012 18:54:02 -0000 --_4085dbb0-dc47-4929-81ac-8c6474f19363_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One question I have is whether we are talking about XMPP Instant Messaging= =2C or MUC (XEP-045) or some mixture of both. The draft currently doesn't m= ention MUC=2C but one can imagine a per-incident chat room. =20 There are several ways that MUC could be used. For example=2C contact betw= een the user and PSAP might be via IM=2C=3B however=2C caller and dispatch= er messages could also be forwarded to an MUC within the PSAP where police= =2C fire and medical could provide information to the dispatcher. Alternat= ively=2C the caller might actually be placed into a per-incident MUC.=20 Date: Wed=2C 14 Mar 2012 07:14:27 +0100 From: gunnar.hellstrom@omnitor.se To: ecrit@ietf.org=3B Hannes.Tschofenig@gmx.net Subject: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comments =20 =20 =20 =20 Hannes and all=2C It is good that this draft is published. =20 Whatever architecture is decided for handling of XMPP in emergency services=2C conversion outside or bring it in=2C it is important to collect information on what factors shall be considered and what problems to solve.=20 =20 I have made some mainly editorial comments that I send in a changemarked copy to you=2C Hannes. =20 Here=2C I just want to comment that I suggest to include a section about session handling as well. =20 A starting proposal: ---------------------------------------------------------------------------= ------------------------------------ =20 =20 4.9 Sessions versus Messaging in Emergency Communication =20 Emergency case handling is currently handled in sessions by the call ta= kers. In most cases it is most efficient if the same call taker can handle the ca= ll=20 and any subsequent calls back=2C so that the detailed knowledge of the case= is maintained.=20 XMPP messaging sessions are often not ended by any specific signaling i= ndicating=20 the end of a session. This causes a need to artificially create an end of a= session=2C so that human and technical resources can be released. It also creates a need to keep messages together in the session even wh= en the user is travelling and moves between PSAP areas during the session. =20 There is thus a need to create a method for a pseudo-session management= of XMPP messages=2C influencing the routing and linking to emergency case. =20 =20 =20 =20 =20 =20 =20 _______________________________________________________________________= ___ =20 /Gunnar =20 internet-drafts@ietf.org skrev 2012-03-05 21:16: =20 A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. Title : Emergency Services Functionality with the Extensible Mes= saging and Presence Protocol (XMPP) Author(s) : Hannes Tschofenig Filename : draft-tschofenig-ecrit-xmpp-es-00.txt Pages : 17 Date : 2012-03-05 The Extensible Messaging and Presence Protocol (XMPP) is a technology that enjoys widespread deployment in the instant messaging application domain. While many features for XMPP had been standardized in the IETF as well as in the XMPP Standards Foundation emergency services functionality was not part of it. This document aims to initiate a discussion about the necessary emergency services functionality for XMPP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt =20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit = --_4085dbb0-dc47-4929-81ac-8c6474f19363_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One question I have is whether we are talking about XMPP I= nstant Messaging=2C or MUC (XEP-045) or some mixture of both. The draft cur= rently doesn't mention MUC=2C but one can imagine a per-incident chat room.=  =3B

There are several ways that MUC could be used. =3B For= example=2C contact between the user and PSAP might be via IM=2C=3B =3B= however=2C caller and dispatcher messages could also be forwarded to an MU= C within the PSAP where police=2C fire and medical could provide informatio= n to the dispatcher. =3B Alternatively=2C the caller might actually be = placed into a per-incident MUC.

Date: Wed=2C 14 Mar 2012 07:14:27 +0100
= From: gunnar.hellstrom@omnitor.se
To: ecrit@ietf.org=3B Hannes.Tschofeni= g@gmx.net
Subject: [Ecrit] draft-tschofenig-ecrit-xmpp-es-00.txt comme= nts

=20 =20 =20 =20 Hannes and all=2C
It is good that this draft is published.

Whatever architecture is decided for handling of XMPP in emergency services=2C conversion outside or bring it in=2C it is important to collect information on what factors shall be considered and what problems to solve.

I have made some mainly editorial comments that I send in a changemarked copy to you=2C Hannes.

Here=2C I just want to comment that I suggest to include a section about session handling as well.

A starting proposal:
---------------------------------------------------------------------------= ------------------------------------
=20 =20 
4.9 =3B Sessions=
 versus Messaging in Emergency =
Communication
 =3B
Emergency case handling is currently handled in sessions by the call takers.
In most cases it is most effici=
ent if the same call taker can handle the call=20
and any subsequent calls back=2C so that the detailed=
 knowledge of the case is maintained. 
XMPP messaging sessi=
ons are often not ended by any specific signaling indicating=20
the end of a session. This caus=
es a need to artificially create an end of a session=2C
 so that human and technical resources can be released.=

It also creates a need to keep messages to=
gether in the session even when the user
 is travelling=
 and moves betwee=
n PSAP areas during the session.
 =3B
There is thus a need to create a method fo=
r a pseudo-session management of XMPP messages=2C
 influencing the routing and linking to emergency case.  =3B =3B=
=
 =3B =
=20 =20 =20 =20 =20 =20 ___________________________________________________________________= _______

/Gunnar

internet-drafts@ietf.org skrev 2012-03-05 21:16: 
A New Internet-Draft is available from the on-line Internet-Draf=
ts directories.

	Title           : Emergency Services Functionality with the Extensible Mes=
saging and Presence Protocol (XMPP)
	Author(s)       : Hannes Tschofenig
	Filename        : draft-tschofenig-ecrit-xmpp-es-00.txt
	Pages           : 17
	Date            : 2012-03-05

   The Extensible Messaging and Presence Protocol (XMPP) is a technology
   that enjoys widespread deployment in the instant messaging
   application domain.  While many features for XMPP had been
   standardized in the IETF as well as in the XMPP Standards Foundation
   emergency services functionality was not part of it.

   This document aims to initiate a discussion about the necessary
   emergency services functionality for XMPP.


A URL for this Internet-Draft is:
http://www.=
ietf.org/internet-drafts/draft-tschofenig-ecrit-xmpp-es-00.txt
=20
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
= --_4085dbb0-dc47-4929-81ac-8c6474f19363_-- From laura.liess.dt@googlemail.com Fri Mar 23 04:11:08 2012 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 8C2C021F854B for ; Fri, 23 Mar 2012 04:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IvlZtExr8DYJ for ; Fri, 23 Mar 2012 04:11:02 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id AA5F321F851D for ; Fri, 23 Mar 2012 04:11:01 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1541611wib.13 for ; Fri, 23 Mar 2012 04:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5LPtNk44kZs4zMRQD61qzfdR0/Uk3U3m1+8Ij64/XE4=; b=uu7Kn0XazdnYLq/IRLwRFxdw1eUZ6nwzTlKdJ79Kp+GORyLOK49+lxBTlXpZwbmePP lLFQcbv2n2LuNvqVFSBi0Z9ITrUD/qEGmnhFPa6EcQTdzVDcNOhgm9WUT0MBLFVmvuMl 0pV4csK58QxJoCa7L08BZcOHcIkYZ8b2PRjnrReI15bdbQzJHY7FNCgxT8FhHW01yhvG /fqtl5mTgSq8p7lMQ+yUSOksRWb4Ij/3MiDWESvWqOH8Ezcxi+lsf2L4sNsnlxlCyo+J jnBO34k8p5wl9VPLKxaSqGot4ctf6pGZXpNqNkhQfzFE0Mx4Lazx0DVvYcxZkXoAueOp NZOg== MIME-Version: 1.0 Received: by 10.180.83.72 with SMTP id o8mr5615888wiy.5.1332501060552; Fri, 23 Mar 2012 04:11:00 -0700 (PDT) Received: by 10.227.112.206 with HTTP; Fri, 23 Mar 2012 04:11:00 -0700 (PDT) Date: Fri, 23 Mar 2012 12:11:00 +0100 Message-ID: From: Laura Liess To: "ecrit@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [Ecrit] Comment on draft-ietf-ecrit-additional-data 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, 23 Mar 2012 11:11:08 -0000 Hi, Sometimes national regulatory bodies have specific requirements about additional data they want to be sent to the PSAP (this is the case in Germany for the mobile networks). Also I hear from my colleagues in 3GPP that they would eventually need additional data for eCall. I think it would be very usefull to have a mechanism which enables national regulatory bodies and SDOs to add, in the future, new XML elements, without having to write an RFC, but having to pass the new XML elements through an IETF/ecrit expert review. (We have such kind of extension mechanism in RFC 5774 for civic adresses.) If we don't do that, different countries will use different, often inappropriate SIP-headers to carry the data required by the local regulation. (I know about such discussions in Germany.) I think we should try to avoid this to happen. Thanks a lot Laura From br@brianrosen.net Fri Mar 23 05:58:35 2012 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 C24BE21F852D for ; Fri, 23 Mar 2012 05:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.067 X-Spam-Level: X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JfkQGKGKpqiq for ; Fri, 23 Mar 2012 05:58:31 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id C120E21F8523 for ; Fri, 23 Mar 2012 05:58:31 -0700 (PDT) X-ASG-Debug-ID: 1332507508-0491e50f99324480001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id rT625Gc2JLBWPtPD; Fri, 23 Mar 2012 05:58:28 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.23]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SB44Z-003jNU-P8; Fri, 23 Mar 2012 05:58:27 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Fri, 23 Mar 2012 08:58:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Laura Liess X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1332507508 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92015 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data 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, 23 Mar 2012 12:58:35 -0000 Good idea. If we have no objection, we'll add it to the next draft. Brian On Mar 23, 2012, at 7:11 AM, Laura Liess wrote: > Hi, > > Sometimes national regulatory bodies have specific requirements about > additional data they want to be sent to the PSAP (this is the case in > Germany for the mobile networks). Also I hear from my colleagues in > 3GPP that they would eventually need additional data for eCall. > > I think it would be very usefull to have a mechanism which enables > national regulatory bodies and SDOs to add, in the future, new XML > elements, without having to write an RFC, but having to pass the new > XML elements through an IETF/ecrit expert review. (We have such kind > of extension mechanism in RFC 5774 for civic adresses.) > If we don't do that, different countries will use different, often > inappropriate SIP-headers to carry the data required by the local > regulation. (I know about such discussions in Germany.) I think we > should try to avoid this to happen. > > Thanks a lot > Laura > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Fri Mar 23 08:14:54 2012 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 CA28821F8476 for ; Fri, 23 Mar 2012 08:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.8 X-Spam-Level: X-Spam-Status: No, score=-8.8 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xCM2Z7lLWMGg for ; Fri, 23 Mar 2012 08:14:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9A21F858E for ; Fri, 23 Mar 2012 08:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1623; q=dns/txt; s=iport; t=1332515690; x=1333725290; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=y80hkJhEI3JeVTfJ7ddOlpHK7wGwMdItgO0yWRvLzwM=; b=fAaXDta0x2dzDCYKZKnKnrY38rGms7dilWQXCu01bnhW0X4jFBa9W7iu LTmEwIi5HFfERJqTvgbyGqtt4YF0+4rRYd9REYT5UODVzAdSo4NUZKZ+f 9Gm6+oKJMXrM0ZCzAPP/b0dm58JN7JkbdJBs3YLTOPG4bQk/CtPrHSbq8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMHADCSbE+tJV2a/2dsb2JhbABFgw60eoEHggkBAQEEAQEBDwEnAgEuAwsMBwgOAwMBAgFVKAgGAQ0FIodoC5oCnwMEiW2HGASVYIVuiFaBaIMD X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="65879776" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 23 Mar 2012 15:14:49 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2NFEjSM014594; Fri, 23 Mar 2012 15:14:47 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 23 Mar 2012 11:14:44 -0400 From: Marc Linsner To: Brian Rosen , Laura Liess Message-ID: Thread-Topic: [Ecrit] Comment on draft-ietf-ecrit-additional-data In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data 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, 23 Mar 2012 15:14:54 -0000 +1 -----Original Message----- From: Brian Rosen Date: Fri, 23 Mar 2012 08:58:17 -0400 To: Laura Liess Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data >Good idea. If we have no objection, we'll add it to the next draft. > >Brian > >On Mar 23, 2012, at 7:11 AM, Laura Liess wrote: > >> Hi, >> >> Sometimes national regulatory bodies have specific requirements about >> additional data they want to be sent to the PSAP (this is the case in >> Germany for the mobile networks). Also I hear from my colleagues in >> 3GPP that they would eventually need additional data for eCall. >> >> I think it would be very usefull to have a mechanism which enables >> national regulatory bodies and SDOs to add, in the future, new XML >> elements, without having to write an RFC, but having to pass the new >> XML elements through an IETF/ecrit expert review. (We have such kind >> of extension mechanism in RFC 5774 for civic adresses.) >> If we don't do that, different countries will use different, often >> inappropriate SIP-headers to carry the data required by the local >> regulation. (I know about such discussions in Germany.) I think we >> should try to avoid this to happen. >> >> Thanks a lot >> Laura >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Sat Mar 24 12:39:22 2012 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 59BE321F855B for ; Sat, 24 Mar 2012 12:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.507 X-Spam-Level: X-Spam-Status: No, score=-105.507 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 yA6LdaPZaDor for ; Sat, 24 Mar 2012 12:39:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6C42221F855A for ; Sat, 24 Mar 2012 12:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332617961; x=1364153961; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type: content-transfer-encoding:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<4F5CF7F4.9030503@omnitor.se>|References: =20<4F59E8D5.4060902@omnitor.se>=0D=0A=20<999913AB42CC934 1B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net>=0D=0A =20 =0D=0A=20<1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> =0D=0A=20=0D=0A=20<4F5CF7F4.9030503@omnitor.se>|X-Mailer:=20E udora=20for=20Mac=20OS=20X|Date:=20Sat,=2024=20Mar=202012 =2012:32:30=20-0700|To:=20Gunnar=20=3D?iso-8859-1?Q?Hells tr=3DF6m?=3D=20,=0D=0A=09|From:=20Randall=20Gellens=20|Subject:=20Re:=20[Ecrit]=20Phonebcp=20issues |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"iso-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.3 9.5]; bh=+nHWf8WBUbZDM2ZiKvOVt04yzv+iS7TJdwpcyJ+vikM=; b=s14DsJP61pH4WJ9cKoxEmiS/VmPF6oVU/HFKPzy8aNHt1S7ooYztQI2t HGkp4lepw/frGg6vE7ANubbT6/U0c7cBo1/Rz+mt6gKplH0KDmzlBAN4H hsapA2tw2TcsSOrd6kkkJLqou7jJKfe6c893bedF5z15aBrl4uUPpI1zG E=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="173200060" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 24 Mar 2012 12:39:20 -0700 X-IronPort-AV: E=Sophos;i="4.75,311,1330934400"; d="scan'208";a="158080555" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Mar 2012 12:39:20 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 24 Mar 2012 12:39:19 -0700 Message-ID: In-Reply-To: <4F5CF7F4.9030503@omnitor.se> References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> <4F5CF7F4.9030503@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sat, 24 Mar 2012 12:32:30 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] Phonebcp issues 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, 24 Mar 2012 19:39:22 -0000 Hi Gunnar, At 8:07 PM +0100 3/11/12, Gunnar Hellstr=F6m wrote: > I have an initial text proposal for phonebcp,=20 > to use to release the media-loopback dependency. > I made the media transfer much longer that the=20 > three packets originally indicated in the=20 > current draft. I think that is needed to make=20 > the test usaful, but the use and effect of that=20 > may be discussed. > > Current wording: > -------------------------- > > > ED-80 A PSAP accepting a test call SHOULD accept a media loopback > test [I-D.ietf-mmusic-media-loopback=20 > ]=20 > and SHOULD support the "rtp- > pkt-loopback" and "rtp-start-loopback" options. The user agent would > specify a loopback attribute of "loopback-source", the PSAP being the > mirror. User Agents should expect the PSAP to loop back no more than > 3 packets of each media type accepted (which limits the duration of > the test), after which the PSAP would normally send BYE. > > ----------------------------------------- > > Change proposal > _______________________. > > ED-80 A PSAP accepting a test call SHOULD=20 > accept all media in the offer for which it has=20 > coresponding codecs. Both the PSAP and the User=20 > Agent SHOULD send media contents until 500 ms=20 > after the session establishment was completed.=20 > From the moment when the PSAP receives media=20 > contents from the User Agent, the received=20 > media contents shall be looped back to the User=20 > Agent. RTCP reports shall be sent before the=20 > PSAP ends the test call by sending BYE. If the=20 > User Agent does not receive a BYE within 35=20 > seconds after it sent its ACK, then the User=20 > Agent SHALL end the call by sending BYE. This seems like a good approach. Your earlier=20 message noted that a loopback test wasn't=20 realistic, that it would be better for the PSAP=20 to have some test media it sends, to better=20 simulate a real call: At 12:26 PM +0100 3/9/12, Gunnar Hellstr=F6m wrote: > I do not think that the current specification=20 > in phonebcp is very realistic, with just a=20 > loopback. I think the test server could just as=20 > well generate some own initial test media and=20 > then possibly also mirror some packets when=20 > received. The current behavior of the=20 > media-loopback to wait for incoming media=20 > before it generates any outgoing media is not=20 > similar to what will be the scenario in real=20 > calls. Both sides in real calls normally take=20 > initiative to media transmission after the=20 > session is established. The resulting problems=20 > for NAT traversal of the current media-loopback=20 > draft is one of the issues that has caused its=20 > delay. So, maybe you can incorporate this into the=20 suggested text, or perhaps this is implied by=20 "Both the PSAP and the User Agent SHOULD send=20 media contents," in which case maybe it can be=20 made more explicit. Also, just wondering if "A PSAP accepting a test=20 call SHOULD accept all media in the offer for=20 which it has coresponding codecs" should maybe be=20 worded "all media in the offer which it would=20 accept had the call been a non-test emergency=20 call." Maybe there's no difference, in which=20 case no change is needed; I am just wondering if=20 there might be situations in which a PSAP has=20 codecs but wouldn't accept the media in a=20 non-test emergency call, perhaps because it's=20 video and the sign language interpreter is not=20 available, or whatever? (I didn't see any=20 requirement in phonebcp when I looked now about=20 accepting all media for which it has codecs.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Quick!! Act as if nothing has happened! From randy@qualcomm.com Sat Mar 24 13:05:41 2012 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 3A43D21F8581 for ; Sat, 24 Mar 2012 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.305 X-Spam-Level: X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 l9JvGqMWoGIz for ; Sat, 24 Mar 2012 13:05:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5271A21F8543 for ; Sat, 24 Mar 2012 13:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332619540; x=1364155540; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20 |References:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sat,=202 4=20Mar=202012=2013:05:33=20-0700|To:=20, =20Brian=20Rosen=20,=20Hannes=20Tschof enig=0D=0A=09,=20Roger=20Marsh all=20|From:=20Randall=20Gellen s=20|Subject:=20My=20comments=20from =20Nov=2020=20on=20additional-data-02|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=mGXSky/sS+/Op45/8LC3LxjV6ik/fLeHEF22yqG3K7o=; b=DYQvHW//SaPYY4aW6/B3AljRB7trV9kN6QJwL1GdIUrOYl1Y0Ky+V+yO GUb3PD4oOzwkh5MIXtcdepxH5jk731fo5ppoMaQOQEqBKlYeoAhiOdc7U asG8KeNm9dPTqyMLcoTwV1XeWYVasVs6c5qgucHzneriNn4QtcBa1OYKF g=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="173203249" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 24 Mar 2012 13:05:37 -0700 X-IronPort-AV: E=Sophos;i="4.75,311,1330934400"; d="scan'208";a="194126581" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Mar 2012 13:05:37 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 24 Mar 2012 13:05:36 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 24 Mar 2012 13:05:33 -0700 To: , Brian Rosen , Hannes Tschofenig , Roger Marshall From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: [Ecrit] My comments from Nov 20 on additional-data-02 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, 24 Mar 2012 20:05:41 -0000 Hi Brian, Hannes, Roger, Were my comments on -02 of additional-data, sent November 20, addressed? Looking through -03, it doesn't appear so. At 2:31 PM -0800 11/20/11, Randall Gellens wrote: > Hi Brian, Hannes, Roger, and fellow ecrit-ers, > > I think this document needs at least another revision before it is > ready for WGLC. Attached is a version of the draft with my > suggested text changes, identified by "RG " in the left margin > (where "^" means insertion at that point in the line above, and "X" > means delete the character above). In a number of places I was > unable to suggest specific text changes because I was unclear of > the intent or for other reasons; those places have my questions or > comments on the text, identified by "RG >>>>>" in the left margin. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The most likely way for the world to be destroyed, most experts agree, > is by accident. That's where we come in; we're computer professionals. > We cause accidents. --Nathaniel Borenstein > > > Attachment converted: TiLand:draft-ietf-ecrit-ad#3077215.txt > (TEXT/R*ch) (03077215) > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I personally think we developed language because of our deep need to complain. --Lily Tomlin From randy@qualcomm.com Sat Mar 24 13:19:21 2012 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 CA5A521E800C for ; Sat, 24 Mar 2012 13:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.327 X-Spam-Level: X-Spam-Status: No, score=-106.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 lVP2n6Ne9stu for ; Sat, 24 Mar 2012 13:19:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDF421F85A1 for ; Sat, 24 Mar 2012 13:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332620361; x=1364156361; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20|References:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sat,=202 4=20Mar=202012=2013:13:45=20-0700|To:=20Marc=20Linsner=20 ,=20Brian=20Rosen=20,=20Laura=0D=0A=20Liess=20,=20"ecrit@ietf.org"=20|From:=20Randall =20Gellens=20|Subject:=20Re:=20[Ecrit ]=20Comment=20on=20draft-ietf-ecrit-additional-data |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.39.5]; bh=JgJ2SzjgRGtvOBGAWMFmUcpkxHfft2mo3syU4n6a8FY=; b=nGu/FrVEco2kvBDp6AZ2W29zkSEIDApSTPuMqAMJJzzYSUd1+g/DCinQ LSUMNN6fA2SHPEC9i9DdEbTAcy37XVqrEVssMS51U+YUWNcVsehF8ItPD veU6c0rVN70wIIFqavJGJbUnvx4eABy4Ow2Qzeo9d8rRreL1EdTVtRXpw I=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="173204804" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 24 Mar 2012 13:19:19 -0700 X-IronPort-AV: E=Sophos;i="4.75,312,1330934400"; d="scan'208";a="292792896" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Mar 2012 13:19:19 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 24 Mar 2012 13:19:17 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 24 Mar 2012 13:13:45 -0700 To: Marc Linsner , Brian Rosen , Laura Liess , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data 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, 24 Mar 2012 20:19:22 -0000 I wonder which mechanism would be best for this: Additional namespaces in the XML, or additional MIME types? I can see advantages to both approaches. I wonder if it depends on the use case? A use case which adds a small number of elements closely associated with existing ones seems very well-suited for a namespace in the XML. A use case (such as eCall) that defines a self-contained block of data might make more sense as its own MIME type. As the draft says, multiple MIME types are expected, wrapped in a MULTIPART type. Maybe both should be permitted? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Never precede any demo by a comment more predictive than "Watch this!". From randy@qualcomm.com Sat Mar 24 13:23:20 2012 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 B43ED21F8565 for ; Sat, 24 Mar 2012 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Wrmv9G8X-0hH for ; Sat, 24 Mar 2012 13:23:20 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 355E721F853D for ; Sat, 24 Mar 2012 13:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1332620600; x=1364156600; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; z=Message-ID:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sat,=202 4=20Mar=202012=2013:21:36=20-0700|To:=20Brian=20Rosen=20< br@brianrosen.net>,=20"ecrit@ietf.org"=20 |From:=20Randall=20Gellens=20 |Subject:=20MIME=20types=20in=20additional-data |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.39.5]; bh=Xhp2ebqSKxBjaEivCjIY6dY6CYrMviptbN3YJTqzia0=; b=CmsL5FbEaNf8SoavekBKZEeGCPxYNb2+Dyl0EfAdv0Q57mlKD7KwrQoF MSg9xQo4u9cvNOAg0Fs/vi/Ypg1kaNPuqvaa2GSIynXViV28mjCVp7yDV tzHZXCvkSB4kfprknfLWzJo5Ymr6ZDaEwVkEuxyIpgpcqlkxJiAYpDV0q g=; X-IronPort-AV: E=McAfee;i="5400,1158,6659"; a="173205665" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 24 Mar 2012 13:23:19 -0700 X-IronPort-AV: E=Sophos;i="4.75,311,1330934400"; d="scan'208";a="158080679" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Mar 2012 13:23:19 -0700 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 24 Mar 2012 13:23:18 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Sat, 24 Mar 2012 13:21:36 -0700 To: Brian Rosen , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: [Ecrit] MIME types in additional-data 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, 24 Mar 2012 20:23:20 -0000 Perhaps the MIME types being registered in additional-data should be more clearly associated with emergency calls, e.g., 'application/emergencyCall-addDataProviderInfo+xml' 'application/emergencyCall-addCallSvcInfo+xml' 'application/emergencyCall-addDataDevInfo+xml' 'application/emergencyCall-addCallSub+xml' -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The first rule is, you must not fool yourself. And you are the easiest person to fool. --Richard Feynman From gunnar.hellstrom@omnitor.se Sat Mar 24 15:46:50 2012 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 7A5B221E8019 for ; Sat, 24 Mar 2012 15:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[AWL=-2.252, BAYES_00=-2.599, GB_SUMOF=5, MIME_8BIT_HEADER=0.3] 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 ySoanVYA4RQH for ; Sat, 24 Mar 2012 15:46:49 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 8F2F221F84F6 for ; Sat, 24 Mar 2012 15:46:46 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sat, 24 Mar 2012 23:46:38 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 469543A166; Sat, 24 Mar 2012 23:46:38 +0100 (CET) Message-ID: <4F6E4ECD.7000301@omnitor.se> Date: Sat, 24 Mar 2012 23:46:37 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Randall Gellens References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> <4F5CF7F4.9030503@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Phonebcp issues 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, 24 Mar 2012 22:46:50 -0000 Hi Randall, I got the impression that a new version of mmusic-media-loopback was on its way, and that we could hope that phonebcp therefore has an opportunity to move on quite soon without modification. The test procedures can of course be discussed anyway. I have accepted bothy your proposals for improvements in the adjusted text below. ---------------------------------------------------- ED-80 Test equipment in a PSAP accepting a test call SHOULD accept all media and codecs in the offer which it would accept if the call had been a non-test emergency call. Both the PSAP and the User Agent SHOULD create and send media contents until 500 ms after the session establishment was completed. From the moment when the PSAP receives media contents from the User Agent, the received media contents shall be looped back to the User Agent. RTCP reports shall be sent before the PSAP ends the test call by sending BYE. If the User Agent does not receive a BYE within 35 seconds after it sent its ACK, then the User Agent SHALL end the call by sending BYE. ---------------------------------------------------- A thought about load: Phonebcp recommends a 30 day interval of tests. Users generate real calls with about 40 months intervals. So, there will be 40 times more test calls than real calls. They will be short, however. Usually just a second, while the real calls last a couple of minutes. Summary: SIP transaction load of tests are 40 times the real number of calls, while the sum time of test calls will be only half of the sum of the time for real calls. It sounds heavy but manageable. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Randall Gellens skrev 2012-03-24 20:32: > Hi Gunnar, > > At 8:07 PM +0100 3/11/12, Gunnar Hellström wrote: > >> I have an initial text proposal for phonebcp, to use to release the >> media-loopback dependency. >> I made the media transfer much longer that the three packets >> originally indicated in the current draft. I think that is needed to >> make the test usaful, but the use and effect of that may be discussed. >> >> Current wording: >> -------------------------- >> >> >> ED-80 A PSAP accepting a test call SHOULD accept a media loopback >> test [I-D.ietf-mmusic-media-loopback >> ] >> and SHOULD support the "rtp- >> pkt-loopback" and "rtp-start-loopback" options. The user agent >> would >> specify a loopback attribute of "loopback-source", the PSAP being >> the >> mirror. User Agents should expect the PSAP to loop back no more >> than >> 3 packets of each media type accepted (which limits the duration of >> the test), after which the PSAP would normally send BYE. >> >> ----------------------------------------- >> >> Change proposal >> _______________________. >> >> ED-80 A PSAP accepting a test call SHOULD accept all media in the >> offer for which it has coresponding codecs. Both the PSAP and the >> User Agent SHOULD send media contents until 500 ms after the session >> establishment was completed. From the moment when the PSAP receives >> media contents from the User Agent, the received media contents shall >> be looped back to the User Agent. RTCP reports shall be sent before >> the PSAP ends the test call by sending BYE. If the User Agent does >> not receive a BYE within 35 seconds after it sent its ACK, then the >> User Agent SHALL end the call by sending BYE. > > This seems like a good approach. Your earlier message noted that a > loopback test wasn't realistic, that it would be better for the PSAP > to have some test media it sends, to better simulate a real call: > > At 12:26 PM +0100 3/9/12, Gunnar Hellström wrote: >> I do not think that the current specification in phonebcp is very >> realistic, with just a loopback. I think the test server could just >> as well generate some own initial test media and then possibly also >> mirror some packets when received. The current behavior of the >> media-loopback to wait for incoming media before it generates any >> outgoing media is not similar to what will be the scenario in real >> calls. Both sides in real calls normally take initiative to media >> transmission after the session is established. The resulting problems >> for NAT traversal of the current media-loopback draft is one of the >> issues that has caused its delay. > > So, maybe you can incorporate this into the suggested text, or perhaps > this is implied by "Both the PSAP and the User Agent SHOULD send media > contents," in which case maybe it can be made more explicit. > > Also, just wondering if "A PSAP accepting a test call SHOULD accept > all media in the offer for which it has coresponding codecs" should > maybe be worded "all media in the offer which it would accept had the > call been a non-test emergency call." Maybe there's no difference, in > which case no change is needed; I am just wondering if there might be > situations in which a PSAP has codecs but wouldn't accept the media in > a non-test emergency call, perhaps because it's video and the sign > language interpreter is not available, or whatever? (I didn't see any > requirement in phonebcp when I looked now about accepting all media > for which it has codecs.) > From martin.thomson@gmail.com Sat Mar 24 16:51:05 2012 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 4D6A021E8028 for ; Sat, 24 Mar 2012 16:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.681 X-Spam-Level: X-Spam-Status: No, score=-4.681 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, 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 lrCu+MTrBXhk for ; Sat, 24 Mar 2012 16:51:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E006321E8019 for ; Sat, 24 Mar 2012 16:51:03 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3769205bku.31 for ; Sat, 24 Mar 2012 16:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F++15XMSmUvGiPiLBlkrsr1aO+Cxm3WBj2wwK2WjFA8=; b=lfWk+2wdcEy2Pm63muQkvvzvSvrGshaPO3oRcyWy58wCQS9S8y6Wwc4hg3XwUsRLiW 4gEZT+AlPGYzYCLvvsi2lta6iYhBbgB4rtp+6hqMpvjE7hkwRhKDjUL9KkqnDN4tHp/b Gjzo0i8yMoo2jiUusA8CuuhWRJGS6zcPHJZeX0b9LiJkCVSI+2xGtK5niDN6kAALKGUr ycVRE3SdsIM4Nr+X7Z5gVvYUco1ILu4NnLTyVRFzrL48NjJUI/evpWGh5hWQs+ynWLtF JT9rnFa9+ZQLgs96+RSSAKBiZHxruKN4+UBjIZHjjPuyIP1Zc0iT3VrZ5pafkHv2mND0 gyWQ== MIME-Version: 1.0 Received: by 10.204.133.216 with SMTP id g24mr6431373bkt.104.1332633063025; Sat, 24 Mar 2012 16:51:03 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Sat, 24 Mar 2012 16:51:02 -0700 (PDT) Date: Sat, 24 Mar 2012 16:51:02 -0700 Message-ID: From: Martin Thomson To: "ecrit@ietf.org Org" Content-Type: text/plain; charset=UTF-8 Subject: [Ecrit] Additional data 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, 24 Mar 2012 23:51:05 -0000 Emergency authorities might request a great range of information. Some of that information might be illegal to provide in some jurisdictions, while mandatory in others. All that this specification can do is provide the framework for the inclusion of arbitrary data. The few examples that are included need to be generic enough to satisfy the needs of all jurisdictions. That should not prevent an organization from registering new MIME types, adding elements to the existing structures, or even choosing to use entirely different formats. What is not clear from the draft is that these things are possible. A small section on extension might help. The discussion in the security considerations section is a little strange. There is already a global PKI infrastructure sufficient for the authentication of HTTPS. Unless the intent is to establish a parallel PKI infrastructure, the paragraph could be a little cleaner. Information that is provided by reference MUST be provided using a mechanism that supports confidentiality. Ensuring that access to information is only provided to emergency services depends on client authentication and the provision of access control policies. This document does not attempt to solve the very difficult problem of client authentication and authorization, but it could do something. If HTTPS URIs contained a per-call authentication token that was difficult to guess (in the path component, for example), then it would only be possible to access this information if the signaling were seen. That gives equivalent protection to those parts that are in the body of the request. The privacy considerations section is weak. SHOULD NOT send when attached to this much of a potential violation of privacy could be made a lot stronger. I suspect that taking a closer look at whether the call is actually an emergency call in the first place would be a good place to start. The security section is much stronger on this point: This additional information MUST NOT be included unless the call is an emergency call and the inclusion of the additional data is mandated by an appropriate authority. If there are cases where it is not certain that a call is emergency or not when making this determination, then the information MAY be provided. A few nits: MIME types are incomplete in most places. When defined, the full MIME media type should be used to eliminate ambiguity, e.g., "application/addCallSvcInfo+xml". The language tag should refer to the applicable RFC for language tags, RFC 5646. --Martin From gunnar.hellstrom@omnitor.se Sat Mar 24 21:35:16 2012 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 749B321F8489 for ; Sat, 24 Mar 2012 21:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 EYyyT5iVuonb for ; Sat, 24 Mar 2012 21:35:15 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id DD75B21F8484 for ; Sat, 24 Mar 2012 21:35:14 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 25 Mar 2012 06:35:06 +0200 (CEST) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 9F29C3A160 for ; Sun, 25 Mar 2012 06:35:06 +0200 (CEST) Message-ID: <4F6EA079.4000806@omnitor.se> Date: Sun, 25 Mar 2012 06:35:05 +0200 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> <4F5CF7F4.9030503@omnitor.se> <4F6E4ECD.7000301@omnitor.se> In-Reply-To: <4F6E4ECD.7000301@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Phonebcp issues -testing 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, 25 Mar 2012 04:35:16 -0000 A few more thoughts about testing: I hope that the wording of ED-80 is sufficient for understanding that all media mentioned in the media chapter of Phonebcp may be tested by the ua and SHOULD be supported by the test station in the PSAP, including video, real-time-text, audio, MSRP-based text messages and SIP Message based text messages. The wording suits fine for video, real-time text and audio, and the mmusic-media-loopback will work for them if it is decided to leave the wording as it is today in the approved phonebcp draft. But I doubt that mmusic-media-loopback works for MSRP messaging, and it does not work for SIP Message. One reason why it does not work for SIP Message is that SIP Message has no SDP negotiation where media-loopback could be negotiated. So, I guess that the conclusion is that separate additional work is needed to describe testing of MSRP and SIP Message. Is it needed to add the straightforward media types in ED-80, like this: ED-80 Test equipment in a PSAP accepting a test call SHOULD accept all media and select codecs in the offer which it would accept if the call had been a non-test emergency call. This is valid for video, real-time text and audio. Both the PSAP and the User Agent SHOULD create and send media contents until 500 ms after the session establishment was completed. From the moment when the PSAP receives media contents from the User Agent, the received media contents shall be looped back to the User Agent. RTCP reports shall be sent before the PSAP ends the test call by sending BYE. If the User Agent does not receive a BYE within 35 seconds after it sent its ACK, then the User Agent SHALL end the call by sending BYE. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Gunnar Hellström skrev 2012-03-24 23:46: > Hi Randall, > > I got the impression that a new version of mmusic-media-loopback was > on its way, and that we could hope that phonebcp therefore has an > opportunity to move on quite soon without modification. > > The test procedures can of course be discussed anyway. > > I have accepted bothy your proposals for improvements in the adjusted > text below. > ---------------------------------------------------- > ED-80 Test equipment in a PSAP accepting a test call SHOULD accept all > media and codecs in the offer which it would accept if the call had > been a non-test emergency call. Both the PSAP and the User Agent > SHOULD create and send media contents until 500 ms after the session > establishment was completed. From the moment when the PSAP receives > media contents from the User Agent, the received media contents shall > be looped back to the User Agent. RTCP reports shall be sent before > the PSAP ends the test call by sending BYE. If the User Agent does not > receive a BYE within 35 seconds after it sent its ACK, then the User > Agent SHALL end the call by sending BYE. > > ---------------------------------------------------- > > A thought about load: > > Phonebcp recommends a 30 day interval of tests. > Users generate real calls with about 40 months intervals. > > So, there will be 40 times more test calls than real calls. > They will be short, however. Usually just a second, while the real > calls last a couple of minutes. > > Summary: SIP transaction load of tests are 40 times the real number of > calls, while the sum time of test calls will be only half of the sum > of the time for real calls. > It sounds heavy but manageable. > > > Gunnar > > > > ___________________________________________________ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > > > Randall Gellens skrev 2012-03-24 20:32: >> Hi Gunnar, >> >> At 8:07 PM +0100 3/11/12, Gunnar Hellström wrote: >> >>> I have an initial text proposal for phonebcp, to use to release the >>> media-loopback dependency. >>> I made the media transfer much longer that the three packets >>> originally indicated in the current draft. I think that is needed to >>> make the test usaful, but the use and effect of that may be discussed. >>> >>> Current wording: >>> -------------------------- >>> >>> >>> ED-80 A PSAP accepting a test call SHOULD accept a media loopback >>> test [I-D.ietf-mmusic-media-loopback >>> ] >>> and SHOULD support the "rtp- >>> pkt-loopback" and "rtp-start-loopback" options. The user agent >>> would >>> specify a loopback attribute of "loopback-source", the PSAP >>> being the >>> mirror. User Agents should expect the PSAP to loop back no more >>> than >>> 3 packets of each media type accepted (which limits the duration of >>> the test), after which the PSAP would normally send BYE. >>> >>> ----------------------------------------- >>> >>> Change proposal >>> _______________________. >>> >>> ED-80 A PSAP accepting a test call SHOULD accept all media in the >>> offer for which it has coresponding codecs. Both the PSAP and the >>> User Agent SHOULD send media contents until 500 ms after the session >>> establishment was completed. From the moment when the PSAP receives >>> media contents from the User Agent, the received media contents >>> shall be looped back to the User Agent. RTCP reports shall be sent >>> before the PSAP ends the test call by sending BYE. If the User Agent >>> does not receive a BYE within 35 seconds after it sent its ACK, then >>> the User Agent SHALL end the call by sending BYE. >> >> This seems like a good approach. Your earlier message noted that a >> loopback test wasn't realistic, that it would be better for the PSAP >> to have some test media it sends, to better simulate a real call: >> >> At 12:26 PM +0100 3/9/12, Gunnar Hellström wrote: >>> I do not think that the current specification in phonebcp is very >>> realistic, with just a loopback. I think the test server could just >>> as well generate some own initial test media and then possibly also >>> mirror some packets when received. The current behavior of the >>> media-loopback to wait for incoming media before it generates any >>> outgoing media is not similar to what will be the scenario in real >>> calls. Both sides in real calls normally take initiative to media >>> transmission after the session is established. The resulting >>> problems for NAT traversal of the current media-loopback draft is >>> one of the issues that has caused its delay. >> >> So, maybe you can incorporate this into the suggested text, or >> perhaps this is implied by "Both the PSAP and the User Agent SHOULD >> send media contents," in which case maybe it can be made more explicit. >> >> Also, just wondering if "A PSAP accepting a test call SHOULD accept >> all media in the offer for which it has coresponding codecs" should >> maybe be worded "all media in the offer which it would accept had the >> call been a non-test emergency call." Maybe there's no difference, >> in which case no change is needed; I am just wondering if there might >> be situations in which a PSAP has codecs but wouldn't accept the >> media in a non-test emergency call, perhaps because it's video and >> the sign language interpreter is not available, or whatever? (I >> didn't see any requirement in phonebcp when I looked now about >> accepting all media for which it has codecs.) >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From HKaplan@acmepacket.com Sun Mar 25 00:26:28 2012 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 2073321F8499 for ; Sun, 25 Mar 2012 00:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 gYc+sDdng4Tc for ; Sun, 25 Mar 2012 00:26:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C68421F849A for ; Sun, 25 Mar 2012 00:26:27 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 03:26:17 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 03:26:17 -0400 From: Hadriel Kaplan To: Brian Rosen Thread-Topic: [Ecrit] PSAP Callback - A New Beginning Thread-Index: AQHNCliQtxPp0ZHAxEe3bTzgE8Za/Q== Date: Sun, 25 Mar 2012 07:26:16 +0000 Message-ID: References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3D914C45@ESESSCMS0356.eemea.ericsson.se> <3D40B922-E458-4C20-B2F7-CD61E5B3BFDB@brianrosen.net> In-Reply-To: <3D40B922-E458-4C20-B2F7-CD61E5B3BFDB@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - A New Beginning 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, 25 Mar 2012 07:26:28 -0000 On Feb 20, 2012, at 8:54 AM, Brian Rosen wrote: > I don't have a problem with a nonce. > We require TLS protection of signaling (because of privacy concerns carry= ing location and other personal information), which would protect the nonce= from misuse. > But, can't the UA and his system construct the contact to contain the non= ce if it wants to, with no involvement of the PSAP? >=20 It could, but there's zero guarantee it will make it to the PSAP's end syst= em, to be used for the callback. B2BUAs along the way can (and often do) r= eplace the INVITE's Contact. -hadriel From HKaplan@acmepacket.com Sun Mar 25 00:26:28 2012 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 EFE0E21F8499 for ; Sun, 25 Mar 2012 00:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csSmhVkshqba for ; Sun, 25 Mar 2012 00:26:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C577F21F849B for ; Sun, 25 Mar 2012 00:26:27 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 03:26:19 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 03:26:19 -0400 From: Hadriel Kaplan To: Brian Rosen Thread-Topic: [Ecrit] Phonebcp issues Thread-Index: AQHNCliRU3QkLOch8UCqSAHk+HEVAA== Date: Sun, 25 Mar 2012 07:26:18 +0000 Message-ID: <2F882A6A-7A8E-4D45-8808-53851CC05C17@acmepacket.com> References: <4F59E8D5.4060902@omnitor.se> <999913AB42CC9341B05A99BBF358718D01342BA4@FIESEXC035.nsn-intra.net> <1F8E9410-52BE-4D56-ACED-263BE15C2F4A@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Ecrit Subject: Re: [Ecrit] Phonebcp issues 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, 25 Mar 2012 07:26:29 -0000 Howdy, I was appointed editor of the media-loopback draft at the last IETF meeting= . Draft-17 was posted a couple weeks ago, resolving the 34 editorial comments= from WGLC. There's also going to be another rev submitted today, Draft-18, as soon as = the submission tool opens again. Draft-18 resolves 35 of the 37 technical = comments from WGLC. The remaining two were not doc change requests, but mo= re procedural (like posting it to ietf-types@iana.org). Draft-18 was actua= lly complete a couple weeks ago as well, but I missed the submission deadli= ne due to my own stupidity. I did email draft-18 a couple weeks ago to the= people who had submitted the WGLC comments, off-list, to see if they were = ok with the changes, and have not gotten any negative feedback so far; so I= 'm hopeful it'll be final. I believe this resolves all outstanding WGLC comments, but it's a lot of ch= anges so it may well hit a snag in the next WGLC. -hadriel On Mar 12, 2012, at 12:13 PM, Brian Rosen wrote: > Hadriel says there will be a new version of media-loopback today. >=20 > Brian > On Mar 11, 2012, at 2:23 PM, Brian Rosen wrote: >=20 >> It's a pretty key capability, given NATs and other middle boxes, to make= sure the media path will work. It's optional, but it's very useful. >>=20 >> I don't see how you could make any kind of normative change without WG c= onsensus to the change, and that would need a review cycle, >>=20 >> I sent a query into Hadriel Kaplan, who was appointed by the WG chairs = to get the document out the door. >>=20 >> I'll let you know what I find out. >>=20 >> Brian >>=20 >> On Mar 11, 2012, at 11:13 AM, Hannes Tschofenig wrote: >>=20 >>> Going back to the working group is indeed a difficult issue. I have exp= erienced that already within the GEOPRIV working group and it stalled the w= ork for years. I do, however, wonder whether this is entirely necessary. Is= n't there a shorter route where the working group needs to approve the chan= ge of the issue. I would even be OK with saying that this entire media loop= back functionality is optional and to turn it into an informative reference= .=20 >>>=20 >>> Another option is to "motivate" the authors of draft-ietf-mmusic-media-= loopback to get their work done. There are unfortunately 6 authors on that = document and without knowing the history I could imagine that nobody feels = responsible for pushing it forward.=20 >>>=20 >>> In any case, we need to do something. Just waiting isn't an option.=20 >>>=20 >>> On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote: >>>=20 >>>> To do this, we would have to take the document back into the working g= roup, make changes, and run through the approval process. >>>>=20 >>>> I think this is something we should consult with ADs before we do anyt= hing. >>>>=20 >>>> I don't have a problem with making the changes. I'm just looking for = the path of least resistance. >>>>=20 >>>> Brian >>>>=20 >>>> On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>=20 >>>>> Hi Gunnar,=20 >>>>> Hi all,=20 >>>>>=20 >>>>> I agree with you regarding the dependency to the media loopback docum= ent.=20 >>>>> The required functionality for PhoneBCP is actually pretty simple.=20 >>>>>=20 >>>>> I would be in favor of untangling the dependency to draft-ietf-mmusic= -media-loopback.=20 >>>>>=20 >>>>> For the SRTP media security I would suggest to go for MUST implement = SDES and SHOULD implement DTLS-SRTP.=20 >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf >>>>>> Of ext Gunnar Hellstr=F6m >>>>>> Sent: Friday, March 09, 2012 1:26 PM >>>>>> To: Ecrit >>>>>> Subject: [Ecrit] Phonebcp issues >>>>>>=20 >>>>>> The final publication of draft-ietf-ecrit-phonebcp has now been hang= ing >>>>>> waiting 7 months for draft-ietf-mmusic-media-loopback to be finalize= d >>>>>> because it is referenced in the test section. >>>>>> The status of the media-loopback draft is that it seems to be less >>>>>> ready >>>>>> now than 7 months ago. >>>>>>=20 >>>>>> This makes in fact even RFC 6443 impossible to implement, because RF= C >>>>>> 6443 refers to phonebcp for specification of the testing procedure >>>>>>=20 >>>>>> I wonder if it is time to pull phonebcp loose from the dependency of >>>>>> the >>>>>> media-loopback draft and specify a simple test method of its own >>>>>> instead. I do not think that the current specification in phonebcp i= s >>>>>> very realistic, with just a loopback. I think the test server could >>>>>> just >>>>>> as well generate some own initial test media and then possibly also >>>>>> mirror some packets when received. The current behavior of the >>>>>> media-loopback to wait for incoming media before it generates any >>>>>> outgoing media is not similar to what will be the scenario in real >>>>>> calls. Both sides in real calls normally take initiative to media >>>>>> transmission after the session is established. The resulting problem= s >>>>>> for NAT traversal of the current media-loopback draft is one of the >>>>>> issues that has caused its delay. >>>>>>=20 >>>>>> Another small issue: RFC 6443 recommends SRTP to be used for media >>>>>> security, but phonebcp does not mention media security. >>>>>> phonebcp is approved, so I do not think it is appropriate to open it >>>>>> for >>>>>> such additions. Can this gap be covered in some additional draft, or >>>>>> can >>>>>> we rely on implementors to apply both phonebcp and RFC 6443? >>>>>>=20 >>>>>> Gunnar >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Sun Mar 25 00:44:42 2012 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 15B0121F85C9 for ; Sun, 25 Mar 2012 00:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 MTaD6Bx-nV21 for ; Sun, 25 Mar 2012 00:44:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 37CBE21F85C7 for ; Sun, 25 Mar 2012 00:44:41 -0700 (PDT) Received: (qmail invoked by alias); 25 Mar 2012 07:44:39 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp070) with SMTP; 25 Mar 2012 09:44:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+f/15kMqufu/iTOKk8Elrl8WwuEI1TGnfdRl1RQC HwsQvswA74DbO/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 23 Mar 2012 13:59:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90B84E43-D183-47F3-80D0-56517D9AFB8C@gmx.net> References: To: Laura Liess X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comment on draft-ietf-ecrit-additional-data 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, 25 Mar 2012 07:44:42 -0000 Hi Laura,=20 I fully understand your point.=20 I think it is useful for us to think about these types of extensibility = stories already as early as possible.=20 Ciao Hannes On Mar 23, 2012, at 1:11 PM, Laura Liess wrote: > Hi, >=20 > Sometimes national regulatory bodies have specific requirements about > additional data they want to be sent to the PSAP (this is the case in > Germany for the mobile networks). Also I hear from my colleagues in > 3GPP that they would eventually need additional data for eCall. >=20 > I think it would be very usefull to have a mechanism which enables > national regulatory bodies and SDOs to add, in the future, new XML > elements, without having to write an RFC, but having to pass the new > XML elements through an IETF/ecrit expert review. (We have such kind > of extension mechanism in RFC 5774 for civic adresses.) > If we don't do that, different countries will use different, often > inappropriate SIP-headers to carry the data required by the local > regulation. (I know about such discussions in Germany.) I think we > should try to avoid this to happen. >=20 > Thanks a lot > Laura > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Sun Mar 25 10:08:35 2012 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 66B7B21F84F5 for ; Sun, 25 Mar 2012 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 4yJnPWWbs3ax for ; Sun, 25 Mar 2012 10:08:34 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id DE81E21F84FD for ; Sun, 25 Mar 2012 10:08:34 -0700 (PDT) X-ASG-Debug-ID: 1332695309-0491e50f904765b0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id xu6AVbjM98m0osCz; Sun, 25 Mar 2012 10:08:29 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.23]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SBqvb-000Uzd-4t; Sun, 25 Mar 2012 10:08:28 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: MIME types in additional-data Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Sun, 25 Mar 2012 13:08:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <008D1AC4-97D4-4AF3-9758-13F78AA72ACD@brianrosen.net> References: To: Randall Gellens X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1332695309 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] MIME types in additional-data 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, 25 Mar 2012 17:08:35 -0000 That's a decent idea. Any objections? Brian On Mar 24, 2012, at 4:21 PM, Randall Gellens wrote: > Perhaps the MIME types being registered in additional-data should be = more clearly associated with emergency calls, e.g., >=20 > 'application/emergencyCall-addDataProviderInfo+xml' > 'application/emergencyCall-addCallSvcInfo+xml' > 'application/emergencyCall-addDataDevInfo+xml' > 'application/emergencyCall-addCallSub+xml' >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The first rule is, you must not fool yourself. And you are the > easiest person to fool. --Richard Feynman From hannes.tschofenig@gmx.net Tue Mar 27 07:26:20 2012 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 33B4021F88ED for ; Tue, 27 Mar 2012 07:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 oIR-3PJVw1dx for ; Tue, 27 Mar 2012 07:26:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EDAA221F88EC for ; Tue, 27 Mar 2012 07:26:17 -0700 (PDT) Received: (qmail invoked by alias); 27 Mar 2012 14:26:16 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp032) with SMTP; 27 Mar 2012 16:26:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wK7Imh7Ow/w6y+q1gTi0glSc2T3P2IuykVIgoR7 qvOu4KQOkD2Nyl Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Tue, 27 Mar 2012 17:26:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <983FCC47-00DC-47E1-8B36-72130D0FCB3E@gmx.net> References: To: Roger Marshall X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] IETF83 ECRIT Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:26:20 -0000 I would like to suggest modifications to the agenda.=20 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Richard = Barnes, Roger Marshall) 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss recent updates based on comments & see if ready for = WGLC 10 min * LoST Sync for Service Boundaries and Mapping Element (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ Intention: Discuss changes made in response to the reviews [hannes] I will talk about the LoST sync changes.=20 20 min. * Public Safety Answering Point (PSAP) Callbacks = (Hannes/Christer) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Intention: Discuss latest changes based on mailing list comments [hannes] we need to figure out how we move forward with this. we are = really stuck.=20 10 min. * Extensions to the Emergency Services Architecture for dealing = with Unauthenticated and Unauthorized Devices (Dirk) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss updates/clarifications and closed issues [hannes] dirk cannot make it to this meeting. I suggest to skip this = presentation.=20 20 min * Data-Only Emergency Calls (Hannes/Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates based on comments & see if ready for = WGLC [hannes] I could speak about the implemented changes agreed at the last = IETF meeting. ] 20 min * XMPP for Emergency Services (presenter Hannes) http://datatracker.ietf.org/doc/draft-tschofenig-ecrit-xmpp-es/ Intention: Discuss new draft written in response to the discussions = around introducing XMPP support into emergency services organizations 10 min. * Open Discussion On Mar 15, 2012, at 1:50 AM, Roger Marshall wrote: > The ECRIT proposed agenda has been uploaded and can be viewed at: = http://www.ietf.org/proceedings/83/agenda/agenda-83-ecrit.txt > =20 > Please comment ahead of the meeting if you=92d like to see any changes = made to it. > =20 > Regards, > =20 > -roger marshall > ecrit secretary > 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. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From iesg-secretary@ietf.org Wed Mar 28 05:17:06 2012 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 7D99F21E81B2; Wed, 28 Mar 2012 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 l+fhEqOv0hkL; Wed, 28 Mar 2012 05:17:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A6F21E81A9; Wed, 28 Mar 2012 05:17:05 -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.00 Message-ID: <20120328121705.6917.45458.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 05:17:05 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements) to Experimental RFC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:17:06 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' as an Experimental RFC 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 2012-04-18. 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 Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1257/ From pkyzivat@alum.mit.edu Wed Mar 28 05:31:15 2012 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 3E57F21E8197 for ; Wed, 28 Mar 2012 05:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] 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 kWrl7Ae-Ac0h for ; Wed, 28 Mar 2012 05:31:14 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 92EEA21E8195 for ; Wed, 28 Mar 2012 05:31:14 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id qzlB1i0021ZXKqc590XEQH; Wed, 28 Mar 2012 12:31:14 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta21.westchester.pa.mail.comcast.net with comcast id r0X51i01A5EhBnE3h0X7Ra; Wed, 28 Mar 2012 12:31:12 +0000 Message-ID: <4F730487.5040101@alum.mit.edu> Date: Wed, 28 Mar 2012 14:31:03 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] PSAP callbacks 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, 28 Mar 2012 12:31:15 -0000 Having just had the discussion of this in the meeting, I just realized what must be the attack that Christer, Andrew, etc. have in mind: If a "carrier" has a user/device who has been "barred" - prevented from initiating or receiving calls, except for emergency calls, then it wants to ensure that it only delivers "legitimate" emergency callbacks to that user. In this case that carrier won't find it sufficient to trust caller assertions that this is an emergency callback. Complicit callers could reach this barred phone by suitably marking their calls. But how much *standard* machinery is needed to protect against that? Could this not be mitigated to a sufficient degree via private means? Presumably this doesn't need to be 100% reliable - if some small number of calls can leak through to barred phones that could be an acceptable tradeoff. Aside from this case I think it could be sufficient to honor the caller's intent until the call reaches something that is in a position to remember when the last emergency call occurred. That thing can then apply policy to decide whether to accept the call, and whether to prioritize it or not. So maybe the barring case can be considered separately. Thanks, Paul