From mailman-bounces@core3.amsl.com Fri Feb 1 06:18:56 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51997294D81 for ; Fri, 1 Feb 2008 06:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH6eIdPfjpqU for ; Fri, 1 Feb 2008 06:18:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F27C294802 for ; Fri, 1 Feb 2008 05:51:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: speermint-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:39 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/speermint/speermint-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:19:42 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A9328E292 for ; Fri, 1 Feb 2008 06:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1km6FOfR6lM for ; Fri, 1 Feb 2008 06:19:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D658A28CD3F for ; Fri, 1 Feb 2008 05:51:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: speermint-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:41 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/speermint/speermint-archive%40megatron.ietf.org From speermint-bounces@ietf.org Fri Feb 1 06:39:16 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9CA28DCE5; Fri, 1 Feb 2008 06:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK7j39S+I9X7; Fri, 1 Feb 2008 06:39:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE7A29594F; Fri, 1 Feb 2008 06:15:29 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A507C294293; Fri, 1 Feb 2008 05:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKxnDkug8L+3; Fri, 1 Feb 2008 05:51:07 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id AE75F28CBA4; Fri, 1 Feb 2008 05:26:41 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKvwB-00040Z-0R; Fri, 01 Feb 2008 07:28:11 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> Date: Fri, 1 Feb 2008 08:28:11 -0500 Message-ID: <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5Wg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I have some conflicting thoughts on this. It should be possible for a phone to send the call itself direct to the PSAP URI. The emergency call system should be able to handle that. On the other hand, carriers are generally thought of as useful partners by the emergency call system, and a recommendation that they be bypassed won't be appreciated by those folks even if there is an engineering argument that it's more efficient. Part of the reason is track and trace. Part of the reason is subscriber name and address. The big one is identity. Carriers provide reasonably verified identity. So, on balance, I think phonebcp should say, as it does now, that phones pass emergency calls to wherever they normally pass outbound calls. Frankly, the number of special processing steps we're asking phones to do for emergency calls is getting too high. I'd rather figure out ways to remove some special processing, not add more. Presently phones have to: *Get location and do LoST lookups *Watch for emergency dial strings *Add Geolocation headers, PSAP URIs and service urns *Disable some features *Not send bye If anything, that list is too long. As with most things like it, the more special stuff you do for emergencies, the less likely it is to actually work in an emergency. Generally, I think phones knowing where they are is a good thing in the big picture, and having the phone do all dial plan interpretation is the right thing also. So the real special processing is the last three. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, January 31, 2008 11:31 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > We need to note the points where we are actually in agreement. Perhaps > there was an inference that we weren't with respect to the following: > > 1. The access network provider (the one that gets you onto the Internet) > should not be responsible for providing any kind of emergency call > processing. > > 2. The access network provider does need to provide a location service > that can be used for emergency call processing > > 3. The LoST service with the translations for that point of access needs > to be available from that point of access. Somebody is actually > responsible for the physical infrastructure that supports it but it > doesn't have to be the access provider - just so long as it's > discoverable from the access. > > I am in agreement with these principles - nothing I said below was > inconsistent with them. > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > distinguishes between the circumstance where a device does this versus > trying to send the call through its VSP? It may be because the specific > implementation of the VoIP client that the caller is using simply > decides to do that. This includes the possibility that the client > doesn't know its actually an emergency call and leaves it up to the VSP > to do the digit analysis. It includes the case where the VoIP client > doesn't know anything about ECRIT and just sends all calls to the VSP. > > I don't think in this decision that's governed by the nature of the > access is there? If not, discussion about NATs etc seem irrelevant to > me. In fact, my standard "nomadic" VoIP service is Skype. In my office, > our IS masters don't let Skype work. It's very difficult to guarantee > that arbitrary VSP access is going to work from arbitrary access points. > It's much simpler to guarantee that SIP calling directly to the relevant > PSAP URIs for those points of access will always work. I think details > such as whether an enterprise VoIP server is the thing that makes the > PSAP call is just that - a detail. In such an environment, the clients > and the server are part of the same package anyway. It's not at all the > same situation as bringing Vonage, for example, into the picture when an > emergency call is made. > > When it comes to phone BCP, it should be quite possible to say that the > phone client should always work to the local network and direct the call > directly to the PSAP. This, in my view, is what pure-ECRIT should be > about. It should also be possible to say that if the phone can only dial > digits that are processed by the VSP, then subsequent behaviour is out > of scope (but here's some suggestions). The NENA i2 architecture already > has this covered and it's being picked up internationally anyway. It's > an interim architecture; it'll go away as jurisdictions implement LoST > and IP PSAP services and VoIP clients learn to use those functions. It > would be preferable that, when the interim solution does disappear, that > VSPs no longer need to have a role or responsibility for providing > emergency access. It would be better for all concerned if they did not. > > Here's the logic: > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > i2. > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > 3.Phone can find LIS and LoST - call PSAP directly > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 1 February 2008 3:56 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > First my response to the original question: > > IMS is special because the visited network is in the call path. When > the > visited network has active elements in the call path, it makes sense to > have > the visited network handle emergency calls. Note that there are lots > and > lots of complications with this. Take for example, call back. What you > want is to have both a Contact URI that will route back to the device > that > placed the call, and you need a real AoR you can use to reach the caller > later on. The visited network would have to provide both. > > When the visited network is not in the call path, you have to use the > VSP. > > > Then my response to Martin: > > It's been said that the emergency service wants the subscriber details > > from the VSP. A caller can have subscriptions to lots of Internet > > services that also don't need to be involved in the call. Should we > also > > make emergency calling dependent on them? > No. However, involving the actual carrier that provides the service > that is > placing the call is essential. Bypassing the carrier that provides the > service that places the call is pretty tough, except in unusual > circumstances. IMS is an example of an unusual circumstance because > they > put the visited network in the call path. Very few other systems do > that. > > I'm very conscious of what we must ask the access network to provide. > This > has lots of implications on engineering as well as cost and liability. > Unless the device itself can locate itself without assistance of the > access > network, we ask the access network to provide location (or at least > location > assistance). We ask them to provide access to a LoST server. I want to > stop there. That's all they have to do. > > > > > I don't think it has to be the same as IMS. IMS requires a > co-operative > > E-CSCF that is actually part of the access network. With LoST and a > > suitable emergency proxy, there doesn't have to be any dependency on > the > > access network to also provide call processing. > IMS is different as discussed above. > > > > > Not involving the VSP in the call does not mean that the caller cannot > > provide callback details (in principle, they could provide multiple > > callback options). I'd also be interested in a discussion around > > providing an automatic presence subscription from the emergency > network > > itself - with a temporary callback number. As long as the emergency > > calling device is attached to the Internet, it should be able to stay > > registered with that temporary subscription and also do regular > location > > updates to it. > I think the notion that we can define the characteristics of an > emergency > proxy that works for all devices is not feasible. Let me cite a few > examples: > > Emergency call from AOL/MSN/Yahoo. We would have to require the device > to > implement SIP/SIMPLE. > > Emergency call from OnStar. Who is the emergency proxy provider? > > Emergency call from "Help I've fallen and I can't get up" buttons with > two > way audio. They would have to meet all of the phonebcp requirements. > > Call backs are an issue. You can get a contact URI, but you can't get > an > AoR you have any trust in for any call. > > But the biggest problem is that I think any attempt to give the access > network the obligation and the liability to totally handle emergency > calls > will not fly. > > > > > > Many of the most convoluted issues that have arisen in this forum have > > been around the challenges that having the VSP involved in call > routing > > introduces (the need for forest guides etc). Since direct-calling is a > > valid option, I know I'd prefer an emergency calling client that > always > > worked that way. > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 1 09:17:20 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0224D3A6978; Fri, 1 Feb 2008 09:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik8IQfmNdASA; Fri, 1 Feb 2008 09:17:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F003E3A69A5; Fri, 1 Feb 2008 09:17:16 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCA23A67EA; Fri, 1 Feb 2008 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xldg5GKCfcW; Fri, 1 Feb 2008 09:17:15 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ED48F3A687D; Fri, 1 Feb 2008 09:17:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,291,1199682000"; d="scan'208";a="85237425" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2008 12:18:36 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m11HIZRi015023; Fri, 1 Feb 2008 12:18:35 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m11HIV7q016557; Fri, 1 Feb 2008 17:18:32 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 12:18:32 -0500 Received: from [161.44.174.133] ([161.44.174.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 12:18:31 -0500 Message-ID: <47A3546D.7000808@cisco.com> Date: Fri, 01 Feb 2008 12:18:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Brian Rosen References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> In-Reply-To: <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 01 Feb 2008 17:18:31.0993 (UTC) FILETIME=[781C9290:01C864F6] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "'Dawson, Martin'" , 'ECRIT' , speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org comments near end. Brian Rosen wrote: > I have some conflicting thoughts on this. It should be possible for a phone > to send the call itself direct to the PSAP URI. The emergency call system > should be able to handle that. > > On the other hand, carriers are generally thought of as useful partners by > the emergency call system, and a recommendation that they be bypassed won't > be appreciated by those folks even if there is an engineering argument that > it's more efficient. > > Part of the reason is track and trace. Part of the reason is subscriber > name and address. The big one is identity. Carriers provide reasonably > verified identity. > > So, on balance, I think phonebcp should say, as it does now, that phones > pass emergency calls to wherever they normally pass outbound calls. > Frankly, the number of special processing steps we're asking phones to do > for emergency calls is getting too high. I'd rather figure out ways to > remove some special processing, not add more. > > Presently phones have to: > *Get location and do LoST lookups > *Watch for emergency dial strings > *Add Geolocation headers, PSAP URIs and service urns > *Disable some features > *Not send bye > > If anything, that list is too long. As with most things like it, the more > special stuff you do for emergencies, the less likely it is to actually work > in an emergency. > > Generally, I think phones knowing where they are is a good thing in the big > picture, and having the phone do all dial plan interpretation is the right > thing also. So the real special processing is the last three. ??? The last three are: > *Add Geolocation headers, PSAP URIs and service urns If you expect the phone to be the one that knows where it is, then how can you delegate adding the geoloc headers to somebody else? > *Disable some features Well, features that are provided by the SP can be disabled by the SP. But features provided by the phone have to be disabled there. > *Not send bye I don't understand what you have in mind here. If you don't disable sending bye, then it will be sent on hangup. There is nothing you can do in the network to prevent it. As I see it, the key things the phone must do itself are: - obtain its location - recognize the dial string(s) that identify emergency calls and insert service URN & geoloc info - disable features that are implemented on the phone. The rest could be done by some server on the path. The recognition of emergency numbers could be a shared responsibility. If a number wasn't recognized by the phone, an upstream entity that is in a position to recognize it as such could return a 3xx containing the service URN. That would clue the phone in to trigger the special processing. Paul > > Brian > > > >> -----Original Message----- >> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: Thursday, January 31, 2008 11:31 PM >> To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT >> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering >> >> We need to note the points where we are actually in agreement. Perhaps >> there was an inference that we weren't with respect to the following: >> >> 1. The access network provider (the one that gets you onto the Internet) >> should not be responsible for providing any kind of emergency call >> processing. >> >> 2. The access network provider does need to provide a location service >> that can be used for emergency call processing >> >> 3. The LoST service with the translations for that point of access needs >> to be available from that point of access. Somebody is actually >> responsible for the physical infrastructure that supports it but it >> doesn't have to be the access provider - just so long as it's >> discoverable from the access. >> >> I am in agreement with these principles - nothing I said below was >> inconsistent with them. >> >> Direct to PSAP-URI calling is a supported mode of operation, yes? What >> distinguishes between the circumstance where a device does this versus >> trying to send the call through its VSP? It may be because the specific >> implementation of the VoIP client that the caller is using simply >> decides to do that. This includes the possibility that the client >> doesn't know its actually an emergency call and leaves it up to the VSP >> to do the digit analysis. It includes the case where the VoIP client >> doesn't know anything about ECRIT and just sends all calls to the VSP. >> >> I don't think in this decision that's governed by the nature of the >> access is there? If not, discussion about NATs etc seem irrelevant to >> me. In fact, my standard "nomadic" VoIP service is Skype. In my office, >> our IS masters don't let Skype work. It's very difficult to guarantee >> that arbitrary VSP access is going to work from arbitrary access points. >> It's much simpler to guarantee that SIP calling directly to the relevant >> PSAP URIs for those points of access will always work. I think details >> such as whether an enterprise VoIP server is the thing that makes the >> PSAP call is just that - a detail. In such an environment, the clients >> and the server are part of the same package anyway. It's not at all the >> same situation as bringing Vonage, for example, into the picture when an >> emergency call is made. >> >> When it comes to phone BCP, it should be quite possible to say that the >> phone client should always work to the local network and direct the call >> directly to the PSAP. This, in my view, is what pure-ECRIT should be >> about. It should also be possible to say that if the phone can only dial >> digits that are processed by the VSP, then subsequent behaviour is out >> of scope (but here's some suggestions). The NENA i2 architecture already >> has this covered and it's being picked up internationally anyway. It's >> an interim architecture; it'll go away as jurisdictions implement LoST >> and IP PSAP services and VoIP clients learn to use those functions. It >> would be preferable that, when the interim solution does disappear, that >> VSPs no longer need to have a role or responsibility for providing >> emergency access. It would be better for all concerned if they did not. >> >> Here's the logic: >> >> 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke >> i2. >> 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 >> 3.Phone can find LIS and LoST - call PSAP directly >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Friday, 1 February 2008 3:56 AM >> To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' >> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering >> >> First my response to the original question: >> >> IMS is special because the visited network is in the call path. When >> the >> visited network has active elements in the call path, it makes sense to >> have >> the visited network handle emergency calls. Note that there are lots >> and >> lots of complications with this. Take for example, call back. What you >> want is to have both a Contact URI that will route back to the device >> that >> placed the call, and you need a real AoR you can use to reach the caller >> later on. The visited network would have to provide both. >> >> When the visited network is not in the call path, you have to use the >> VSP. >> >> >> Then my response to Martin: >>> It's been said that the emergency service wants the subscriber details >>> from the VSP. A caller can have subscriptions to lots of Internet >>> services that also don't need to be involved in the call. Should we >> also >>> make emergency calling dependent on them? >> No. However, involving the actual carrier that provides the service >> that is >> placing the call is essential. Bypassing the carrier that provides the >> service that places the call is pretty tough, except in unusual >> circumstances. IMS is an example of an unusual circumstance because >> they >> put the visited network in the call path. Very few other systems do >> that. >> >> I'm very conscious of what we must ask the access network to provide. >> This >> has lots of implications on engineering as well as cost and liability. >> Unless the device itself can locate itself without assistance of the >> access >> network, we ask the access network to provide location (or at least >> location >> assistance). We ask them to provide access to a LoST server. I want to >> stop there. That's all they have to do. >> >>> I don't think it has to be the same as IMS. IMS requires a >> co-operative >>> E-CSCF that is actually part of the access network. With LoST and a >>> suitable emergency proxy, there doesn't have to be any dependency on >> the >>> access network to also provide call processing. >> IMS is different as discussed above. >> >>> Not involving the VSP in the call does not mean that the caller cannot >>> provide callback details (in principle, they could provide multiple >>> callback options). I'd also be interested in a discussion around >>> providing an automatic presence subscription from the emergency >> network >>> itself - with a temporary callback number. As long as the emergency >>> calling device is attached to the Internet, it should be able to stay >>> registered with that temporary subscription and also do regular >> location >>> updates to it. >> I think the notion that we can define the characteristics of an >> emergency >> proxy that works for all devices is not feasible. Let me cite a few >> examples: >> >> Emergency call from AOL/MSN/Yahoo. We would have to require the device >> to >> implement SIP/SIMPLE. >> >> Emergency call from OnStar. Who is the emergency proxy provider? >> >> Emergency call from "Help I've fallen and I can't get up" buttons with >> two >> way audio. They would have to meet all of the phonebcp requirements. >> >> Call backs are an issue. You can get a contact URI, but you can't get >> an >> AoR you have any trust in for any call. >> >> But the biggest problem is that I think any attempt to give the access >> network the obligation and the liability to totally handle emergency >> calls >> will not fly. >> >> >>> Many of the most convoluted issues that have arisen in this forum have >>> been around the challenges that having the VSP involved in call >> routing >>> introduces (the need for forest guides etc). Since direct-calling is a >>> valid option, I know I'd prefer an emergency calling client that >> always >>> worked that way. >> >> >> -------------------------------------------------------------------------- >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> -------------------------------------------------------------------------- >> ---------------------- >> [mf2] > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 1 14:08:13 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F7A28C465; Fri, 1 Feb 2008 14:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODK6qwQ89Luo; Fri, 1 Feb 2008 14:08:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CEF3A68B1; Fri, 1 Feb 2008 14:08:12 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D86928C22C for ; Fri, 1 Feb 2008 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To1ykxjrMY1S for ; Fri, 1 Feb 2008 14:08:09 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CE1143A6888 for ; Fri, 1 Feb 2008 14:08:09 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m11M9e4D007004; Fri, 1 Feb 2008 15:09:41 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 1 Feb 2008 15:09:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 15:09:40 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0C9C@srvxchg3.cablelabs.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJwABS+aJAAgk7egA== References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> From: "Daryl Malas" To: "Elwell, John" , X-Approved: ondar Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org John, Thank you for the quick response. Comments in-line... -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Wednesday, January 30, 2008 12:47 AM To: Daryl Malas; speermint@ietf.org Subject: RE: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Daryl, Thanks, it's getting there. A few more things I noticed: 1. The document uses the words "application" and "session" in a number of places, and I feel there may be some inconsistency. For example: "A SIP Service Provider (or SSP) is an entity that provides application services utilizing SIP signaling to its customers." Should it really be "application services", or should it be "session services". Consider a service provider that provides no more than SIP proxy functionality. It can hardly be said to provide application services to its users, so according to the definition it is not an SSP. There is just one other instance of "application". I wonder if the two instances should be changed to "session". [DM] I think the confusion here is SIP is an application-layer control protocol, which is used to create sessions. I will check the uses of application again, and will consider changing to "session". I do not see a problem with it. 2. "In some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary." Two comments. First, should "peering assistance" be changed to "assistance". [DM] I think it means the same thing. Second, this paragraph occurs within 4.3.2 on LRF. Should a similar statement be added to 4.3.1 on LuF? [DM] The reason why it is only in the LRF section, is because the LUF is simply a mechanism. It is used to query either an internal or an "assisting" server. No one can assist with the mechanism. 3. "In this case it is generally required that a trust relationship is established between the originating SSP and the transit network on one side; and, the transit network representing the termination network on the other side." Two comments: First, in order to complement the first part, should the latter part be rewritten as "; and the transit network and the terminating SSP on the other side."? [DM] It appears to me you just would like to change "network" to "SSP", is this correct?! Second, on the use of the term "transit network". Is this intentional, or would it be better to talk about "transit SSP". In this context a transit network must provide functionality at the session layer (otherwise it would not be considered as indirect peering), so doesn't this make it an SSP? [DM] I agree. The context of 4.2.2 is Layer 5 peering, so I think both "network" instances should be corrected to "SSP's". John > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: 29 January 2008 21:41 > To: speermint@ietf.org > Subject: [Speermint] RE: I-D > Action:draft-ietf-speermint-terminology-15.txt > > This version of the draft includes updates to the following sections: > > Section 2. Context > Section 4.2.3 Assisted Peering (REMOVED) Section 4.3.1 Location > Routing Function Section 4.3.2 Location Routing Function (Previously > Look-Up Function) Section 5 - Minor add to "Common dynamic policies" > Section 9 & 10 > > --Daryl > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, January 29, 2008 2:10 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D > Action:draft-ietf-speermint-terminology-15.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session PEERing for Multimedia > INTerconnect Working Group of the IETF. > > > Title : SPEERMINT Terminology > Author(s) : D. Malas, D. Meyer > Filename : draft-ietf-speermint-terminology-15.txt > Pages : 12 > Date : 2008-01-29 > > This document defines the terminology that is to be used in describing > Session PEERing for Multimedia INTerconnect (SPEERMINT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > nology-15. > txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-speermint-terminology-15.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Feb 3 01:14:27 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBE63A6C07; Sun, 3 Feb 2008 01:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_05=-1.11, HELO_EQ_DE=0.35, SARE_RECV_BEZEQINT_B=0.763] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOuRlXHIe0xI; Sun, 3 Feb 2008 01:14:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F7B3A6BD2; Sun, 3 Feb 2008 01:14:27 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05FB3A6BD2 for ; Sun, 3 Feb 2008 01:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH9idC1Jg7uD for ; Sun, 3 Feb 2008 01:14:25 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by core3.amsl.com (Postfix) with ESMTP id CD5B33A6BBD for ; Sun, 3 Feb 2008 01:14:24 -0800 (PST) Received: from [10.0.1.196] (bzq-219-131-200.static.bezeqint.net [62.219.131.200]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JLax904mR-00028M; Sun, 03 Feb 2008 10:15:56 +0100 Message-Id: <41BB6A96-92FD-49D7-92F6-8F2465908589@xconnect.net> From: David Schwartz To: "Daryl Malas" In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0C9C@srvxchg3.cablelabs.com> Mime-Version: 1.0 (Apple Message framework v912) Date: Sun, 3 Feb 2008 11:15:53 +0200 References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA4917B0C9C@srvxchg3.cablelabs.com> X-Mailer: Apple Mail (2.912) X-Provags-ID: V01U2FsdGVkX1/DwMsi1ec77qtU98ETmTJ7oN32Vm7kQZCapjT CWEZGG1XGamXY98JuPImUnVkxNHknggYOCc05tpPv9+NAfmPGC iQB0PH5hPgpZGDiiypNRg== Cc: speermint@ietf.org Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Hi Daryl I have one comment... > > 2. "In some cases, some entity (usually a 3rd party or federation) > provides peering assistance to the originating SSP by providing this > function. The assisting entity may provide information relating to > direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > necessary." > Two comments. First, should "peering assistance" be changed to > "assistance". > [DM] I think it means the same thing. > Second, this paragraph occurs within 4.3.2 on LRF. Should a similar > statement be added to 4.3.1 on LuF? > [DM] The reason why it is only in the LRF section, is because the > LUF is > simply a mechanism. It is used to query either an internal or an > "assisting" server. No one can assist with the mechanism. > DS: I agree with John on this one. In the same way that assistance can be offered for LRF it can be offered for LUF. You yourself state "It is used to query either an internal or an assisting server". To me - this is an external server providing "assistance" for the LUF. D. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 00:55:12 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A1D3A6DDA; Mon, 4 Feb 2008 00:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b5umf2UC2pD; Mon, 4 Feb 2008 00:55:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C483A6BC3; Mon, 4 Feb 2008 00:55:11 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E6F3A6874 for ; Mon, 4 Feb 2008 00:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5USrOIBMBulN for ; Mon, 4 Feb 2008 00:55:09 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2F3873A6C46 for ; Mon, 4 Feb 2008 00:55:01 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JVP00C6TI6ATO@siemenscomms.co.uk> for speermint@ietf.org; Mon, 04 Feb 2008 08:56:34 +0000 (GMT) Date: Mon, 04 Feb 2008 08:56:32 +0000 From: "Elwell, John" In-reply-to: <160DE07A1C4F8E4AA2715DEC577DA4917B0C9C@srvxchg3.cablelabs.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0601ECC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJwABS+aJAAgk7egAB8A3KA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> <160DE07A1C4F8E4AA2715DEC577DA4917B0C9C@srvxchg3.cablelabs.com> Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Daryl, See below. John > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: 01 February 2008 22:10 > To: Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > Action:draft-ietf-speermint-terminology-15.txt > > John, > > Thank you for the quick response. Comments in-line... > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, January 30, 2008 12:47 AM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > Action:draft-ietf-speermint-terminology-15.txt > > Daryl, > > Thanks, it's getting there. A few more things I noticed: > > 1. The document uses the words "application" and "session" in a number > of places, and I feel there may be some inconsistency. For example: > "A SIP Service Provider (or SSP) is an entity that provides > application services utilizing SIP signaling to its customers." > Should it really be "application services", or should it be "session > services". Consider a service provider that provides no more than SIP > proxy functionality. It can hardly be said to provide application > services to its users, so according to the definition it is > not an SSP. > There is just one other instance of "application". I wonder if the two > instances should be changed to "session". > > [DM] I think the confusion here is SIP is an application-layer control > protocol, which is used to create sessions. I will check the uses of > application again, and will consider changing to "session". I do not > see a problem with it. > > 2. "In some cases, some entity (usually a 3rd party or federation) > provides peering assistance to the originating SSP by > providing this > function. The assisting entity may provide information > relating to > direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > necessary." > Two comments. First, should "peering assistance" be changed to > "assistance". > [DM] I think it means the same thing. > Second, this paragraph occurs within 4.3.2 on LRF. Should a similar > statement be added to 4.3.1 on LuF? > [DM] The reason why it is only in the LRF section, is because > the LUF is > simply a mechanism. It is used to query either an internal or an > "assisting" server. No one can assist with the mechanism. > > 3. "In this case it is generally required that a > trust relationship is established between the originating > SSP and the > > transit network on one side; and, the transit network representing > the termination network on the other side." > Two comments: First, in order to complement the first part, should the > latter part be rewritten as "; and the transit network and the > terminating SSP on the other side."? > [DM] It appears to me you just would like to change "network" > to "SSP", > is this correct?! [JRE] My proposed wording change went further than that. The problem is that for the "on one side" case the present words talk about the two networks between which a trust relationship is established, but for the "on the other side" case the present words mention only a single network, which doesn't make sense. > Second, on the use of the term "transit network". Is this intentional, > or would it be better to talk about "transit SSP". In this context a > transit network must provide functionality at the session layer > (otherwise it would not be considered as indirect peering), so doesn't > this make it an SSP? > [DM] I agree. The context of 4.2.2 is Layer 5 peering, so I > think both > "network" instances should be corrected to "SSP's". > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: 29 January 2008 21:41 > > To: speermint@ietf.org > > Subject: [Speermint] RE: I-D > > Action:draft-ietf-speermint-terminology-15.txt > > > > This version of the draft includes updates to the following > sections: > > > > Section 2. Context > > Section 4.2.3 Assisted Peering (REMOVED) Section 4.3.1 Location > > Routing Function Section 4.3.2 Location Routing Function > (Previously > > Look-Up Function) Section 5 - Minor add to "Common dynamic policies" > > Section 9 & 10 > > > > --Daryl > > > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 29, 2008 2:10 PM > > To: i-d-announce@ietf.org > > Cc: speermint@ietf.org > > Subject: [Speermint] I-D > > Action:draft-ietf-speermint-terminology-15.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session PEERing for Multimedia > > INTerconnect Working Group of the IETF. > > > > > > Title : SPEERMINT Terminology > > Author(s) : D. Malas, D. Meyer > > Filename : draft-ietf-speermint-terminology-15.txt > > Pages : 12 > > Date : 2008-01-29 > > > > This document defines the terminology that is to be used in > describing > > > Session PEERing for Multimedia INTerconnect (SPEERMINT). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > > nology-15. > > txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-speermint-terminology-15.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 05:54:49 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B55C3A6F6A; Mon, 4 Feb 2008 05:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kal1ui+pd8Yp; Mon, 4 Feb 2008 05:54:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629413A6D81; Mon, 4 Feb 2008 05:54:47 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA47A3A6D81; Mon, 4 Feb 2008 05:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUDxGcVI0AEj; Mon, 4 Feb 2008 05:54:43 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B147A3A6F4F; Mon, 4 Feb 2008 05:54:43 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JM1nu-0007mS-Oo; Mon, 04 Feb 2008 07:56:11 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> Date: Mon, 4 Feb 2008 08:56:11 -0500 Message-ID: <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5WgAIFfjJAAFyluAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I think we will have to agree to disagree. I noticed you ignored identity. Anyone else think the only way emergency calls should (normally) work is to have all devices place emergency calls direct to PSAPs with (normally) no proxies? Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Sunday, February 03, 2008 10:20 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > Hi Brian, > > This seems to suggest that there's a complexity argument for saying > phones should pass emergency calls however they "normally" make calls. > > If we have a precept that says it must always be possible to make a call > directly to the PSAP URI from a given point of access, then also > supporting call routing via the VSP can only add complexity. Issues such > as how do VSPs that don't use SIP work, or recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are, or > the VSP finding the right LoST server when it's not in a position to > perform local discovery are all complexities that arise by not sending > the call directly to the PSAP URI. They are all things that make the > handling of an emergency call more brittle. > > The question of what is "normal" can only become more fuzzy over time as > well. Increasingly we just have IP-enabled multimedia devices that can > have an arbitrary number of service clients/subscriptions hosted on > them. I think this is really the environment that ECRIT should be > focussed on. It's the device that should know how to initiate and > support emergency calling - not the potential multitude of other service > clients hosted on that device. > > Ideally, all devices should have practically the same implementation > that knows how to do local location and LoST service discovery and to > subsequently contact the local emergency service. Dedicated VSP client > devices could integrate such a reference implementation, provide a > mechanism to call it, and only invoke VSP-specific emergency handling if > (as I described below) the local network does not appear to support the > necessary ECRIT functions. This should result in less complexity over > time with more and more consistent implementations from the device > perspective as well as the network perspective. As long as the reference > client works, then the network is doing the right thing. > > "Track and trace" become Internet access issues. We get to the point > where we have optimal assurance that the access is local to the > emergency jurisdiction and we have all the same wherewithal with respect > to this function as we do with the PSTN - without needing to think that > VSPs are important to it. > > I think everything that ECRIT has is just about right. I just think that > the mantra about "normal call processing" has things the wrong way > around. i.e I have the opposite view to what you expressed, Brian. > Ultimately, I think VSP involvement should go away - and not actually be > the recommended approach in perpetuity. The VSP considerations should > become recommendations that are ultimately deprecated. > > Note - I understand very well that redoing documentation and recanting > on policy is a demotivator. However, now is always the best time to > change if we don't have things quite right. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Saturday, 2 February 2008 12:28 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I have some conflicting thoughts on this. It should be possible for a > phone > to send the call itself direct to the PSAP URI. The emergency call > system > should be able to handle that. > > On the other hand, carriers are generally thought of as useful partners > by > the emergency call system, and a recommendation that they be bypassed > won't > be appreciated by those folks even if there is an engineering argument > that > it's more efficient. > > Part of the reason is track and trace. Part of the reason is subscriber > name and address. The big one is identity. Carriers provide reasonably > verified identity. > > So, on balance, I think phonebcp should say, as it does now, that phones > pass emergency calls to wherever they normally pass outbound calls. > Frankly, the number of special processing steps we're asking phones to > do > for emergency calls is getting too high. I'd rather figure out ways to > remove some special processing, not add more. > > Presently phones have to: > *Get location and do LoST lookups > *Watch for emergency dial strings > *Add Geolocation headers, PSAP URIs and service urns > *Disable some features > *Not send bye > > If anything, that list is too long. As with most things like it, the > more > special stuff you do for emergencies, the less likely it is to actually > work > in an emergency. > > Generally, I think phones knowing where they are is a good thing in the > big > picture, and having the phone do all dial plan interpretation is the > right > thing also. So the real special processing is the last three. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, January 31, 2008 11:31 PM > > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > We need to note the points where we are actually in agreement. Perhaps > > there was an inference that we weren't with respect to the following: > > > > 1. The access network provider (the one that gets you onto the > Internet) > > should not be responsible for providing any kind of emergency call > > processing. > > > > 2. The access network provider does need to provide a location service > > that can be used for emergency call processing > > > > 3. The LoST service with the translations for that point of access > needs > > to be available from that point of access. Somebody is actually > > responsible for the physical infrastructure that supports it but it > > doesn't have to be the access provider - just so long as it's > > discoverable from the access. > > > > I am in agreement with these principles - nothing I said below was > > inconsistent with them. > > > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > > distinguishes between the circumstance where a device does this versus > > trying to send the call through its VSP? It may be because the > specific > > implementation of the VoIP client that the caller is using simply > > decides to do that. This includes the possibility that the client > > doesn't know its actually an emergency call and leaves it up to the > VSP > > to do the digit analysis. It includes the case where the VoIP client > > doesn't know anything about ECRIT and just sends all calls to the VSP. > > > > I don't think in this decision that's governed by the nature of the > > access is there? If not, discussion about NATs etc seem irrelevant to > > me. In fact, my standard "nomadic" VoIP service is Skype. In my > office, > > our IS masters don't let Skype work. It's very difficult to guarantee > > that arbitrary VSP access is going to work from arbitrary access > points. > > It's much simpler to guarantee that SIP calling directly to the > relevant > > PSAP URIs for those points of access will always work. I think details > > such as whether an enterprise VoIP server is the thing that makes the > > PSAP call is just that - a detail. In such an environment, the clients > > and the server are part of the same package anyway. It's not at all > the > > same situation as bringing Vonage, for example, into the picture when > an > > emergency call is made. > > > > When it comes to phone BCP, it should be quite possible to say that > the > > phone client should always work to the local network and direct the > call > > directly to the PSAP. This, in my view, is what pure-ECRIT should be > > about. It should also be possible to say that if the phone can only > dial > > digits that are processed by the VSP, then subsequent behaviour is out > > of scope (but here's some suggestions). The NENA i2 architecture > already > > has this covered and it's being picked up internationally anyway. It's > > an interim architecture; it'll go away as jurisdictions implement LoST > > and IP PSAP services and VoIP clients learn to use those functions. It > > would be preferable that, when the interim solution does disappear, > that > > VSPs no longer need to have a role or responsibility for providing > > emergency access. It would be better for all concerned if they did > not. > > > > Here's the logic: > > > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > > i2. > > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > > 3.Phone can find LIS and LoST - call PSAP directly > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 1 February 2008 3:56 AM > > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > > the > > visited network has active elements in the call path, it makes sense > to > > have > > the visited network handle emergency calls. Note that there are lots > > and > > lots of complications with this. Take for example, call back. What > you > > want is to have both a Contact URI that will route back to the device > > that > > placed the call, and you need a real AoR you can use to reach the > caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > > VSP. > > > > > > Then my response to Martin: > > > It's been said that the emergency service wants the subscriber > details > > > from the VSP. A caller can have subscriptions to lots of Internet > > > services that also don't need to be involved in the call. Should we > > also > > > make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > > that is > > placing the call is essential. Bypassing the carrier that provides > the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > > they > > put the visited network in the call path. Very few other systems do > > that. > > > > I'm very conscious of what we must ask the access network to provide. > > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > > access > > network, we ask the access network to provide location (or at least > > location > > assistance). We ask them to provide access to a LoST server. I want > to > > stop there. That's all they have to do. > > > > > > > > I don't think it has to be the same as IMS. IMS requires a > > co-operative > > > E-CSCF that is actually part of the access network. With LoST and a > > > suitable emergency proxy, there doesn't have to be any dependency on > > the > > > access network to also provide call processing. > > IMS is different as discussed above. > > > > > > > > Not involving the VSP in the call does not mean that the caller > cannot > > > provide callback details (in principle, they could provide multiple > > > callback options). I'd also be interested in a discussion around > > > providing an automatic presence subscription from the emergency > > network > > > itself - with a temporary callback number. As long as the emergency > > > calling device is attached to the Internet, it should be able to > stay > > > registered with that temporary subscription and also do regular > > location > > > updates to it. > > I think the notion that we can define the characteristics of an > > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the > device > > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > > calls > > will not fly. > > > > > > > > > > Many of the most convoluted issues that have arisen in this forum > have > > > been around the challenges that having the VSP involved in call > > routing > > > introduces (the need for forest guides etc). Since direct-calling is > a > > > valid option, I know I'd prefer an emergency calling client that > > always > > > worked that way. > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:04:16 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B1F3A7059; Mon, 4 Feb 2008 10:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqmOPYL7xfrY; Mon, 4 Feb 2008 10:04:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249833A7000; Mon, 4 Feb 2008 10:04:03 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03DA3A6F85 for ; Mon, 4 Feb 2008 10:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evlua+pcGs8L for ; Mon, 4 Feb 2008 10:03:59 -0800 (PST) Received: from mail.aus-biz.com (mail.aus-biz.com [65.23.153.184]) by core3.amsl.com (Postfix) with ESMTP id CAD9F3A7059 for ; Mon, 4 Feb 2008 10:00:25 -0800 (PST) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 8A5A2122656 for ; Tue, 5 Feb 2008 05:01:58 +1100 (EST) Message-ID: <47A75326.4050200@e164.org> Date: Tue, 05 Feb 2008 05:02:14 +1100 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: speermint@ietf.org References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> In-Reply-To: <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> X-Enigmail-Version: 0.95.0 Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > I think we will have to agree to disagree. I noticed you ignored identity. > > Anyone else think the only way emergency calls should (normally) work is to > have all devices place emergency calls direct to PSAPs with (normally) no > proxies? (sorry if I have duplicated what others have written, I'm trying to catch up on emails/this thread) This is a double edged sword, it reduces the risk or problems caused when any of the hops in the middle fail especially if there is a lack of redundancy, this would/should have better call quality if there is no codec conversions occurring in the middle as well. That said however setups I'd suggest putting the smarts at the emergency side of things rather then the phone and you could deal with calls in some kind of smart fashion ideally utilising geoip information so that only people within x km distance can make those calls, otherwise extra work would be generated for no ones benefit due to abuse. You could go one step further and have calls go to a central switch that redirects the SIP calls based on IP location etc. Also I really like how all GSM carriers honour (or were forced to honour) calls to 112, which can redirected to the local emergency number and I really wish carriers the world over could come up with a similar thing, not just for VoIP but all phone services in general, because as the number of international travelers increase, how many keep up with the local emergency number? Then of course you could possible handle multilingual services this way too, although for the local language you shouldn't have to wait for the full prompt. Even with the above limitations in place you would probably need some ISP industry consensus on procedures with respect to localised abuse, this would need to cover things like bot infested PCs generating calls. No doubt as others have pointed out this would need some kind of subscriber authentication/information and one way would be real time, or near real time to subscriber information based on the IP address similar to databases that store phone number and subscriber information used by law enforcement agencies etc to cover IPs. Which is just another slippery slope, especially for countries already in the grips of police like states. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:19:20 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248073A7014; Mon, 4 Feb 2008 10:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wzn-XN4NsDx; Mon, 4 Feb 2008 10:19:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704C83A7000; Mon, 4 Feb 2008 10:19:18 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754123A6FF5; Mon, 4 Feb 2008 10:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcJ8eXAHFJnu; Mon, 4 Feb 2008 10:19:15 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 800EB3A6DF7; Mon, 4 Feb 2008 10:19:14 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m14IJGKF000270; Mon, 4 Feb 2008 12:20:30 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 12:20:24 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 19:20:21 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 19:20:21 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> In-Reply-To: <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiw References: <47A186C1.7080004@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Stark, Barbara" , "Dawson, Martin" , "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 04 Feb 2008 18:20:21.0735 (UTC) FILETIME=[9A878770:01C8675A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org The access network in 3GPP is the part of the network that provides the radio access and the first level of mobility management. From there you have the access network and part of the core network providing IP connectivity to the first element that appears at the SIP layer. That IP connectivity can end you up in the local network or the home network. I would suggest you are probably looking for something like IMS local network. Regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, January 31, 2008 5:10 PM > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > speermint@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > I made the same assumption, which I know to be wrong. Thank > you for correcting us. Is "3GPP Access Network" the right > terminology for the kind of network where the visited network > provides the E-CSCF? > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, January 31, 2008 12:05 PM > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > snip... > > > IMS requires a co-operative > > > E-CSCF that is actually part of the access network. > > > > This is not true. Please don't confuse "IMS" with "3GPP > Access Network" > > and early 3GPP IMS definitions. They aren't the same. It's > absolutely > > possible to have an IMS core that exists only on the Internet, and > > that makes no assumptions about access networks. > > Barbara > > > > ***** > > > > The information transmitted is intended only for the person > or entity > > to which it is addressed and may contain confidential, proprietary, > > and/or privileged material. Any review, retransmission, > dissemination > > or other use of, or taking of any action in reliance upon this > > information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact the > > sender and delete the material from all computers. GA622 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:31:44 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782513A6FF7; Mon, 4 Feb 2008 10:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiuqWcF-m-7G; Mon, 4 Feb 2008 10:31:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EFA3A6EF2; Mon, 4 Feb 2008 10:31:43 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE9D3A6EF2 for ; Mon, 4 Feb 2008 10:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hItvSwxyuGl for ; Mon, 4 Feb 2008 10:31:41 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 15ADB3A706A for ; Mon, 4 Feb 2008 10:31:29 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JM67k-0006mt-Qp; Mon, 04 Feb 2008 12:32:57 -0600 From: "Brian Rosen" To: "'Duane'" , References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> Date: Mon, 4 Feb 2008 13:32:59 -0500 Message-ID: <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47A75326.4050200@e164.org> Thread-Index: AchnWST3uNBg+pJBQHqG9FqtZyboSAAAdYWQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org > This is a double edged sword, it reduces the risk or problems caused > when any of the hops in the middle fail especially if there is a lack of > redundancy, this would/should have better call quality if there is no > codec conversions occurring in the middle as well. Putting proxies in the middle doesn't imply something is in the middle of the media path. It often is, but the discussion we're having doesn't depend on that. Your double edged sword applies to codecs. How many codecs can we expect the PSAP to reasonably implement? Are you forcing ALL devices to implement at least one of those codecs? History suggests this won't work. > > That said however setups I'd suggest putting the smarts at the emergency > side of things rather then the phone and you could deal with calls in > some kind of smart fashion ideally utilising geoip information so that > only people within x km distance can make those calls, otherwise extra > work would be generated for no ones benefit due to abuse. That makes no sense to me. The PSAP can't enforce any form of admission control unless it's under attack, and x km distance doesn't work at all --service boundaries don't depend on distance from a caller, they depend on jurisdictional boundaries that are absolute. > > You could go one step further and have calls go to a central switch that > redirects the SIP calls based on IP location etc. There is no "central switch" in the Internet. That is the point of the Internet. > > Also I really like how all GSM carriers honour (or were forced to > honour) calls to 112, which can redirected to the local emergency number > and I really wish carriers the world over could come up with a similar > thing, not just for VoIP but all phone services in general, because as > the number of international travelers increase, how many keep up with > the local emergency number? Please go back and look at the archives in this list for discussions on local and home dial strings. Despite the appeal of the entire world accepting 1-1-2 as the sole emergency number, it won't happen in your lifetime. > > Then of course you could possible handle multilingual services this way > too, although for the local language you shouldn't have to wait for the > full prompt. At the moment, that is outside the scope of the work in ecrit. In NENA, we plan to allow routing that depends on the language headers in the SIP messages. > > Even with the above limitations in place you would probably need some > ISP industry consensus on procedures with respect to localised abuse, > this would need to cover things like bot infested PCs generating calls. As I said, identity is the big problem with a direct connection from caller to PSAP. > > No doubt as others have pointed out this would need some kind of > subscriber authentication/information and one way would be real time, or > near real time to subscriber information based on the IP address similar > to databases that store phone number and subscriber information used by > law enforcement agencies etc to cover IPs. Which is just another > slippery slope, especially for countries already in the grips of police > like states. So you propose to have credential based authorization to get on the local access network, map that to some kind of identity that can be put on a SIP call, assume all bad devices will do that, and check it on entrance to a PSAP? In the end, are you in favor of a direct connection from calling device to PSAP (no proxy servers other than in the emergency services IP networks)? Brian _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:33:42 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD7C3A705C; Mon, 4 Feb 2008 10:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNmVMBZlqE6Z; Mon, 4 Feb 2008 10:33:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18A33A7000; Mon, 4 Feb 2008 10:33:40 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A727D3A6EDF; Mon, 4 Feb 2008 10:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNnhao3qyX3F; Mon, 4 Feb 2008 10:33:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B7F7C3A6E43; Mon, 4 Feb 2008 10:33:38 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JM69n-0006yl-0R; Mon, 04 Feb 2008 12:35:03 -0600 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Stark, Barbara'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> Date: Mon, 4 Feb 2008 13:35:05 -0500 Message-ID: <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiwAIxm8LA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I'm looking for a term of art when a local access network is IMS aware, and the local network provides the E-CSCF. Not all IMS systems do that, right? Is "IMS local network" a known term of art where I can expect an E-CSCF to handle emergency calls rather than forwarding to the home domain? Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Monday, February 04, 2008 1:20 PM > To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig; > speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > The access network in 3GPP is the part of the network that provides the > radio access and the first level of mobility management. > > From there you have the access network and part of the core network > providing IP connectivity to the first element that appears at the SIP > layer. That IP connectivity can end you up in the local network or the > home network. > > I would suggest you are probably looking for something like IMS local > network. > > Regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, January 31, 2008 5:10 PM > > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > > speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > I made the same assumption, which I know to be wrong. Thank > > you for correcting us. Is "3GPP Access Network" the right > > terminology for the kind of network where the visited network > > provides the E-CSCF? > > > > Brian > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, January 31, 2008 12:05 PM > > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > snip... > > > > IMS requires a co-operative > > > > E-CSCF that is actually part of the access network. > > > > > > This is not true. Please don't confuse "IMS" with "3GPP > > Access Network" > > > and early 3GPP IMS definitions. They aren't the same. It's > > absolutely > > > possible to have an IMS core that exists only on the Internet, and > > > that makes no assumptions about access networks. > > > Barbara > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > > to which it is addressed and may contain confidential, proprietary, > > > and/or privileged material. Any review, retransmission, > > dissemination > > > or other use of, or taking of any action in reliance upon this > > > information by persons or entities other than the intended > > recipient > > > is prohibited. If you received this in error, please contact the > > > sender and delete the material from all computers. GA622 > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:41:25 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60533A7060; Mon, 4 Feb 2008 10:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kItpbxksuyNf; Mon, 4 Feb 2008 10:41:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897E93A6FB6; Mon, 4 Feb 2008 10:41:24 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A603A7033 for ; Mon, 4 Feb 2008 10:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWp5EtbFFQAR for ; Mon, 4 Feb 2008 10:41:21 -0800 (PST) Received: from pacdcimo02.cable.comcast.com (PacdcIMO02.cable.comcast.com [24.40.8.146]) by core3.amsl.com (Postfix) with ESMTP id 8F38F3A6C7A for ; Mon, 4 Feb 2008 10:41:21 -0800 (PST) Received: from ([10.195.246.152]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.16407015; Mon, 04 Feb 2008 13:42:43 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 13:42:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 13:42:42 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5A8D0@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJwABS+aJABEsIzAA== References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com> <0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net> From: "Livingood, Jason" To: "Elwell, John" , "Daryl Malas" , X-OriginalArrivalTime: 04 Feb 2008 18:42:43.0654 (UTC) FILETIME=[BA601E60:01C8675D] Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Guys - I am at the end of my rope on this one. John, I appreciate the feedback but we're really iterating this greatly overdue draft for just you at this point and I want to accelerate the feedback and close this draft within one week. Taking in the feedback via email, waiting for the I-D editor to publish, then seeing more feedback and interating again is looking like a 3 - 4 week process... Daryl - Would you please conatct John privately and arrange a brief con call to discuss and close any remaining concerns he has. John - I appreciate your making yourself available for ~30 mins to close any remaining concerns you have. Thanks all. Jason > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, January 30, 2008 2:47 AM > To: Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > Action:draft-ietf-speermint-terminology-15.txt > > Daryl, > > Thanks, it's getting there. A few more things I noticed: > > 1. The document uses the words "application" and "session" in > a number of places, and I feel there may be some > inconsistency. For example: > "A SIP Service Provider (or SSP) is an entity that provides > application services utilizing SIP signaling to its customers." > Should it really be "application services", or should it be > "session services". Consider a service provider that provides > no more than SIP proxy functionality. It can hardly be said > to provide application services to its users, so according to > the definition it is not an SSP. > There is just one other instance of "application". I wonder > if the two instances should be changed to "session". > > 2. "In some cases, some entity (usually a 3rd party or federation) > provides peering assistance to the originating SSP by > providing this > function. The assisting entity may provide information > relating to > direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > necessary." > Two comments. First, should "peering assistance" be changed > to "assistance". > Second, this paragraph occurs within 4.3.2 on LRF. Should a > similar statement be added to 4.3.1 on LuF? > > 3. "In this case it is generally required that a > trust relationship is established between the originating > SSP and the > > transit network on one side; and, the transit network representing > the termination network on the other side." > Two comments: First, in order to complement the first part, > should the latter part be rewritten as "; and the transit > network and the terminating SSP on the other side."? > Second, on the use of the term "transit network". Is this > intentional, or would it be better to talk about "transit > SSP". In this context a transit network must provide > functionality at the session layer (otherwise it would not be > considered as indirect peering), so doesn't this make it an SSP? > > John > > > -----Original Message----- > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > Sent: 29 January 2008 21:41 > > To: speermint@ietf.org > > Subject: [Speermint] RE: I-D > > Action:draft-ietf-speermint-terminology-15.txt > > > > This version of the draft includes updates to the following > sections: > > > > Section 2. Context > > Section 4.2.3 Assisted Peering (REMOVED) Section 4.3.1 Location > > Routing Function Section 4.3.2 Location Routing Function > (Previously > > Look-Up Function) Section 5 - Minor add to "Common dynamic policies" > > Section 9 & 10 > > > > --Daryl > > > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, January 29, 2008 2:10 PM > > To: i-d-announce@ietf.org > > Cc: speermint@ietf.org > > Subject: [Speermint] I-D > > Action:draft-ietf-speermint-terminology-15.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session PEERing for Multimedia > > INTerconnect Working Group of the IETF. > > > > > > Title : SPEERMINT Terminology > > Author(s) : D. Malas, D. Meyer > > Filename : draft-ietf-speermint-terminology-15.txt > > Pages : 12 > > Date : 2008-01-29 > > > > This document defines the terminology that is to be used in > describing > > Session PEERing for Multimedia INTerconnect (SPEERMINT). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > > nology-15. > > txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-speermint-terminology-15.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 10:51:02 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B333A6FB7; Mon, 4 Feb 2008 10:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYFXvHJ8DCVU; Mon, 4 Feb 2008 10:51:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88CC3A6DAA; Mon, 4 Feb 2008 10:51:01 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B18B3A6DAA for ; Mon, 4 Feb 2008 10:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoeEe1P6sRUq for ; Mon, 4 Feb 2008 10:50:59 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 5AD593A6AC5 for ; Mon, 4 Feb 2008 10:50:59 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.51553341; Mon, 04 Feb 2008 13:52:12 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 13:52:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 13:52:12 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5A8D3@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <479E12BE.9000909@enum.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] (extremely) late comments ondraft-ietf-speermint-consolidated-presence-im-usecases-03 Thread-Index: Achh1IUNuFABVI6nQyWh6IX+Cdu5hQFifGkA References: <479E12BE.9000909@enum.at> From: "Livingood, Jason" To: "Alexander Mayrhofer" , , , , X-OriginalArrivalTime: 04 Feb 2008 18:52:13.0326 (UTC) FILETIME=[0DED2AE0:01C8675F] Subject: Re: [Speermint] (extremely) late comments ondraft-ietf-speermint-consolidated-presence-im-usecases-03 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Sorry - but WGLC for this draft closed on 21 May 2007. I sent you a private note on the correction of your name, which I think we can get in there in time. Regards Jason > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@enum.at] > Sent: Monday, January 28, 2008 12:37 PM > To: speermint@ietf.org; avshalom@il.ibm.com; aoki@aol.net; > sriram.parameswar@microsoft.com > Subject: [Speermint] (extremely) late comments > ondraft-ietf-speermint-consolidated-presence-im-usecases-03 > > > Hi, > > i found a couple of nits in the IM-usecases draft. I'm aware > that i'm _really_ late, but since i think they improve the > document, here you go: > > - Abstract: please remove "(SP)" from the abstract. > Definition of acronyms must not happen in the abstract. > > - 1. (Introduction): Please explain the acronym "PSTN" > acronym here - it's not on the well known list of abbreviations. > > - 1. (Introduction): the second "(RTC)" (5 lines from end of > section) is > not needed (is explained in first line already). Please remove it. > > - 2.1. It might be good to mention which user is associated > with with peering network - otherwise that becomes a riddle > :). So please add something like "Alice@example.com (with > example.com hosted by Peer A)..." to the text. > > - 2.2. I think the "Ad-hock" group should be an "Ad-hoc" > group. Also, in that paragraph, you say "A public group may > be created by Alice..." > while i think it should read "An ad-hoc group may be created > by Alice..." > > - 2.6. "Fully standardized (became RFCs)" is weak language - > as you know, not every RFC is a standard. Also, what is > "fully standardized"? > > - 2.7. I think it should start with "A Federation" instead of > "Federation". Also, "Peer Networks may connect each other via > a peer-to-peer fashion" should probably read "Peer Networks > may connect to each other in a peer-to-peer fashion". > > - 2.7. The text "the other Peering Network is who it claims to be" > sounds unclear to me. You could replace that text by "that > enables each Peering Network to clearly identify Peering > partners, and set up secured trust relationships" - but that > is just a personal suggestion. > > - 4. I'd replace "We are seeing today users are concerned > with providing.." with "We are seeing today users are > concerned about providing .." and "domain" with "domain name". > > - 4. The reference to section 2.3 would look better in > parentheses "... > (see Section 2.3)". > > > - 4. Last sentence on page 6 - It would be good to change > that to "This document discusses ause cases for peering > between Peer Networks. It is out of scope of this document to > provide for..." > > - 5. Acknowledgements: nit: My last name is misspelled :) > > - 6.1. Normative References: You don't use RFC 2119 language > in the draft - please remove that reference, it's not neccessary. > > > That's all, i hope it was helpful (though very late). > > thanks, > > Alex > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 11:39:33 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5379A3A70B1; Mon, 4 Feb 2008 11:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHmUiqMrcChV; Mon, 4 Feb 2008 11:39:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEFC3A7066; Mon, 4 Feb 2008 11:39:30 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377323A70C2; Mon, 4 Feb 2008 11:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckwbotJbtAMQ; Mon, 4 Feb 2008 11:39:28 -0800 (PST) Received: from pmesmtp01.mci.com (pmesmtp01.wcom.com [199.249.20.1]) by core3.amsl.com (Postfix) with ESMTP id 80DE23A70B2; Mon, 4 Feb 2008 11:39:20 -0800 (PST) Received: from pmismtp01.mcilink.com ([166.37.158.161]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JVQ00432BZOTU@firewall.verizonbusiness.com>; Mon, 04 Feb 2008 19:40:53 +0000 (GMT) Received: from pmismtp01.mcilink.com ([127.0.0.1]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JVQ008FQC00BW@pmismtp01.mcilink.com>; Mon, 04 Feb 2008 19:40:48 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JVQ0090FBZE67@pmismtp01.mcilink.com>; Mon, 04 Feb 2008 19:40:48 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 04 Feb 2008 19:39:52 +0000 Date: Mon, 04 Feb 2008 19:39:51 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> To: Brian Rosen , "DRAGE, Keith (Keith)" , "Stark, Barbara" , "Dawson, Martin" , Hannes Tschofenig , speermint@ietf.org, ECRIT Message-id: <092B2658AAB56A4D80836399A4C470310350E677@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Ecrit] Emergency Calls & VoIP Peering Thread-index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiwAIxm8LAAAUApcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47A186C1.7080004@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 04 Feb 2008 19:39:52.0432 (UTC) FILETIME=[B6161F00:01C86765] Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org My assumption is that "local network" is fairly well understood to mean "the network with which the IP-CAN to which the user is currently attached, is associated". In other words the local network is the visited network if you're roaming, your home network otherwise. Do all IMS networks provide an E-CSCF? I doubt any do at the moment, because the standards are pretty new and not all details are resolved. If there were an E-CSCF in the "IMS local network" I would expect it to behave per TS 24.229, which indicates that the call is directed to the PSAP by the E-CSCF and is NOT forwarded to the home network. Tim > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, February 04, 2008 12:35 PM > To: 'DRAGE, Keith (Keith)'; 'Stark, Barbara'; 'Dawson, > Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I'm looking for a term of art when a local access network is > IMS aware, and > the local network provides the E-CSCF. Not all IMS systems > do that, right? > > Is "IMS local network" a known term of art where I can expect > an E-CSCF to > handle emergency calls rather than forwarding to the home domain? > > Brian > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Monday, February 04, 2008 1:20 PM > > To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig; > > speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > The access network in 3GPP is the part of the network that > provides the > > radio access and the first level of mobility management. > > > > From there you have the access network and part of the core network > > providing IP connectivity to the first element that appears > at the SIP > > layer. That IP connectivity can end you up in the local > network or the > > home network. > > > > I would suggest you are probably looking for something like > IMS local > > network. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, January 31, 2008 5:10 PM > > > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > > > speermint@ietf.org; 'ECRIT' > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > I made the same assumption, which I know to be wrong. Thank > > > you for correcting us. Is "3GPP Access Network" the right > > > terminology for the kind of network where the visited network > > > provides the E-CSCF? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, January 31, 2008 12:05 PM > > > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > > > snip... > > > > > IMS requires a co-operative > > > > > E-CSCF that is actually part of the access network. > > > > > > > > This is not true. Please don't confuse "IMS" with "3GPP > > > Access Network" > > > > and early 3GPP IMS definitions. They aren't the same. It's > > > absolutely > > > > possible to have an IMS core that exists only on the > Internet, and > > > > that makes no assumptions about access networks. > > > > Barbara > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please contact the > > > > sender and delete the material from all computers. GA622 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 4 13:02:03 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FC93A712F; Mon, 4 Feb 2008 13:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.931 X-Spam-Level: X-Spam-Status: No, score=0.931 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL4mqke986pB; Mon, 4 Feb 2008 13:02:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED873A6FA7; Mon, 4 Feb 2008 13:02:02 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58663A6FA7 for ; Mon, 4 Feb 2008 13:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFvT1F3AYM6l for ; Mon, 4 Feb 2008 13:02:00 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CA6D83A6DC7 for ; Mon, 4 Feb 2008 13:01:59 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.12897175; Mon, 04 Feb 2008 16:03:17 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 16:03:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 16:03:16 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5A8E1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-speermint-srv-naptr-use-02 Thread-Index: AchncVv4us9/45gxQEGxPdGYUWCeMA== From: "Livingood, Jason" To: X-OriginalArrivalTime: 04 Feb 2008 21:03:16.0973 (UTC) FILETIME=[5D0679D0:01C86771] Subject: [Speermint] Updating draft-ietf-speermint-srv-naptr-use-02 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I am planning to work on an update of this I-D soon. Anyone have any glaring issues that need to be fixed in or addressed by the draft that they wish to point out? http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-0 2.txt Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 5 14:41:36 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279523A6B6A; Tue, 5 Feb 2008 14:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9StKKuORwmv5; Tue, 5 Feb 2008 14:41:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34803A73A5; Tue, 5 Feb 2008 14:25:48 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E733A6FE1 for ; Tue, 5 Feb 2008 14:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxyAJ3h8YhJz for ; Tue, 5 Feb 2008 14:25:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9947E3A6B5C for ; Tue, 5 Feb 2008 14:02:16 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2008 17:03:49 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m15M3m29030538; Tue, 5 Feb 2008 17:03:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m15M3hMR014594; Tue, 5 Feb 2008 22:03:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 17:03:43 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 17:03:42 -0500 Message-ID: <47A8DD45.3020308@cisco.com> Date: Tue, 05 Feb 2008 17:03:49 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Duane References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> <47A7AFD7.2090302@e164.org> In-Reply-To: <47A7AFD7.2090302@e164.org> X-OriginalArrivalTime: 05 Feb 2008 22:03:42.0665 (UTC) FILETIME=[F884EB90:01C86842] Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Duane wrote: > I am, but it's a very delicate situation that has to extend beyond > boundaries to try and cover the globe, remember my little pipe dream > about 112? I don't buy into your pipe dream. If I want to have a dial plan in my office in the USA that uses office numbers as extension numbers, then I want to be able to call office 112, and telling me I can't have office number 112 because of emergency dialing conventions in Germany isn't going to fly with me. Also, is it just a *complete* string of 112, or is it any number that is prefixed with 112? That makes it worse. IMO my phone should have a dial plan that works the same no matter where I take it. If I am in Germany and want to dial somebody in Germany then I will do so using the same dialing conventions I use to dial that person in Germany when I am at home in the US. And if I have an emergency I will invoke that the same (911) no matter where I am, because that is the way I expect my phone to work. (Dialing 911 ought to get me the local German PSAP if I happen to be in Germany.) But I am sure Brian has been thru this many times, and what *I* want doesn't matter. Paul _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 5 15:50:33 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F963A6891; Tue, 5 Feb 2008 15:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2oDQuJ96ule; Tue, 5 Feb 2008 15:50:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9653A6914; Tue, 5 Feb 2008 15:50:13 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E133A67ED for ; Tue, 5 Feb 2008 15:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrZwwgltK6L1 for ; Tue, 5 Feb 2008 15:50:11 -0800 (PST) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id 5EF5F3A67B4 for ; Tue, 5 Feb 2008 15:48:56 -0800 (PST) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id E56804B80C8; Wed, 6 Feb 2008 10:50:14 +1100 (EST) Message-ID: <47A8F64E.4090909@e164.org> Date: Wed, 06 Feb 2008 10:50:38 +1100 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Paul Kyzivat References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> <47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com> In-Reply-To: <47A8DD45.3020308@cisco.com> X-Enigmail-Version: 0.95.0 X-aus-biz.com-MailScanner-Information: Please contact the ISP for more information X-aus-biz.com-MailScanner: Found to be clean X-aus-biz.com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60) X-aus-biz.com-MailScanner-From: duane@e164.org Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Paul Kyzivat wrote: > I don't buy into your pipe dream. If I want to have a dial plan in my I'm not in Germany :P However that small issue aside, any GSM mobile phone any where can dial 112 and it just works, although it doesn't have to be 112, do you also setup 911 as an extension for kicks too? :) -- Best regards, Duane -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 5 16:19:49 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B2793A686E; Tue, 5 Feb 2008 16:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2JuSfmu8ZH9; Tue, 5 Feb 2008 16:19:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EDB3A6834; Tue, 5 Feb 2008 16:19:48 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA273A6834 for ; Tue, 5 Feb 2008 16:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dctDg99ygprg for ; Tue, 5 Feb 2008 16:19:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B13A3A680C for ; Tue, 5 Feb 2008 16:19:45 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2008 19:21:18 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m160LHJ8024521; Tue, 5 Feb 2008 19:21:17 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m160LDMT029379; Wed, 6 Feb 2008 00:21:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 19:21:14 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 19:21:10 -0500 Message-ID: <47A8FD7D.3040901@cisco.com> Date: Tue, 05 Feb 2008 19:21:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Duane References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> <47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com> <47A8F64E.4090909@e164.org> In-Reply-To: <47A8F64E.4090909@e164.org> X-OriginalArrivalTime: 06 Feb 2008 00:21:10.0154 (UTC) FILETIME=[2C67DEA0:01C86856] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Duane wrote: > Paul Kyzivat wrote: > >> I don't buy into your pipe dream. If I want to have a dial plan in my > > I'm not in Germany :P Sorry. I wasn't intending to suggest that you were. I only used germany as a place where I thought (I'm not certain) 112 was valid. > However that small issue aside, any GSM mobile phone any where can dial > 112 and it just works, although it doesn't have to be 112, I hope it at least must be "112", rather than it initiating the call after you press the "2" in "112" ??? At least then it only takes one sequence out of play, rather than all sequences with that as a prefix. If you started imposing such a rule on land lines then I fear it would be restricted as a prefix, because many people don't expect to type a special key on traditional phones. > do you also > setup 911 as an extension for kicks too? :) I can see how a hotel where 911 isn't special might want to use 911 to dial room 11 on the 9th floor. My primary point is that reserving particular numbers in one dial plan because of decisions made in an unrelated context is a very bad idea in general. I'm pretty sure that 112 and 911 aren't the only emergency numbers in the world. Should we reserve 666 everywhere because somebody somewhere decided to use that as their emergency number? I do have some sympathy for this concept in places like hotels that provide phones for use by travelers. They already typically have a private dial plan, and can adjust it carefully to allow for all these reserved numbers that their guests might be inclined to try. But I find it less than compelling that *my* cell phone needs to recognize 112 because somebody else might try to use it to make an emergency call. Thanks, Paul _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 5 16:53:56 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CB23A6803; Tue, 5 Feb 2008 16:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In7SLSZWVdJy; Tue, 5 Feb 2008 16:53:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE353A67EE; Tue, 5 Feb 2008 16:53:55 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7803A67EE for ; Tue, 5 Feb 2008 16:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Yav0lZxpC6Q for ; Tue, 5 Feb 2008 16:53:52 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id BCFFB3A67A6 for ; Tue, 5 Feb 2008 16:53:52 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m160tNFx025819; Tue, 5 Feb 2008 17:55:23 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 5 Feb 2008 17:55:23 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Feb 2008 17:55:22 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0CB8@srvxchg3.cablelabs.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D06021F9@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt Thread-Index: Achiu2zGjCE7c4pdRx+jVFTZe7oYfAAA6VJwABS+aJABEsIzAAAckP0gACLRbAA= References: <160DE07A1C4F8E4AA2715DEC577DA4917B0C6D@srvxchg3.cablelabs.com><0D5F89FAC29E2C41B98A6A762007F5D05CF164@GBNTHT12009MSX.gb002.siemens.net>A<45AEC6EF95942140888406588E1A660203A5A8D0@PACDCEXCMB04.cable.comcast.com> <0D5F89FAC29E2C41B98A6A762007F5D06021F9@GBNTHT12009MSX.gb002.siemens.net> From: "Daryl Malas" To: "Elwell, John" , "Livingood, Jason" , X-Approved: ondar Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Jason, John and I had a call this afternoon to resolve all of the remaining issues he had with the draft. As I was just about to submit the rev (and final)16, I noticed a couple of NIT issues. I plan to resolve these tomorrow and upload the version. Thanks, Daryl -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, February 05, 2008 1:22 AM To: Livingood, Jason; Daryl Malas; speermint@ietf.org Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-15.txt Jason, If comments are no longer solicited I will withdraw my comments - please go ahead and request publication. However, I really don't see why it is a 3-4 week cycle to bring out a new version - once comments have been received and resolved, a new version can be published in less than half an hour, now that we no longer go through the I-D editor. John > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: 04 February 2008 18:43 > To: Elwell, John; Daryl Malas; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > Action:draft-ietf-speermint-terminology-15.txt > > Guys - > > I am at the end of my rope on this one. John, I appreciate the > feedback but we're really iterating this greatly overdue draft for > just you at this point and I want to accelerate the feedback and close > this draft within one week. Taking in the feedback via email, waiting > for the I-D editor to publish, then seeing more feedback and > interating again is looking like a 3 - 4 week process... > > Daryl - Would you please conatct John privately and arrange a brief > con call to discuss and close any remaining concerns he has. > > John - I appreciate your making yourself available for ~30 mins to > close any remaining concerns you have. > > Thanks all. > > Jason > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Wednesday, January 30, 2008 2:47 AM > > To: Daryl Malas; speermint@ietf.org > > Subject: RE: [Speermint] RE: I-D > > Action:draft-ietf-speermint-terminology-15.txt > > > > Daryl, > > > > Thanks, it's getting there. A few more things I noticed: > > > > 1. The document uses the words "application" and "session" in a > > number of places, and I feel there may be some inconsistency. For > > example: > > "A SIP Service Provider (or SSP) is an entity that provides > > application services utilizing SIP signaling to its customers." > > Should it really be "application services", or should it be "session > > services". Consider a service provider that provides no more than > > SIP proxy functionality. It can hardly be said to provide > > application services to its users, so according to the definition it > > is not an SSP. > > There is just one other instance of "application". I wonder if the > > two instances should be changed to "session". > > > > 2. "In some cases, some entity (usually a 3rd party or federation) > > provides peering assistance to the originating SSP by providing > > this > > function. The assisting entity may provide information relating > > to > > direct (Section 4.2.1) or indirect (Section 4.2.2) peering as > > necessary." > > Two comments. First, should "peering assistance" be changed to > > "assistance". > > Second, this paragraph occurs within 4.3.2 on LRF. Should a similar > > statement be added to 4.3.1 on LuF? > > > > 3. "In this case it is generally required that a > > trust relationship is established between the originating SSP and > > the > > > > transit network on one side; and, the transit network > representing > > the termination network on the other side." > > Two comments: First, in order to complement the first part, should > > the latter part be rewritten as "; and the transit network and the > > terminating SSP on the other side."? > > Second, on the use of the term "transit network". Is this > > intentional, or would it be better to talk about "transit SSP". In > > this context a transit network must provide functionality at the > > session layer (otherwise it would not be considered as indirect > > peering), so doesn't this make it an SSP? > > > > John > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > > > Sent: 29 January 2008 21:41 > > > To: speermint@ietf.org > > > Subject: [Speermint] RE: I-D > > > Action:draft-ietf-speermint-terminology-15.txt > > > > > > This version of the draft includes updates to the following > > sections: > > > > > > Section 2. Context > > > Section 4.2.3 Assisted Peering (REMOVED) Section 4.3.1 Location > > > Routing Function Section 4.3.2 Location Routing Function > > (Previously > > > Look-Up Function) Section 5 - Minor add to "Common > dynamic policies" > > > Section 9 & 10 > > > > > > --Daryl > > > > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Tuesday, January 29, 2008 2:10 PM > > > To: i-d-announce@ietf.org > > > Cc: speermint@ietf.org > > > Subject: [Speermint] I-D > > > Action:draft-ietf-speermint-terminology-15.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > This draft is a work item of the Session PEERing for Multimedia > > > INTerconnect Working Group of the IETF. > > > > > > > > > Title : SPEERMINT Terminology > > > Author(s) : D. Malas, D. Meyer > > > Filename : draft-ietf-speermint-terminology-15.txt > > > Pages : 12 > > > Date : 2008-01-29 > > > > > > This document defines the terminology that is to be used in > > describing > > > Session PEERing for Multimedia INTerconnect (SPEERMINT). > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > > > nology-15. > > > txt > > > > > > To remove yourself from the I-D Announcement list, send a > > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > > the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. > Login with the > > > username "anonymous" and a password of your e-mail address. After > > > logging in, type "cd internet-drafts" and then > > > "get draft-ietf-speermint-terminology-15.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-speermint-terminology-15.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 5 19:08:29 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC8C3A6899; Tue, 5 Feb 2008 19:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-8mmAxWWHFU; Tue, 5 Feb 2008 19:08:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F250A3A6800; Tue, 5 Feb 2008 19:08:28 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943493A6868 for ; Tue, 5 Feb 2008 19:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqd9a2WL8gZu for ; Tue, 5 Feb 2008 19:08:26 -0800 (PST) Received: from mail.aus-biz.com (mail.aus-biz.com [208.82.100.153]) by core3.amsl.com (Postfix) with ESMTP id CCDFE3A6800 for ; Tue, 5 Feb 2008 19:08:24 -0800 (PST) Received: from [192.168.2.144] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 5814A4B8055; Wed, 6 Feb 2008 14:09:49 +1100 (EST) Message-ID: <47A92516.7060609@e164.org> Date: Wed, 06 Feb 2008 14:10:14 +1100 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Paul Kyzivat References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> <47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com> <47A8F64E.4090909@e164.org> <47A8FD7D.3040901@cisco.com> In-Reply-To: <47A8FD7D.3040901@cisco.com> X-Enigmail-Version: 0.95.0 X-aus-biz.com-MailScanner-Information: Please contact the ISP for more information X-aus-biz.com-MailScanner: Found to be clean X-aus-biz.com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.599, required 5, autolearn=not spam, BAYES_00 -2.60) X-aus-biz.com-MailScanner-From: duane@e164.org Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Paul Kyzivat wrote: > But I find it less than compelling that *my* cell phone needs to > recognize 112 because somebody else might try to use it to make an > emergency call. That wasn't even my original point, I was pointing out travelers, ie you, go somewhere different, ie Europe or Australia and take your GSM mobile phone with you and you don't need to know or care what the local emergency number is, you just have to remember 112. -- Best regards, Duane -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 6 07:08:10 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CE73A6D82; Wed, 6 Feb 2008 07:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJvP-zMzS+07; Wed, 6 Feb 2008 07:08:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6773A6E07; Wed, 6 Feb 2008 07:08:08 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721B43A6850 for ; Wed, 6 Feb 2008 07:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gAkjdYYc8FI for ; Wed, 6 Feb 2008 07:08:06 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8C6E63A6E17 for ; Wed, 6 Feb 2008 07:06:31 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m16F6wqN016057; Wed, 6 Feb 2008 09:07:47 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 09:07:42 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 16:07:39 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 16:07:39 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB8BAD@DEEXC1U01.de.lucent.com> In-Reply-To: <47A92516.7060609@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [Ecrit] Emergency Calls & VoIP Peering Thread-index: Achobcebh3C2rTIJTaOQTUHhqXKerAAYT87A References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com><47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com><47A8F64E.4090909@e164.org> <47A8FD7D.3040901@cisco.com> <47A92516.7060609@e164.org> From: "DRAGE, Keith \(Keith\)" To: "Duane" , "Paul Kyzivat" X-OriginalArrivalTime: 06 Feb 2008 15:07:39.0554 (UTC) FILETIME=[03C23820:01C868D2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org GSM phones have a multilayered approach to this process, and the distinction only works for numbers that are used in conjunction with a public telecommunications number. - Firstly 112 and 911 are always recognised by the phone itself. - Secondly a batch of numbers can be configured on the SIM or UICC. The principle here is that these are the local service numbers that are used for emergency in foreign countries, but are not used for other local service number purposes in the home network. - Thirdly if the SIM or UICC is not present, then the following numbers also act the same as 112 and 911, that is 000, 08, 110, 999, 118 and 119. - Fourthly the protocol used between the network and the phone also allows the downloading of emergency numbers, which are assumed to be the valid emergency numbers for the local network. However as soon as you get to private numbering plan numbers, then these will frequently conflict, unless you have a means of distinguishing numbers that appear in the private number plan from local service numbers that appear in the public number plan. This can be done in ISDN, and for tel URIs, but cannot be performed for an analogue phone sending LD or DTMF. For them not to conflict, any potential emergency number has to be assigned as a valid number in that particular private numbering plan as well as being a local service number in the public numbering plan. This is something that owners of hotels, for example, are unlikely to do without rebuilding the hotel minus room 112. Finally, in response to Paul > I hope it at least must be "112", rather than it initiating the call after you > press the "2" in "112" ??? At least then it only takes one sequence out of play, rather > than all sequences with that as a prefix. Treating "112" and "1120" as two different valid numbers is something that I have heard of only being used in the US. It has taken ages to explain that people sometimes do it to colleagues outside the US. Regards Keith > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Duane > Sent: Wednesday, February 06, 2008 3:10 AM > To: Paul Kyzivat > Cc: speermint@ietf.org > Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering > > Paul Kyzivat wrote: > > > But I find it less than compelling that *my* cell phone needs to > > recognize 112 because somebody else might try to use it to make an > > emergency call. > > That wasn't even my original point, I was pointing out > travelers, ie you, go somewhere different, ie Europe or > Australia and take your GSM mobile phone with you and you > don't need to know or care what the local emergency number > is, you just have to remember 112. > > -- > > Best regards, > Duane > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 6 09:22:51 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2393A6F17; Wed, 6 Feb 2008 09:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv40MjOB3gr5; Wed, 6 Feb 2008 09:22:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61703A6E6F; Wed, 6 Feb 2008 09:22:50 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2043A6E9D for ; Wed, 6 Feb 2008 09:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ2a3mnSaBCy for ; Wed, 6 Feb 2008 09:22:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D860D3A6D60 for ; Wed, 6 Feb 2008 09:22:46 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Feb 2008 12:24:19 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m16HOIvq031755; Wed, 6 Feb 2008 12:24:18 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m16HNrMr028988; Wed, 6 Feb 2008 17:24:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:24:13 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:24:12 -0500 Message-ID: <47A9ED44.3070405@cisco.com> Date: Wed, 06 Feb 2008 12:24:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Duane References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com> <47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com> <47A8F64E.4090909@e164.org> <47A8FD7D.3040901@cisco.com> <47A92516.7060609@e164.org> In-Reply-To: <47A92516.7060609@e164.org> X-OriginalArrivalTime: 06 Feb 2008 17:24:12.0880 (UTC) FILETIME=[175C8D00:01C868E5] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Duane wrote: > Paul Kyzivat wrote: > >> But I find it less than compelling that *my* cell phone needs to >> recognize 112 because somebody else might try to use it to make an >> emergency call. > > That wasn't even my original point, I was pointing out travelers, ie > you, go somewhere different, ie Europe or Australia and take your GSM > mobile phone with you and you don't need to know or care what the local > emergency number is, you just have to remember 112. But us provincial Americans don't remember 112 as an emergency number. [If God had meant 112 to be the emergency number then he wouldn't have given us 911.] :-) I don't think of my self as provincial, but even though I travel out of the country a modest amount, I can't remember the last time I used a phone that was homed in another country and had a foreign dial plan, so I really have little interest in what other emergency numbers are except in discussions like this about implementing emergency services. Emergency numbers are designed to work with a particular dial plan. If you import a number designed to work with one dial plan, into an unrelated dial plan, then you mostly get a mess. In reality 112 is perhaps a fortuitous accident in that I don't think it conflicts with anything in the North American Numbering Plan. Thanks, Paul _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 6 09:31:56 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468B63A6FF0; Wed, 6 Feb 2008 09:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn167wc1KOJo; Wed, 6 Feb 2008 09:31:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A743A6EC6; Wed, 6 Feb 2008 09:30:59 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1253A6EC6 for ; Wed, 6 Feb 2008 09:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj4II6F+JIqE for ; Wed, 6 Feb 2008 09:30:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C2EB3A6D60 for ; Wed, 6 Feb 2008 09:30:53 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Feb 2008 12:32:25 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m16HWP1s002993; Wed, 6 Feb 2008 12:32:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m16HVUN5001865; Wed, 6 Feb 2008 17:32:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:32:14 -0500 Received: from [161.44.174.140] ([161.44.174.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 12:32:13 -0500 Message-ID: <47A9EF24.8070800@cisco.com> Date: Wed, 06 Feb 2008 12:32:20 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com><47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com><47A8F64E.4090909@e164.org> <47A8FD7D.3040901@cisco.com> <47A92516.7060609@e164.org> <5D1A7985295922448D5550C94DE2918001BB8BAD@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001BB8BAD@DEEXC1U01.de.lucent.com> X-OriginalArrivalTime: 06 Feb 2008 17:32:13.0312 (UTC) FILETIME=[35B8A800:01C868E6] Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org DRAGE, Keith (Keith) wrote: > GSM phones have a multilayered approach to this process, and the > distinction only works for numbers that are used in conjunction with a > public telecommunications number. > > - Firstly 112 and 911 are always recognised by the phone itself. > > - Secondly a batch of numbers can be configured on the SIM or > UICC. The principle here is that these are the local service numbers > that are used for emergency in foreign countries, but are not used for > other local service number purposes in the home network. > > - Thirdly if the SIM or UICC is not present, then the following > numbers also act the same as 112 and 911, that is 000, 08, 110, 999, 118 > and 119. > > - Fourthly the protocol used between the network and the phone > also allows the downloading of emergency numbers, which are assumed to > be the valid emergency numbers for the local network. > > However as soon as you get to private numbering plan numbers, then these > will frequently conflict, unless you have a means of distinguishing > numbers that appear in the private number plan from local service > numbers that appear in the public number plan. This can be done in ISDN, > and for tel URIs, but cannot be performed for an analogue phone sending > LD or DTMF. > > For them not to conflict, any potential emergency number has to be > assigned as a valid number in that particular private numbering plan as > well as being a local service number in the public numbering plan. This > is something that owners of hotels, for example, are unlikely to do > without rebuilding the hotel minus room 112. They can do that at the same time they leave out room 666 and the 13th floor. :-) > Finally, in response to Paul > >> I hope it at least must be "112", rather than it > initiating the call after you >> press the "2" in "112" ??? At least then it only takes one > sequence out of play, rather >> than all sequences with that as a prefix. > > Treating "112" and "1120" as two different valid numbers is something > that I have heard of only being used in the US. It has taken ages to > explain that people sometimes do it to colleagues outside the US. Funny, because the concept is alien in the US. I thought it was only in places like Germany and France where that sort of thing was in common use. I have just recently had a discussion of how to implement overlap dialing to support this somewhere. We keep hoping it will go away because of phones with keys enabling en bloc dialing. But that argument doesn't seem to be winning yet. I only bring it up because if you want to bring in a particular number that may otherwise conflict with the local dialing plan, then it has a larger potential impact if it preempts all numbers with that prefix than it has when it only preempts itself. With en bloc dialing, 112 would only bother hotels with three digit room numbers. Hotels with with 4 digit room numbers wouldn't have to block 112*. Thanks, Paul > Regards > > > Keith > > >> -----Original Message----- >> From: speermint-bounces@ietf.org >> [mailto:speermint-bounces@ietf.org] On Behalf Of Duane >> Sent: Wednesday, February 06, 2008 3:10 AM >> To: Paul Kyzivat >> Cc: speermint@ietf.org >> Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering >> >> Paul Kyzivat wrote: >> >>> But I find it less than compelling that *my* cell phone needs to >>> recognize 112 because somebody else might try to use it to make an >>> emergency call. >> That wasn't even my original point, I was pointing out >> travelers, ie you, go somewhere different, ie Europe or >> Australia and take your GSM mobile phone with you and you >> don't need to know or care what the local emergency number >> is, you just have to remember 112. >> >> -- >> >> Best regards, >> Duane >> >> -- >> This message has been scanned for viruses and dangerous >> content by MailScanner, and is believed to be clean. >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> http://www.ietf.org/mailman/listinfo/speermint >> > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 7 03:57:30 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9243A7830; Thu, 7 Feb 2008 03:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSm7uDmx6UGR; Thu, 7 Feb 2008 03:57:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38C33A7445; Thu, 7 Feb 2008 03:57:28 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C353A689A for ; Thu, 7 Feb 2008 03:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui5D3IWjhAkr for ; Thu, 7 Feb 2008 03:57:26 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DF5B93A7524 for ; Thu, 7 Feb 2008 03:56:00 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m17Buc6h014892; Thu, 7 Feb 2008 05:57:17 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 05:57:11 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 12:57:09 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Feb 2008 12:57:09 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BF7146@DEEXC1U01.de.lucent.com> In-Reply-To: <47A9EF24.8070800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [Ecrit] Emergency Calls & VoIP Peering Thread-index: Acho5k0+JkJndXPdQ+mH6MoKZKH9nAAmY8hw References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com><47A7AFD7.2090302@e164.org> <47A8DD45.3020308@cisco.com><47A8F64E.4090909@e164.org> <47A8FD7D.3040901@cisco.com> <47A92516.7060609@e164.org> <5D1A7985295922448D5550C94DE2918001BB8BAD@DEEXC1U01.de.lucent.com> <47A9EF24.8070800@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Feb 2008 11:57:09.0187 (UTC) FILETIME=[91246130:01C86980] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: speermint@ietf.org Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org > > Funny, because the concept is alien in the US. I thought it > was only in places like Germany and France where that sort of > thing was in common use. I have just recently had a > discussion of how to implement overlap dialing to support > this somewhere. We keep hoping it will go away because of > phones with keys enabling en bloc dialing. But that > argument doesn't seem to be winning yet. My only known example of the use of this is in the US, in local service numbers. If I can think back to about 1980 and a very hazy memory, it was used where xxx represented the local service number for operator assistance generally and xxx followed by an area code represented operator assistance specifically for that area. To distinguish required a shorter timeout between the two elements of the number in DTMF and LD phones. Germany (and Austria) has variable length numbers but 112 and 1120 never coexist. Rather adjacent numbers in the numbering plan may be of different length, e.g. 1230 12310 123111 123112 123113 Regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, February 06, 2008 5:32 PM > To: DRAGE, Keith (Keith) > Cc: Duane; speermint@ietf.org > Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering > > > > DRAGE, Keith (Keith) wrote: > > GSM phones have a multilayered approach to this process, and the > > distinction only works for numbers that are used in > conjunction with a > > public telecommunications number. > > > > - Firstly 112 and 911 are always recognised by the phone itself. > > > > - Secondly a batch of numbers can be configured on the SIM or > > UICC. The principle here is that these are the local > service numbers > > that are used for emergency in foreign countries, but are > not used for > > other local service number purposes in the home network. > > > > - Thirdly if the SIM or UICC is not present, then the following > > numbers also act the same as 112 and 911, that is 000, 08, > 110, 999, > > 118 and 119. > > > > - Fourthly the protocol used between the network and the phone > > also allows the downloading of emergency numbers, which are > assumed to > > be the valid emergency numbers for the local network. > > > > However as soon as you get to private numbering plan numbers, then > > these will frequently conflict, unless you have a means of > > distinguishing numbers that appear in the private number plan from > > local service numbers that appear in the public number > plan. This can > > be done in ISDN, and for tel URIs, but cannot be performed for an > > analogue phone sending LD or DTMF. > > > > For them not to conflict, any potential emergency number has to be > > assigned as a valid number in that particular private > numbering plan > > as well as being a local service number in the public > numbering plan. > > This is something that owners of hotels, for example, are > unlikely to > > do without rebuilding the hotel minus room 112. > > They can do that at the same time they leave out room 666 and > the 13th floor. :-) > > > Finally, in response to Paul > > > >> I hope it at least must be "112", rather than it > > initiating the call after you > >> press the "2" in "112" ??? At least then it only takes one > > sequence out of play, rather > >> than all sequences with that as a prefix. > > > > Treating "112" and "1120" as two different valid numbers is > something > > that I have heard of only being used in the US. It has > taken ages to > > explain that people sometimes do it to colleagues outside the US. > > Funny, because the concept is alien in the US. I thought it > was only in places like Germany and France where that sort of > thing was in common use. I have just recently had a > discussion of how to implement overlap dialing to support > this somewhere. We keep hoping it will go away because of > phones with keys enabling en bloc dialing. But that > argument doesn't seem to be winning yet. > > I only bring it up because if you want to bring in a > particular number that may otherwise conflict with the local > dialing plan, then it has a larger potential impact if it > preempts all numbers with that prefix than it has when it > only preempts itself. > > With en bloc dialing, 112 would only bother hotels with three > digit room numbers. Hotels with with 4 digit room numbers > wouldn't have to block 112*. > > Thanks, > Paul > > > Regards > > > > > > Keith > > > > > >> -----Original Message----- > >> From: speermint-bounces@ietf.org > >> [mailto:speermint-bounces@ietf.org] On Behalf Of Duane > >> Sent: Wednesday, February 06, 2008 3:10 AM > >> To: Paul Kyzivat > >> Cc: speermint@ietf.org > >> Subject: Re: [Speermint] [Ecrit] Emergency Calls & VoIP Peering > >> > >> Paul Kyzivat wrote: > >> > >>> But I find it less than compelling that *my* cell phone needs to > >>> recognize 112 because somebody else might try to use it > to make an > >>> emergency call. > >> That wasn't even my original point, I was pointing out > travelers, ie > >> you, go somewhere different, ie Europe or Australia and > take your GSM > >> mobile phone with you and you don't need to know or care what the > >> local emergency number is, you just have to remember 112. > >> > >> -- > >> > >> Best regards, > >> Duane > >> > >> -- > >> This message has been scanned for viruses and dangerous content by > >> MailScanner, and is believed to be clean. > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> http://www.ietf.org/mailman/listinfo/speermint > >> > > > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 12 18:00:05 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1ED28C650; Tue, 12 Feb 2008 18:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUCyox2Hg7Yo; Tue, 12 Feb 2008 18:00:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB02628C65A; Tue, 12 Feb 2008 18:00:03 -0800 (PST) X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8260228C141; Tue, 12 Feb 2008 18:00:00 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080213020001.8260228C141@core3.amsl.com> Date: Tue, 12 Feb 2008 18:00:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-16.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-16.txt Pages : 12 Date : 2008-2-12 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-12174530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-12174530.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Feb 13 08:37:54 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DA728C8DA; Wed, 13 Feb 2008 08:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTF8aQN6w7c8; Wed, 13 Feb 2008 08:37:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9E028C8D6; Wed, 13 Feb 2008 08:37:53 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3BA28C8A6 for ; Wed, 13 Feb 2008 08:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN-bIH7yZMht for ; Wed, 13 Feb 2008 08:37:51 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 6C63028C86F for ; Wed, 13 Feb 2008 08:37:51 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.42218975; Wed, 13 Feb 2008 11:38:41 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 11:38:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 11:38:40 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5AAF1@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20080213020001.8260228C141@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-16.txt Thread-Index: Acht5LCiCZsybpgrTeSItre6xAwVWAAegWag References: <20080213020001.8260228C141@core3.amsl.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 13 Feb 2008 16:38:41.0185 (UTC) FILETIME=[E4093910:01C86E5E] Cc: Daryl Malas Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-16.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Since we've had a few WGLCs on this document already, we are calling an abbreviated WGLC from today, February 13, 2008, to February 21, 2008. Thank you Jason > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 12, 2008 9:00 PM > To: i-d-announce@ietf.org > Cc: speermint@ietf.org > Subject: [Speermint] I-D > ACTION:draft-ietf-speermint-terminology-16.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session PEERing for > Multimedia INTerconnect Working Group of the IETF. > > Title : SPEERMINT Terminology > Author(s) : D. Malas, D. Meyer > Filename : draft-ietf-speermint-terminology-16.txt > Pages : 12 > Date : 2008-2-12 > > This document defines the terminology that is to be used in > describing Session PEERing for Multimedia INTerconnect (SPEERMINT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > nology-16.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-speermint-terminology-16.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-terminology-16.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 15 06:19:56 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1B928D1BD; Fri, 15 Feb 2008 06:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.23 X-Spam-Level: X-Spam-Status: No, score=0.23 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zGFqeLdfOhC; Fri, 15 Feb 2008 06:19:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AFF28D1DE; Fri, 15 Feb 2008 06:19:50 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3983A6ADF for ; Fri, 15 Feb 2008 06:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GHs1bcckdzh for ; Fri, 15 Feb 2008 06:19:47 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D1D6C3A6AD3 for ; Fri, 15 Feb 2008 06:19:38 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.13339471; Fri, 15 Feb 2008 09:20:48 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Feb 2008 09:20:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Feb 2008 09:20:47 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5AB8C@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001BF7146@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [Ecrit] Emergency Calls & VoIP Peering ((ON AGENDA??)) Thread-Index: Acho5k0+JkJndXPdQ+mH6MoKZKH9nAAmY8hwAZd90iA= References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <47A75326.4050200@e164.org> <050a01c8675c$601cc710$640fa8c0@cis.neustar.com><47A7AFD7.2090302@e164.org><47A8DD45.3020308@cisco.com><47A8F64E.4090909@e164.org><47A8FD7D.3040901@cisco.com> <47A92516.7060609@e164.org><5D1A7985295922448D5550C94DE2918001BB8BAD@DEEXC1U01.de.lucent.com><47A9EF24.8070800@cisco.com> <5D1A7985295922448D5550C94DE2918001BF7146@DEEXC1U01.de.lucent.com> From: "Livingood, Jason" To: X-OriginalArrivalTime: 15 Feb 2008 14:20:48.0281 (UTC) FILETIME=[F5D3C090:01C86FDD] Subject: [Speermint] [Ecrit] Emergency Calls & VoIP Peering ((ON AGENDA??)) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org We're finalizing the IETF 71 agenda now. Do we want to add this discussion topic to the meeting, and if so who wishes to speak and what document will we review? Jason _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 15 13:04:55 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E383028C4AD; Fri, 15 Feb 2008 13:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhfEWFAD4vUN; Fri, 15 Feb 2008 13:04:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5B828C395; Fri, 15 Feb 2008 13:04:53 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970EB28C23A; Fri, 15 Feb 2008 13:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j4+d2Oxqem0; Fri, 15 Feb 2008 13:04:50 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 3E2CA28C36A; Fri, 15 Feb 2008 13:04:36 -0800 (PST) Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1FL5HII018763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Feb 2008 13:05:18 -0800 From: "Richard Shockey" To: , Date: Fri, 15 Feb 2008 16:04:17 -0500 Message-ID: <044701c87016$54d53730$fe7fa590$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0448_01C86FEC.6BFF2F30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchwE8RL6LwRC/DwTvOgLdJ7FGVJXwAAoZXw Content-Language: en-us Subject: [Speermint] FW: I-D Action:draft-rosenberg-sipping-siptrunk-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_0448_01C86FEC.6BFF2F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, February 15, 2008 3:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-rosenberg-sipping-siptrunk-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : What is a Session Initiation Protocol (SIP) Trunk Anyway? Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-siptrunk-00.txt Pages : 10 Date : 2008-02-15 The term "Session Initiation Protocol (SIP) Trunk" has become almost commonplace amongst vendors and SIP providers. Even though the notion of a 'trunk' has a well defined meaning in circuit switched systems, it has never been defined for SIP. This document provides a formal definition for a SIP trunk, discusses its scope and applications, and establishes best practices for identification and security of SIP trunks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-siptrunk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-siptrunk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sipping-siptrunk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0448_01C86FEC.6BFF2F30 Content-Type: Message/External-body; name="ATT01074.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01074.dat" Content-Type: text/plain Content-ID: <2008-02-15124248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-siptrunk-00.txt ------=_NextPart_000_0448_01C86FEC.6BFF2F30 Content-Type: Message/External-body; name="draft-rosenberg-sipping-siptrunk-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-rosenberg-sipping-siptrunk-00.txt" Content-Type: text/plain Content-ID: <2008-02-15124248.I-D\@ietf.org> ------=_NextPart_000_0448_01C86FEC.6BFF2F30 Content-Type: text/plain; name="ATT01077.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01077.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0448_01C86FEC.6BFF2F30 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint ------=_NextPart_000_0448_01C86FEC.6BFF2F30-- From speermint-bounces@ietf.org Mon Feb 18 14:38:36 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8998C3A6CDA; Mon, 18 Feb 2008 14:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvSj3oJXfYFq; Mon, 18 Feb 2008 14:38:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8700A3A69CD; Mon, 18 Feb 2008 14:38:35 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2A43A6934; Mon, 18 Feb 2008 14:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9079TnOrfgyB; Mon, 18 Feb 2008 14:38:33 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 9C74E3A6963; Mon, 18 Feb 2008 14:38:33 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMbap2032297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:37:37 -0800 From: "Richard Shockey" To: , Date: Mon, 18 Feb 2008 17:36:22 -0500 Message-ID: <134e01c8727e$b1bfec50$153fc4f0$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_134F_01C87254.C8E9E450" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyeyXAX9PFlZtxTO+6FuemSLONzgAA3iuQ Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Speermint] FW: I-D Action:draft-mule-peppermint-espp-protocol-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_134F_01C87254.C8E9E450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 18, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-peppermint-espp-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Provisioning Protocol for ENUM-SIP Addressing Servers Author(s) : K. Cartwright, et al. Filename : draft-mule-peppermint-espp-protocol-00.txt Pages : 117 Date : 2008-02-18 This document defines a provisioning protocol for ENUM-SIP addressing servers. This protocol has been recently published as part of CableLabs(r) PacketCable(tm) specifications. It allows SIP service providers to provision and manage session establishment data used by SIP network elements to route SIP sessions to the target destinations which may be served by the operator's own internal network or by a session peering partner. The data provisioned into an ENUM-SIP addressing server is queried by SIP entities using ENUM or SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-00.t xt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mule-peppermint-espp-protocol-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mule-peppermint-espp-protocol-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_134F_01C87254.C8E9E450 Content-Type: Message/External-body; name="ATT04896.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT04896.dat" Content-Type: text/plain Content-ID: <2008-02-18135556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mule-peppermint-espp-protocol-00.txt ------=_NextPart_000_134F_01C87254.C8E9E450 Content-Type: Message/External-body; name="draft-mule-peppermint-espp-protocol-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mule-peppermint-espp-protocol-00.txt" Content-Type: text/plain Content-ID: <2008-02-18135556.I-D\@ietf.org> ------=_NextPart_000_134F_01C87254.C8E9E450 Content-Type: text/plain; name="ATT04899.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT04899.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_134F_01C87254.C8E9E450 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint ------=_NextPart_000_134F_01C87254.C8E9E450-- From speermint-bounces@ietf.org Mon Feb 18 14:38:49 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228FE28C3E1; Mon, 18 Feb 2008 14:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHgQySJKYkYD; Mon, 18 Feb 2008 14:38:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDF23A6DA5; Mon, 18 Feb 2008 14:38:47 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CDC93A6963; Mon, 18 Feb 2008 14:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDtNBeSPJj1L; Mon, 18 Feb 2008 14:38:44 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id DB1FB3A6D91; Mon, 18 Feb 2008 14:38:43 -0800 (PST) Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1IMboIn032524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2008 14:37:52 -0800 From: "Richard Shockey" To: , Date: Mon, 18 Feb 2008 17:36:37 -0500 Message-ID: <135201c8727e$ba0fe9f0$2e2fbdd0$@us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1353_01C87254.D139E1F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Achyesn22bGixofXQs+M5jw+I91bggAA+f8g Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Speermint] FW: I-D Action:draft-mule-peppermint-espp-requirements-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_1353_01C87254.D139E1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 18, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-mule-peppermint-espp-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Provisioning Protocol Requirements for ENUM-SIP Addressing Servers Author(s) : T. Creighton, J. Mule Filename : draft-mule-peppermint-espp-requirements-00.txt Pages : 16 Date : 2008-02-18 This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by an addressing server to return part of the session establishment data to SIP entities so that they can route SIP sessions to the target destinations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements- 00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mule-peppermint-espp-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mule-peppermint-espp-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_1353_01C87254.D139E1F0 Content-Type: Message/External-body; name="ATT04878.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT04878.dat" Content-Type: text/plain Content-ID: <2008-02-18135422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mule-peppermint-espp-requirements-00.txt ------=_NextPart_000_1353_01C87254.D139E1F0 Content-Type: Message/External-body; name="draft-mule-peppermint-espp-requirements-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mule-peppermint-espp-requirements-00.txt" Content-Type: text/plain Content-ID: <2008-02-18135422.I-D\@ietf.org> ------=_NextPart_000_1353_01C87254.D139E1F0 Content-Type: text/plain; name="ATT04881.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT04881.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_1353_01C87254.D139E1F0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint ------=_NextPart_000_1353_01C87254.D139E1F0-- From speermint-bounces@ietf.org Tue Feb 19 16:56:04 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3C03A6E44; Tue, 19 Feb 2008 16:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI0diXtmUz6W; Tue, 19 Feb 2008 16:56:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D613A6E4F; Tue, 19 Feb 2008 16:56:02 -0800 (PST) X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5A0C93A6E46; Tue, 19 Feb 2008 16:56:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080220005601.5A0C93A6E46@core3.amsl.com> Date: Tue, 19 Feb 2008 16:56:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-consolidated-presence-im-usecases-04.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : Presence & Instant Messaging Peering Use Cases Author(s) : A. Houri Filename : draft-ietf-speermint-consolidated-presence-im-usecases-04.txt Pages : 9 Date : 2008-2-19 The document describes several use cases of peering of non-VoIP services between two or more Service Providers. These Service Providers create a peering relationship between themselves thus enabling their users to collaborate with users on the other Service Provider network. The target of the document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services and presence and Instant Messaging (IM) in particular. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-consolidated-presence-im-usecases-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-2-19163037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-consolidated-presence-im-usecases-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-2-19163037.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Fri Feb 22 03:13:25 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716EE28C2E4; Fri, 22 Feb 2008 03:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.259 X-Spam-Level: ** X-Spam-Status: No, score=2.259 tagged_above=-999 required=5 tests=[AWL=2.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFVfwslKLSka; Fri, 22 Feb 2008 03:13:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C3F3A6C99; Fri, 22 Feb 2008 03:13:23 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51D728C2E9 for ; Fri, 22 Feb 2008 03:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58xkI+eEwJkI for ; Fri, 22 Feb 2008 03:13:21 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id E21B628C2CC for ; Fri, 22 Feb 2008 03:13:20 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m1MBCsht014585; Fri, 22 Feb 2008 04:12:54 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 22 Feb 2008 04:12:54 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 04:12:38 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6FA6620@srvxchg3.cablelabs.com> In-Reply-To: <45AEC6EF95942140888406588E1A660203A5AAF1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-16.txt Thread-Index: Acht5LCiCZsybpgrTeSItre6xAwVWAAegWagAbi+uhA= References: <20080213020001.8260228C141@core3.amsl.com> <45AEC6EF95942140888406588E1A660203A5AAF1@PACDCEXCMB04.cable.comcast.com> From: "Jean-Francois Mule" To: "Daryl Malas" , X-Approved: ondar Cc: speermint@ietf.org, "Livingood, Jason" Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-terminology-16.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I read the last version of the terminology document and it looks ok to me. A few minor comments: a) Reference sections The terminology document has an informational status and no 2119 verbs. Should the normative references be moved to the informative reference? Also, please check the IDnits and warnings for unused references: http://tools.ietf.org/tools/idnits/ Checking references for intended status: Informational ------------------------------------------------------------------------ ---- == Unused Reference: '9' is defined on line 480, but no explicit reference was found in the text '[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA...' == Unused Reference: '10' is defined on line 484, but no explicit reference was found in the text '[10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RF...' == Unused Reference: '11' is defined on line 487, but no explicit reference was found in the text '[11] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1...' == Unused Reference: '12' is defined on line 490, but no explicit reference was found in the text '[12] Postel, J., "DoD Standard Transmission Control Protocol", RFC...' == Unused Reference: '13' is defined on line 493, but no explicit reference was found in the text '[13] Plummer, David C., "An Ethernet Address Resolution Protocol",...' == Unused Reference: '14' is defined on line 496, but no explicit reference was found in the text '[14] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines...' c) other typos: The RFC editor will likely catch that but just in case: In "7. Security Considerations": s/analyzes/analyses ? Jean-Francois. > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint- > bounces@ietf.org] On Behalf Of Livingood, Jason > Sent: Wednesday, February 13, 2008 9:39 AM > To: speermint@ietf.org > Cc: Daryl Malas > Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint- > terminology-16.txt > > Since we've had a few WGLCs on this document already, we are > calling an > abbreviated WGLC from today, February 13, 2008, to February 21, > 2008. > > Thank you > Jason > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, February 12, 2008 9:00 PM > > To: i-d-announce@ietf.org > > Cc: speermint@ietf.org > > Subject: [Speermint] I-D > > ACTION:draft-ietf-speermint-terminology-16.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Session PEERing for > > Multimedia INTerconnect Working Group of the IETF. > > > > Title : SPEERMINT Terminology > > Author(s) : D. Malas, D. Meyer > > Filename : draft-ietf-speermint-terminology-16.txt > > Pages : 12 > > Date : 2008-2-12 > > > > This document defines the terminology that is to be used in > > describing Session PEERing for Multimedia INTerconnect > (SPEERMINT). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi > > nology-16.txt > > > > To remove yourself from the I-D Announcement list, send a > > message to i-d-announce-request@ietf.org with the word > > unsubscribe in the body of the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D- > announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username "anonymous" and a password of your e-mail > > address. After logging in, type "cd internet-drafts" and then > > "get draft-ietf-speermint-terminology-16.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-speermint-terminology- > 16.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" > or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > split > > up into multiple messages), so check your local documentation > on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail > > reader implementation to automatically retrieve the ASCII > > version of the Internet-Draft. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 22 10:26:09 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBDE28C453; Fri, 22 Feb 2008 10:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1T5dMcpWubh; Fri, 22 Feb 2008 10:26:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C867D28C3DA; Fri, 22 Feb 2008 10:26:08 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB0C3A6CA7 for ; Fri, 22 Feb 2008 10:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo5mMQIHa0I5 for ; Fri, 22 Feb 2008 10:26:06 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8DE9028C3DA for ; Fri, 22 Feb 2008 10:26:06 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3A5DC2C000357 for ; Fri, 22 Feb 2008 19:26:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJExrLTT4Fw1 for ; Fri, 22 Feb 2008 19:26:02 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id 197E72C000355 for ; Fri, 22 Feb 2008 19:25:57 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C87580.5E3AD2E3" Date: Fri, 22 Feb 2008 19:25:55 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DBF5@mx1.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-niccolini-speermint-voipthreats-03.txt Thread-Index: Ach1UQFRJo4uOkLHSSCSK6EOXc9GGQALx4SQ From: "Saverio Niccolini" To: Subject: [Speermint] FW: I-D Action:draft-niccolini-speermint-voipthreats-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C87580.5E3AD2E3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, a new version of the VoIP Threats draft is available. Main changes are: -- adapted to the terminology draft -- added the BCPs Comments are appreciated, Saverio > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Friday, February 22, 2008 1:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-niccolini-speermint-voipthreats-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : SPEERMINT Security BCPs > Author(s) : S. Niccolini, et al. > Filename : draft-niccolini-speermint-voipthreats-03.txt > Pages : 22 > Date : 2008-02-22 >=20 > This memo presents the different security threats related to=20 > SPEERMINT classifying them into threats to the Location=20 > Function, to the Signaling Function and to the Media=20 > Function. The different instances of the threats are briefly=20 > introduced inside the classification. Finally the existing=20 > security solutions in SIP and RTP/RTCP are presented to=20 > describe the countermeasures currently available for such=20 > threats. The objective of this document is to identify and=20 > enumerate the SPEERMINT-specific threat vectors in order to=20 > specify security-related requirements. Once the requirements=20 > are identified, methods and solutions how to achieve such=20 > requirements can be selected. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-niccolini-speermint- > voipthreats-03.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-niccolini-speermint-voipthreats-03.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-niccolini-speermint-voipthreats-03.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 ------_=_NextPart_001_01C87580.5E3AD2E3 Content-Type: application/octet-stream; name="draft-niccolini-speermint-voipthreats-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-niccolini-speermint-voipthreats-03.URL Content-Disposition: attachment; filename="draft-niccolini-speermint-voipthreats-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1uaWNjb2xpbmktc3BlZXJtaW50LXZvaXB0aHJlYXRzLTAzLnR4dA0K ------_=_NextPart_001_01C87580.5E3AD2E3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C87580.5E3AD2E3-- From speermint-bounces@ietf.org Fri Feb 22 11:40:27 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E6328C480; Fri, 22 Feb 2008 11:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnQh0kFmXxZZ; Fri, 22 Feb 2008 11:40:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD6328C4F5; Fri, 22 Feb 2008 11:40:05 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45AC28C4BE for ; Fri, 22 Feb 2008 11:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AItw1RqC3b3E for ; Fri, 22 Feb 2008 11:40:00 -0800 (PST) Received: from mailsrv.ams.gblxint.com (unknown-230-det.globalcrossing.com [64.208.159.230]) by core3.amsl.com (Postfix) with ESMTP id EBBA128CA21 for ; Fri, 22 Feb 2008 11:37:24 -0800 (PST) Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id B644294A3 for ; Fri, 22 Feb 2008 14:37:20 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 14:37:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 14:37:19 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTg== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 22 Feb 2008 19:37:20.0916 (UTC) FILETIME=[57361D40:01C8758A] Subject: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org For general consumption in prep for Philly. See y'all in the city of brotherly love! Feedback welcomed. Changes: - resync with the latest term draft. - clarifications based on feedback from the last meeting - like collapse/removal of assisted peering use cases into direct/indirect models. http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat ed-usecases-05.txt I am working on version 6, mostly weeding out nits, and will issue after the WG session. Thanks in advance for your feedback!! Adam Uzelac Director, Converged Network Arch and Planning Global Crossing 585-563-4359 _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Feb 24 14:13:50 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B71C28C1FE; Sun, 24 Feb 2008 14:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N4OrTUaGv5s; Sun, 24 Feb 2008 14:13:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAAD3A68A0; Sun, 24 Feb 2008 14:13:49 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A5028C15B; Sun, 24 Feb 2008 14:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3MZw2AYnPlD; Sun, 24 Feb 2008 14:13:47 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id E053E3A68A0; Sun, 24 Feb 2008 14:13:47 -0800 (PST) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1OMCK5g026130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Feb 2008 14:12:28 -0800 From: "Richard Shockey" To: , Date: Sun, 24 Feb 2008 17:10:39 -0500 Message-ID: <335b01c87732$1f19bdf0$5d4d39d0$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach2/+Fg0gcdqw0/QXuL9tWkFwu44AAMhfMA Content-language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Subject: [Speermint] FW: [CYBERTEL] The Future of IP Interconnection: Technical, Economic and Public Policy Aspects X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org FYI from our friends at the Commission.. ******** The following report, produced by WIK-Consult on behalf of the European Commission, has just been published on the European Commission's web site. I had the pleasure and honor of working with some very exceptional colleagues. Those of you who are familiar with my previous work on the subject will see that this is a deeper and more comprehensive treatment. =============== The Future of IP Interconnection: Technical, Economic and Public Policy Aspects - prepared by WIK-Consult. http://ec.europa.eu/information_society/policy/ecomm/library/ext_studies/ind ex_en.htm#2008 Executive Summary only: http://ec.europa.eu/information_society/policy/ecomm/doc/library/ext_studies /future_ip_intercon/ip_intercon_study_exec_sum.pdf Full Study: http://ec.europa.eu/information_society/policy/ecomm/doc/library/ext_studies /future_ip_intercon/ip_intercon_study_final.pdf Cheers, = Scott _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 25 06:07:25 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1793A6C0B; Mon, 25 Feb 2008 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, HTML_OBFUSCATE_05_10=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjxWIbE7zEaD; Mon, 25 Feb 2008 06:07:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E90128C33F; Mon, 25 Feb 2008 06:06:43 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0CA28C2C4 for ; Mon, 25 Feb 2008 06:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwnYJ7y06RnV for ; Mon, 25 Feb 2008 06:06:41 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id D529728C3B5 for ; Mon, 25 Feb 2008 06:05:47 -0800 (PST) Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28195093; Mon, 25 Feb 2008 14:05:40 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DBF5@mx1.office> References: <5F6519BF2DE0404D99B7C75607FF76FF53DBF5@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <384253AE-20F6-41A2-B540-0CA3CA2AE2BB@voxeo.com> From: Dan York Date: Mon, 25 Feb 2008 09:05:29 -0500 To: Saverio Niccolini X-Mailer: Apple Mail (2.753) Cc: speermint@ietf.org Subject: Re: [Speermint] FW: I-D Action:draft-niccolini-speermint-voipthreats-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0413831007==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============0413831007== Content-Type: multipart/alternative; boundary=Apple-Mail-252-155346919 --Apple-Mail-252-155346919 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Saverio, The document looks quite good. On behalf of VOIPSA, I'll say again thanks for the mention of the Threat Taxonomy. (I know I've said this to you personally in the past but also want to do so publicly.) A couple of minor nits, mostly related to formatting: - In sections 2.1.x and 2.2.1-2, you list out individual attacks as bullet items. In section 2.2.3, you mention several attacks but do not list them as bullet items. For the sake of consistency you might want to consider doing so. - Sections 2.1.1 and 2.2.1 do not have introductory sentences but purely include bullets. I don't know if you care about being consistent with the other sections. - In section 2.2.3, there is a missing "the" in the first sentence: "The LF can be THE object of DoS attacks." - In section 2.3 there are a couple of places in the first sentence where you use "signaling function" but I think to be grammatically correct it should be "the signaling function". (As I wonder if I'm going to unleash another grammar rathole... ) - In sections 2.3.2.1 and 2.3.2.2 the bullets suddenly disappeared (at least on http://www.ietf.org/internet-drafts/draft-niccolini- speermint-voipthreats-03.txt ) - Section 2.4.1 again has no bullets while 2.4.2-2.4.3 do Like I said, really all just formatting issues. The only real substantive comment I'll make is to ask this - have you considered if there is a threat of what I'll call a "self-inflicted DoS" within the SPEERMINT architecture? By that I mean what happens when, for instance, there is a power outage and upon the return of power there is a large flood as all the SIP devices send INVITEs to the registrar. Obviously that instance doesn't impact the SPEERMINT architecture, but are there similar issues? For instance, misconfiguration of one SIP provider's servers sending a flood of bogus packets within the peering fabric? If there are such situations it may make sense to at least mention them in this document. I find that people often focus on the external attackers and forget to look at how to protect against internal configuration problems that can have the same ultimate effect as an external attacker. Overall a great document, Dan On Feb 22, 2008, at 1:25 PM, Saverio Niccolini wrote: > Hi, > > a new version of the VoIP Threats draft is available. > Main changes are: > -- adapted to the terminology draft > -- added the BCPs > > Comments are appreciated, > Saverio > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Friday, February 22, 2008 1:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-niccolini-speermint-voipthreats-03.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : SPEERMINT Security BCPs >> Author(s) : S. Niccolini, et al. >> Filename : draft-niccolini-speermint-voipthreats-03.txt >> Pages : 22 >> Date : 2008-02-22 >> >> This memo presents the different security threats related to >> SPEERMINT classifying them into threats to the Location >> Function, to the Signaling Function and to the Media >> Function. The different instances of the threats are briefly >> introduced inside the classification. Finally the existing >> security solutions in SIP and RTP/RTCP are presented to >> describe the countermeasures currently available for such >> threats. The objective of this document is to identify and >> enumerate the SPEERMINT-specific threat vectors in order to >> specify security-related requirements. Once the requirements >> are identified, methods and solutions how to achieve such >> requirements can be selected. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-niccolini-speermint- >> voipthreats-03.txt >> >> To remove yourself from the I-D Announcement list, send a >> message to i-d-announce-request@ietf.org with the word >> unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login >> with the username "anonymous" and a password of your e-mail >> address. After logging in, type "cd internet-drafts" and then >> "get draft-niccolini-speermint-voipthreats-03.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> /internet-drafts/draft-niccolini-speermint-voipthreats-03.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail >> reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >> > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 speermint- > voipthreats-03.URL>_______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-252-155346919 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

The = document looks quite good. =A0On behalf of VOIPSA, I'll say again thanks = for the mention of the Threat Taxonomy. (I know I've said this to you = personally in the past but also want to do so publicly.)

A couple of minor nits, = mostly related to formatting:

- In sections 2.1.x and = 2.2.1-2, you list out individual attacks as bullet items. =A0In section = 2.2.3, you mention several attacks but do not list them as bullet items. = =A0For the sake of consistency you might want to consider doing = so.

- Sections 2.1.1 and 2.2.1 do not have = introductory sentences but purely include bullets. I don't know if you = care about being consistent with the other sections.

- In section 2.2.3, there = is a missing "the" in the first sentence: "The LF can be THE object of = DoS attacks."

- In section 2.3 there are = a couple of places in the first sentence where you use "signaling = function" but I think to be grammatically correct it should be "the = signaling function". =A0(As I wonder if I'm going to unleash another = grammar rathole... )

- In sections 2.3.2.1 and = 2.3.2.2 the bullets suddenly disappeared (at least on=A0http://www.ietf.org/internet-drafts/draft-niccolini-speerm= int-voipthreats-03.txt )

- Section 2.4.1 again has = no bullets while 2.4.2-2.4.3 do

Like I said, really all = just formatting issues.

The only real substantive = comment I'll make is to ask this - have you considered if there is a = threat of what I'll call a "self-inflicted DoS" within the SPEERMINT = architecture? =A0By that I mean what happens when, for instance, there = is a power outage and upon the return of power there is a large flood as = all the SIP devices send INVITEs to the registrar. =A0 Obviously that = instance doesn't impact the SPEERMINT architecture, but are there = similar issues? =A0For instance, misconfiguration of one SIP provider's = servers sending a flood of bogus packets within the peering fabric? =A0If = there are such situations it may make sense to at least mention them in = this document. =A0I find that people often focus on the external = attackers and forget to look at how to protect against internal = configuration problems that can have the same ultimate effect as an = external attacker.

Overall a great = document,
Dan

On Feb 22, 2008, = at 1:25 PM, Saverio Niccolini wrote:

Hi,

a new version of the VoIP = Threats draft is available.
Main changes = are:
-- adapted to the terminology = draft
-- added the BCPs

Comments = are appreciated,
Saverio

-----Original = Message-----
Internet-Drafts@ietf.org
Sent: Friday, February 22, 2008 1:45 PM
Subject: I-D = Action:draft-niccolini-speermint-voipthreats-03.txt=A0

A New = Internet-Draft is available from the on-line=A0

Title =A0 =A0 =A0 =A0 =A0 : SPEERMINT = Security BCPs
Author(s) =A0 =A0 =A0 : S. Niccolini, et = al.
Filename=A0 =A0 =A0 =A0 : = draft-niccolini-speermint-voipthreats-03.txt
Pages =A0 =A0 =A0 =A0 =A0 : = 22
Date=A0 =A0 =A0 =A0 =A0 =A0 : = 2008-02-22

This memo presents the different security threats = related to=A0
SPEERMINT classifying them into threats to the = Location=A0
Function, to the Signaling Function and to the = Media=A0
Function.=A0 = The different instances of the threats are briefly=A0
=A0 Finally the existing=A0
security = solutions in SIP and RTP/RTCP are presented to=A0
describe = the countermeasures currently available for such=A0
=A0 The objective = of this document is to identify and=A0
=A0
specify = security-related requirements.=A0 = Once the requirements=A0
are = identified, methods and solutions how to achieve such=A0

A URL for this Internet-Draft = is:
voipthreats-03.txt

To remove = yourself from the I-D Announcement list, send a=A0
message = to i-d-announce-request@ietf.or= g with the word=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login=A0
with the = username "anonymous" and a password of your e-mail=A0
address. = After logging in, type "cd internet-drafts" and then
"get = draft-niccolini-speermint-voipthreats-03.txt".

A list = of Internet-Drafts directories can be found in=A0
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
= "FILE=A0

NOTE: = =A0 The mail server at = ietf.org can return the document in
= MIME-encoded form by using the "mpack" utility.=A0 To use this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant=A0
mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail=A0
reader implementation to automatically retrieve the = ASCII=A0
version of the Internet-Draft.

Dr. Saverio = Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research = Division =
Kurfuerstenanlage 36, D-69115 = Heidelberg
Tel. =A0 =A0 +49 (0)6221 = 4342-118
Fax: =A0 =A0 +49 (0)6221 = 4342-155
e-mail:=A0 saverio.niccolini@nw.neclab= .eu <-- !!! NEW ADDRESS !!!
NEC Europe = Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England = 2832014<draft-niccolini-speermint-voipthreats-03.URL>__= _____________________________________________
Speermint mailing list

=
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-252-155346919-- --===============0413831007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint --===============0413831007==-- From speermint-bounces@ietf.org Mon Feb 25 09:47:16 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F8F28C6B0; Mon, 25 Feb 2008 09:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erhcQAKTqJGM; Mon, 25 Feb 2008 09:47:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A2028C889; Mon, 25 Feb 2008 09:45:05 -0800 (PST) X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4431728C865; Mon, 25 Feb 2008 09:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225174501.4431728C865@core3.amsl.com> Date: Mon, 25 Feb 2008 09:45:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-requirements-04.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Requirements for SIP-based VoIP Interconnection Author(s) : J. Mule Filename : draft-ietf-speermint-requirements-04.txt Pages : 28 Date : 2008-02-25 A number of use cases have been described for session peering of voice, presence, instant messaging and other types of multimedia traffic. This memo captures some of the requirements identified by these use case scenarios. It is intended to become an informational document linking the use cases to potential protocol solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-requirements-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-requirements-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25093301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25093301.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Feb 25 15:09:30 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B0128D7CD; Mon, 25 Feb 2008 15:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEBJHDU9uNbD; Mon, 25 Feb 2008 15:09:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A905828D425; Mon, 25 Feb 2008 14:15:09 -0800 (PST) X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B618628D302; Mon, 25 Feb 2008 14:15:01 -0800 (PST) Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225221501.B618628D302@core3.amsl.com> Date: Mon, 25 Feb 2008 14:15:01 -0800 (PST) Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno Filename : draft-ietf-speermint-architecture-05.txt Pages : 22 Date : 2008-2-25 This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. It also describes the steps taken to establish a session between two peering domains in the context of the functions defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 25 16:48:56 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354BB28CC45; Mon, 25 Feb 2008 16:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMDmLoBOaE7J; Mon, 25 Feb 2008 16:48:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715C73A6E39; Mon, 25 Feb 2008 15:33:49 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864E53A6E34; Mon, 25 Feb 2008 15:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI3No9u4ujmU; Mon, 25 Feb 2008 15:33:47 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6DC2928C563; Mon, 25 Feb 2008 15:24:44 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 18:24:23 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 18:24:23 -0500 From: Hadriel Kaplan To: "otmar.lendl@enum.at" Date: Mon, 25 Feb 2008 18:24:02 -0500 Thread-Topic: I-D Action:draft-lendl-speermint-background-01.txt Thread-Index: Ach3/lP1YlJ4BqNfR/iwl+z1P+KHZgAA7TEw Message-ID: References: <20080225211502.9836C3A6D85@core3.amsl.com> In-Reply-To: <20080225211502.9836C3A6D85@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "speermint@ietf.org" , "PEPPERMINT@ietf.org" Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Awesome draft. (I missed it the first time 'round) I agree with your statement of "The obvious solution is to add an on-demand mapping step ahead of the routing protocol." The trick will be how that works/scales, and how it interacts with a routing protocol. The easy case is the non-transit bilateral peering - the very hard case is transit. One very minor nit: I don't think TRIP failed due to being prefix-based and thus needing aggregation. I think it failed because the market wasn't ready for it (the problem didn't need to be fixed for most people yet), the idea of implementing/using BGP scared off voip vendors, and it didn't cover some of the routing selection models people need. -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, February 25, 2008 4:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-lendl-speermint-background-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : VoIP Peering: Background and Assumptions > Author(s) : O. Lendl > Filename : draft-lendl-speermint-background-01.txt > Pages : 15 > Date : 2008-02-25 > > This documents provides background for the work on VoIP peering and > tries to provide guidance on what kind of work is needed to > facilitate widespread SIP-based peering of telephony networks. It is > intended to spur discussion on the work about peering and should also > serve as input to the ongoing discussions on reducing Spam for > Internet Telephony (SPIT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-speermint-background- > 01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lendl-speermint-background-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lendl-speermint-background-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 25 16:49:03 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31B128CDA7; Mon, 25 Feb 2008 16:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2LUghYOpjFu; Mon, 25 Feb 2008 16:49:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDE53A6AC9; Mon, 25 Feb 2008 15:47:13 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2243C3A67FF for ; Mon, 25 Feb 2008 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfSaWhli8573 for ; Mon, 25 Feb 2008 15:47:11 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7FB013A6913 for ; Mon, 25 Feb 2008 15:38:05 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m1PNbu6a030341; Mon, 25 Feb 2008 16:37:56 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 25 Feb 2008 16:37:56 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Feb 2008 16:37:56 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTgCZfdLA References: From: "Daryl Malas" To: "Uzelac, Adam" , X-Approved: ondar Subject: Re: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org "VoIP consolidated use cases" author's, First, let me say, I think the draft is off to a good start. I would like to suggest some things, I believe will allow the draft to provide better clarity and more depth for a reader to understand the reasons and situations relating to VoIP peering. Here are a few encompassing comments and general nits of the document: - I recommend looking through RFC 3285 before the next revision of the draft. There are a number of Word template issues, which can be resolved fairly easy. - The references need to be updated. - Finally, as I review the use cases, I am looking for the following basic structure within each use case: Goal, Summary, Actors, Preconditions, Triggers, Basic course of events, Alternative paths (if applicable), and any Policy considerations. -------------------------------- More detailed comments: Section 4 - "Each grouping can further sub-divided to Direct Peering and Indirect Peering [15]." Should it be, "Each grouping can be further sub-divided to Direct and Indirect Peering [15]"? "Each use-case has to specify how a few core operations which are to be performed by its members." I would like to suggest re-wording to, "Each use case must specify a basic set of required operations to be performed by each member when peering." Section 5.1 - I would expect this intro paragraph to describe the goal of static peering. For example, "Static peering is used in cases, when two peers want a consistent and "hardened" approach to peering. In this scenario, all of the variables are very well defined and known by each peer....." Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer with Enterprise B, SSP A wants to peer with SSP B, SSP A is providing static peering for Enterprise A, B, and C, etc.)? What are the preconditions required for this use case to be successful (e.g. each peer must exchange their allowable set of codecs, authentication method, no RFC1918 addresses, etc.)? What are the triggers (i.e. what causes SSPA to think it can send it to a peer?) The sentence beginning, "Two SSP negotiate and agree..." seems to begin the course of events, but you have other events numbered below. This is confusing. I would suggest moving these into the numbered events below. Each of the events listed, such provide an example of what is occurring with each. The current ones are too high level of value in deriving requirements. For example: 1. UAC initiates a call via SIP INVITE to O-Proxy (Snippets frm RFC 3665) INVITE sip:+13031112222@denver.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: +13031112222 Contact: 2. O-Proxy queries for SED information from a routing database (ENUM?? - LUF) (The result of the ENUM query is...) $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com NAPTR 10 100 "u" "E2U+SIP" "!^.*$ !sip:\\1@sbe1-denver.sspa.example.com!". 3. Routing database entity replies with SED to called party (NAPTR - LRF) sbe1-denver.sspa.example.com. order pref flgs service regx replacement IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.sbe1-denver.sspa.example.com 4. O-Proxy sends a DNS SRV query for _sip._udp.sbe1-denver.sspa.example.com which results in: $ORIGIN _sip._udp.sbe1-denver.sspa.example.com. (Some content not included for clarity purposes.) IN SRV 0 1 5060 sbe1-denver.sspa.example.com ;; ANSWER SECTION sbe1-denver.sspa.example.com A 192.0.2.17 sbe2-denver.sspa.example.com A 192.0.2.18 5. Call sent to terminating domain proxy. INVITE sip:+13031112222@sbe1-denver.sspa.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: +13031112222 Contact: 6. T-Proxy determines called party location by querying the ENUM server $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com NAPTR 10 100 "u" "E2U+SIP" "!^.*$ !sip:\\bob@proxy1-denver.sspa.example.com!". ....and so on. I think this detail will provide clarity for the requirements and for readers to understand the necessary steps to successfully peer. I think this should be done for each of the use cases. Section 5.1.1 - These appear to be optional (or additional potential) pre-conditions, which could occur relative to this use case. If this is case, I would suggest calling them Optional Pre-conditions and not Options and Nuances. --------------------------------- I think making similar, relative changes to each of the use case sections will get the very close to a finished product. --Daryl -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam Sent: Friday, February 22, 2008 12:37 PM To: speermint@ietf.org Subject: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt For general consumption in prep for Philly. See y'all in the city of brotherly love! Feedback welcomed. Changes: - resync with the latest term draft. - clarifications based on feedback from the last meeting - like collapse/removal of assisted peering use cases into direct/indirect models. http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat ed-usecases-05.txt I am working on version 6, mostly weeding out nits, and will issue after the WG session. Thanks in advance for your feedback!! Adam Uzelac Director, Converged Network Arch and Planning Global Crossing 585-563-4359 _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 25 17:46:52 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1134828C7A3; Mon, 25 Feb 2008 17:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgk+2Hab6FlL; Mon, 25 Feb 2008 17:46:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46FF43A6E56; Mon, 25 Feb 2008 17:37:55 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F123A6C14; Mon, 25 Feb 2008 17:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk6N5WxQaCB6; Mon, 25 Feb 2008 17:37:53 -0800 (PST) Received: from mail.songbird.com (mail.songbird.com [208.184.79.10]) by core3.amsl.com (Postfix) with ESMTP id 44A773A6EF0; Mon, 25 Feb 2008 17:28:49 -0800 (PST) Received: from rshockeyPC (h-68-165-240-38.mclnva23.covad.net [68.165.240.38]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id m1Q1RXhk027744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2008 17:27:44 -0800 From: "Richard Shockey" To: "'Hadriel Kaplan'" , References: <20080225211502.9836C3A6D85@core3.amsl.com> In-Reply-To: Date: Mon, 25 Feb 2008 20:25:48 -0500 Message-ID: <03e901c87816$8cf8ac20$a6ea0460$@us> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach3/lP1YlJ4BqNfR/iwl+z1P+KHZgAA7TEwAAUJ2/A= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us Cc: speermint@ietf.org, PEPPERMINT@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org > Awesome draft. (I missed it the first time 'round) > > I agree with your statement of "The obvious solution is to add an on- > demand mapping step ahead of the routing protocol." The trick will be > how that works/scales, and how it interacts with a routing protocol. > The easy case is the non-transit bilateral peering - the very hard > case is transit. > > One very minor nit: I don't think TRIP failed due to being prefix- > based and thus needing aggregation. I think it failed because the > market wasn't ready for it (the problem didn't need to be fixed for > most people yet), the idea of implementing/using BGP scared off voip > vendors, and it didn't cover some of the routing selection models > people need. IMHO TRIP failed because it was using a 120 mm howitzer to deal with a problem better dealt with a BB gun. There were enough issues with BGP as it was. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 25 19:32:59 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DB628C2B0; Mon, 25 Feb 2008 19:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvpoKoHuZYZ3; Mon, 25 Feb 2008 19:32:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B053A6BA9; Mon, 25 Feb 2008 19:32:58 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12853A67FF; Mon, 25 Feb 2008 19:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Y37UtPXp9b; Mon, 25 Feb 2008 19:32:56 -0800 (PST) Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D6A753A6783; Mon, 25 Feb 2008 19:32:55 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 25 Feb 2008 22:32:34 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 25 Feb 2008 22:32:34 -0500 From: Hadriel Kaplan To: Richard Shockey , "otmar.lendl@enum.at" Date: Mon, 25 Feb 2008 22:30:53 -0500 Thread-Topic: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Thread-Index: Ach3/lP1YlJ4BqNfR/iwl+z1P+KHZgAA7TEwAAUJ2/AAA2ePMA== Message-ID: References: <20080225211502.9836C3A6D85@core3.amsl.com> <03e901c87816$8cf8ac20$a6ea0460$@us> In-Reply-To: <03e901c87816$8cf8ac20$a6ea0460$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "speermint@ietf.org" , "PEPPERMINT@ietf.org" Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Well... working for one of only two vendors who implemented it, afaict, it failed for multiple reasons. None of them had to do with prefix aggregation or scalability, at least at the time. BGP was definitely a poor choice, though more for marketing/perception reasons than technical, albeit there were some major technical issues with it too. It was never tied to BGP for IP routing - it operated on a separate plane really, and even had a different protocol model for internal route distribution, but yes it inherited too much of BGP in terms of deployment model and some unnecessary baggage. The big killer though, imho, was there was no real problem at the time that it solved. It's moot though - I'm definitely not suggesting a TRIP down memory lane. :) -hadriel > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Monday, February 25, 2008 8:26 PM > To: Hadriel Kaplan; otmar.lendl@enum.at > Cc: speermint@ietf.org; PEPPERMINT@ietf.org > Subject: RE: [Speermint] I-D Action:draft-lendl-speermint-background- > 01.txt > > > Awesome draft. (I missed it the first time 'round) > > > > I agree with your statement of "The obvious solution is to add an on- > > demand mapping step ahead of the routing protocol." The trick will be > > how that works/scales, and how it interacts with a routing protocol. > > The easy case is the non-transit bilateral peering - the very hard > > case is transit. > > > > One very minor nit: I don't think TRIP failed due to being prefix- > > based and thus needing aggregation. I think it failed because the > > market wasn't ready for it (the problem didn't need to be fixed for > > most people yet), the idea of implementing/using BGP scared off voip > > vendors, and it didn't cover some of the routing selection models > > people need. > > IMHO TRIP failed because it was using a 120 mm howitzer to deal with a > problem better dealt with a BB gun. There were enough issues with BGP as > it > was. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 06:14:11 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794763A6CBC; Tue, 26 Feb 2008 06:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz+2wGQI-fxF; Tue, 26 Feb 2008 06:14:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B983A6D16; Tue, 26 Feb 2008 06:14:07 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330673A6D16 for ; Tue, 26 Feb 2008 06:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdZ-deQTLR0c for ; Tue, 26 Feb 2008 06:14:05 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id F11443A6BBF for ; Tue, 26 Feb 2008 06:14:03 -0800 (PST) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C16872C002B4A; Tue, 26 Feb 2008 15:13:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erI1PeuM75WN; Tue, 26 Feb 2008 15:13:57 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id ADA4A2C000355; Tue, 26 Feb 2008 15:13:47 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 15:13:49 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF53DE12@mx1.office> In-Reply-To: <384253AE-20F6-41A2-B540-0CA3CA2AE2BB@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: I-D Action:draft-niccolini-speermint-voipthreats-03.txt Thread-Index: Ach3t4lrxmtKe0f4QjKUMs2Td5J+WQAyWMjQ References: <5F6519BF2DE0404D99B7C75607FF76FF53DBF5@mx1.office> <384253AE-20F6-41A2-B540-0CA3CA2AE2BB@voxeo.com> From: "Saverio Niccolini" To: "Dan York" Cc: speermint@ietf.org Subject: Re: [Speermint] FW: I-D Action:draft-niccolini-speermint-voipthreats-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Dan, thanks for the review, I will take care of your editorial comments in the next revision of the draft. > The only real substantive comment I'll make is to ask this - > have you considered if there is a threat of what I'll call a > "self-inflicted DoS" within the SPEERMINT architecture? By > that I mean what happens when, for instance, there is a power > outage and upon the return of power there is a large flood as > all the SIP devices send INVITEs to the registrar. > Obviously that instance doesn't impact the SPEERMINT > architecture, but are there similar issues? For instance, > misconfiguration of one SIP provider's servers sending a > flood of bogus packets within the peering fabric? If there > are such situations it may make sense to at least mention > them in this document. I find that people often focus on the > external attackers and forget to look at how to protect > against internal configuration problems that can have the > same ultimate effect as an external attacker. Right, we explicitly did not look at these and if the group has consensus on this we can add them in the next version of the draft. Anyway we need to be sure that the threats we are addressing are specific to SPEERMINT, we excluded domain-internal threats from the classification (not interesting to SPEERMINT the REGISTER after loss of power example you cited). Can you suggest (maybe offline) more specifically which kind of threats that are SPEERMINT specific did you have in mind? > Overall a great document, Thanks, looking forward to discussing it at the next IETF during the SPEERMINt session (we should have time allocated for this on the agenda). Cheers, Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 07:03:07 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FED28C382; Tue, 26 Feb 2008 07:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jziu7JFxheJ; Tue, 26 Feb 2008 07:03:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E1728C3A1; Tue, 26 Feb 2008 07:03:06 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CADF28C3A1 for ; Tue, 26 Feb 2008 07:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZHYZeY5B8sk for ; Tue, 26 Feb 2008 07:02:59 -0800 (PST) Received: from mailsrv.ams.gblxint.com (unknown-230-det.globalcrossing.com [64.208.159.230]) by core3.amsl.com (Postfix) with ESMTP id CA6F73A6AF7 for ; Tue, 26 Feb 2008 07:02:24 -0800 (PST) Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id A79739890; Tue, 26 Feb 2008 10:02:16 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Feb 2008 10:02:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 10:02:15 -0500 Message-ID: In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTgCZfdLAACVykKA= References: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> From: "Uzelac, Adam" To: "Daryl Malas" , X-OriginalArrivalTime: 26 Feb 2008 15:02:16.0630 (UTC) FILETIME=[938AED60:01C87888] Subject: Re: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Daryl, Excellent comments and thanks for the feedback. We have version 6 queued up and are in the process of updating. Regarding some of your comments, starting with the "(Snippets frm RFC 3665)" - you state: > ...I think this detail will provide clarity for > the requirements and for readers to understand the necessary > steps to successfully peer. I think this should be done for > each of the use cases. I read that you are requesting more detail in the use cases, but I feel it isn't necessary to get the pertinent points across. Initially, and I believe to a certain extent still, one goal of capturing current use cases (what is "occurring in the wild today), is to capture requirements. At the same time, I think that a goal in capturing the VoIP use cases at present is to identify the "ugliness", like limited-to-no transparency of SIP/VoIP Peering as it exists today. Also, with the advent of B2BUAs as the SBE/DBEs in the call flows, there would be numerous iterations of SIP Header manipulation/mangling that is done for various business, regulatory and other reasons. It could be a very slippery slope to start digging into the details, and would also balloon the draft greatly. To summarize, I am on the fence with this one. Others have thoughts? Will the details help clarify, or narrow the discussion too much? -Adam > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Monday, February 25, 2008 11:38 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: > [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt > > "VoIP consolidated use cases" author's, > > First, let me say, I think the draft is off to a good start. > I would like to suggest some things, I believe will allow the > draft to provide better clarity and more depth for a reader > to understand the reasons and situations relating to VoIP peering. > > Here are a few encompassing comments and general nits of the document: > > - I recommend looking through RFC 3285 before the next > revision of the draft. There are a number of Word template > issues, which can be resolved fairly easy. > > - The references need to be updated. > > - Finally, as I review the use cases, I am looking for the > following basic structure within each use case: Goal, > Summary, Actors, Preconditions, Triggers, Basic course of > events, Alternative paths (if applicable), and any Policy > considerations. > > -------------------------------- > > More detailed comments: > > Section 4 - "Each grouping can further sub-divided to Direct > Peering and Indirect Peering [15]." Should it be, "Each > grouping can be further sub-divided to Direct and Indirect > Peering [15]"? > > "Each use-case has to specify how a few core operations which > are to be performed by its members." I would like to suggest > re-wording to, "Each use case must specify a basic set of > required operations to be performed by each member when peering." > > Section 5.1 - I would expect this intro paragraph to describe > the goal of static peering. For example, "Static peering is > used in cases, when two peers want a consistent and > "hardened" approach to peering. In this scenario, all of the > variables are very well defined and known by each peer....." > > Section 5.1.1 - Who are the actors (e.g. Enterprise A wants > to peer with Enterprise B, SSP A wants to peer with SSP B, > SSP A is providing static peering for Enterprise A, B, and C, > etc.)? What are the preconditions required for this use case > to be successful (e.g. each peer must exchange their > allowable set of codecs, authentication method, no > RFC1918 addresses, etc.)? What are the triggers (i.e. what > causes SSPA to think it can send it to a peer?) > > The sentence beginning, "Two SSP negotiate and agree..." > seems to begin the course of events, but you have other > events numbered below. This is confusing. I would suggest > moving these into the numbered events below. > > Each of the events listed, such provide an example of what is > occurring with each. The current ones are too high level of > value in deriving requirements. For example: > > 1. UAC initiates a call via SIP INVITE to O-Proxy > > (Snippets frm RFC 3665) > INVITE sip:+13031112222@denver.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 2. O-Proxy queries for SED information from a routing > database (ENUM?? - > LUF) > > (The result of the ENUM query is...) > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\1@sbe1-denver.sspa.example.com!". > > 3. Routing database entity replies with SED to called party (NAPTR - > LRF) > > sbe1-denver.sspa.example.com. > order pref flgs service regx replacement > IN NAPTR 100 50 "s" "SIP+D2U" "" > _sip._udp.sbe1-denver.sspa.example.com > > 4. O-Proxy sends a DNS SRV query for > _sip._udp.sbe1-denver.sspa.example.com which results in: > > $ORIGIN _sip._udp.sbe1-denver.sspa.example.com. > (Some content not included for clarity purposes.) > IN SRV 0 1 5060 sbe1-denver.sspa.example.com > > ;; ANSWER SECTION > sbe1-denver.sspa.example.com A 192.0.2.17 > sbe2-denver.sspa.example.com A 192.0.2.18 > > 5. Call sent to terminating domain proxy. > > INVITE sip:+13031112222@sbe1-denver.sspa.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 6. T-Proxy determines called party location by querying the > ENUM server > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\bob@proxy1-denver.sspa.example.com!". > > ....and so on. I think this detail will provide clarity for > the requirements and for readers to understand the necessary > steps to successfully peer. I think this should be done for > each of the use cases. > > Section 5.1.1 - These appear to be optional (or additional > potential) pre-conditions, which could occur relative to this > use case. If this is case, I would suggest calling them > Optional Pre-conditions and not Options and Nuances. > > --------------------------------- > > I think making similar, relative changes to each of the use > case sections will get the very close to a finished product. > > --Daryl > > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > Sent: Friday, February 22, 2008 12:37 PM > To: speermint@ietf.org > Subject: [Speermint] > draft-ietf-speermint-voip-consolidated-usecases-05.txt > > For general consumption in prep for Philly. See y'all in the > city of brotherly love! Feedback welcomed. > > Changes: > - resync with the latest term draft. > - clarifications based on feedback from the last meeting - > like collapse/removal of assisted peering use cases into > direct/indirect models. > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidat > ed-usecases-05.txt > > I am working on version 6, mostly weeding out nits, and will > issue after the WG session. Thanks in advance for your feedback!! > > Adam Uzelac > Director, Converged Network Arch and Planning Global Crossing > 585-563-4359 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 07:38:13 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EB128C5C2; Tue, 26 Feb 2008 07:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bba-MvPMfDXp; Tue, 26 Feb 2008 07:38:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C33428C4AB; Tue, 26 Feb 2008 07:38:08 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4A03A6D1A for ; Tue, 26 Feb 2008 07:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0dZAnGJkA4e for ; Tue, 26 Feb 2008 07:37:59 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 728B93A6B8B for ; Tue, 26 Feb 2008 07:36:51 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m1QFaemO018430; Tue, 26 Feb 2008 08:36:40 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 26 Feb 2008 08:36:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 08:36:39 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0D7B@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTgCZfdLAACVykKAAAWYm0A== References: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> From: "Daryl Malas" To: "Uzelac, Adam" , X-Approved: ondar Subject: Re: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Adam, I am not suggesting a detailed signaling example of every possible scenario, but I am suggesting a relative example of the scenario described within the use case. For example, static peering can use ENUM or a redirect server. I am suggesting a detailed view of the ENUM process within the peering use case, to help the reader understand the complexities of manipulating the signaling from the UAC to the UAS. As you probably already know, this draft is not intended to define the solution, but rather describe the things that need to happen. How it should or must happen is up to later drafts. This is not as simple as it seems, and requires more than just a "oh by the way...". Then, after the use case, you suggest other possible conditions. You can say, "The described course of events is an example, and here are some other possibilities, and here are a few things, which must be considered with these other possibilities." Also, you describe the necessity to identify the "ugliness". This is my point, wrt providing detail. I see a fluffy high level overview in the draft, not much ugliness. By the way, I went through a similar situation recently...it's an easy problem to talk about, until you start diving down into a step-by-step analysis of what needs to happen and what needs to change for it to be successful. I think this is some of what Otmar has been trying to say for awhile. The final solution may require other protocol work, but I do not get a sense of this possibility yet based on the use cases. Thanks... --Daryl -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Tuesday, February 26, 2008 8:02 AM To: Daryl Malas; speermint@ietf.org Subject: RE: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Daryl, Excellent comments and thanks for the feedback. We have version 6 queued up and are in the process of updating. Regarding some of your comments, starting with the "(Snippets frm RFC 3665)" - you state: > ...I think this detail will provide clarity for the requirements and > for readers to understand the necessary steps to successfully peer. I > think this should be done for each of the use cases. I read that you are requesting more detail in the use cases, but I feel it isn't necessary to get the pertinent points across. Initially, and I believe to a certain extent still, one goal of capturing current use cases (what is "occurring in the wild today), is to capture requirements. At the same time, I think that a goal in capturing the VoIP use cases at present is to identify the "ugliness", like limited-to-no transparency of SIP/VoIP Peering as it exists today. Also, with the advent of B2BUAs as the SBE/DBEs in the call flows, there would be numerous iterations of SIP Header manipulation/mangling that is done for various business, regulatory and other reasons. It could be a very slippery slope to start digging into the details, and would also balloon the draft greatly. To summarize, I am on the fence with this one. Others have thoughts? Will the details help clarify, or narrow the discussion too much? -Adam > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Monday, February 25, 2008 11:38 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: > [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt > > "VoIP consolidated use cases" author's, > > First, let me say, I think the draft is off to a good start. > I would like to suggest some things, I believe will allow the draft to > provide better clarity and more depth for a reader to understand the > reasons and situations relating to VoIP peering. > > Here are a few encompassing comments and general nits of the document: > > - I recommend looking through RFC 3285 before the next revision of the > draft. There are a number of Word template issues, which can be > resolved fairly easy. > > - The references need to be updated. > > - Finally, as I review the use cases, I am looking for the following > basic structure within each use case: Goal, Summary, Actors, > Preconditions, Triggers, Basic course of events, Alternative paths (if > applicable), and any Policy considerations. > > -------------------------------- > > More detailed comments: > > Section 4 - "Each grouping can further sub-divided to Direct Peering > and Indirect Peering [15]." Should it be, "Each grouping can be > further sub-divided to Direct and Indirect Peering [15]"? > > "Each use-case has to specify how a few core operations which are to > be performed by its members." I would like to suggest re-wording to, > "Each use case must specify a basic set of required operations to be > performed by each member when peering." > > Section 5.1 - I would expect this intro paragraph to describe the goal > of static peering. For example, "Static peering is used in cases, > when two peers want a consistent and "hardened" approach to peering. > In this scenario, all of the variables are very well defined and known > by each peer....." > > Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer > with Enterprise B, SSP A wants to peer with SSP B, SSP A is providing > static peering for Enterprise A, B, and C, etc.)? What are the > preconditions required for this use case to be successful (e.g. each > peer must exchange their allowable set of codecs, authentication > method, no > RFC1918 addresses, etc.)? What are the triggers (i.e. what causes > SSPA to think it can send it to a peer?) > > The sentence beginning, "Two SSP negotiate and agree..." > seems to begin the course of events, but you have other events > numbered below. This is confusing. I would suggest moving these into > the numbered events below. > > Each of the events listed, such provide an example of what is > occurring with each. The current ones are too high level of value in > deriving requirements. For example: > > 1. UAC initiates a call via SIP INVITE to O-Proxy > > (Snippets frm RFC 3665) > INVITE sip:+13031112222@denver.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 2. O-Proxy queries for SED information from a routing database (ENUM?? > - > LUF) > > (The result of the ENUM query is...) > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\1@sbe1-denver.sspa.example.com!". > > 3. Routing database entity replies with SED to called party (NAPTR - > LRF) > > sbe1-denver.sspa.example.com. > order pref flgs service regx replacement > IN NAPTR 100 50 "s" "SIP+D2U" "" > _sip._udp.sbe1-denver.sspa.example.com > > 4. O-Proxy sends a DNS SRV query for > _sip._udp.sbe1-denver.sspa.example.com which results in: > > $ORIGIN _sip._udp.sbe1-denver.sspa.example.com. > (Some content not included for clarity purposes.) > IN SRV 0 1 5060 sbe1-denver.sspa.example.com > > ;; ANSWER SECTION > sbe1-denver.sspa.example.com A 192.0.2.17 > sbe2-denver.sspa.example.com A 192.0.2.18 > > 5. Call sent to terminating domain proxy. > > INVITE sip:+13031112222@sbe1-denver.sspa.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 6. T-Proxy determines called party location by querying the ENUM > server > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\bob@proxy1-denver.sspa.example.com!". > > ....and so on. I think this detail will provide clarity for the > requirements and for readers to understand the necessary steps to > successfully peer. I think this should be done for each of the use > cases. > > Section 5.1.1 - These appear to be optional (or additional > potential) pre-conditions, which could occur relative to this use > case. If this is case, I would suggest calling them Optional > Pre-conditions and not Options and Nuances. > > --------------------------------- > > I think making similar, relative changes to each of the use case > sections will get the very close to a finished product. > > --Daryl > > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > Sent: Friday, February 22, 2008 12:37 PM > To: speermint@ietf.org > Subject: [Speermint] > draft-ietf-speermint-voip-consolidated-usecases-05.txt > > For general consumption in prep for Philly. See y'all in the city of > brotherly love! Feedback welcomed. > > Changes: > - resync with the latest term draft. > - clarifications based on feedback from the last meeting - like > collapse/removal of assisted peering use cases into direct/indirect > models. > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidat > ed-usecases-05.txt > > I am working on version 6, mostly weeding out nits, and will issue > after the WG session. Thanks in advance for your feedback!! > > Adam Uzelac > Director, Converged Network Arch and Planning Global Crossing > 585-563-4359 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 07:43:23 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE06628C1BA; Tue, 26 Feb 2008 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7tF4Jh-vCWT; Tue, 26 Feb 2008 07:43:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A52B3A6C46; Tue, 26 Feb 2008 07:43:22 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21F328C246 for ; Tue, 26 Feb 2008 07:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvbR92kd3ZvW for ; Tue, 26 Feb 2008 07:43:19 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 9BA6E3A6B8B for ; Tue, 26 Feb 2008 07:43:19 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m1QFh7eM018885; Tue, 26 Feb 2008 08:43:07 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 26 Feb 2008 08:43:07 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 08:43:07 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0D7D@srvxchg3.cablelabs.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0D7B@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTgCZfdLAACVykKAAAWYm0AAAhz/A References: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> <160DE07A1C4F8E4AA2715DEC577DA4917B0D7B@srvxchg3.cablelabs.com> From: "Daryl Malas" To: "Uzelac, Adam" , X-Approved: ondar Subject: Re: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org One more thing...the detailed view should only describe known processes. Other steps, should include what needs to happen regardless of an existing process. For example, SSPA must somehow get their subscriber information into the LUF (as we know...to be potentially handled by PEPPERMINT). This is work, which can be identified by the use cases and then a solution defined SPEERMINT or in other groups as necessary. --Daryl -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Tuesday, February 26, 2008 8:37 AM To: Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Adam, I am not suggesting a detailed signaling example of every possible scenario, but I am suggesting a relative example of the scenario described within the use case. For example, static peering can use ENUM or a redirect server. I am suggesting a detailed view of the ENUM process within the peering use case, to help the reader understand the complexities of manipulating the signaling from the UAC to the UAS. As you probably already know, this draft is not intended to define the solution, but rather describe the things that need to happen. How it should or must happen is up to later drafts. This is not as simple as it seems, and requires more than just a "oh by the way...". Then, after the use case, you suggest other possible conditions. You can say, "The described course of events is an example, and here are some other possibilities, and here are a few things, which must be considered with these other possibilities." Also, you describe the necessity to identify the "ugliness". This is my point, wrt providing detail. I see a fluffy high level overview in the draft, not much ugliness. By the way, I went through a similar situation recently...it's an easy problem to talk about, until you start diving down into a step-by-step analysis of what needs to happen and what needs to change for it to be successful. I think this is some of what Otmar has been trying to say for awhile. The final solution may require other protocol work, but I do not get a sense of this possibility yet based on the use cases. Thanks... --Daryl -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Tuesday, February 26, 2008 8:02 AM To: Daryl Malas; speermint@ietf.org Subject: RE: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Daryl, Excellent comments and thanks for the feedback. We have version 6 queued up and are in the process of updating. Regarding some of your comments, starting with the "(Snippets frm RFC 3665)" - you state: > ...I think this detail will provide clarity for the requirements and > for readers to understand the necessary steps to successfully peer. I > think this should be done for each of the use cases. I read that you are requesting more detail in the use cases, but I feel it isn't necessary to get the pertinent points across. Initially, and I believe to a certain extent still, one goal of capturing current use cases (what is "occurring in the wild today), is to capture requirements. At the same time, I think that a goal in capturing the VoIP use cases at present is to identify the "ugliness", like limited-to-no transparency of SIP/VoIP Peering as it exists today. Also, with the advent of B2BUAs as the SBE/DBEs in the call flows, there would be numerous iterations of SIP Header manipulation/mangling that is done for various business, regulatory and other reasons. It could be a very slippery slope to start digging into the details, and would also balloon the draft greatly. To summarize, I am on the fence with this one. Others have thoughts? Will the details help clarify, or narrow the discussion too much? -Adam > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Monday, February 25, 2008 11:38 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: > [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt > > "VoIP consolidated use cases" author's, > > First, let me say, I think the draft is off to a good start. > I would like to suggest some things, I believe will allow the draft to > provide better clarity and more depth for a reader to understand the > reasons and situations relating to VoIP peering. > > Here are a few encompassing comments and general nits of the document: > > - I recommend looking through RFC 3285 before the next revision of the > draft. There are a number of Word template issues, which can be > resolved fairly easy. > > - The references need to be updated. > > - Finally, as I review the use cases, I am looking for the following > basic structure within each use case: Goal, Summary, Actors, > Preconditions, Triggers, Basic course of events, Alternative paths (if > applicable), and any Policy considerations. > > -------------------------------- > > More detailed comments: > > Section 4 - "Each grouping can further sub-divided to Direct Peering > and Indirect Peering [15]." Should it be, "Each grouping can be > further sub-divided to Direct and Indirect Peering [15]"? > > "Each use-case has to specify how a few core operations which are to > be performed by its members." I would like to suggest re-wording to, > "Each use case must specify a basic set of required operations to be > performed by each member when peering." > > Section 5.1 - I would expect this intro paragraph to describe the goal > of static peering. For example, "Static peering is used in cases, > when two peers want a consistent and "hardened" approach to peering. > In this scenario, all of the variables are very well defined and known > by each peer....." > > Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer > with Enterprise B, SSP A wants to peer with SSP B, SSP A is providing > static peering for Enterprise A, B, and C, etc.)? What are the > preconditions required for this use case to be successful (e.g. each > peer must exchange their allowable set of codecs, authentication > method, no > RFC1918 addresses, etc.)? What are the triggers (i.e. what causes > SSPA to think it can send it to a peer?) > > The sentence beginning, "Two SSP negotiate and agree..." > seems to begin the course of events, but you have other events > numbered below. This is confusing. I would suggest moving these into > the numbered events below. > > Each of the events listed, such provide an example of what is > occurring with each. The current ones are too high level of value in > deriving requirements. For example: > > 1. UAC initiates a call via SIP INVITE to O-Proxy > > (Snippets frm RFC 3665) > INVITE sip:+13031112222@denver.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 2. O-Proxy queries for SED information from a routing database (ENUM?? > - > LUF) > > (The result of the ENUM query is...) > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\1@sbe1-denver.sspa.example.com!". > > 3. Routing database entity replies with SED to called party (NAPTR - > LRF) > > sbe1-denver.sspa.example.com. > order pref flgs service regx replacement > IN NAPTR 100 50 "s" "SIP+D2U" "" > _sip._udp.sbe1-denver.sspa.example.com > > 4. O-Proxy sends a DNS SRV query for > _sip._udp.sbe1-denver.sspa.example.com which results in: > > $ORIGIN _sip._udp.sbe1-denver.sspa.example.com. > (Some content not included for clarity purposes.) > IN SRV 0 1 5060 sbe1-denver.sspa.example.com > > ;; ANSWER SECTION > sbe1-denver.sspa.example.com A 192.0.2.17 > sbe2-denver.sspa.example.com A 192.0.2.18 > > 5. Call sent to terminating domain proxy. > > INVITE sip:+13031112222@sbe1-denver.sspa.example.com SIP/2.0 > Via: SIP/2.0/TCP > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=9fxced76sl > To: +13031112222 > Contact: > > 6. T-Proxy determines called party location by querying the ENUM > server > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > !sip:\\bob@proxy1-denver.sspa.example.com!". > > ....and so on. I think this detail will provide clarity for the > requirements and for readers to understand the necessary steps to > successfully peer. I think this should be done for each of the use > cases. > > Section 5.1.1 - These appear to be optional (or additional > potential) pre-conditions, which could occur relative to this use > case. If this is case, I would suggest calling them Optional > Pre-conditions and not Options and Nuances. > > --------------------------------- > > I think making similar, relative changes to each of the use case > sections will get the very close to a finished product. > > --Daryl > > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > Sent: Friday, February 22, 2008 12:37 PM > To: speermint@ietf.org > Subject: [Speermint] > draft-ietf-speermint-voip-consolidated-usecases-05.txt > > For general consumption in prep for Philly. See y'all in the city of > brotherly love! Feedback welcomed. > > Changes: > - resync with the latest term draft. > - clarifications based on feedback from the last meeting - like > collapse/removal of assisted peering use cases into direct/indirect > models. > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > consolidat > ed-usecases-05.txt > > I am working on version 6, mostly weeding out nits, and will issue > after the WG session. Thanks in advance for your feedback!! > > Adam Uzelac > Director, Converged Network Arch and Planning Global Crossing > 585-563-4359 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 09:59:46 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180B828C611; Tue, 26 Feb 2008 09:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb5g3JdGaZnQ; Tue, 26 Feb 2008 09:59:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671D028C783; Tue, 26 Feb 2008 09:59:25 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D78328C762 for ; Tue, 26 Feb 2008 09:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og6-QEEQK+Cl for ; Tue, 26 Feb 2008 09:59:22 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 25EAF28C7A4 for ; Tue, 26 Feb 2008 09:58:51 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m1QHwdEN029955; Tue, 26 Feb 2008 10:58:39 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 26 Feb 2008 10:58:39 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 10:58:38 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA4917B0D80@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Thread-Index: Ach3/lP1YlJ4BqNfR/iwl+z1P+KHZgAA7TEwACeqNCA= References: <20080225211502.9836C3A6D85@core3.amsl.com> From: "Daryl Malas" To: X-Approved: ondar Cc: speermint@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Otmar, I also enjoyed reading the draft. I think you bring up some very interesting and valid discussion points. I also think you re-enforce there is much to do within SPEERMINT. A comment to the use case authors...please read this draft, because I think it has some important topics to touch on in your draft. I encourage everyone to take the time to read this draft prior to Philadelphia. Thank you, Otmar, for taking the time to update this draft. --Daryl -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, February 25, 2008 4:24 PM To: otmar.lendl@enum.at Cc: speermint@ietf.org; PEPPERMINT@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Awesome draft. (I missed it the first time 'round) I agree with your statement of "The obvious solution is to add an on-demand mapping step ahead of the routing protocol." The trick will be how that works/scales, and how it interacts with a routing protocol. The easy case is the non-transit bilateral peering - the very hard case is transit. One very minor nit: I don't think TRIP failed due to being prefix-based and thus needing aggregation. I think it failed because the market wasn't ready for it (the problem didn't need to be fixed for most people yet), the idea of implementing/using BGP scared off voip vendors, and it didn't cover some of the routing selection models people need. -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, February 25, 2008 4:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-lendl-speermint-background-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : VoIP Peering: Background and Assumptions > Author(s) : O. Lendl > Filename : draft-lendl-speermint-background-01.txt > Pages : 15 > Date : 2008-02-25 > > This documents provides background for the work on VoIP peering and > tries to provide guidance on what kind of work is needed to facilitate > widespread SIP-based peering of telephony networks. It is intended to > spur discussion on the work about peering and should also serve as > input to the ongoing discussions on reducing Spam for Internet > Telephony (SPIT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-speermint-background- > 01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lendl-speermint-background-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lendl-speermint-background-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 10:09:47 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8DE28C351; Tue, 26 Feb 2008 10:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElRpW+iP6riS; Tue, 26 Feb 2008 10:09:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD853A6837; Tue, 26 Feb 2008 10:09:45 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421F63A6837 for ; Tue, 26 Feb 2008 10:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSVV54XTC0CX for ; Tue, 26 Feb 2008 10:09:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 513423A680E for ; Tue, 26 Feb 2008 10:09:38 -0800 (PST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Feb 2008 13:09:31 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1QI9W0p024704; Tue, 26 Feb 2008 13:09:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1QI9VUi013521; Tue, 26 Feb 2008 18:09:32 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 13:09:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 13:10:10 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3046E3BD0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt Thread-Index: Ach1ilZn+lTbGsPmT3+GRCQwunJbTgCZfdLAACVykKAAByNLwA== References: <160DE07A1C4F8E4AA2715DEC577DA4917B0D73@srvxchg3.cablelabs.com> From: "Michael Hammer (mhammer)" To: "Uzelac, Adam" , "Daryl Malas" , X-OriginalArrivalTime: 26 Feb 2008 18:09:29.0454 (UTC) FILETIME=[BAD3D8E0:01C878A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9727; t=1204049372; x=1204913372; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20(mhammer)=22=20 |Subject:=20RE=3A=20[Speermint]draft-ietf-speermint-voip-co nsolidated-usecases-05.txt |Sender:=20 |To:=20=22Uzelac,=20Adam=22=20,=0A=20=20=20=20=20=20=20=20=22Daryl=20Malas=22=20,=20; bh=BFBZNq47Qlxf9W0BzLH0vW3Id1va0BOOK3YbRrzHz3Q=; b=g2Z2559KrTkLvZ/ZuwkEe0fIztqbTj+6bXibUwlNv01R+pQk1iuI3UseAb EBIV/0SDsSBHBOPmDbmMcUvNF+NLnArxQn+4O6Of0cUCPxD9a2FnYR08mmoa gERXuBwiay; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Speermint] draft-ietf-speermint-voip-consolidated-usecases-05.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Adam, Only the idea I expressed before that since the main gist of this is call routing, the main SIP header that should be mangled is the Route header. Mike > -----Original Message----- > From: speermint-bounces@ietf.org > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > Sent: Tuesday, February 26, 2008 10:02 AM > To: Daryl Malas; speermint@ietf.org > Subject: Re: > [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt > > Daryl, > > Excellent comments and thanks for the feedback. We have > version 6 queued up and are in the process of updating. > Regarding some of your comments, starting with the "(Snippets > frm RFC 3665)" - you state: > > > ...I think this detail will provide clarity for the > requirements and > > for readers to understand the necessary steps to > successfully peer. I > > think this should be done for each of the use cases. > > I read that you are requesting more detail in the use cases, > but I feel it isn't necessary to get the pertinent points > across. Initially, and I believe to a certain extent still, > one goal of capturing current use cases (what is "occurring > in the wild today), is to capture requirements. At the same > time, I think that a goal in capturing the VoIP use cases at > present is to identify the "ugliness", like limited-to-no > transparency of SIP/VoIP Peering as it exists today. > Also, with the advent of B2BUAs as the SBE/DBEs in the call > flows, there would be numerous iterations of SIP Header > manipulation/mangling that is done for various business, > regulatory and other reasons. It could be a very slippery > slope to start digging into the details, and would also > balloon the draft greatly. > > To summarize, I am on the fence with this one. Others have thoughts? > Will the details help clarify, or narrow the discussion too much? > > -Adam > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas > > Sent: Monday, February 25, 2008 11:38 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: > > [Speermint]draft-ietf-speermint-voip-consolidated-usecases-05.txt > > > > "VoIP consolidated use cases" author's, > > > > First, let me say, I think the draft is off to a good start. > > I would like to suggest some things, I believe will allow > the draft to > > provide better clarity and more depth for a reader to > understand the > > reasons and situations relating to VoIP peering. > > > > Here are a few encompassing comments and general nits of > the document: > > > > - I recommend looking through RFC 3285 before the next > revision of the > > draft. There are a number of Word template issues, which can be > > resolved fairly easy. > > > > - The references need to be updated. > > > > - Finally, as I review the use cases, I am looking for the > following > > basic structure within each use case: Goal, Summary, Actors, > > Preconditions, Triggers, Basic course of events, > Alternative paths (if > > applicable), and any Policy considerations. > > > > -------------------------------- > > > > More detailed comments: > > > > Section 4 - "Each grouping can further sub-divided to > Direct Peering > > and Indirect Peering [15]." Should it be, "Each grouping can be > > further sub-divided to Direct and Indirect Peering [15]"? > > > > "Each use-case has to specify how a few core operations > which are to > > be performed by its members." I would like to suggest > re-wording to, > > "Each use case must specify a basic set of required > operations to be > > performed by each member when peering." > > > > Section 5.1 - I would expect this intro paragraph to > describe the goal > > of static peering. For example, "Static peering is used in cases, > > when two peers want a consistent and "hardened" approach to > peering. > > In this scenario, all of the variables are very well > defined and known > > by each peer....." > > > > Section 5.1.1 - Who are the actors (e.g. Enterprise A wants to peer > > with Enterprise B, SSP A wants to peer with SSP B, SSP A is > providing > > static peering for Enterprise A, B, and C, etc.)? What are the > > preconditions required for this use case to be successful > (e.g. each > > peer must exchange their allowable set of codecs, authentication > > method, no > > RFC1918 addresses, etc.)? What are the triggers (i.e. what causes > > SSPA to think it can send it to a peer?) > > > > The sentence beginning, "Two SSP negotiate and agree..." > > seems to begin the course of events, but you have other events > > numbered below. This is confusing. I would suggest moving > these into > > the numbered events below. > > > > Each of the events listed, such provide an example of what is > > occurring with each. The current ones are too high level > of value in > > deriving requirements. For example: > > > > 1. UAC initiates a call via SIP INVITE to O-Proxy > > > > (Snippets frm RFC 3665) > > INVITE sip:+13031112222@denver.example.com SIP/2.0 > > Via: SIP/2.0/TCP > > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > > Max-Forwards: 70 > > From: Alice ;tag=9fxced76sl > > To: +13031112222 > > Contact: > > > > 2. O-Proxy queries for SED information from a routing > database (ENUM?? > > - > > LUF) > > > > (The result of the ENUM query is...) > > > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > > !sip:\\1@sbe1-denver.sspa.example.com!". > > > > 3. Routing database entity replies with SED to called party (NAPTR - > > LRF) > > > > sbe1-denver.sspa.example.com. > > order pref flgs service regx replacement > > IN NAPTR 100 50 "s" "SIP+D2U" "" > > _sip._udp.sbe1-denver.sspa.example.com > > > > 4. O-Proxy sends a DNS SRV query for > > _sip._udp.sbe1-denver.sspa.example.com which results in: > > > > $ORIGIN _sip._udp.sbe1-denver.sspa.example.com. > > (Some content not included for clarity purposes.) > > IN SRV 0 1 5060 sbe1-denver.sspa.example.com > > > > ;; ANSWER SECTION > > sbe1-denver.sspa.example.com A 192.0.2.17 > > sbe2-denver.sspa.example.com A 192.0.2.18 > > > > 5. Call sent to terminating domain proxy. > > > > INVITE sip:+13031112222@sbe1-denver.sspa.example.com SIP/2.0 > > Via: SIP/2.0/TCP > > client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > > Max-Forwards: 70 > > From: Alice ;tag=9fxced76sl > > To: +13031112222 > > Contact: > > > > 6. T-Proxy determines called party location by querying the ENUM > > server > > > > $ORIGIN 2.2.2.2.1.1.1.3.0.3.1.denver.example.com > > NAPTR 10 100 "u" "E2U+SIP" "!^.*$ > > !sip:\\bob@proxy1-denver.sspa.example.com!". > > > > ....and so on. I think this detail will provide clarity for the > > requirements and for readers to understand the necessary steps to > > successfully peer. I think this should be done for each of the use > > cases. > > > > Section 5.1.1 - These appear to be optional (or additional > > potential) pre-conditions, which could occur relative to this use > > case. If this is case, I would suggest calling them Optional > > Pre-conditions and not Options and Nuances. > > > > --------------------------------- > > > > I think making similar, relative changes to each of the use case > > sections will get the very close to a finished product. > > > > --Daryl > > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Uzelac, Adam > > Sent: Friday, February 22, 2008 12:37 PM > > To: speermint@ietf.org > > Subject: [Speermint] > > draft-ietf-speermint-voip-consolidated-usecases-05.txt > > > > For general consumption in prep for Philly. See y'all in > the city of > > brotherly love! Feedback welcomed. > > > > Changes: > > - resync with the latest term draft. > > - clarifications based on feedback from the last meeting - like > > collapse/removal of assisted peering use cases into direct/indirect > > models. > > > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip- > > consolidat > > ed-usecases-05.txt > > > > I am working on version 6, mostly weeding out nits, and will issue > > after the WG session. Thanks in advance for your feedback!! > > > > Adam Uzelac > > Director, Converged Network Arch and Planning Global Crossing > > 585-563-4359 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > http://www.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > http://www.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > http://www.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 10:21:16 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944AB3A6D9A; Tue, 26 Feb 2008 10:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55pUF-It0QIq; Tue, 26 Feb 2008 10:21:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9C03A6D8C; Tue, 26 Feb 2008 10:21:15 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9333B3A6D8C for ; Tue, 26 Feb 2008 10:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAq2+IQ9+F8Z for ; Tue, 26 Feb 2008 10:21:13 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 42ADE3A6D4F for ; Tue, 26 Feb 2008 10:21:13 -0800 (PST) Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.52373314; Tue, 26 Feb 2008 13:20:51 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 13:20:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Feb 2008 13:20:09 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203E9C9FC@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA4917B0D80@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Thread-Index: Ach3/lP1YlJ4BqNfR/iwl+z1P+KHZgAA7TEwACeqNCAAAM2mkA== From: "Lee, Yiu" To: "Daryl Malas" , X-OriginalArrivalTime: 26 Feb 2008 18:20:51.0210 (UTC) FILETIME=[512F8EA0:01C878A4] Cc: speermint@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I read the first 00 draft and enjoyed it. I will definitely read this one. Thanks Otmar for taking the time to write it. -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Tuesday, February 26, 2008 12:59 PM To: otmar.lendl@enum.at Cc: speermint@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Otmar, I also enjoyed reading the draft. I think you bring up some very interesting and valid discussion points. I also think you re-enforce there is much to do within SPEERMINT. A comment to the use case authors...please read this draft, because I think it has some important topics to touch on in your draft. I encourage everyone to take the time to read this draft prior to Philadelphia. Thank you, Otmar, for taking the time to update this draft. --Daryl -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, February 25, 2008 4:24 PM To: otmar.lendl@enum.at Cc: speermint@ietf.org; PEPPERMINT@ietf.org Subject: Re: [Speermint] I-D Action:draft-lendl-speermint-background-01.txt Awesome draft. (I missed it the first time 'round) I agree with your statement of "The obvious solution is to add an on-demand mapping step ahead of the routing protocol." The trick will be how that works/scales, and how it interacts with a routing protocol. The easy case is the non-transit bilateral peering - the very hard case is transit. One very minor nit: I don't think TRIP failed due to being prefix-based and thus needing aggregation. I think it failed because the market wasn't ready for it (the problem didn't need to be fixed for most people yet), the idea of implementing/using BGP scared off voip vendors, and it didn't cover some of the routing selection models people need. -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, February 25, 2008 4:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-lendl-speermint-background-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : VoIP Peering: Background and Assumptions > Author(s) : O. Lendl > Filename : draft-lendl-speermint-background-01.txt > Pages : 15 > Date : 2008-02-25 > > This documents provides background for the work on VoIP peering and > tries to provide guidance on what kind of work is needed to facilitate > widespread SIP-based peering of telephony networks. It is intended to > spur discussion on the work about peering and should also serve as > input to the ongoing discussions on reducing Spam for Internet > Telephony (SPIT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-speermint-background- > 01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lendl-speermint-background-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lendl-speermint-background-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 26 14:50:14 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A303A6CC4; Tue, 26 Feb 2008 14:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVLDZ2U9seg2; Tue, 26 Feb 2008 14:50:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02093A6B68; Tue, 26 Feb 2008 14:50:13 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889893A6B68 for ; Tue, 26 Feb 2008 14:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWos9ac3IQPs for ; Tue, 26 Feb 2008 14:50:12 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 507FE3A67D9 for ; Tue, 26 Feb 2008 14:50:12 -0800 (PST) Received: from [172.16.99.62] (account dyork [172.16.99.62] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 28230272; Tue, 26 Feb 2008 22:50:05 +0000 In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF53DE12@mx1.office> References: <5F6519BF2DE0404D99B7C75607FF76FF53DBF5@mx1.office> <384253AE-20F6-41A2-B540-0CA3CA2AE2BB@voxeo.com> <5F6519BF2DE0404D99B7C75607FF76FF53DE12@mx1.office> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <9E4E9614-BE8F-4E3B-B537-587FE7E5AD6E@voxeo.com> From: Dan York Date: Tue, 26 Feb 2008 17:49:52 -0500 To: Saverio Niccolini X-Mailer: Apple Mail (2.753) Cc: speermint@ietf.org Subject: Re: [Speermint] FW: I-D Action:draft-niccolini-speermint-voipthreats-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280948964==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============1280948964== Content-Type: multipart/alternative; boundary=Apple-Mail-314-273209828 --Apple-Mail-314-273209828 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Saverio, On Feb 26, 2008, at 9:13 AM, Saverio Niccolini wrote: > Right, we explicitly did not look at these and if the group > has consensus on this we can add them in the next version of the > draft. Anyway we need to be sure that the threats we are addressing > are specific to SPEERMINT, we excluded domain-internal threats > from the classification (not interesting to SPEERMINT the REGISTER > after loss of power example you cited). DY> Yes, I realized that my loss-of-power example was NOT applicable to SPEERMINT. > Can you suggest (maybe offline) more specifically which kind of > threats that are SPEERMINT specific did you have in mind? DY> Unfortunately I haven't spent enough time yet analyzing the SPEERMINT architecture to be able to provide solid feedback on this point. In my initial thinking, there aren't many cases that leap out at me. Perhaps the misconfiguration of a SIP proxy at a provider's network that starts spewing a flood of packets out into the peering fabric? I'm not honestly sure... but I will give it some thought. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-314-273209828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Saverio,

On Feb 26, 2008, at 9:13 AM, Saverio = Niccolini wrote:

Right, we explicitly did not = look at these and if the group
has = consensus on this we can add them in the next version of the
draft. Anyway we need to be sure that the threats we = are addressing
are specific to SPEERMINT, we = excluded domain-internal threats
from the = classification (not interesting to SPEERMINT the REGISTER
after loss of power example you = cited).

DY> Yes, I realized that my = loss-of-power example was NOT applicable to = SPEERMINT.

Can you suggest (maybe offline) more specifically = which kind of
threats that are SPEERMINT = specific did you have in mind?

DY> Unfortunately I haven't = spent enough time yet analyzing the SPEERMINT architecture to be able to = provide solid feedback on this point. =A0In my initial thinking, there = aren't many cases that leap out at me. =A0Perhaps the misconfiguration = of a SIP proxy at a provider's network that starts spewing a flood of = packets out into the peering fabric? =A0I'm not honestly sure... but I = will give it some thought.

Regards,
Dan
=

--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=

= --Apple-Mail-314-273209828-- --===============1280948964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint --===============1280948964==-- From speermint-bounces@ietf.org Tue Feb 26 14:54:47 2008 Return-Path: X-Original-To: ietfarch-speermint-archive@core3.amsl.com Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E7728C484; Tue, 26 Feb 2008 14:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiRJChu6wP1P; Tue, 26 Feb 2008 14:54:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D4428C205; Tue, 26 Feb 2008 14:54:46 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA3528C444 for ; Tue, 26 Feb 2008 14:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUgF4All7n25 for ; Tue, 26 Feb 2008 14:54:43 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 3254228C2FB for ; Tue, 26 Feb 2008 14:54:43 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.52393203; Tue, 26 Feb 2008 17:54:15 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 17:54:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C878CA.82DAB116" Date: Tue, 26 Feb 2008 17:54:15 -0500 Message-ID: <45AEC6EF95942140888406588E1A660203A5AE2A@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 71 Agenda Thread-Index: Ach4yoK9Rz0DxSLrS8iFVQzNA8Xf7g== From: "Livingood, Jason" To: X-OriginalArrivalTime: 26 Feb 2008 22:54:16.0020 (UTC) FILETIME=[8336E940:01C878CA] Subject: [Speermint] Draft IETF 71 Agenda X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C878CA.82DAB116 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please comment if you would like any changes or additions. Regards Jason ------_=_NextPart_001_01C878CA.82DAB116 Content-Type: text/plain; name="speermint_agenda_ietf71.txt" Content-Transfer-Encoding: base64 Content-Description: speermint_agenda_ietf71.txt Content-Disposition: attachment; filename="speermint_agenda_ietf71.txt" U2Vzc2lvbiBQRUVSaW5nIGZvciBNdWx0aW1lZGlhIElOVGVyY29ubmVjdCAoc3BlZXJtaW50KQ0K DQpXZWRuZXNkYXksIE1hcmNoIDEyLCAyMDA4LCAxMzAwIC0gMTUwMCAoQWZ0ZXJub29uIFNlc3Np b24gSSkgDQpSb29tIE5hbWU6IEJyZWFrb3V0IFJvb20NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KQ0hBSVJTOgkgICAgICAgCQlKYXNvbiBMaXZpbmdvb2QgIAk8amFz b25fbGl2aW5nb29kQGNhYmxlLmNvbWNhc3QuY29tPg0KCQkJRGFyeWwgTWFsYXMJCTxkLm1hbGFz QGNhYmxlbGFicy5jb20+IA0KDQpTRUNSRVRBUlk6ICAJCUFsZXhhbmRlciBNYXlyaG9mZXIgCTxh bGV4YW5kZXIubWF5cmhvZmVyQG5pYy5hdD4NCg0KUkFJIEFSRUEgRElSRUNUT1JTOglDdWxsZW4g SmVubmluZ3MgCTxmbHVmZnlAY2lzY28uY29tPg0KCQkJSm9uIFBldGVyc29uIAkJPGpvbi5wZXRl cnNvbkBuZXVzdGFyLmJpej4NCg0KUkFJIEFSRUEgQURWSVNPUjoJSm9uIFBldGVyc29uIAkJPGpv bi5wZXRlcnNvbkBuZXVzdGFyLmJpej4NCg0KDQpHRU5FUkFMICgxNSBtaW51dGVzKQ0KDQoxIC0g V2VsY29tZSAmIEludHJvZHVjdGlvbiB0byBzcGVlcm1pbnQgLyBBZG1pbmlzdHJpdmlhCSAgCQk1 IG1pbnV0ZXMNCiAgICAgCUphc29uIExpdmluZ29vZA0KDQogICAtIE1haWxpbmcgbGlzdDogc3Bl ZXJtaW50LXJlcXVlc3RAaWV0Zi5vcmcNCg0KICAgLSBTY3JpYmUgKGphYmJlcikNCiAgIA0KICAg LSBCbHVlIFNoZWV0cw0KDQoyIC0gUHJvZ3Jlc3MgUmVwb3J0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAJCTUgbWludXRlcw0KCS0gUmV2aWV3IG9mIENvbXBsZXRlZCBE b2N1bWVudHMNCgktIFJldmlldyBvZiBEb2N1bWVudCBGbG93IC8gUHJpb3JpdHkgb2YgVXBjb21p bmcgU3VibWlzc2lvbnMNCglKYXNvbiBMaXZpbmdvb2QNCg0KMyAtIEFnZW5kYSBCYXNoaW5nICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAJCTUgbWludXRlcw0KICAgICAJ RGFyeWwgTWFsYXMNCg0KDQpSRVZJRVcgUFJJTUFSWSBXRyBEUkFGVFMgKDcwIG1pbnV0ZXMpDQoN Cg0KNCAtIERFVEFJTEVEIFJFVklFVyBBTkQgRklOQUwgRkVFREJBSyAtLT4gVm9JUCBDb25zb2xp ZGF0ZWQgVXNlIENhc2VzCTIwIG1pbnV0ZXMNCglodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXNwZWVybWludC12b2lwLWNvbnNvbGlkYXRlZC11c2VjYXNlcy0w NS50eHQNCglBZGFtIFV6ZWxhYw0KDQo1IC0gREVUQUlMRUQgUkVWSUVXIC0tPiBTUEVFUk1JTlQg UmVxdWlyZW1lbnRzIGZvciBTSVAtYmFzZWQgCQkyMCBtaW51dGVzIA0KCVZvSVAgSW50ZXJjb25u ZWN0aW9uDQoJaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1z cGVlcm1pbnQtcmVxdWlyZW1lbnRzLTA0LnR4dA0KCUplYW4tRnJhbmNvaXMgTXVsZQ0KDQo2IC0g REVUQUlMRUQgUkVWSUVXIC0tPiBTUEVFUk1JTlQgUGVlcmluZyBBcmNoaXRlY3R1cmUJIAkJMzAg bWludXRlcw0KCWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt c3BlZXJtaW50LWFyY2hpdGVjdHVyZS0wNS50eHQNCglSZWluYWxkbyBQZW5ubw0KDQpSRVZJRVcg TkVXIElORElWSURVQUwgRFJBRlRTDQoNCjcgLSBTcGVlcm1pbnQgU2VjdXJpdHkgQkNQcwkJCQkJ CTE1IG1pbnV0ZXMNCglodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1u aWNjb2xpbmktc3BlZXJtaW50LXZvaXB0aHJlYXRzLTAzLnR4dA0KCVNhdmVyaW8gTmljY29saW5p DQoNCk9QRU4gRElTQ1VTU0lPTiAJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAJCTIwIG1pbnV0ZXMNCgkqIE5leHQgV0dMQyBkcmFmdHMNCgkqIE5ldyBpbmRpdmR1YWwgZHJh ZnRzIGNvbWluZz8NCgkqIE5lZWQgZm9yIGFuIGludGVyaW0gbWVldGluZz8NCgkqIE5lZWQgZm9y IG1vcmUgZnJlcXVlbnQgY29uZmVyZW5jZSBjYWxscz8NCg0KT1RIRVIgUkVDT01NRU5ERUQgUkVB RElORzoNCg0KMSAtIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxl bmRsLXNwZWVybWludC1iYWNrZ3JvdW5kLTAxLnR4dA0KDQoyIC0gaHR0cDovL2VjLmV1cm9wYS5l dS9pbmZvcm1hdGlvbl9zb2NpZXR5L3BvbGljeS9lY29tbS9kb2MvbGlicmFyeS9leHRfc3R1ZGll cy9mdXR1cmVfaXBfaW50ZXJjb24vaXBfaW50ZXJjb25fc3R1ZHlfZmluYWwucGRmDQoNCg0KRU5E DQogICANCg0K ------_=_NextPart_001_01C878CA.82DAB116 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org http://www.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C878CA.82DAB116--