From pkyzivat@cisco.com Mon Mar 1 12:45:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1C628C19F for ; Mon, 1 Mar 2010 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhzQMe+SpP54 for ; Mon, 1 Mar 2010 12:45:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B0AD328C17D for ; Mon, 1 Mar 2010 12:45:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,562,1262563200"; d="scan'208";a="94129737" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2010 20:45:52 +0000 Received: from [10.86.253.204] ([10.86.253.204]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o21KjpRr015698; Mon, 1 Mar 2010 20:45:51 GMT Message-ID: <4B8C277E.4000701@cisco.com> Date: Mon, 01 Mar 2010 15:45:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 20:45:52 -0000 inline... Avasarala Ranjit-A20990 wrote: > I'm still a little confused here. > If phone is on and subscription is active, then in general notification > should be possible, regardless of registration. I realize IMS doesn't > permit that, but from a general standard perspective we shouldn't assume > it. The manifestation in this case is that the NOTIFY would fail and the > subscription would eventually be torn down. > > So I think the cases are: > - there is a subscription and notification works > - there is a subscription but notification fails > - there is no subscription. > > Agreed. Actually instead of calling it as Notification > fails, we can say - not sending notification due to (1) no match of > filter criteria (2) phone not registered or outside coverage area due to > which there is no connectivity and hence notification cannot be sent > Anyway if no subscription, no notification. Are you suggesting that you might have a subscription, and have the filter criteria met, and yet not attempt to send a NOTIFY because the phone is not registered or has no network connectivity??? That seems wrong. ISTM that either you would remove the subscription, or else you would try to send the NOTIFY and then discover that it fails. OTOH, this probably ought not to be within scope of what is discussed in this draft. >> [3] in the example u suggested where sip:alice@atlanta.org with two >> contacts: sip:line1@alice.office.atlanta.com and >> sip:line2@alice.home.atlanta.com and >> both the phones ring, then it would be a case of parallel forking. >> Now say one or both the phones have set diversion rules, to divert the > > In this case, what does it mean for "one or both phones have set > diversion rules"? Does that somehow imply distinct rules for each phone? > > I don't see how that could work. Aren't the diversion rules for the > *AOR*? > > Yes the diversion rules are for AoR. So when there is a > diversion rule set for the AoR and when diversions occur, the > notifications are > Sent to the AoR. Not sent to the AoR - sent to the remote contact of the dialog for each subscription to the AoR. Same point as below that you agreed with. > I see they could be set/changed from either phone. But its a single set > of rules isn't it? So I might set the rules from the office, and then > cancel them from home. > > yes single set and could be set from either of the > phones. True. > >> call to say >> sip:voicemail@alice.atlanta.com, then the notifications would get >> generated with respect to both the contacts. > > Again I'm confused by the terminology you use, and how it relates > operationally. The diversion happens on the AOR, and the subscriptions > are on the AOR, and the notifications are sent to the subscribers. I > don't see where the registered contacts enter into the picture at all. > > Ya agree with you on this. Sorry for the confusion. > > If you have something else in mind, I hope you can explain it better in > the draft. > >> [4] Yes the value of N is configurable and depends on how many >> diversions the subscribe wants to keep or could be dependent on server > >> policy (some maximum >> number). If the server policy is to send notifications as and when > >> they occur and not keep any divsersions information, then the value of > >> last N >> diversions will be zero. But if the server chooses to retain the >> last diversion always, then the value of N will be 1 and so on. > > All is straightforward for N>=1. > > For N=0 things are messy. If we are modeling this as state, and > notifications are about state changes, then the new diversion is added > to the (previously empty) state and that triggers notifications to all > current subscriptions. Then if you don't want to retain even this much > state (because N=0) you immediately remove that version from the state. > But that is again a state change, so you end up with another > notification of that state change. > > True. Actually the notifications are for informing the > subscriber of the call diversions that happen. The notifications are not > for informing the subscriber of state changes in the notifier or the > number of diversions that occurred. As I mentioned in the abstract as > well as 24.604, the main intent of CDIVN service is to inform the > subscribers of communication diversions that occur on their behalf in > the network and this information will help them manage their rules > better. I am not certain, but think we may still be talking past one another to some extent. The state can be considered just a formalism for defining the service clearly, regardless of whether it has intrinsic value to the CDIV service. But it *is* a formalism. So if it is introduced, then its behavior can't be ignored when inconvenient. Defining the state with N=0 leads to some undesired behavior. The simplest way around that is to insist that N be >=1. If its important to you that no state be retained once a notification has been sent about the most recent diversion, then you will have to find some other way to specify the service, that still meets the expectations of 3265. I don't know if there is anything there that Adam would consider valid. We will have to get his opinion on that. Thanks, Paul > But if we want to include the information related to > how many diversions have happened till time (say from 12 AM ) till the > time the notification is being sent, then as you say we can store the > diversions. This would be useful when the subscriber specifies in the > filter criteria to send notifications only during certain time like > between 5 and 6 PM and not whenever a diversion occurs. Then N is grater > than 1. > I presume you don't want that behavior. If you can live with N>=1 then > we don't have the problem at all. If you need to support N=0 and don't > want the extra notify, then we have to figure out if there is some trick > to how things are modeled to get the desired effect. I've suggested > something previously, but Adam didn't like it. > > This needs sorting out. > > Thanks, > Paul From adam@nostrum.com Mon Mar 1 14:53:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234F328C1E5 for ; Mon, 1 Mar 2010 14:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56dU8ZAyhyZ6 for ; Mon, 1 Mar 2010 14:53:16 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0FAF928C1DD for ; Mon, 1 Mar 2010 14:53:15 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o21MrDJ8033408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 16:53:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8C4559.3070605@nostrum.com> Date: Mon, 01 Mar 2010 16:53:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> In-Reply-To: <4B8C277E.4000701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:53:17 -0000 On 3/1/10 14:45, Mar 1, Paul Kyzivat wrote: > Are you suggesting that you might have a subscription, and have the > filter criteria met, and yet not attempt to send a NOTIFY because the > phone is not registered or has no network connectivity??? > > That seems wrong. It seems wrong because it is wrong. If the terminal cannot be reached, the subscription goes away. /a From D.Malas@cablelabs.com Mon Mar 1 15:50:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CFB3A8880 for ; Mon, 1 Mar 2010 15:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu0RAl+VoPBg for ; Mon, 1 Mar 2010 15:50:52 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 36FDB3A80F5 for ; Mon, 1 Mar 2010 15:50:52 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o21Nop3x024329 for ; Mon, 1 Mar 2010 16:50:52 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 1 Mar 2010 16:50:52 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 1 Mar 2010 16:50:52 -0700 From: Daryl Malas To: "'dispatch@ietf.org'" Date: Mon, 1 Mar 2010 16:50:51 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4A== Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66AAsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 23:50:53 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66AAsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66AAsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
A New Internet-Draft is available from the= on-line=20 Internet-Drafts directories.
 
Title : SIP Egress Route Use in = ENUM=20
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20
 
Regards,
 
Daryl
 
---------------------------
Daryl=20 Malas
Project D= irector, IP=20 Interconnects
w - +1 30= 3 661=20 3302
mailto:d.malas@cablelabs.com=
 
--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66AAsrvxchg_-- From ranjit@motorola.com Mon Mar 1 20:39:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601883A8C1F for ; Mon, 1 Mar 2010 20:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiuRzeWXBVuJ for ; Mon, 1 Mar 2010 20:39:57 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id BC34A3A8C1E for ; Mon, 1 Mar 2010 20:39:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-14.tower-55.messagelabs.com!1267504791!88467847!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3387 invoked from network); 2 Mar 2010 04:39:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2010 04:39:52 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o224dkl1023951 for ; Mon, 1 Mar 2010 21:39:51 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o224dj1q004799 for ; Mon, 1 Mar 2010 22:39:45 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o224difW004786 for ; Mon, 1 Mar 2010 22:39:44 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 12:39:21 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B8C277E.4000701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq5gDRj/qE+XzN/QFGiXOER1Dap9QAQIsTg References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 04:39:58 -0000 Inline =20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, March 02, 2010 2:16 AM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] inline... Avasarala Ranjit-A20990 wrote: > I'm still a little confused here. > If phone is on and subscription is active, then in general=20 > notification should be possible, regardless of registration. I realize > IMS doesn't permit that, but from a general standard perspective we=20 > shouldn't assume it. The manifestation in this case is that the NOTIFY > would fail and the subscription would eventually be torn down. >=20 > So I think the cases are: > - there is a subscription and notification works > - there is a subscription but notification fails > - there is no subscription. >=20 > Agreed. Actually instead of calling it as=20 > Notification fails, we can say - not sending notification due to (1)=20 > no match of filter criteria (2) phone not registered or outside=20 > coverage area due to which there is no connectivity and hence=20 > notification cannot be sent Anyway if no subscription, no notification. Are you suggesting that you might have a subscription, and have the filter criteria met, and yet not attempt to send a NOTIFY because the phone is not registered or has no network connectivity??? That seems wrong. ISTM that either you would remove the subscription, or else you would try to send the NOTIFY and then discover that it fails. yes the subscription could be removed when the device is not reachable.=20 OTOH, this probably ought not to be within scope of what is discussed in this draft. yes true not within the scope of this draft. >> [3] in the example u suggested where sip:alice@atlanta.org with two >> contacts: sip:line1@alice.office.atlanta.com and=20 >> sip:line2@alice.home.atlanta.com and >> both the phones ring, then it would be a case of parallel forking. >> Now say one or both the phones have set diversion rules, to divert=20 >> the >=20 > In this case, what does it mean for "one or both phones have set=20 > diversion rules"? Does that somehow imply distinct rules for each phone? >=20 > I don't see how that could work. Aren't the diversion rules for the=20 > *AOR*? >=20 > Yes the diversion rules are for AoR. So when there is > a diversion rule set for the AoR and when diversions occur, the=20 > notifications are Sent to the AoR. Not sent to the AoR - sent to the remote contact of the dialog for each subscription to the AoR. Same point as below that you agreed with. Yes agree with u.=20 > I see they could be set/changed from either phone. But its a single=20 > set of rules isn't it? So I might set the rules from the office, and=20 > then cancel them from home. >=20 > yes single set and could be set from either of the=20 > phones. True. >=20 >> call to say=20 >> sip:voicemail@alice.atlanta.com, then the notifications would get >> generated with respect to both the contacts. >=20 > Again I'm confused by the terminology you use, and how it relates=20 > operationally. The diversion happens on the AOR, and the subscriptions > are on the AOR, and the notifications are sent to the subscribers. I=20 > don't see where the registered contacts enter into the picture at all. >=20 > Ya agree with you on this. Sorry for the confusion. >=20 > If you have something else in mind, I hope you can explain it better=20 > in the draft. >=20 >> [4] Yes the value of N is configurable and depends on how many=20 >> diversions the subscribe wants to keep or could be dependent on=20 >> server >=20 >> policy (some maximum >> number). If the server policy is to send notifications as and=20 >> when >=20 >> they occur and not keep any divsersions information, then the value=20 >> of >=20 >> last N >> diversions will be zero. But if the server chooses to retain the=20 >> last diversion always, then the value of N will be 1 and so on. >=20 > All is straightforward for N>=3D1. >=20 > For N=3D0 things are messy. If we are modeling this as state, and=20 > notifications are about state changes, then the new diversion is added > to the (previously empty) state and that triggers notifications to all > current subscriptions. Then if you don't want to retain even this much > state (because N=3D0) you immediately remove that version from the state. > But that is again a state change, so you end up with another=20 > notification of that state change. >=20 > True. Actually the notifications are for informing=20 > the subscriber of the call diversions that happen. The notifications=20 > are not for informing the subscriber of state changes in the notifier=20 > or the number of diversions that occurred. As I mentioned in the=20 > abstract as well as 24.604, the main intent of CDIVN service is to=20 > inform the subscribers of communication diversions that occur on their > behalf in the network and this information will help them manage their > rules better. I am not certain, but think we may still be talking past one another to some extent. The state can be considered just a formalism for defining the service clearly, regardless of whether it has intrinsic value to the CDIV service. But it *is* a formalism. So if it is introduced, then its behavior can't be ignored when inconvenient. Defining the state with = N=3D0 leads to some undesired behavior. The simplest way around that is to insist that N be >=3D1. Ok in that case we can say that value of N >=3D1 and the notifier has always maintains history of last diversion at a minimu. It can maintain more than 1 too depending on the policy.=20 If its important to you that no state be retained once a notification has been sent about the most recent diversion, then you will have to find some other way to specify the service, that still meets the expectations of 3265. I don't know if there is anything there that Adam would consider valid. We will have to get his opinion on that. In that case I am OK maintaining the hostory of diversions that occurred as part of state information and retaining that state even after the notification for that diversion is sent - so that in case I do not get a confirmation, I would be able to re-send the notification. Also maintaining state of diversions would help when the notifications need to sent only at a particular time (if fikter criteria mentions it). Thanks, Paul > But if we want to include the information related to=20 > how many diversions have happened till time (say from 12 AM ) till the > time the notification is being sent, then as you say we can store the=20 > diversions. This would be useful when the subscriber specifies in the=20 > filter criteria to send notifications only during certain time like=20 > between 5 and 6 PM and not whenever a diversion occurs. Then N is=20 > grater than 1. > I presume you don't want that behavior. If you can live with N>=3D1 = then > we don't have the problem at all. If you need to support N=3D0 and = don't > want the extra notify, then we have to figure out if there is some=20 > trick to how things are modeled to get the desired effect. I've=20 > suggested something previously, but Adam didn't like it. >=20 > This needs sorting out. >=20 > Thanks, > Paul From pkyzivat@cisco.com Tue Mar 2 05:48:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D333A89BC for ; Tue, 2 Mar 2010 05:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDCfazIqDttU for ; Tue, 2 Mar 2010 05:48:44 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 747B53A8692 for ; Tue, 2 Mar 2010 05:48:44 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,567,1262563200"; d="scan'208";a="89998253" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2010 13:48:45 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o22Dmi7M008397; Tue, 2 Mar 2010 13:48:44 GMT Message-ID: <4B8D173C.9070102@cisco.com> Date: Tue, 02 Mar 2010 08:48:44 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 13:48:46 -0000 I think this all sounds good now. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Inline > > > > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 2:16 AM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > inline... > > Avasarala Ranjit-A20990 wrote: > >> I'm still a little confused here. >> If phone is on and subscription is active, then in general >> notification should be possible, regardless of registration. I realize > >> IMS doesn't permit that, but from a general standard perspective we >> shouldn't assume it. The manifestation in this case is that the NOTIFY > >> would fail and the subscription would eventually be torn down. >> >> So I think the cases are: >> - there is a subscription and notification works >> - there is a subscription but notification fails >> - there is no subscription. >> >> Agreed. Actually instead of calling it as >> Notification fails, we can say - not sending notification due to (1) >> no match of filter criteria (2) phone not registered or outside >> coverage area due to which there is no connectivity and hence >> notification cannot be sent Anyway if no subscription, no > notification. > > Are you suggesting that you might have a subscription, and have the > filter criteria met, and yet not attempt to send a NOTIFY because the > phone is not registered or has no network connectivity??? > > That seems wrong. ISTM that either you would remove the subscription, or > else you would try to send the NOTIFY and then discover that it fails. > > yes the subscription could be removed when the device is > not reachable. > > OTOH, this probably ought not to be within scope of what is discussed in > this draft. > > yes true not within the scope of this draft. > >>> [3] in the example u suggested where sip:alice@atlanta.org with two >>> contacts: sip:line1@alice.office.atlanta.com and >>> sip:line2@alice.home.atlanta.com and >>> both the phones ring, then it would be a case of parallel > forking. >>> Now say one or both the phones have set diversion rules, to divert >>> the >> In this case, what does it mean for "one or both phones have set >> diversion rules"? Does that somehow imply distinct rules for each > phone? >> I don't see how that could work. Aren't the diversion rules for the >> *AOR*? >> >> Yes the diversion rules are for AoR. So when there is > >> a diversion rule set for the AoR and when diversions occur, the >> notifications are Sent to the AoR. > > Not sent to the AoR - sent to the remote contact of the dialog for each > subscription to the AoR. Same point as below that you agreed with. > > Yes agree with u. > >> I see they could be set/changed from either phone. But its a single >> set of rules isn't it? So I might set the rules from the office, and >> then cancel them from home. >> >> yes single set and could be set from either of the >> phones. True. >> >>> call to say >>> sip:voicemail@alice.atlanta.com, then the notifications would get > >>> generated with respect to both the contacts. >> Again I'm confused by the terminology you use, and how it relates >> operationally. The diversion happens on the AOR, and the subscriptions > >> are on the AOR, and the notifications are sent to the subscribers. I >> don't see where the registered contacts enter into the picture at all. >> >> Ya agree with you on this. Sorry for the confusion. >> >> If you have something else in mind, I hope you can explain it better >> in the draft. >> >>> [4] Yes the value of N is configurable and depends on how many >>> diversions the subscribe wants to keep or could be dependent on >>> server >>> policy (some maximum >>> number). If the server policy is to send notifications as and >>> when >>> they occur and not keep any divsersions information, then the value >>> of >>> last N >>> diversions will be zero. But if the server chooses to retain the >>> last diversion always, then the value of N will be 1 and so on. >> All is straightforward for N>=1. >> >> For N=0 things are messy. If we are modeling this as state, and >> notifications are about state changes, then the new diversion is added > >> to the (previously empty) state and that triggers notifications to all > >> current subscriptions. Then if you don't want to retain even this much > >> state (because N=0) you immediately remove that version from the > state. >> But that is again a state change, so you end up with another >> notification of that state change. >> >> True. Actually the notifications are for informing >> the subscriber of the call diversions that happen. The notifications >> are not for informing the subscriber of state changes in the notifier >> or the number of diversions that occurred. As I mentioned in the >> abstract as well as 24.604, the main intent of CDIVN service is to >> inform the subscribers of communication diversions that occur on their > >> behalf in the network and this information will help them manage their > >> rules better. > > I am not certain, but think we may still be talking past one another to > some extent. > > The state can be considered just a formalism for defining the service > clearly, regardless of whether it has intrinsic value to the CDIV > service. But it *is* a formalism. So if it is introduced, then its > behavior can't be ignored when inconvenient. Defining the state with N=0 > leads to some undesired behavior. The simplest way around that is to > insist that N be >=1. > > Ok in that case we can say that value of N >=1 and the > notifier has always maintains history of last diversion at a minimu. It > can maintain more than 1 too depending on the policy. > > If its important to you that no state be retained once a notification > has been sent about the most recent diversion, then you will have to > find some other way to specify the service, that still meets the > expectations of 3265. I don't know if there is anything there that Adam > would consider valid. We will have to get his opinion on that. > > In that case I am OK maintaining the hostory of diversions > that occurred as part of state information and retaining that state even > after the notification for that diversion is sent - so that in case I do > not get a confirmation, I would be able to re-send the notification. > Also maintaining state of diversions would help when the notifications > need to sent only at a particular time (if fikter criteria mentions it). > > > Thanks, > Paul > >> But if we want to include the information related to >> how many diversions have happened till time (say from 12 AM ) till the > >> time the notification is being sent, then as you say we can store the >> diversions. This would be useful when the subscriber specifies in the >> filter criteria to send notifications only during certain time like >> between 5 and 6 PM and not whenever a diversion occurs. Then N is >> grater than 1. > >> I presume you don't want that behavior. If you can live with N>=1 then > >> we don't have the problem at all. If you need to support N=0 and don't > >> want the extra notify, then we have to figure out if there is some >> trick to how things are modeled to get the desired effect. I've >> suggested something previously, but Adam didn't like it. >> >> This needs sorting out. >> >> Thanks, >> Paul > From ranjit@motorola.com Tue Mar 2 08:56:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BF13A8AB9 for ; Tue, 2 Mar 2010 08:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5MjhVL3U86g for ; Tue, 2 Mar 2010 08:56:25 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 4F7B53A8AAF for ; Tue, 2 Mar 2010 08:56:25 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1267548980!13798573!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 15574 invoked from network); 2 Mar 2010 16:56:21 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-3.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2010 16:56:21 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id o22GuKLF000600 for ; Tue, 2 Mar 2010 09:56:20 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o22GuKSt011111 for ; Tue, 2 Mar 2010 10:56:20 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o22GuIE7011062 for ; Tue, 2 Mar 2010 10:56:19 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Mar 2010 00:55:56 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A37B88B@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B8D173C.9070102@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq6DxoGh5YtpP6wR3iO9pldHX5I1wAFbE5g References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 16:56:26 -0000 Ok will incorporate all the comments we discussed so far in the updated version (-04)=20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, March 02, 2010 7:19 PM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] I think this all sounds good now. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Inline >=20 > >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 2:16 AM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 > inline... >=20 > Avasarala Ranjit-A20990 wrote: >=20 >> I'm still a little confused here. >> If phone is on and subscription is active, then in general=20 >> notification should be possible, regardless of registration. I=20 >> realize >=20 >> IMS doesn't permit that, but from a general standard perspective we=20 >> shouldn't assume it. The manifestation in this case is that the=20 >> NOTIFY >=20 >> would fail and the subscription would eventually be torn down. >> >> So I think the cases are: >> - there is a subscription and notification works >> - there is a subscription but notification fails >> - there is no subscription. >> >> Agreed. Actually instead of calling it as=20 >> Notification fails, we can say - not sending notification due to (1)=20 >> no match of filter criteria (2) phone not registered or outside=20 >> coverage area due to which there is no connectivity and hence=20 >> notification cannot be sent Anyway if no subscription, no > notification. >=20 > Are you suggesting that you might have a subscription, and have the=20 > filter criteria met, and yet not attempt to send a NOTIFY because the=20 > phone is not registered or has no network connectivity??? >=20 > That seems wrong. ISTM that either you would remove the subscription,=20 > or else you would try to send the NOTIFY and then discover that it fails. >=20 > yes the subscription could be removed when the device is > not reachable. >=20 > OTOH, this probably ought not to be within scope of what is discussed=20 > in this draft. >=20 > yes true not within the scope of this draft. >=20 >>> [3] in the example u suggested where sip:alice@atlanta.org with two >>> contacts: sip:line1@alice.office.atlanta.com and=20 >>> sip:line2@alice.home.atlanta.com and >>> both the phones ring, then it would be a case of parallel > forking. >>> Now say one or both the phones have set diversion rules, to divert=20 >>> the >> In this case, what does it mean for "one or both phones have set=20 >> diversion rules"? Does that somehow imply distinct rules for each > phone? >> I don't see how that could work. Aren't the diversion rules for the=20 >> *AOR*? >> >> Yes the diversion rules are for AoR. So when there=20 >> is >=20 >> a diversion rule set for the AoR and when diversions occur, the=20 >> notifications are Sent to the AoR. >=20 > Not sent to the AoR - sent to the remote contact of the dialog for=20 > each subscription to the AoR. Same point as below that you agreed with. >=20 > Yes agree with u.=20 >=20 >> I see they could be set/changed from either phone. But its a single=20 >> set of rules isn't it? So I might set the rules from the office, and=20 >> then cancel them from home. >> >> yes single set and could be set from either of the=20 >> phones. True. >> >>> call to say=20 >>> sip:voicemail@alice.atlanta.com, then the notifications would=20 >>> get >=20 >>> generated with respect to both the contacts. >> Again I'm confused by the terminology you use, and how it relates=20 >> operationally. The diversion happens on the AOR, and the=20 >> subscriptions >=20 >> are on the AOR, and the notifications are sent to the subscribers. I=20 >> don't see where the registered contacts enter into the picture at all. >> >> Ya agree with you on this. Sorry for the confusion. >> >> If you have something else in mind, I hope you can explain it better=20 >> in the draft. >> >>> [4] Yes the value of N is configurable and depends on how many=20 >>> diversions the subscribe wants to keep or could be dependent on=20 >>> server policy (some maximum >>> number). If the server policy is to send notifications as and=20 >>> when they occur and not keep any divsersions information, then the=20 >>> value of last N >>> diversions will be zero. But if the server chooses to retain the >>> last diversion always, then the value of N will be 1 and so on. >> All is straightforward for N>=3D1. >> >> For N=3D0 things are messy. If we are modeling this as state, and=20 >> notifications are about state changes, then the new diversion is=20 >> added >=20 >> to the (previously empty) state and that triggers notifications to=20 >> all >=20 >> current subscriptions. Then if you don't want to retain even this=20 >> much >=20 >> state (because N=3D0) you immediately remove that version from the > state. >> But that is again a state change, so you end up with another=20 >> notification of that state change. >> >> True. Actually the notifications are for informing=20 >> the subscriber of the call diversions that happen. The notifications=20 >> are not for informing the subscriber of state changes in the notifier >> or the number of diversions that occurred. As I mentioned in the=20 >> abstract as well as 24.604, the main intent of CDIVN service is to=20 >> inform the subscribers of communication diversions that occur on=20 >> their >=20 >> behalf in the network and this information will help them manage=20 >> their >=20 >> rules better. >=20 > I am not certain, but think we may still be talking past one another=20 > to some extent. >=20 > The state can be considered just a formalism for defining the service=20 > clearly, regardless of whether it has intrinsic value to the CDIV=20 > service. But it *is* a formalism. So if it is introduced, then its=20 > behavior can't be ignored when inconvenient. Defining the state with=20 > N=3D0 leads to some undesired behavior. The simplest way around that = is=20 > to insist that N be >=3D1. >=20 > Ok in that case we can say that value of N >=3D1 and the = > notifier has always maintains history of last diversion at a minimu.=20 > It can maintain more than 1 too depending on the policy. >=20 > If its important to you that no state be retained once a notification=20 > has been sent about the most recent diversion, then you will have to=20 > find some other way to specify the service, that still meets the=20 > expectations of 3265. I don't know if there is anything there that=20 > Adam would consider valid. We will have to get his opinion on that. >=20 > In that case I am OK maintaining the hostory of=20 > diversions that occurred as part of state information and retaining=20 > that state even after the notification for that diversion is sent - so > that in case I do not get a confirmation, I would be able to re-send the notification. > Also maintaining state of diversions would help when the notifications > need to sent only at a particular time (if fikter criteria mentions it). >=20 >=20 > Thanks, > Paul >=20 >> But if we want to include the information related to >> how many diversions have happened till time (say from 12 AM ) till=20 >> the >=20 >> time the notification is being sent, then as you say we can store the >> diversions. This would be useful when the subscriber specifies in the >> filter criteria to send notifications only during certain time like=20 >> between 5 and 6 PM and not whenever a diversion occurs. Then N is=20 >> grater than 1. >=20 >> I presume you don't want that behavior. If you can live with N>=3D1=20 >> then >=20 >> we don't have the problem at all. If you need to support N=3D0 and=20 >> don't >=20 >> want the extra notify, then we have to figure out if there is some=20 >> trick to how things are modeled to get the desired effect. I've=20 >> suggested something previously, but Adam didn't like it. >> >> This needs sorting out. >> >> Thanks, >> Paul >=20 From dean.willis@softarmor.com Tue Mar 2 10:36:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439F828C133 for ; Tue, 2 Mar 2010 10:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyr0LvVGqnNd for ; Tue, 2 Mar 2010 10:36:14 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ABE6728C229 for ; Tue, 2 Mar 2010 10:36:14 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o22IaB30026006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Mar 2010 12:36:13 -0600 Message-Id: <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> Content-Type: multipart/alternative; boundary=Apple-Mail-22--662526163 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Mar 2010 12:36:06 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:36:16 -0000 --Apple-Mail-22--662526163 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote: > All, > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP Egress Route Use in ENUM > Author(s) : D. Malas > Filename : draft-malas-dispatch-sip-egress-route-00.txt > Pages : 11 > Date : 2010-03-01 > The universe has apparently shifted beneath my feet again. When did DNS (and ENUM is just DNS, or maybe a private-root DNS depending on what you believe) become a legitimate repository for intermediary routing information? Let's take the scenario from the draft: +=====================++ ++====================+ || || SSP1 Network +--------+ || SSP2 Network ssp1.example.com | | || ssp2.example.com +--->| SBE1 |---+ || | | | | || | +--------+ | || | || | || | || | || +-------+ | || | +--------+ +-------+ | |---+ || +---->| |---->| | | Proxy | || | SBE3 | | Proxy | | |---+ || +---->| |---->| | +-------+ | || | +--------+ +-------+ | || | || | || | || | +--------+ | || | | | | || +--->| SBE2 |---+ || | | || +--------+ || || || +=====================++ ++====================+ Here's the scenario recast in a "more traditional" terminology: SSP2 has externally advertised (at least to SSP1) that SBE3 is a (or "the") route to the address space of SSP2. Both SBE1 and SBE2 have been informed of this advertisement. Presumably there's a route in the other direction as well, although that's out of scope for the example. SSP1 wishes to advertise, within the administrative domain of SSP1, two routes to the address space of SSP2. The preferred route is through SBE2, with a secondary route through SBE1, although nothing has been said about the load-metric so we assume the policy use "Use SBE1 only if SBE2 isn't responding". Explain to me why ANY of this routing/reachability information should be in DNS or a DNS-like static map? That's just absurd! We appear to going through some extreme convolutions to twist a dynamic routing problem (that should be dealt with by protocols more like BGP and OSPF) into a name-service problem. I think it's time for a complete re-think of what's going on here. ENUM is NOT a routing protocol. It's a distributed database for mapping names to addresses and for looking up related information about names, where the associations involved are relatively long-lived (and for the most part effectively static). There's a reason we don't have every Internet router do a DNS lookup on a request-destination and use that lookup result to select a next- hop route. We COULD do this, it just requires having lots and lots of DNS servers configured with alt-root structures that reflect local routing tables, and that get continuously reprovisioned to reflect changes in network topology, load, and policy. We COULD do this -- why don't we? The answer is that doing this would be deeply, profoundly, and astoundingly inefficient. It's just the wrong way to solve the problem. It's sort of like trying to print highway maps that, rather than showing the road to follow to reach a destination, only show the next exit or turn and therefore one needs an entirely different map for each possible place that one might currently be standing. Sure, it makes for a big business in maintaining and printing maps, but it makes actually getting anywhere profoundly painful and expensive. So why on earth are we attempting to use the same pattern for routing phone calls? Is it just a matter of ENUM being the only hammer we were given to play with? Folks, we can get a different tool if we need one; we don't need to keep beating on the plumbing with the ENUM hammer when what we really need is a pipe-threader or bender. -- Dean --Apple-Mail-22--662526163 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 1, 2010, = at 5:50 PM, Daryl Malas wrote:

=
All,
 
A New Internet-Draft is available from the = on-line Internet-Drafts directories.
 
Title : SIP Egress = Route Use in ENUM
Author(s) : D. Malas
Filename : = draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : = 2010-03-01 =
 

The = universe has apparently shifted beneath my feet again. When did DNS (and = ENUM is just DNS, or maybe a private-root DNS depending on what you = believe) become a legitimate repository for intermediary routing = information? 


Let's take = the scenario from the draft:

   =
+=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+
                         ||                 ||
       SSP1 Network  +--------+             ||       SSP2 Network
   ssp1.example.com  |        |             ||   ssp2.example.com
                +--->|  SBE1  |---+         ||
                |    |        |   |         ||
                |    +--------+   |         ||
                |        ||       |         ||
                |        ||       |         ||
    +-------+   |        ||       |     +--------+     +-------+
    |       |---+        ||       +---->|        |---->|       |
    | Proxy |            ||             |  SBE3  |     | Proxy |
    |       |---+        ||       +---->|        |---->|       |
    +-------+   |        ||       |     +--------+     +-------+
                |        ||       |         ||
                |        ||       |         ||
                |    +--------+   |         ||
                |    |        |   |         ||
                +--->|  SBE2  |---+         ||
                     |        |             ||
                     +--------+             ||
                         ||                 ||
   +=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+


Here's the scenario recast in = a "more traditional" terminology:

SSP2 has = externally advertised (at least to SSP1) that SBE3 is a (or "the") route = to the address space of SSP2. Both SBE1 and SBE2 have been informed of = this advertisement. Presumably there's a route in the other direction as = well, although that's out of scope for the = example.

SSP1 wishes to advertise, within the = administrative domain of SSP1, two routes to the address space of SSP2. = The preferred route is through SBE2, with a secondary route through = SBE1, although nothing has been said about the load-metric so we assume = the policy use "Use SBE1 only if SBE2 isn't = responding".

Explain to me why ANY of this = routing/reachability information should be in DNS or a DNS-like static = map? That's just absurd! We appear to  going through some extreme = convolutions to twist a dynamic routing problem (that should be dealt = with by protocols more like BGP and OSPF) into a name-service = problem.

I think it's time for a complete = re-think of what's going on here.

ENUM is NOT a = routing protocol. It's a distributed database for mapping names to = addresses and for looking up related information about names, where the = associations involved are relatively long-lived (and for the most part = effectively static).

There's a reason we don't = have every Internet router do a DNS lookup on a request-destination and = use that lookup result to select a next-hop route. We COULD do this, it = just requires having lots and lots of DNS servers configured with = alt-root structures that reflect local routing tables, and that get = continuously reprovisioned to reflect changes in network topology, load, = and policy.  We COULD do this -- why don't we?  The = answer is that doing this would be deeply, profoundly, and astoundingly = inefficient. It's just the wrong way to solve the problem. It's sort of = like trying to print highway maps that, rather than showing the road to = follow to reach a destination, only show the next exit or turn and = therefore one needs an entirely different map for each possible place = that one might currently be standing. Sure, it makes for a big business = in maintaining and printing maps, but it makes actually getting anywhere = profoundly painful and expensive.

So why on = earth are we attempting to use the same pattern for routing phone calls? =  Is it just a matter of ENUM being the only hammer we were given to = play with? Folks, we can get a different tool if we need one; we don't = need to keep beating on the plumbing with the ENUM hammer when what we = really need is a pipe-threader or = bender.

--
Dean
= --Apple-Mail-22--662526163-- From pp3129@att.com Tue Mar 2 11:24:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E9B3A8C84 for ; Tue, 2 Mar 2010 11:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gVHhN4WvMob for ; Tue, 2 Mar 2010 11:24:29 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 180D33A8C81 for ; Tue, 2 Mar 2010 11:24:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-12.tower-129.messagelabs.com!1267557868!7662556!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 5859 invoked from network); 2 Mar 2010 19:24:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2010 19:24:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o22JOIYt021797 for ; Tue, 2 Mar 2010 14:24:19 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o22JOC4D021552 for ; Tue, 2 Mar 2010 14:24:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABA3D.F5F1C4B5" Date: Tue, 2 Mar 2010 14:24:21 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQ References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Daryl Malas" , Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 19:24:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABA3D.F5F1C4B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daryl: I want to be sure I understand what you're proposing. In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. =20 Thanks, =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 All, =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : SIP Egress Route Use in ENUM=20 Author(s) : D. Malas=20 Filename : draft-malas-dispatch-sip-egress-route-00.txt=20 Pages : 11=20 Date : 2010-03-01=20 =20 In some cases a UA (or proxy) within a Session Initiation Protocol=20 [RFC3261] Service Provider (SSP) has multiple parallel egress proxy=20 options to reach an ingress proxy within another SSP to reach the=20 target UA. If the originating SSP uses ENUM to identify the ingress=20 proxy of the target SSP, there is currently no way for the ENUM NAPTR=20 response to identify a specific preferred egress proxy from the set=20 of multiple parallel proxies. This draft solves this problem by=20 defining a method for returning deterministic routing information=20 within an ENUM NAPTR response enabling the UA (or proxy) to choose a=20 preferred egress proxy. Using this information, the originating UA=20 now sends the SIP request through the predetermined preferred egress=20 proxy to reach the target SSP's proxy. This document describes=20 several methods to make this determination by incorporating variables=20 into a SIP service URI contained in the E.164 Number Mapping (ENUM)=20 response.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout e-00.txt=20 =20 Regards, =20 Daryl =20 --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com =20 =20 ------_=_NextPart_001_01CABA3D.F5F1C4B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daryl:

I want to be sure I understand what you’re proposing.  In what name server would the modified records be? One = local to SSP1 or some general industry DNS? I’m trying to understand how = SSP1 modifies an RR for an SSP2 number.

 

Thanks,

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: 'dispatch@ietf.org'
Subject: [dispatch] I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR =
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a =
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress =
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables =
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch= -sip-egress-route-00.txt

 

Regards,

 

Daryl<= o:p>

 

-------------= --------------

Daryl Malas

Project Director, IP Interconnects

w - +1 303 661 3302

 

------_=_NextPart_001_01CABA3D.F5F1C4B5-- From adam@nostrum.com Tue Mar 2 11:26:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D663A8B97 for ; Tue, 2 Mar 2010 11:26: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1ZGwjd5SZqj for ; Tue, 2 Mar 2010 11:26:05 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8C4783A8C84 for ; Tue, 2 Mar 2010 11:26:04 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22JQ15c029739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 13:26:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D6649.5080602@nostrum.com> Date: Tue, 02 Mar 2010 13:26:01 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> In-Reply-To: <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> Content-Type: multipart/alternative; boundary="------------060209060003050806090006" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 19:26:05 -0000 This is a multi-part message in MIME format. --------------060209060003050806090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/2/10 12:36, Mar 2, Dean Willis wrote: > > On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote: > >> All, >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : SIP Egress Route Use in ENUM >> Author(s) : D. Malas >> Filename : draft-malas-dispatch-sip-egress-route-00.txt >> Pages : 11 >> Date : 2010-03-01 >> > > The universe has apparently shifted beneath my feet again. When did > DNS (and ENUM is just DNS, or maybe a private-root DNS depending on > what you believe) become a legitimate repository for intermediary > routing information? 1992? http://www.rfc-editor.org/rfc/rfc1383.txt /a --------------060209060003050806090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/2/10 12:36, Mar 2, Dean Willis wrote:

On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote:

All,
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 

The universe has apparently shifted beneath my feet again. When did DNS (and ENUM is just DNS, or maybe a private-root DNS depending on what you believe) become a legitimate repository for intermediary routing information?

1992?

http://www.rfc-editor.org/rfc/rfc1383.txt

/a
--------------060209060003050806090006-- From adam@nostrum.com Tue Mar 2 11:52:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B22328C164 for ; Tue, 2 Mar 2010 11:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOfItK6c3Esz for ; Tue, 2 Mar 2010 11:52:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 06ED328C1F0 for ; Tue, 2 Mar 2010 11:52:42 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22JqfBk031771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 13:52:42 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D6C89.8050409@nostrum.com> Date: Tue, 02 Mar 2010 13:52:41 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <4B8D6649.5080602@nostrum.com> In-Reply-To: <4B8D6649.5080602@nostrum.com> Content-Type: multipart/alternative; boundary="------------030907040806070309060703" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 19:52:44 -0000 This is a multi-part message in MIME format. --------------030907040806070309060703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/2/10 13:26, Mar 2, Adam Roach wrote: > On 3/2/10 12:36, Mar 2, Dean Willis wrote: >> >> On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote: >> >>> All, >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : SIP Egress Route Use in ENUM >>> Author(s) : D. Malas >>> Filename : draft-malas-dispatch-sip-egress-route-00.txt >>> Pages : 11 >>> Date : 2010-03-01 >>> >> >> The universe has apparently shifted beneath my feet again. When did >> DNS (and ENUM is just DNS, or maybe a private-root DNS depending on >> what you believe) become a legitimate repository for intermediary >> routing information? > > 1992? > > http://www.rfc-editor.org/rfc/rfc1383.txt And, really, if you look at the original DNS spec (RFC 882, published in 1983), the MF record type (as distinct from the MD record type, both since subsumed by MX records) talk about the same kinds of information as Daryl is proposing here. Semantically: "To get to host B, deliver to host A, and indicate the domain of host B in the application data itself." There's also the use of the "RT" (Route Through) record defined by RFC 1183, which does exactly this kind of thing. In fact, a careful dusting off of RT (accompanied by a BCP for this specific application) would probably serve the purpose intended by this draft. I really see very little historical basis for objecting to storing this kind of information in DNS at all. /a --------------030907040806070309060703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/2/10 13:26, Mar 2, Adam Roach wrote:
On 3/2/10 12:36, Mar 2, Dean Willis wrote:

On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote:

All,
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 

The universe has apparently shifted beneath my feet again. When did DNS (and ENUM is just DNS, or maybe a private-root DNS depending on what you believe) become a legitimate repository for intermediary routing information?

1992?

http://www.rfc-editor.org/rfc/rfc1383.txt

And, really, if you look at the original DNS spec (RFC 882, published in 1983), the MF record type (as distinct from the MD record type, both since subsumed by MX records) talk about the same kinds of information as Daryl is proposing here. Semantically: "To get to host B, deliver to host A, and indicate the domain of host B in the application data itself."

There's also the use of the "RT" (Route Through) record defined by RFC 1183, which does exactly this kind of thing. In fact, a careful dusting off of RT (accompanied by a BCP for this specific application) would probably serve the purpose intended by this draft.

I really see very little historical basis for objecting to storing this kind of information in DNS at all.

/a
--------------030907040806070309060703-- From dean.willis@softarmor.com Tue Mar 2 22:59:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A777F28C21C for ; Tue, 2 Mar 2010 22:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFioMAig03QG for ; Tue, 2 Mar 2010 22:59:23 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AD1AB28C101 for ; Tue, 2 Mar 2010 22:59:23 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o236xLBL030954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 00:59:22 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B8D6649.5080602@nostrum.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--617936864 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 00:59:15 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <4B8D6649.5080602@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 06:59:24 -0000 --Apple-Mail-1--617936864 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 2, 2010, at 1:26 PM, Adam Roach wrote: > On 3/2/10 12:36, Mar 2, Dean Willis wrote: >> >> >> On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote: >> >>> All, >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : SIP Egress Route Use in ENUM >>> Author(s) : D. Malas >>> Filename : draft-malas-dispatch-sip-egress-route-00.txt >>> Pages : 11 >>> Date : 2010-03-01 >>> >> >> The universe has apparently shifted beneath my feet again. When did >> DNS (and ENUM is just DNS, or maybe a private-root DNS depending on >> what you believe) become a legitimate repository for intermediary >> routing information? > > 1992? > > http://www.rfc-editor.org/rfc/rfc1383.txt That was what we might colloquially call a "valid experiment that successfully produced a result invalidating the hypothesis". Bravely done, but perhaps not so functional in the real world. An experimental approach resulting in failure does not qualify the failed approach as a legitimate solution. Do we learn from it, or just blindly do it all over again? -- Dean --Apple-Mail-1--617936864 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 2, 2010, = at 1:26 PM, Adam Roach wrote:

On 3/2/10 12:36, Mar 2, Dean = Willis wrote:

On Mar 1, 2010, at 5:50 PM, Daryl Malas = wrote:

All,
 
A New Internet-Draft is available from the = on-line Internet-Drafts directories.
 
Title : SIP Egress = Route Use in ENUM
Author(s) : D. Malas
Filename : = draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : = 2010-03-01
 
=

The universe has apparently shifted beneath my feet = again. When did DNS (and ENUM is just DNS, or maybe a private-root DNS = depending on what you believe) become a legitimate repository for = intermediary routing information?

1992?
=
http://www.rfc-editor.o= rg/rfc/rfc1383.txt

That was = what we might colloquially  call a "valid experiment that = successfully produced a result invalidating the hypothesis". Bravely = done, but perhaps not so functional in the real world.  An = experimental approach resulting in failure does not qualify the failed = approach as a legitimate solution.

Do we learn = from it, or just blindly do it all over = again?

--
Dean

= --Apple-Mail-1--617936864-- From dean.willis@softarmor.com Tue Mar 2 23:05:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3245F28C222 for ; Tue, 2 Mar 2010 23:05:50 -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 wlNqb5lz1dgs for ; Tue, 2 Mar 2010 23:05:49 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1120528C212 for ; Tue, 2 Mar 2010 23:05:49 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2375ma8031023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:05:50 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B8D6C89.8050409@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:05:43 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <4B8D6649.5080602@nostrum.com> <4B8D6C89.8050409@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:05:50 -0000 On Mar 2, 2010, at 1:52 PM, Adam Roach wrote: > > And, really, if you look at the original DNS spec (RFC 882, > published in 1983), the MF record type (as distinct from the MD > record type, both since subsumed by MX records) talk about the same > kinds of information as Daryl is proposing here. Semantically: "To > get to host B, deliver to host A, and indicate the domain of host B > in the application data itself." > > There's also the use of the "RT" (Route Through) record defined by > RFC 1183, which does exactly this kind of thing. In fact, a careful > dusting off of RT (accompanied by a BCP for this specific > application) would probably serve the purpose intended by this draft. > > I really see very little historical basis for objecting to storing > this kind of information in DNS at all. The unused routing cruft in the DNS is unused for a reason; it doesn't make for an operational network or a scaleable DNS. This is also why we don't use UUCP-style addressing for phone calls and web traffic. The applicability of the approach can be summed up in the non-response to: http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg00915.html But you are right; RT does almost exactly what the draft in question proposes. I wouldn't stop anybody from doing an experimental-track draft warming over RT for phone number routing. But I'd probably laugh at them. -- Dean From gregert@teigre.com Tue Mar 2 23:16:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2AD3A8C3F for ; Tue, 2 Mar 2010 23:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-PqzWXXfqyI for ; Tue, 2 Mar 2010 23:16:06 -0800 (PST) Received: from pontius.teigre.com (pontius.teigre.com [213.225.78.155]) by core3.amsl.com (Postfix) with ESMTP id C7DB43A8C3A for ; Tue, 2 Mar 2010 23:16:05 -0800 (PST) X-ClientAddr: 217.14.5.61 Received: from [192.168.5.192] (217-14-5-61-dhcp-osl.bbse.no [217.14.5.61]) (authenticated bits=0) by pontius.teigre.com (8.13.8/8.13.8) with ESMTP id o237G6xB023449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Mar 2010 08:16:06 +0100 Message-ID: <4B8E0CB5.5040808@teigre.com> Date: Wed, 03 Mar 2010 08:16:05 +0100 From: Greger Viken Teigre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> Content-Type: multipart/alternative; boundary="------------070808010505020605080009" X-teigre.com-MailScanner-Information: Please contact the ISP for more information X-teigre.com-MailScanner: Found to be clean X-teigre.com-MailScanner-From: gregert@teigre.com Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:16:13 -0000 This is a multi-part message in MIME format. --------------070808010505020605080009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02.03.2010 20:24, PFAUTZ, PENN L (ATTCORP) wrote: > > Daryl: > > I want to be sure I understand what you're proposing. In what name > server would the modified records be? One local to SSP1 or some > general industry DNS? I'm trying to understand how SSP1 modifies an RR > for an SSP2 number. > A few follow-up questions to that. I'm a bit confused about the problem that you are trying to solve. From the draft it looks like the name server is local to SSP1. If that is correct, why would you like to standardize how you acquire routing information? If both the proxy and the name server are local to SSP1, I don't see why you need to standardize the data retrieval interface in a SIP context? We already have a few of those. And there must surely be more efficient ways of storing and retrieving such information?! However, if the intention is primarily to be a standard for UAs to implement to avoid a ("static") proxy for determining routing path (i.e. a per session outbound proxy), we should surely look at a more generic approach to determining the outbound proxy?! I thought dynamic routing was one of the reasons for having an outbound proxy and choosing an egress proxy is hardly a problem specific to e.164 addresses. g-) > Thanks, > > Penn Pfautz > > AT&T Access Management > > +1-732-420-4962 > > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Daryl Malas > *Sent:* Monday, March 01, 2010 6:51 PM > *To:* 'dispatch@ietf.org' > *Subject:* [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 > > All, > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : SIP Egress Route Use in ENUM > Author(s) : D. Malas > Filename : draft-malas-dispatch-sip-egress-route-00.txt > Pages : 11 > Date : 2010-03-01 > > In some cases a UA (or proxy) within a Session Initiation Protocol > [RFC3261] Service Provider (SSP) has multiple parallel egress proxy > options to reach an ingress proxy within another SSP to reach the > target UA. If the originating SSP uses ENUM to identify the ingress > proxy of the target SSP, there is currently no way for the ENUM NAPTR > response to identify a specific preferred egress proxy from the set > of multiple parallel proxies. This draft solves this problem by > defining a method for returning deterministic routing information > within an ENUM NAPTR response enabling the UA (or proxy) to choose a > preferred egress proxy. Using this information, the originating UA > now sends the SIP request through the predetermined preferred egress > proxy to reach the target SSP's proxy. This document describes > several methods to make this determination by incorporating variables > into a SIP service URI contained in the E.164 Number Mapping (ENUM) > response. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-00.txt > > > Regards, > > Daryl > > --------------------------- > > Daryl Malas > > Project Director, IP Interconnects > > w - +1 303 661 3302 > > mailto:d.malas@cablelabs.com > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------070808010505020605080009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02.03.2010 20:24, PFAUTZ, PENN L (ATTCORP) wrote:

Daryl:

I want to be sure I understand what you’re proposing.  In what name server would the modified records be? One local to SSP1 or some general industry DNS? I’m trying to understand how SSP1 modifies an RR for an SSP2 number.


A few follow-up questions to that. I'm a bit confused about the problem that you are trying to solve.

>From the draft it looks like the name server is local to SSP1. If that is correct, why would you like to standardize how you acquire routing information? If both the proxy and the name server are local to SSP1, I don't see why you need to standardize the data retrieval interface in a SIP context?  We already have a few of those.  And there must surely be more efficient ways of storing and retrieving such information?!
However, if the intention is primarily to be a standard for UAs to implement to avoid a ("static") proxy for determining routing path (i.e. a per session outbound proxy), we should surely look at a more generic approach to determining the outbound proxy?!  I thought dynamic routing was one of the reasons for having an outbound proxy and choosing an egress proxy is hardly a problem specific to e.164 addresses.
g-)

 

Thanks,

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: 'dispatch@ietf.org'
Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-00.txt

 

Regards,

 

Daryl

 

---------------------------

Daryl Malas

Project Director, IP Interconnects

w - +1 303 661 3302

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------070808010505020605080009-- From D.Malas@cablelabs.com Wed Mar 3 08:22:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3487628C10A for ; Wed, 3 Mar 2010 08:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mukt3rP1AdYy for ; Wed, 3 Mar 2010 08:21:59 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 2FB5F3A8B36 for ; Wed, 3 Mar 2010 08:21:55 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23GLriM020171; Wed, 3 Mar 2010 09:21:53 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 09:21:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 09:21:53 -0700 From: Daryl Malas To: "'PFAUTZ, PENN L (ATTCORP)'" , "dispatch@ietf.org" Date: Wed, 3 Mar 2010 09:21:52 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQA= Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:22:07 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Penn, The use case for this application is SSP1 (or someone on their behalf) prov= isions their numbers and relative routes into the LUF associated with their= federation. SSP2 reviews SSP1's "routes" available to them in the LUF bas= ed on what SSP1 provisioned. They then add an egress route and associate i= t with the ingress route SSP1 provisioned. Let me know if this makes sense. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Penn,
 
The use case for this application is SSP1 (or someone= on their=20 behalf) provisions their numbers and relative routes into the LUF=20 associated with their federation.  SSP2 reviews SSP1's "routes"=20 available to them in the LUF based on what SSP1 provisioned.  They the= n add=20 an egress route and associate it with the ingress route SSP1=20 provisioned.
 
Let me know if this makes sense.
 
Regards,
 
Daryl

From: PFAUTZ, PENN L (ATTCORP)=20 [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24=20 PM
To: Daryl Malas; dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl:

I=20 want to be sure I understand what you’re proposing.  In what nam= e server=20 would the modified records be? One local to SSP1 or some general industry D= NS?=20 I’m trying to understand how SSP1 modifies an RR for an SSP2=20 number.

 

Thanks,

 

From:<= /B>=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To:=20 'dispatch@ietf.org'
Subject: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet= -Draft=20 is available from the on-line Internet-Drafts directories.
 
Ti= tle :=20 SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20

 

Regards,

 

Daryl

 

--------------= -------------

Daryl=20 Malas

Project Direct= or, IP=20 Interconnects

w - +1 303 661= =20 3302

mailto:d.malas@cablelabs.com=

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3srvxchg_-- From D.Malas@cablelabs.com Wed Mar 3 08:26:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E0428C0F0 for ; Wed, 3 Mar 2010 08:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKhj+ok5hLHr for ; Wed, 3 Mar 2010 08:26:51 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 12B923A845A for ; Wed, 3 Mar 2010 08:26:51 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23GQpUK020816; Wed, 3 Mar 2010 09:26:51 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 09:26:51 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 09:26:51 -0700 From: Daryl Malas To: "'Greger Viken Teigre'" , "dispatch@ietf.org" Date: Wed, 3 Mar 2010 09:26:51 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq6oWrmFHb7FBcrRO6qCiHACCbU0wATNjpw Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B4@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <4B8E0CB5.5040808@teigre.com> In-Reply-To: <4B8E0CB5.5040808@teigre.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B4srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:26:58 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B4srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greger, Please see my last email in response to Penn and let me know if it helps. Regards, Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Greger Viken Teigre Sent: Wednesday, March 03, 2010 12:16 AM To: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On 02.03.2010 20:24, PFAUTZ, PENN L (ATTCORP) wrote: Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. A few follow-up questions to that. I'm a bit confused about the problem tha= t you are trying to solve. >From the draft it looks like the name server is local to SSP1. If that is c= orrect, why would you like to standardize how you acquire routing informati= on? If both the proxy and the name server are local to SSP1, I don't see wh= y you need to standardize the data retrieval interface in a SIP context? W= e already have a few of those. And there must surely be more efficient way= s of storing and retrieving such information?! However, if the intention is primarily to be a standard for UAs to implemen= t to avoid a ("static") proxy for determining routing path (i.e. a per sess= ion outbound proxy), we should surely look at a more generic approach to de= termining the outbound proxy?! I thought dynamic routing was one of the re= asons for having an outbound proxy and choosing an egress proxy is hardly a= problem specific to e.164 addresses. g-) Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B4srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greger,
 
Please see my last email in response to Penn and let = me know=20 if it helps.
 
Regards,
 
Daryl

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Greger Viken=20 Teigre
Sent: Wednesday, March 03, 2010 12:16 AM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

On 02.03.2010 20:24, PFAUTZ, PENN L (ATTCORP) wrote:=20

Daryl:

I=20 want to be sure I understand what you’re proposing.  In what n= ame server=20 would the modified records be? One local to SSP1 or some general industry= DNS?=20 I’m trying to understand how SSP1 modifies an RR for an SSP2=20 number.


A few follow-up questions to tha= t. I'm=20 a bit confused about the problem that you are trying to solve.

From = the=20 draft it looks like the name server is local to SSP1. If that is correct, w= hy=20 would you like to standardize how you acquire routing information? If both = the=20 proxy and the name server are local to SSP1, I don't see why you need to=20 standardize the data retrieval interface in a SIP context?  We already= have=20 a few of those.  And there must surely be more efficient ways of stori= ng=20 and retrieving such information?!
However, if the intention is primarily= to=20 be a standard for UAs to implement to avoid a ("static") proxy for determin= ing=20 routing path (i.e. a per session outbound proxy), we should surely look at = a=20 more generic approach to determining the outbound proxy?!  I thought=20 dynamic routing was one of the reasons for having an outbound proxy and cho= osing=20 an egress proxy is hardly a problem specific to e.164 addresses.
g-)
=

Thanks,

Penn=20 Pfautz

AT&T=20 Access Management

+1-732-420-4962

From: dispatch-bounces@ietf.org [= mailto:dispatch-bounces@ietf.or= g]=20 On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:= 51=20 PM
To: 'dispatch@ietf.org'
Subject:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

All,<= O:P>

A New=20 Internet-Draft is available from the on-line Internet-Drafts directories.= =20
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Mal= as=20
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 1= 1=20
Date : 2010-03-01
 
In some cases a UA (or proxy) within = a=20 Session Initiation Protocol
[RFC3261] Service Provider (SSP) has mult= iple=20 parallel egress proxy
options to reach an ingress proxy within anothe= r SSP=20 to reach the
target UA. If the originating SSP uses ENUM to identify = the=20 ingress
proxy of the target SSP, there is currently no way for the EN= UM=20 NAPTR
response to identify a specific preferred egress proxy from the= set=20
of multiple parallel proxies. This draft solves this problem by=20
defining a method for returning deterministic routing information=20
within an ENUM NAPTR response enabling the UA (or proxy) to choose a= =20
preferred egress proxy. Using this information, the originating UA now=20 sends the SIP request through the predetermined preferred egress
prox= y to=20 reach the target SSP's proxy. This document describes
several methods= to=20 make this determination by incorporating variables
into a SIP service= URI=20 contained in the E.164 Number Mapping (ENUM)
response.
 
= A URL=20 for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-= dispatch-sip-egress-route-00.txt=20

Regards,

Daryl=

------------= ---------------

Daryl=20 Malas

Project Dire= ctor,=20 IP Interconnects

w - +1 303 6= 61=20 3302

mailto:d.malas@cablelabs.com


_______________________________________________
dispatch mailing list
dispa=
tch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B4srvxchg_-- From D.Malas@cablelabs.com Wed Mar 3 08:31:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C1A3A8676 for ; Wed, 3 Mar 2010 08:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpCTEwdLEMXH for ; Wed, 3 Mar 2010 08:31:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 077033A8B18 for ; Wed, 3 Mar 2010 08:31:34 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23GVYOs021852; Wed, 3 Mar 2010 09:31:34 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 09:31:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 09:31:34 -0700 From: Daryl Malas To: "'PFAUTZ, PENN L (ATTCORP)'" , "dispatch@ietf.org" Date: Wed, 3 Mar 2010 09:31:34 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAO83sA== Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:31:43 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Penn, Just to continue my thought a bit further, the UI associated with adding an= d managing the "egress route" is out of scope of this draft. The purpose o= f this draft is to define a standard approach for first, defining what the = egress route should look like and then how it should be conveyed in the NAP= TR. Regards, Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Wednesday, March 03, 2010 9:22 AM To: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, The use case for this application is SSP1 (or someone on their behalf) prov= isions their numbers and relative routes into the LUF associated with their= federation. SSP2 reviews SSP1's "routes" available to them in the LUF bas= ed on what SSP1 provisioned. They then add an egress route and associate i= t with the ingress route SSP1 provisioned. Let me know if this makes sense. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Penn,
 
Just to continue my thought a bit further, the U= I=20 associated with adding and managing the "egress route" is out of scope of t= his=20 draft.  The purpose of this draft is to define a standard approach for= =20 first, defining what the egress route should look like and then how it shou= ld be=20 conveyed in the NAPTR.
 
Regards,
 
Daryl

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl=20 Malas
Sent: Wednesday, March 03, 2010 9:22 AM
To: 'PFAU= TZ,=20 PENN L (ATTCORP)'; dispatch@ietf.org
Subject: Re: [dispatch] I-D= =20 Action: draft-malas-dispatch-sip-egress-route-00

Penn,
 
The use case for this application is SSP1 (or someone= on their=20 behalf) provisions their numbers and relative routes into the LUF=20 associated with their federation.  SSP2 reviews SSP1's "routes"=20 available to them in the LUF based on what SSP1 provisioned.  They the= n add=20 an egress route and associate it with the ingress route SSP1=20 provisioned.
 
Let me know if this makes sense.
 
Regards,
 
Daryl

From: PFAUTZ, PENN L (ATTCORP)=20 [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24=20 PM
To: Daryl Malas; dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl:

I=20 want to be sure I understand what you’re proposing.  In what nam= e server=20 would the modified records be? One local to SSP1 or some general industry D= NS?=20 I’m trying to understand how SSP1 modifies an RR for an SSP2=20 number.

 

Thanks,

 

From:<= /B>=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To:=20 'dispatch@ietf.org'
Subject: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet= -Draft=20 is available from the on-line Internet-Drafts directories.
 
Ti= tle :=20 SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20

 

Regards,

 

Daryl

 

--------------= -------------

Daryl=20 Malas

Project Direct= or, IP=20 Interconnects

w - +1 303 661= =20 3302

mailto:d.malas@cablelabs.com=

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5srvxchg_-- From adam@nostrum.com Wed Mar 3 08:41:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12893A8B59 for ; Wed, 3 Mar 2010 08:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7B6Fc71Xz1p for ; Wed, 3 Mar 2010 08:41:24 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 566223A7851 for ; Wed, 3 Mar 2010 08:41:22 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o23GfIaf027070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 10:41:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8E912D.8060908@nostrum.com> Date: Wed, 03 Mar 2010 10:41:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Daryl Malas References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5@srvxchg> Content-Type: multipart/alternative; boundary="------------020508070302030909010806" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:41:24 -0000 This is a multi-part message in MIME format. --------------020508070302030909010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/3/10 10:31 AM, Daryl Malas wrote: > Just to continue my thought a bit further, the UI associated with > adding and managing the "egress route" is out of scope of this draft. > The purpose of this draft is to define a standard approach for first, > defining what the egress route should look like and then how it should > be conveyed in the NAPTR. > And, to be clear, what I read in this document (if we discard the third alternative that it discusses but clearly does not favor) is of the nature of a BCP, not a standard. The first two alternatives don't actually change existing protocols or propose any new protocols -- they show how existing protocols can be used to achieve the stated goal. It looks like more of a clever, "hey, guys, I figured out a way to scratch an itch I had, and here's how I did it" kind of thing. I believe it would be useful to publish in that context. /a --------------020508070302030909010806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/3/10 10:31 AM, Daryl Malas wrote:
Just to continue my thought a bit further, the UI associated with adding and managing the "egress route" is out of scope of this draft.  The purpose of this draft is to define a standard approach for first, defining what the egress route should look like and then how it should be conveyed in the NAPTR.


And, to be clear, what I read in this document (if we discard the third alternative that it discusses but clearly does not favor) is of the nature of a BCP, not a standard. The first two alternatives don't actually change existing protocols or propose any new protocols -- they show how existing protocols can be used to achieve the stated goal.

It looks like more of a clever, "hey, guys, I figured out a way to scratch an itch I had, and here's how I did it" kind of thing. I believe it would be useful to publish in that context.

/a
--------------020508070302030909010806-- From D.Malas@cablelabs.com Wed Mar 3 08:48:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D21528C0D6 for ; Wed, 3 Mar 2010 08:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJi7hfVRUUy1 for ; Wed, 3 Mar 2010 08:48:31 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id F0AB13A8405 for ; Wed, 3 Mar 2010 08:48:30 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23GmV89025024; Wed, 3 Mar 2010 09:48:31 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 09:48:31 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 09:48:31 -0700 From: Daryl Malas To: "'Dean Willis'" Date: Wed, 3 Mar 2010 09:48:30 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq6Nz5LhcH56b/tQ2OIafjIH6NNSgAuBxMw Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> In-Reply-To: <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8srvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:48:32 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dean, I don't agree with your map analogy. Every hop along the way in the draft = example does not require a new look-up. The single ENUM response provides = all of the information necessary to reach the target. It just includes "ne= xt hop" information to provide more intelligent routing. The final target = information is still contained in the single response. Perhaps the reason E= NUM may be a little different is based on the application associated with t= he NAPTR. SIP is an intelligent application with the ability to receive de= tailed information to reach the target UA. The draft just leverages the SI= P service NAPTR to provide the SIP application with more of this detailed i= nformation. This way information does not need to be stored and managed in= many different locations. Regards, Daryl ________________________________ From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, March 02, 2010 11:36 AM To: Daryl Malas Cc: 'dispatch@ietf.org' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote: All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 The universe has apparently shifted beneath my feet again. When did DNS (an= d ENUM is just DNS, or maybe a private-root DNS depending on what you belie= ve) become a legitimate repository for intermediary routing information? Let's take the scenario from the draft: +=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+ || || SSP1 Network +--------+ || SSP2 Network ssp1.example.com | | || ssp2.example.com +--->| SBE1 |---+ || | | | | || | +--------+ | || | || | || | || | || +-------+ | || | +--------+ +-------+ | |---+ || +---->| |---->| | | Proxy | || | SBE3 | | Proxy | | |---+ || +---->| |---->| | +-------+ | || | +--------+ +-------+ | || | || | || | || | +--------+ | || | | | | || +--->| SBE2 |---+ || | | || +--------+ || || || +=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+ Here's the scenario recast in a "more traditional" terminology: SSP2 has externally advertised (at least to SSP1) that SBE3 is a (or "the")= route to the address space of SSP2. Both SBE1 and SBE2 have been informed = of this advertisement. Presumably there's a route in the other direction as= well, although that's out of scope for the example. SSP1 wishes to advertise, within the administrative domain of SSP1, two rou= tes to the address space of SSP2. The preferred route is through SBE2, with= a secondary route through SBE1, although nothing has been said about the l= oad-metric so we assume the policy use "Use SBE1 only if SBE2 isn't respond= ing". Explain to me why ANY of this routing/reachability information should be in= DNS or a DNS-like static map? That's just absurd! We appear to going thro= ugh some extreme convolutions to twist a dynamic routing problem (that shou= ld be dealt with by protocols more like BGP and OSPF) into a name-service p= roblem. I think it's time for a complete re-think of what's going on here. ENUM is NOT a routing protocol. It's a distributed database for mapping nam= es to addresses and for looking up related information about names, where t= he associations involved are relatively long-lived (and for the most part e= ffectively static). There's a reason we don't have every Internet router do a DNS lookup on a r= equest-destination and use that lookup result to select a next-hop route. W= e COULD do this, it just requires having lots and lots of DNS servers confi= gured with alt-root structures that reflect local routing tables, and that = get continuously reprovisioned to reflect changes in network topology, load= , and policy. We COULD do this -- why don't we? The answer is that doing = this would be deeply, profoundly, and astoundingly inefficient. It's just t= he wrong way to solve the problem. It's sort of like trying to print highwa= y maps that, rather than showing the road to follow to reach a destination,= only show the next exit or turn and therefore one needs an entirely differ= ent map for each possible place that one might currently be standing. Sure,= it makes for a big business in maintaining and printing maps, but it makes= actually getting anywhere profoundly painful and expensive. So why on earth are we attempting to use the same pattern for routing phone= calls? Is it just a matter of ENUM being the only hammer we were given to= play with? Folks, we can get a different tool if we need one; we don't nee= d to keep beating on the plumbing with the ENUM hammer when what we really = need is a pipe-threader or bender. -- Dean --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dean,
 
I don't agree with your map analogy.  Every= hop=20 along the way in the draft example does not require a new look-up.  Th= e=20 single ENUM response provides all of the information necessary to reach the= =20 target.  It just includes "next hop" information to provide more=20 intelligent routing.  The final target information is still contained = in=20 the single response. Perhaps the reason ENUM may be a little different is b= ased=20 on the application associated with the NAPTR.  SIP is an intelligent=20 application with the ability to receive detailed information to reach the t= arget=20 UA.  The draft just leverages the SIP service NAPTR to provide the SIP= =20 application with more of this detailed information.  This way informat= ion=20 does not need to be stored and managed in many different=20 locations.
 
Regards,
 
Daryl

From: Dean Willis=20 [mailto:dean.willis@softarmor.com]
Sent: Tuesday, March 02, 2010= =20 11:36 AM
To: Daryl Malas
Cc:=20 'dispatch@ietf.org'
Subject: Re: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00


On Mar 1, 2010, at 5:50 PM, Daryl Malas wrote:
All,
 
A New Internet-Draft is available from t= he=20 on-line Internet-Drafts directories.
 
Title : SIP Egress Rou= te=20 Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 

The universe has apparently shifted beneath my feet again. When did DN= S=20 (and ENUM is just DNS, or maybe a private-root DNS depending on what you=20 believe) become a legitimate repository for intermediary routing=20 information? 


Let's take the scenario from the draft:

   +=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+
                         ||                 ||
       SSP1 Network  +--------+             ||       SSP2 Network
   ssp1.example.com  |        |             ||   ssp2.example.com
                +--->|  SBE1  |---+         ||
                |    |        |   |         ||
                |    +--------+   |         ||
                |        ||       |         ||
                |        ||       |         ||
    +-------+   |        ||       |     +--------+     +-------+
    |       |---+        ||       +---->|        |---->|       |
    | Proxy |            ||             |  SBE3  |     | Proxy |
    |       |---+        ||       +---->|        |---->|       |
    +-------+   |        ||       |     +--------+     +-------+
                |        ||       |         ||
                |        ||       |         ||
                |    +--------+   |         ||
                |    |        |   |         ||
                +--->|  SBE2  |---+         ||
                     |        |             ||
                     +--------+             ||
                         ||                 ||
   +=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+<=
/PRE>


Here's the scenario recast in a "more traditional" terminology:

SSP2 has externally advertised (at least to SSP1) that SBE3 is a (or "= the")=20 route to the address space of SSP2. Both SBE1 and SBE2 have been informed o= f=20 this advertisement. Presumably there's a route in the other direction as we= ll,=20 although that's out of scope for the example.

SSP1 wishes to advertise, within the administrative domain of SSP1, tw= o=20 routes to the address space of SSP2. The preferred route is through SBE2, w= ith a=20 secondary route through SBE1, although nothing has been said about the=20 load-metric so we assume the policy use "Use SBE1 only if SBE2 isn't=20 responding".

Explain to me why ANY of this routing/reachability information should = be in=20 DNS or a DNS-like static map? That's just absurd! We appear to  going= =20 through some extreme convolutions to twist a dynamic routing problem (that= =20 should be dealt with by protocols more like BGP and OSPF) into a name-servi= ce=20 problem.

I think it's time for a complete re-think of what's going on here.

ENUM is NOT a routing protocol. It's a distributed database for mappin= g=20 names to addresses and for looking up related information about names, wher= e the=20 associations involved are relatively long-lived (and for the most part=20 effectively static).

There's a reason we don't have every Internet router do a DNS lookup o= n a=20 request-destination and use that lookup result to select a next-hop route. = We=20 COULD do this, it just requires having lots and lots of DNS servers configu= red=20 with alt-root structures that reflect local routing tables, and that get=20 continuously reprovisioned to reflect changes in network topology, load, an= d=20 policy.  We COULD do this -- why don't we?  The answer is th= at=20 doing this would be deeply, profoundly, and astoundingly inefficient. It's = just=20 the wrong way to solve the problem. It's sort of like trying to print highw= ay=20 maps that, rather than showing the road to follow to reach a destination, o= nly=20 show the next exit or turn and therefore one needs an entirely different ma= p for=20 each possible place that one might currently be standing. Sure, it makes fo= r a=20 big business in maintaining and printing maps, but it makes actually gettin= g=20 anywhere profoundly painful and expensive.

So why on earth are we attempting to use the same pattern for routing = phone=20 calls?  Is it just a matter of ENUM being the only hammer we were give= n to=20 play with? Folks, we can get a different tool if we need one; we don't need= to=20 keep beating on the plumbing with the ENUM hammer when what we really need = is a=20 pipe-threader or bender.

--
Dean
--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8srvxchg_-- From D.Malas@cablelabs.com Wed Mar 3 08:51:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77C428C151 for ; Wed, 3 Mar 2010 08:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB9qnDyXf9ay for ; Wed, 3 Mar 2010 08:51:12 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id D60763A8B8F for ; Wed, 3 Mar 2010 08:51:11 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23GpBRZ025515; Wed, 3 Mar 2010 09:51:11 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 09:51:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 09:51:11 -0700 From: Daryl Malas To: "'Adam Roach'" Date: Wed, 3 Mar 2010 09:51:11 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq68Fwzr3Jcc4RMSEaERoinxVfW+QAAT5KA Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B9@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B5@srvxchg> <4B8E912D.8060908@nostrum.com> In-Reply-To: <4B8E912D.8060908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B9srvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:51:12 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B9srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, You "hit the nail on the head." This is the exact intension of this draft. --Daryl ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Wednesday, March 03, 2010 9:41 AM To: Daryl Malas Cc: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On 3/3/10 10:31 AM, Daryl Malas wrote: Just to continue my thought a bit further, the UI associated with adding an= d managing the "egress route" is out of scope of this draft. The purpose o= f this draft is to define a standard approach for first, defining what the = egress route should look like and then how it should be conveyed in the NAP= TR. And, to be clear, what I read in this document (if we discard the third alt= ernative that it discusses but clearly does not favor) is of the nature of = a BCP, not a standard. The first two alternatives don't actually change exi= sting protocols or propose any new protocols -- they show how existing prot= ocols can be used to achieve the stated goal. It looks like more of a clever, "hey, guys, I figured out a way to scratch = an itch I had, and here's how I did it" kind of thing. I believe it would b= e useful to publish in that context. /a --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B9srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adam,
 
You "hit the nail on the head."  This is the exa= ct=20 intension of this draft.
 
--Daryl

From: Adam Roach [mailto:adam@nostrum.c= om]=20
Sent: Wednesday, March 03, 2010 9:41 AM
To: Daryl=20 Malas
Cc: 'PFAUTZ, PENN L (ATTCORP)';=20 dispatch@ietf.org
Subject: Re: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

On 3/3/10 10:31 AM, Daryl Malas wrote:=20
<= SPAN=20 class=3D765003016-03032010>Just to continue my thought a bit further, the= UI=20 associated with adding and managing the "egress route" is out of scope of= this=20 draft.  The purpose of this draft is to define a standard approach f= or=20 first, defining what the egress route should look like and then how it sh= ould=20 be conveyed in the NAPTR.


And, to= be=20 clear, what I read in this document (if we discard the third alternative th= at it=20 discusses but clearly does not favor) is of the nature of a BCP, not a stan= dard.=20 The first two alternatives don't actually change existing protocols or prop= ose=20 any new protocols -- they show how existing protocols can be used to achiev= e the=20 stated goal.

It looks like more of a clever, "hey, guys, I figured o= ut a=20 way to scratch an itch I had, and here's how I did it" kind of thing. I bel= ieve=20 it would be useful to publish in that context.

/a
--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66B9srvxchg_-- From pp3129@att.com Wed Mar 3 09:37:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9673A8C9A for ; Wed, 3 Mar 2010 09:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8mXLjKtBuP4 for ; Wed, 3 Mar 2010 09:37:39 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 914413A8C8F for ; Wed, 3 Mar 2010 09:37:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1267637859!24263168!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 1080 invoked from network); 3 Mar 2010 17:37:40 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Mar 2010 17:37:40 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23HbTpn003579 for ; Wed, 3 Mar 2010 12:37:29 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23HbPGZ003554 for ; Wed, 3 Mar 2010 12:37:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABAF8.35EBE805" Date: Wed, 3 Mar 2010 12:37:31 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkA== References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Daryl Malas" , Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:37:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABAF8.35EBE805 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daryl=20 I was a little confused by this since I thought the call was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local copy I can see that but I wouldn't expect the resulting elaborated NAPTRs to be in the Registry.=20 Have I got this right now? =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 The use case for this application is SSP1 (or someone on their behalf) provisions their numbers and relative routes into the LUF associated with their federation. SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned. They then add an egress route and associate it with the ingress route SSP1 provisioned. =20 Let me know if this makes sense. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl: I want to be sure I understand what you're proposing. In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. =20 Thanks, =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 All, =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : SIP Egress Route Use in ENUM=20 Author(s) : D. Malas=20 Filename : draft-malas-dispatch-sip-egress-route-00.txt=20 Pages : 11=20 Date : 2010-03-01=20 =20 In some cases a UA (or proxy) within a Session Initiation Protocol=20 [RFC3261] Service Provider (SSP) has multiple parallel egress proxy=20 options to reach an ingress proxy within another SSP to reach the=20 target UA. If the originating SSP uses ENUM to identify the ingress=20 proxy of the target SSP, there is currently no way for the ENUM NAPTR=20 response to identify a specific preferred egress proxy from the set=20 of multiple parallel proxies. This draft solves this problem by=20 defining a method for returning deterministic routing information=20 within an ENUM NAPTR response enabling the UA (or proxy) to choose a=20 preferred egress proxy. Using this information, the originating UA=20 now sends the SIP request through the predetermined preferred egress=20 proxy to reach the target SSP's proxy. This document describes=20 several methods to make this determination by incorporating variables=20 into a SIP service URI contained in the E.164 Number Mapping (ENUM)=20 response.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout e-00.txt=20 =20 Regards, =20 Daryl =20 --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com =20 =20 ------_=_NextPart_001_01CABAF8.35EBE805 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daryl

I was a little confused by this since I thought the call = was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the = registry. If SSP1 get the SSP2 data and wants to add their egress routes in their = local copy I can see that but I wouldn’t expect the resulting elaborated = NAPTRs to be in the Registry.

Have I got this right now?

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 11:22 AM
To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

The use case for this application is SSP1 (or someone on = their behalf) provisions their numbers and relative routes into the LUF associated with their federation.  SSP2 reviews SSP1's = "routes" available to them in the LUF based on what SSP1 provisioned.  They = then add an egress route and associate it with the ingress route SSP1 = provisioned.

 

Let me know if this makes sense.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24 PM
To: Daryl Malas; dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Daryl:

I want to be sure I understand what you’re = proposing.  In what name server would the modified records be? One local to SSP1 or = some general industry DNS? I’m trying to understand how SSP1 modifies = an RR for an SSP2 number.

 

Thanks,

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: 'dispatch@ietf.org'
Subject: [dispatch] I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR =
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a =
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress =
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables =
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch= -sip-egress-route-00.txt

 

Regards,

 

Daryl<= o:p>

 

-------------= --------------

Daryl Malas

Project Director, IP Interconnects

w - +1 303 661 3302

 

------_=_NextPart_001_01CABAF8.35EBE805-- From D.Malas@cablelabs.com Wed Mar 3 10:01:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39423A8BD4 for ; Wed, 3 Mar 2010 10:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBJu-Cd2FYiB for ; Wed, 3 Mar 2010 10:01:22 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id E131B28C447 for ; Wed, 3 Mar 2010 10:01:05 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o23I15ad003358; Wed, 3 Mar 2010 11:01:05 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 11:01:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 11:01:05 -0700 From: Daryl Malas To: "'PFAUTZ, PENN L (ATTCORP)'" , "dispatch@ietf.org" Date: Wed, 3 Mar 2010 11:01:04 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPw Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66BDsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 18:01:28 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66BDsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Penn, I think what you're describing is leaning towards implementation specific q= uestions. I apologize, my example below is backwards, but the principle is= the same. SSP2 provisions their numbers and "routes" into the ENUM server= . SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify= their own egress routes in the same ENUM server. The method for SSP1's egress routes for SSP2 to be received into a "local c= opy" is implementation specific, imo. This being said, obviously, SSP3 and= SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 whe= n they query the ENUM server. If this is resolved in some "for queries fro= m here give this" or "here is a local copy of peer numbers and routes plus = *your* egress routes" is implementation specific. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl I was a little confused by this since I thought the call was from SSP1 to S= SP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get th= e SSP2 data and wants to add their egress routes in their local copy I can = see that but I wouldn't expect the resulting elaborated NAPTRs to be in the= Registry. Have I got this right now? Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, The use case for this application is SSP1 (or someone on their behalf) prov= isions their numbers and relative routes into the LUF associated with their= federation. SSP2 reviews SSP1's "routes" available to them in the LUF bas= ed on what SSP1 provisioned. They then add an egress route and associate i= t with the ingress route SSP1 provisioned. Let me know if this makes sense. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66BDsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Penn,
 
I think what you're describing is leaning towards=20 implementation specific questions.  I apologize, my example below is=20 backwards, but the principle is the same.  SSP2 provisions their numbe= rs=20 and "routes" into the ENUM server.  SSP1 can see the ingress routes fo= r=20 SSP2 numbers.  SSP1 can then specify their own egress routes in the sa= me=20 ENUM server.
 
The method for SSP1's egress routes for SSP2&nbs= p;to=20 be received into a "local copy" is implementation specific, imo. = This=20 being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisi= oned=20 egress routes for SSP2 when they query the ENUM server.  If this is=20 resolved in some "for queries from here give this" or "here is a local copy= of=20 peer numbers and routes plus *your* egress routes" is implementation=20 specific.
 
Regards,
 
Daryl

From: PFAUTZ, PENN L (ATTCORP)=20 [mailto:pp3129@att.com]
Sent: Wednesday, March 03, 2010 10:38=20 AM
To: Daryl Malas; dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl=20

I=20 was a little confused by this since I thought the call was from SSP1 to SSP= 2 and=20 that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 d= ata=20 and wants to add their egress routes in their local copy I can see that but= I=20 wouldn’t expect the resulting elaborated NAPTRs to be in the Registry= .=20

Have=20 I got this right now?

 

From:<= /B> Daryl Malas= =20 [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 1= 1:22=20 AM
To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org
Subject:= =20 RE: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

 

P= enn,

 

T= he use=20 case for this application is SSP1 (or someone on their behalf) provisions t= heir=20 numbers and relative routes into the LUF associated with their=20 federation.  SSP2 reviews SSP1's "routes" available to them in th= e LUF=20 based on what SSP1 provisioned.  They then add an egress route and=20 associate it with the ingress route SSP1 provisioned.

 

L= et me=20 know if this makes sense.

 

R= egards,

 

D= aryl

 

From:<= /B> PFAUTZ, PENN= L=20 (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 = 12:24=20 PM
To: Daryl Malas; dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl:

I=20 want to be sure I understand what you’re proposing.  In what nam= e server=20 would the modified records be? One local to SSP1 or some general industry D= NS?=20 I’m trying to understand how SSP1 modifies an RR for an SSP2=20 number.

 

Thanks,

 

From:<= /B>=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To:=20 'dispatch@ietf.org'
Subject: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet= -Draft=20 is available from the on-line Internet-Drafts directories.
 
Ti= tle :=20 SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20

 

Regards,

 

Daryl

 

--------------= -------------

Daryl=20 Malas

Project Direct= or, IP=20 Interconnects

w - +1 303 661= =20 3302

mailto:d.malas@cablelabs.com=

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66BDsrvxchg_-- From pp3129@att.com Wed Mar 3 10:11:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F6128C1DC for ; Wed, 3 Mar 2010 10:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TCZu6N9Y6Ha for ; Wed, 3 Mar 2010 10:11:20 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 3122828C18D for ; Wed, 3 Mar 2010 10:11:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-6.tower-167.messagelabs.com!1267639879!10896264!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31167 invoked from network); 3 Mar 2010 18:11:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Mar 2010 18:11:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23IB9oA028692 for ; Wed, 3 Mar 2010 13:11:09 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23IB4fu028564 for ; Wed, 3 Mar 2010 13:11:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABAFC.E92A4A71" Date: Wed, 3 Mar 2010 13:11:08 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0374F62C@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPwAAC5ttA= References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Daryl Malas" , Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 18:11:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABAFC.E92A4A71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daryl: Thanks. I now understand what you're after and it is just the implementation questions that concern me. It might be useful to make clear you're not proposing any specific implementation. For example, in a different context (drinks) if it were proposed to support building these kinds of records in the registry as opposed to the SSP1 network I'd probably be agin it. =20 Thanks for the clarification =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 1:01 PM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 I think what you're describing is leaning towards implementation specific questions. I apologize, my example below is backwards, but the principle is the same. SSP2 provisions their numbers and "routes" into the ENUM server. SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify their own egress routes in the same ENUM server. =20 The method for SSP1's egress routes for SSP2 to be received into a "local copy" is implementation specific, imo. This being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when they query the ENUM server. If this is resolved in some "for queries from here give this" or "here is a local copy of peer numbers and routes plus *your* egress routes" is implementation specific. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl=20 I was a little confused by this since I thought the call was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local copy I can see that but I wouldn't expect the resulting elaborated NAPTRs to be in the Registry.=20 Have I got this right now? =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 The use case for this application is SSP1 (or someone on their behalf) provisions their numbers and relative routes into the LUF associated with their federation. SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned. They then add an egress route and associate it with the ingress route SSP1 provisioned. =20 Let me know if this makes sense. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl: I want to be sure I understand what you're proposing. In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. =20 Thanks, =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 All, =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : SIP Egress Route Use in ENUM=20 Author(s) : D. Malas=20 Filename : draft-malas-dispatch-sip-egress-route-00.txt=20 Pages : 11=20 Date : 2010-03-01=20 =20 In some cases a UA (or proxy) within a Session Initiation Protocol=20 [RFC3261] Service Provider (SSP) has multiple parallel egress proxy=20 options to reach an ingress proxy within another SSP to reach the=20 target UA. If the originating SSP uses ENUM to identify the ingress=20 proxy of the target SSP, there is currently no way for the ENUM NAPTR=20 response to identify a specific preferred egress proxy from the set=20 of multiple parallel proxies. This draft solves this problem by=20 defining a method for returning deterministic routing information=20 within an ENUM NAPTR response enabling the UA (or proxy) to choose a=20 preferred egress proxy. Using this information, the originating UA=20 now sends the SIP request through the predetermined preferred egress=20 proxy to reach the target SSP's proxy. This document describes=20 several methods to make this determination by incorporating variables=20 into a SIP service URI contained in the E.164 Number Mapping (ENUM)=20 response.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout e-00.txt=20 =20 Regards, =20 Daryl =20 --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com =20 =20 ------_=_NextPart_001_01CABAFC.E92A4A71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daryl:

Thanks. I now understand what you’re after and it = is just the implementation questions that concern me.  It might be useful to = make clear you’re not proposing any specific = implementation.

For example, in a different context (drinks) if it were = proposed to support building these kinds of records in the registry as opposed to = the SSP1 network  I’d probably be agin it.

 

Thanks for the clarification

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 1:01 PM
To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

I think what you're describing is leaning towards = implementation specific questions.  I apologize, my example below is backwards, = but the principle is the same.  SSP2 provisions their numbers and = "routes" into the ENUM server.  SSP1 can see the ingress routes for SSP2 numbers.  SSP1 can then specify their own egress routes in the same = ENUM server.

 

The method for SSP1's egress routes for SSP2 to be received into a "local copy" is implementation = specific, imo.  This being said, obviously, SSP3 and SSP4 would not (want to) = see SSP1's provisioned egress routes for SSP2 when they query the ENUM server.  If this is resolved in some "for queries from here = give this" or "here is a local copy of peer numbers and routes plus = *your* egress routes" is implementation specific.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Wednesday, March 03, 2010 10:38 AM
To: Daryl Malas; dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Daryl

I was a little confused by this since I thought the call = was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the = registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local = copy I can see that but I wouldn’t expect the resulting elaborated NAPTRs = to be in the Registry.

Have I got this right now?

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 11:22 AM
To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

The use case for this application is SSP1 (or someone on = their behalf) provisions their numbers and relative routes into the LUF associated with their federation.  SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned.  They then add an egress route and associate it with = the ingress route SSP1 provisioned.

 

Let me know if this makes sense.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24 PM
To: Daryl Malas; dispatch@ietf.org
Subject: RE: [dispatch] I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl:

I want to be sure I understand what you’re proposing.  In what name server would the modified records be? One = local to SSP1 or some general industry DNS? I’m trying to understand how = SSP1 modifies an RR for an SSP2 number.

 

Thanks,

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: 'dispatch@ietf.org'
Subject: [dispatch] I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR =
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a =
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress =
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables =
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch= -sip-egress-route-00.txt

 

Regards,

 

Daryl<= o:p>

 

-------------= --------------

Daryl Malas

Project Director, IP Interconnects

w - +1 303 661 3302

 

------_=_NextPart_001_01CABAFC.E92A4A71-- From dean.willis@softarmor.com Wed Mar 3 11:26:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AD23A8E03 for ; Wed, 3 Mar 2010 11:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p15TXh6HkXFK for ; Wed, 3 Mar 2010 11:26:29 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7ED2028C43C for ; Wed, 3 Mar 2010 11:26:28 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o23JQRrT004737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 13:26:28 -0600 Message-Id: From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> Content-Type: multipart/alternative; boundary=Apple-Mail-2--573110561 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 13:26:21 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 19:26:33 -0000 --Apple-Mail-2--573110561 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 3, 2010, at 10:48 AM, Daryl Malas wrote: > Dean, > > I don't agree with your map analogy. Every hop along the way in the > draft example does not require a new look-up. The single ENUM > response provides all of the information necessary to reach the > target. It just includes "next hop" information to provide more > intelligent routing. The final target information is still > contained in the single response. Perhaps the reason ENUM may be a > little different is based on the application associated with the > NAPTR. SIP is an intelligent application with the ability to > receive detailed information to reach the target UA. The draft just > leverages the SIP service NAPTR to provide the SIP application with > more of this detailed information. This way information does not > need to be stored and managed in many different locations. > But the "egress route" returned by the ENUM lookup is dependent on where the lookup is happening, right? This means lots of different ENUM databases that return different values for queries on the same key. This is the exact antithesis of the scalability model of DNS, which is predicated on universally-valid results that allow dissemination through recursive lookups and caching. If each of SSP1 and SSP2 interconnects with SSP3, the "egress route" from SSP1 to SSP3 is NOT the same as the route from SSP2 to SSP3. So the ENUM database seen by nodes at SSP1 returns different values from the ENUM database seen by nodes at SSP2, which is different yet again for nodes at SSP3. This means that for the "SSP3" key, at least two different context-dependent values are being stored in the databases. It's just not how DNS was designed to distribute. Yeah, it sort of works if you assume lots of independently provisioned databases, but it's still an operational nightmare and all you're getting out of ENUM is a standardized database format. You have here a very real problem that is exactly analogous to the IP- level route-peering problem. Many years of working this problem at the IP level have shown that statically provisioned databases (aka DNS) are NOT an effective way to solve the problem at a large scale. DNS provides a nice mechanism for turning a name (or phone number) into a target IP address, but a lousy mechanism for telling us each of the intermediate hops needed to get from a source IP address to a target IP address (which is a vector of the router in between the two addresses). We really need a SIP-targeted analog of the BGP/OSPF route-exchange protocols to solve the general problem. -- Dean --Apple-Mail-2--573110561 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 3, 2010, = at 10:48 AM, Daryl Malas wrote:

Dean,
 
I don't agree with your map analogy.  = Every hop along the way in the draft example does not require a new = look-up.  The single ENUM response provides all of the information = necessary to reach the target.  It just includes "next hop" = information to provide more intelligent routing.  The final target = information is still contained in the single response. Perhaps the = reason ENUM may be a little different is based on the application = associated with the NAPTR.  SIP is an intelligent application with = the ability to receive detailed information to reach the target = UA.  The draft just leverages the SIP service NAPTR to provide the = SIP application with more of this detailed information.  This way = information does not need to be stored and managed in many different = locations.
 
=

But the "egress route" = returned by the ENUM lookup is dependent on where the lookup is = happening, right? This means lots of different ENUM databases that = return different values for queries on the same key. This is the exact = antithesis of the scalability model of DNS, which is predicated on = universally-valid results that allow dissemination through recursive = lookups and caching.

If each of SSP1 and SSP2 = interconnects with SSP3, the "egress route" from SSP1 to SSP3 is NOT the = same as the route from SSP2 to SSP3.

So the = ENUM database seen by nodes at SSP1 returns different values from the = ENUM database seen by nodes at SSP2, which is different yet again for = nodes at SSP3. This means that for the "SSP3" key, at least two = different context-dependent values are being stored in the databases. = It's just not how DNS was designed to distribute. Yeah, it sort of works = if you assume lots of independently provisioned databases, but it's = still an operational nightmare and all you're getting out of ENUM is a = standardized database format.

You have here a = very real problem that is exactly analogous to the IP-level = route-peering problem. Many years of working this problem at the IP = level have shown that statically provisioned databases (aka DNS) are NOT = an effective way to solve the problem at a large scale. DNS provides a = nice mechanism for turning a name (or phone number) into a target IP = address, but a lousy mechanism for telling us each of the intermediate = hops needed to get from a source IP address to a target IP address = (which is a vector of the router in between the two = addresses).

We really need a SIP-targeted = analog of the BGP/OSPF route-exchange protocols to solve the general = problem.

--
Dean





= --Apple-Mail-2--573110561-- From dean.willis@softarmor.com Wed Mar 3 11:30:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE5428C167 for ; Wed, 3 Mar 2010 11:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjCdxU8YmiPa for ; Wed, 3 Mar 2010 11:30:39 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5CEF728C1F5 for ; Wed, 3 Mar 2010 11:30:22 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o23JUIxx004783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 13:30:20 -0600 Message-Id: From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> Content-Type: multipart/alternative; boundary=Apple-Mail-3--572879359 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 13:30:12 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 19:30:43 -0000 --Apple-Mail-3--572879359 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 3, 2010, at 12:01 PM, Daryl Malas wrote: > > The method for SSP1's egress routes for SSP2 to be received into a > "local copy" is implementation specific, imo. This being said, > obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned > egress routes for SSP2 when they query the ENUM server. If this is > resolved in some "for queries from here give this" or "here is a > local copy of peer numbers and routes plus *your* egress routes" is > implementation specific. And this part right here is exactly why the DNS infrastructure of ENUM is NOT a good solution for the problem. Unlike Einstein, DNS does not embrace relativity (AKA location-context sensitivity). There are ugly hacks to make relativity happen in certain limited cases, but they defeat the fundamental scalability mechanisms of the DNS. -- Dean --Apple-Mail-3--572879359 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 3, 2010, = at 12:01 PM, Daryl Malas wrote:


The method for SSP1's egress routes for SSP2 to = be received into a "local copy" is implementation specific, = imo.  This being said, obviously, SSP3 and SSP4 would not (want to) = see SSP1's provisioned egress routes for SSP2 when they query the ENUM = server.  If this is resolved in some "for queries from here give = this" or "here is a local copy of peer numbers and routes plus *your* = egress routes" is implementation = specific.

And = this part right here is exactly why the DNS infrastructure of ENUM is = NOT a good solution for the problem. Unlike Einstein, DNS does not = embrace relativity (AKA location-context sensitivity). There are ugly = hacks to make relativity happen in certain limited cases, but they = defeat the fundamental scalability mechanisms of the = DNS.

--
Dean
= --Apple-Mail-3--572879359-- From pp3129@att.com Wed Mar 3 11:41:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8C628C485 for ; Wed, 3 Mar 2010 11:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db3Qv5YwLfKF for ; Wed, 3 Mar 2010 11:40:57 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id C2A9A28C475 for ; Wed, 3 Mar 2010 11:40:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-4.tower-167.messagelabs.com!1267645251!21981128!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17919 invoked from network); 3 Mar 2010 19:40:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Mar 2010 19:40:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23JecHg020716 for ; Wed, 3 Mar 2010 14:40:39 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o23JeWpR020508 for ; Wed, 3 Mar 2010 14:40:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABB09.685975B7" Date: Wed, 3 Mar 2010 14:40:40 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0374F6CF@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq7B3Xwq1Dr2XR1STyLzb3JJtub0QAAE5Zg References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg><564499D5-6303-4727-AD8C-996D182D9726@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> From: "PFAUTZ, PENN L (ATTCORP)" To: "Dean Willis" , "Daryl Malas" Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 19:41:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABB09.685975B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah, this is exactly why the GSMA chose to handle the problem by moving it to layer 3: The IPX carriers implement a private IP network through which connecting service providers advertise the IP addresses of their border elements via BGP. An ENUM lookup resolves to a common IP address for all querying parties but each SP associates the IP address with a route learned from their chosen IPX provider. This is, of course, just the basic Internet approach moved off the "public" Internet. It also works for bilateral direct connections and, in principle, should prefer such connections over a route through an IPX provider where both are available. =20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, March 03, 2010 2:26 PM To: Daryl Malas Cc: 'dispatch@ietf.org' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 =20 On Mar 3, 2010, at 10:48 AM, Daryl Malas wrote: Dean, =20 I don't agree with your map analogy. Every hop along the way in the draft example does not require a new look-up. The single ENUM response provides all of the information necessary to reach the target. It just includes "next hop" information to provide more intelligent routing. The final target information is still contained in the single response. Perhaps the reason ENUM may be a little different is based on the application associated with the NAPTR. SIP is an intelligent application with the ability to receive detailed information to reach the target UA. The draft just leverages the SIP service NAPTR to provide the SIP application with more of this detailed information. This way information does not need to be stored and managed in many different locations. =20 =20 But the "egress route" returned by the ENUM lookup is dependent on where the lookup is happening, right? This means lots of different ENUM databases that return different values for queries on the same key. This is the exact antithesis of the scalability model of DNS, which is predicated on universally-valid results that allow dissemination through recursive lookups and caching. =20 If each of SSP1 and SSP2 interconnects with SSP3, the "egress route" from SSP1 to SSP3 is NOT the same as the route from SSP2 to SSP3. =20 So the ENUM database seen by nodes at SSP1 returns different values from the ENUM database seen by nodes at SSP2, which is different yet again for nodes at SSP3. This means that for the "SSP3" key, at least two different context-dependent values are being stored in the databases. It's just not how DNS was designed to distribute. Yeah, it sort of works if you assume lots of independently provisioned databases, but it's still an operational nightmare and all you're getting out of ENUM is a standardized database format. =20 You have here a very real problem that is exactly analogous to the IP-level route-peering problem. Many years of working this problem at the IP level have shown that statically provisioned databases (aka DNS) are NOT an effective way to solve the problem at a large scale. DNS provides a nice mechanism for turning a name (or phone number) into a target IP address, but a lousy mechanism for telling us each of the intermediate hops needed to get from a source IP address to a target IP address (which is a vector of the router in between the two addresses). =20 We really need a SIP-targeted analog of the BGP/OSPF route-exchange protocols to solve the general problem. =20 -- Dean =20 =20 =20 =20 =20 ------_=_NextPart_001_01CABB09.685975B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ah, this is exactly why the GSMA chose to handle the = problem by moving it to layer 3:  The IPX carriers implement a private IP = network through which connecting service providers advertise the IP addresses of = their border elements via BGP. An ENUM lookup resolves to a common IP address = for all querying parties but each SP associates the IP address with a route = learned from their chosen IPX provider. This is, of course, just the basic = Internet approach moved off the “public” Internet. It also works for bilateral direct connections and, in principle, should prefer such = connections over a route through an IPX provider where both are available.  =

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Dean Willis
Sent: Wednesday, March 03, 2010 2:26 PM
To: Daryl Malas
Cc: 'dispatch@ietf.org'
Subject: Re: [dispatch] I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

 

On Mar 3, 2010, at 10:48 AM, Daryl Malas = wrote:



Dean,

 

I don't agree with your map analogy.  Every hop along = the way in the draft example does not require a new look-up.  The single = ENUM response provides all of the information necessary to reach the = target.  It just includes "next hop" information to provide more = intelligent routing.  The final target information is still contained in the = single response. Perhaps the reason ENUM may be a little different is based on = the application associated with the NAPTR.  SIP is an intelligent = application with the ability to receive detailed information to reach the target = UA.  The draft just leverages the SIP service NAPTR to provide the SIP = application with more of this detailed information.  This way information does = not need to be stored and managed in many different = locations.

 

 

But the "egress route" returned by the = ENUM lookup is dependent on where the lookup is happening, right? This means lots of different ENUM databases that return different values for queries on the = same key. This is the exact antithesis of the scalability model of DNS, which = is predicated on universally-valid results that allow dissemination through recursive = lookups and caching.

 

If each of SSP1 and SSP2 interconnects with SSP3, = the "egress route" from SSP1 to SSP3 is NOT the same as the route = from SSP2 to SSP3.

 

So the ENUM database seen by nodes at SSP1 returns = different values from the ENUM database seen by nodes at SSP2, which is different = yet again for nodes at SSP3. This means that for the "SSP3" key, = at least two different context-dependent values are being stored in the = databases. It's just not how DNS was designed to distribute. Yeah, it sort of works if = you assume lots of independently provisioned databases, but it's still an operational nightmare and all you're getting out of ENUM is a = standardized database format.

 

You have here a very real problem that is exactly = analogous to the IP-level route-peering problem. Many years of working this = problem at the IP level have shown that statically provisioned databases (aka DNS) = are NOT an effective way to solve the problem at a large scale. DNS provides a = nice mechanism for turning a name (or phone number) into a target IP address, = but a lousy mechanism for telling us each of the intermediate hops needed to = get from a source IP address to a target IP address (which is a vector of the = router in between the two addresses).

 

We really need a SIP-targeted analog of the = BGP/OSPF route-exchange protocols to solve the general problem.

 

--

Dean

 

 

 

 

 

------_=_NextPart_001_01CABB09.685975B7-- From adam@nostrum.com Wed Mar 3 13:42:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B814028C26F for ; Wed, 3 Mar 2010 13:42:56 -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 XDXIY0ftuwOz for ; Wed, 3 Mar 2010 13:42:56 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id EDCC828C271 for ; Wed, 3 Mar 2010 13:42:52 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o23LgiMT050195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 15:42:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8ED7D2.8000806@nostrum.com> Date: Wed, 03 Mar 2010 15:42:42 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Dean Willis References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 21:42:56 -0000 On 3/3/10 1:26 PM, Dean Willis wrote: > > We really need a SIP-targeted analog of the BGP/OSPF route-exchange > protocols to solve the general problem. So, what, like TRIP, but for things other than phone numbers? /a From dschwartz@xconnect.net Wed Mar 3 15:57:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BEA28C284 for ; Wed, 3 Mar 2010 15:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvLnq7uNUNOk for ; Wed, 3 Mar 2010 15:57:05 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 785F128C4AC for ; Wed, 3 Mar 2010 15:57:02 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 4 Mar 2010 01:57:02 +0200 From: David Schwartz To: Adam Roach , Dean Willis Date: Thu, 4 Mar 2010 01:57:02 +0200 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq7GoDbWTjSi0NHQlaHHQBtLZyJtAAEY87g Message-ID: <6EA53FAD386F9D46B97D49BFE148D5140603A409@ISR-JLM-MAIL1.xconnect.co.il> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> , <4B8ED7D2.8000806@nostrum.com> In-Reply-To: <4B8ED7D2.8000806@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 23:57:06 -0000 In the now expired draft-kaplan-drinks-lrf-requirements-00, Hadriel seemed = to be pushing for a "Session Location Routing Protocol" (SLRP) to deal with= this issue... ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Ad= am Roach [adam@nostrum.com] Sent: Wednesday, March 03, 2010 11:42 PM To: Dean Willis Cc: 'dispatch@ietf.org' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On 3/3/10 1:26 PM, Dean Willis wrote: > > We really need a SIP-targeted analog of the BGP/OSPF route-exchange > protocols to solve the general problem. So, what, like TRIP, but for things other than phone numbers? /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From D.Malas@cablelabs.com Wed Mar 3 16:01:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B9A3A89D6 for ; Wed, 3 Mar 2010 16:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sukL5Xuh-2xg for ; Wed, 3 Mar 2010 16:01:39 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 01CDD3A89AF for ; Wed, 3 Mar 2010 16:01:38 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2401amM007294; Wed, 3 Mar 2010 17:01:37 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Mar 2010 17:01:36 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Mar 2010 17:01:37 -0700 From: Daryl Malas To: "'Dwight, Timothy M (Tim)'" , "PFAUTZ, PENN L (ATTCORP)" Date: Wed, 3 Mar 2010 17:01:36 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPwAAMs4TAABSXPgAAATcwwAAO4knA= Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66CEsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 00:01:52 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66CEsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, Thank you for the additional context. I think we are in sync regarding the= purposes of the draft as you indicate below. Regarding placing a route he= ader into a local non-ENUM database is obviously outside the scope of the d= raft. If you use a local private ENUM server to add your own route header = (or egress route) to the NAPTR URI, is implementation specific and up to yo= u. Even in this implementation specific case, I believe defining a best pr= actice for defining and including egress information in the NAPTR URI will = provide better industry adoption and implementation consistency. Do you ag= ree? Regards, Daryl ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, March 03, 2010 4:34 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl, I guess our use cases differ. The draft illustrates a NAPTR producing a URI whose host part is the ingres= s point to SSP2's network through which SSP2 prefers to receive session req= uests targeted at the example TN. It then talks about mechanisms to includ= e in the ENUM response, information that "steer" the session request messag= e through the "egress point" from SSP1's network, desired by SSP1. I get that. I've done it, in a private ENUM, so I know it's possible. It'= s a little trickier to manage in the context of a shared registry, but stil= l seems within the capabilities of the commercial ENUM servers with which I= 'm familiar. Thinking of the "route header" solution, SSP1 could maintain = in the registry a table that instructs the registry provider to append a ro= ute header identifying SBE2 to any URI whose host part was "SBE3.ssp2.examp= le.com". Although this sort of detail isn't subject to standardization I a= ssume you have something like that in mind. This seems workable in large part because SSP1 and SSP2 will in practice kn= ow quite a lot about their interconnection. If SSP1 had no prior knowledge= of the "ingress points" (e.g., SBE3) to SSP2's networks, it would be impos= sible to maintain such a table. But in practice it will know these ingress= points; moreover it will know how its own "egress points" are connected to= them (e.g., via a partial mesh of IPsec tunnels). Again I'm assuming you = have something like this in mind. What I meant to propose, was a different use case. Suppose SSP2 doesn't id= entify its ingress point in the URI resulting from the NAPTR it returns. S= uppose instead it returns a URI whose host part is something like "call-ser= ver-1.ssp2.example.com". This is the FQDN of the call server (e.g., softsw= itch, application server) in SSP2 network that will serve calls to the exam= ple TN. Returning such a value avoids SSP2 having to make another routing = decision after receiving the call from SSP1. But if you do that, you may also want to "steer" the session request to an = ingress point (SBE3 in the draft). This could be done using e.g., a ROUTE = header imbedded in the URI in the NAPTR. The logic to determine the conten= t of this ROUTE header is simple since it depends only on where the call is= going not where it came from; and easily administered since it would be sp= ecified by the same entity that serves the example TN. SSP1 might also want to steer the call through SBE2, which could be done vi= a any of the mechanisms in the draft, or via some table maintained outside = of ENUM. The 2 approaches are AFAIK both possible with existing standards and suppor= table by currently available products. Were it up to me, based on my curre= nt (probably flawed and incomplete) understanding, I'd probably do the form= er (identification of the "ingress point" to the serving domain) in the ENU= M database or registry, and the latter (identification of the "egress point= " from the querying domain, as a function of the URI returned in an ENUM re= sponse) either via some non-ENUM database, or via some "private data" in my= local ENUM servers (private meaning not managed by the registry service). Anyway I appreciated and enjoyed the draft, and appreciate the technical ex= change. Best regards, Tim ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 3:45 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Tim, SSP2 does provide their preferred "ingress point." This information is sti= ll in the ENUM response regardless of whether an additional egress route va= riable has been added or not. I am not sure I understand your second paragraph. Regards, Daryl ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, March 03, 2010 12:25 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Why not let SSP2 provide their preferred "ingress point" for session reques= ts addressed to the queried TN, in the ENUM response? That would presumabl= y be the same for all querying networks, and it is data for which the SSP s= erving the queried TN (SSP2) is authoritative. In the common case of "mated peering points" (e.g., a pair of SBCs in SSP1 = connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local tabl= e mapping the remote-network ingress points received in ENUM responses, to = its own egress points (i.e., its SBCs that are connected via IPsec to the i= ngress point in the ENUM response). tim ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Wednesday, March 03, 2010 12:01 PM To: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, I think what you're describing is leaning towards implementation specific q= uestions. I apologize, my example below is backwards, but the principle is= the same. SSP2 provisions their numbers and "routes" into the ENUM server= . SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify= their own egress routes in the same ENUM server. The method for SSP1's egress routes for SSP2 to be received into a "local c= opy" is implementation specific, imo. This being said, obviously, SSP3 and= SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 whe= n they query the ENUM server. If this is resolved in some "for queries fro= m here give this" or "here is a local copy of peer numbers and routes plus = *your* egress routes" is implementation specific. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl I was a little confused by this since I thought the call was from SSP1 to S= SP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get th= e SSP2 data and wants to add their egress routes in their local copy I can = see that but I wouldn't expect the resulting elaborated NAPTRs to be in the= Registry. Have I got this right now? Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, The use case for this application is SSP1 (or someone on their behalf) prov= isions their numbers and relative routes into the LUF associated with their= federation. SSP2 reviews SSP1's "routes" available to them in the LUF bas= ed on what SSP1 provisioned. They then add an egress route and associate i= t with the ingress route SSP1 provisioned. Let me know if this makes sense. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66CEsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Tim,
 
Thank you for the additional context.  I think&n= bsp;we=20 are in sync regarding the purposes of the draft as you indicate=20 below.  Regarding placing a route header into a local non-ENUM databas= e is=20 obviously outside the scope of the draft.  If you use a local private = ENUM=20 server to add your own route header (or egress route) to the NAPTR URI, is= =20 implementation specific and up to you.  Even in this implementation=20 specific case, I believe defining a best practice for defining and includin= g=20 egress information in the NAPTR URI will provide better industry adoption a= nd=20 implementation consistency.  Do you agree?
 
Regards,
 
Daryl

From: Dwight, Timothy M (Tim)=20 [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March 03, 2= 010=20 4:34 PM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP)
Subject:<= /B>=20 RE: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl,

&nb= sp;

I guess = our use=20 cases differ.  

&nb= sp;

The draf= t=20 illustrates a NAPTR producing a URI whose host part is the ingress point to= =20 SSP2’s network through which SSP2 prefers to receive session requests= targeted=20 at the example TN.  It then talks about mechanisms to include in the E= NUM=20 response, information that “steer” the session request message = through the=20 “egress point” from SSP1’s network, desired by=20 SSP1.

&nb= sp;

I get=20 that.  I’ve done it, in a private ENUM, so I know it’s pos= sible.  It’s=20 a little trickier to manage in the context of a shared registry, but still = seems=20 within the capabilities of the commercial ENUM servers with which I’m= =20 familiar.  Thinking of the “route header” solution, SSP1 c= ould maintain in=20 the registry a table that instructs the registry provider to append a route= =20 header identifying SBE2 to any URI whose host part was “SBE3.ssp2.exa= mple.com”.=20  Although this sort of detail isn’t subject to standardization I= assume you=20 have something like that in mind.

&nb= sp;

This see= ms=20 workable in large part because SSP1 and SSP2 will in practice know quite a = lot=20 about their interconnection.  If SSP1 had no prior knowledge of the=20 “ingress points” (e.g., SBE3) to SSP2’s networks, it woul= d be impossible to=20 maintain such a table.  But in practice it will know these ingress poi= nts;=20 moreover it will know how its own “egress points” are connected= to them (e.g.,=20 via a partial mesh of IPsec tunnels).  Again I’m assuming you ha= ve=20 something like this in mind.

&nb= sp;

&nb= sp;

What I m= eant to=20 propose, was a different use case.  Suppose SSP2 doesn’t identif= y its=20 ingress point in the URI resulting from the NAPTR it returns.  Suppose= =20 instead it returns a URI whose host part is something like=20 “call-server-1.ssp2.example.com”.  This is the FQDN of the= call server=20 (e.g., softswitch, application server) in SSP2 network that will serve call= s to=20 the example TN.  Returning such a value avoids SSP2 having to make ano= ther=20 routing decision after receiving the call from=20 SSP1.

&nb= sp;

But if y= ou do=20 that, you may also want to “steer” the session request to an in= gress point (SBE3=20 in the draft).  This could be done using e.g., a ROUTE header imbedded= in=20 the URI in the NAPTR.  The logic to determine the content of this ROUT= E=20 header is simple since it depends only on where the call is going not where= it=20 came from; and easily administered since it would be specified by the same= =20 entity that serves the example TN.

&nb= sp;

SSP1 mig= ht also=20 want to steer the call through SBE2, which could be done via any of the=20 mechanisms in the draft, or via some table maintained outside of ENUM.=20

&nb= sp;

The 2=20 approaches are AFAIK both possible with existing standards and supportable = by=20 currently available products.  Were it up to me, based on my current=20 (probably flawed and incomplete) understanding, I’d probably do the f= ormer=20 (identification of the “ingress point” to the serving domain) i= n the ENUM=20 database or registry, and the latter (identification of the “egress p= oint” from=20 the querying domain, as a function of the URI returned in an ENUM response)= =20 either via some non-ENUM database, or via some “private data” i= n my local ENUM=20 servers (private meaning not managed by the registry=20 service).

&nb= sp;

Anyway I= =20 appreciated and enjoyed the draft, and appreciate the technical=20 exchange.

&nb= sp;

Best=20 regards,

&nb= sp;

Tim=

&nb= sp;

&nb= sp;

From: Daryl=20 Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 3:45= =20 PM
To: Dwight, Timothy M= (Tim);=20 PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

SSP2 does provid= e their=20 preferred "ingress point."  This information is still in the ENUM resp= onse=20 regardless of whether an additional egress route variable has been added or= =20 not.

 

I am not sure I= =20 understand your second paragraph.

 

Regards,<= /FONT>

 

Daryl

 

From: Dwight,=20 Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March 03, 2010 12:2= 5=20 PM
To: Daryl Malas; PFAU= TZ,=20 PENN L (ATTCORP)
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Why not = let=20 SSP2 provide their preferred “ingress point” for session reques= ts addressed to=20 the queried TN, in the ENUM response?  That would presumably be the sa= me=20 for all querying networks, and it is data for which the SSP serving the que= ried=20 TN (SSP2) is authoritative.

&nb= sp;

In the c= ommon=20 case of “mated peering points” (e.g., a pair of SBCs in SSP1 co= nnected to a pair=20 of SBCs in SSP2 via IPsec) SSP2 could keep a local table mapping the=20 remote-network ingress points received in ENUM responses, to its own egress= =20 points (i.e., its SBCs that are connected via IPsec to the ingress point in= the=20 ENUM response).

&nb= sp;

tim=

&nb= sp;

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Wednesday, March 03, 2010 12:0= 1=20 PM
To: 'PFAUTZ, PENN L=20 (ATTCORP)'; dispatch@ietf.org
Subject: Re: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

I think what you= 're=20 describing is leaning towards implementation specific questions.  I=20 apologize, my example below is backwards, but the principle is the same.&nb= sp;=20 SSP2 provisions their numbers and "routes" into the ENUM server.  SSP1= can=20 see the ingress routes for SSP2 numbers.  SSP1 can then specify their = own=20 egress routes in the same ENUM server.

 

The method=20 for SSP1's egress routes for SSP2 to be received into a "loc= al=20 copy" is implementation specific, imo.  This being said, obviously, SS= P3=20 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 = when=20 they query the ENUM server.  If this is resolved in some "for queries = from=20 here give this" or "here is a local copy of peer numbers and routes plus *y= our*=20 egress routes" is implementation specific.

 

Regards,<= /FONT>

 

Daryl

 

From: PFAUTZ,=20 PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Wednesday, March 03, 2010 10:3= 8=20 AM
To: Daryl Malas;=20 dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl=20

I was a lit= tle=20 confused by this since I thought the call was from SSP1 to SSP2 and that SS= P2=20 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wa= nts=20 to add their egress routes in their local copy I can see that but I wouldn&= #8217;t=20 expect the resulting elaborated NAPTRs to be in the Registry.=20

Have I got = this=20 right now?

 =

Penn=20 Pfautz

AT&T Acce= ss=20 Management

+1-732-420-49= 62=

From: Daryl=20 Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 11:2= 2=20 AM
To: PFAUTZ, PENN L=20 (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

=

 

Penn,

 

The use case for= this=20 application is SSP1 (or someone on their behalf) provisions their numbers a= nd=20 relative routes into the LUF associated with their federation.  S= SP2=20 reviews SSP1's "routes" available to them in the LUF based on what SSP= 1=20 provisioned.  They then add an egress route and associate it with the= =20 ingress route SSP1 provisioned.

 

Let me know if t= his=20 makes sense.

 

Regards,<= /FONT>

 

Daryl

 

From: PFAUTZ,=20 PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24= =20 PM
To: Daryl Malas;=20 dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl:=

I want to b= e sure=20 I understand what you’re proposing.  In what name server would t= he modified=20 records be? One local to SSP1 or some general industry DNS? I’m tryin= g to=20 understand how SSP1 modifies an RR for an SSP2=20 number.

 =

Thanks,

 =

Penn=20 Pfautz

AT&T Acce= ss=20 Management

+1-732-420-49= 62=

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51=20 PM
To:=20 'dispatch@ietf.org'
Subject:= =20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

=

 

All,=

 

A New Internet-Draft is avail= able=20 from the on-line Internet-Drafts directories.
 
Title : SIP Egr= ess=20 Route Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20

 

Regards,

 

Daryl

 

---------------------------

Daryl=20 Malas

Project Director, IP=20 Interconnects

w - +1 303 661=20 3302

mailto:d.malas@cablelabs.com=

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66CEsrvxchg_-- From richard@shockey.us Wed Mar 3 17:38:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E94028C1BF for ; Wed, 3 Mar 2010 17:38:36 -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 0IW-0uyJqHNu for ; Wed, 3 Mar 2010 17:38:34 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 286373A8383 for ; Wed, 3 Mar 2010 17:38:34 -0800 (PST) Received: (qmail 14045 invoked by uid 0); 4 Mar 2010 01:38:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 4 Mar 2010 01:38:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=XCmrdhjcCkD6mad2yMjRKe84oZTt5Mlxixrg9byGD8fxZ//nFlk4Nedb/Kw7fvpGNqECEeeIptgj3J1Rd3hX1B0WUQyFjEy1XnlIE4RyO++a8tj/0nm2FnidV6gwq6ec; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nn01L-000321-E4; Wed, 03 Mar 2010 18:38:35 -0700 From: "Richard Shockey" To: "'Adam Roach'" , "'Dean Willis'" References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> In-Reply-To: <4B8ED7D2.8000806@nostrum.com> Date: Wed, 3 Mar 2010 20:38:33 -0500 Message-ID: <01eb01cabb3b$6758d520$360a7f60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7Gn6KK2AYJyPiTxaGwE27f+0jbQAHsKDQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 01:38:36 -0000 Dean ..again this is not about _THE_ DNS only the use of DNS _technology_ to provide a specific and necessary function for inter carrier routing as Penn points out in the GSMA case. ENUM has difficulty in actually performing some of these functions since the ENUM query has no way to signal what is the source of the query since in many cases you need a differentiated response which you correctly point out is not THE DNS as we commonly understand it. Hadriel Kaplan put out a draft some time ago on source URI that would fix that issue, one I fully support. http://ietfreport.isoc.org/all-ids/draft-kaplan-enum-source-uri-00.txt In some cases SIP redirect actually works better since the From: field can allow the localized directory servers ( aka IP SCP's) to formulate a response based on the source. The meta issue all of these drafts are all of the lovely number translation tasks that inspired my favorite NO TCAP NO SS7 baseball caps I made upyears ago along with NO PRI T-shirts. If you want to replace the PSTN you have to deal with TCAP replecemenmt and the tools we have are ENUM and SIP and they both work. This also relates to E.164 metadata like SPID's etal that will be addressed in the E2M BOF that you and Bernie are running and BTW yes SIP needs a means to express non routable E.164 metadata as well. Any ideas on a new header for that problem? Could you do that in a 302 MOVE as well? And as for TRIP ..been there heard that argument before ..no one is going to deploy a BGP like function for this. Not going to happen no more stacks in the proxy's we need to deal with the protocols we have not try and invent new ones. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Wednesday, March 03, 2010 4:43 PM To: Dean Willis Cc: 'dispatch@ietf.org' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 On 3/3/10 1:26 PM, Dean Willis wrote: > > We really need a SIP-targeted analog of the BGP/OSPF route-exchange > protocols to solve the general problem. So, what, like TRIP, but for things other than phone numbers? /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From kcartwright@tnsi.com Thu Mar 4 06:38:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1923728C13C for ; Thu, 4 Mar 2010 06:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifB2TouE85qe for ; Thu, 4 Mar 2010 06:38:50 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id AD8B13A8D05 for ; Thu, 4 Mar 2010 06:38:50 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41151398; Thu, 04 Mar 2010 09:38:41 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 4 Mar 2010 09:38:40 -0500 From: "Cartwright, Kenneth" To: Dean Willis , "d.malas@cablelabs.com" Date: Thu, 4 Mar 2010 09:38:39 -0500 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq7CAuBBG+4tp+oRG+T6VUioiqwMgAnYpOg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D890E145F@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0D890E145FTNSMAILNAwin2_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 14:38:57 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0D890E145FTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that these discussions that focus on some macro level principles th= at underlay the worldwide DNS system, and that seem to presume that the und= erlying implementation of this draft will live in plain vanilla DNS/bind im= plementations, out on the world-wide domain name system are not necessarily= relevant. It's certainly true that vanilla DNS and bind, as they live in = the world-wide DNS system, were designed primarily to return the same answe= r to all queriers, and to use TTL to improve performance via caching, and g= enerally have comparatively simple internal data structures to house their = data, etc, etc. But I do not think that is the context within which this d= raft is required to be used or evaluated, nor is that the context within wh= ich many many ENUM capable implementations are designed/built/used. When you get down to it, ENUM is really just a query/response protocol for = the resolution activities, and implementing an application that can give st= andards based ENUM responses does not require that that implementation be B= ind-like in its additional capabilities and design, or that the usage conte= xt be the world-wide DNS system, or that the internal data structure just b= e a list of domain names with a link to a set of RRs, or that TTL/caching m= ust always play a significant role in scalability or performance, or that r= esponses must always be the same regardless of the querier. Ken ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dean Willis Sent: Wednesday, March 03, 2010 2:30 PM To: d.malas@cablelabs.com Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 3, 2010, at 12:01 PM, Daryl Malas wrote: The method for SSP1's egress routes for SSP2 to be received into a "local c= opy" is implementation specific, imo. This being said, obviously, SSP3 and= SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 whe= n they query the ENUM server. If this is resolved in some "for queries fro= m here give this" or "here is a local copy of peer numbers and routes plus = *your* egress routes" is implementation specific. And this part right here is exactly why the DNS infrastructure of ENUM is N= OT a good solution for the problem. Unlike Einstein, DNS does not embrace r= elativity (AKA location-context sensitivity). There are ugly hacks to make = relativity happen in certain limited cases, but they defeat the fundamental= scalability mechanisms of the DNS. -- Dean ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0D890E145FTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that these discussions that fo= cus on some macro level principles that underlay the worldwide DNS system, = and that seem to presume that the underlying implementation of this draft will live in plain vanill= a DNS/bind implementations, out on the world-wide domain name system are no= t necessarily relevant.  It’s certainly true that vanilla DNS an= d bind, as they live in the world-wide DNS system, were designed primarily to return the same answer to all queriers,= and to use TTL to improve performance via caching, and generally have comp= aratively simple internal data structures to house their data, etc, etc.&nb= sp; But I do not think that is the context within which this draft is required to be used or evaluated, nor is that t= he context within which many many ENUM capable implementations are designed= /built/used.

 

When you get down to it, ENUM is reall= y just a query/response protocol for the resolution activities, and impleme= nting an application that can give standards based ENUM responses does not require that that im= plementation be Bind-like in its additional capabilities and design, or tha= t the usage context be the world-wide DNS system, or that the internal data= structure just be a list of domain names with a link to a set of RRs, or that TTL/caching must always play a = significant role in scalability or performance, or that responses must alwa= ys be the same regardless of the querier.

 

Ken

 

From: disp= atch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Wednesday, March 03, 2= 010 2:30 PM
To: d.malas@cablelabs.com Cc: dispatch@ietf.org
Subject: Re: [dispatch] I-D = Action: draft-malas-dispatch-sip-egress-route-00

 

 

On Mar 3, 2010, at 12:01 PM, Daryl Malas wrote:



= &nb= sp;

The method for SSP1's egress rout= es for SSP2 to be received into a "local copy" is imple= mentation specific, imo.  This being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned egress routes for= SSP2 when they query the ENUM server.  If this is resolved in some &q= uot;for queries from here give this" or "here is a local copy of = peer numbers and routes plus *your* egress routes" is implementation specific.

 

And this part right here is exactly why the DNS infrastructure of E= NUM is NOT a good solution for the problem. Unlike Einstein, DNS does not e= mbrace relativity (AKA location-context sensitivity). There are ugly hacks to make relativity hap= pen in certain limited cases, but they defeat the fundamental scalability m= echanisms of the DNS.

 

--

Dean


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0D890E145FTNSMAILNAwin2_-- From dean.willis@softarmor.com Thu Mar 4 08:15:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB05E28C1D5 for ; Thu, 4 Mar 2010 08:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTRjCpUyBTLx for ; Thu, 4 Mar 2010 08:15:51 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2217428C1F8 for ; Thu, 4 Mar 2010 08:15:51 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24GFoaL013449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 10:15:51 -0600 Message-Id: <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B8ED7D2.8000806@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 10:15:45 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:15:51 -0000 On Mar 3, 2010, at 3:42 PM, Adam Roach wrote: > On 3/3/10 1:26 PM, Dean Willis wrote: >> >> We really need a SIP-targeted analog of the BGP/OSPF route-exchange >> protocols to solve the general problem. > > So, what, like TRIP, but for things other than phone numbers? > Yep. Imagine a TRIP extended to say "I have a SIP peering agreement with domain X". Or better yet, imagine something that actually works and is widely implemented that allows sharing such route information. A caveat: we also have simple phone-number-peering issues, and TRIP hasn't caught on there. Therefore, I suspect that TRIP isn't quite right. A thorough post-mortem analysis might be interesting. -- Dean From dean.willis@softarmor.com Thu Mar 4 08:36:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF7D3A8B4A for ; Thu, 4 Mar 2010 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8ds74q5cfLI for ; Thu, 4 Mar 2010 08:36:02 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 96A973A8AEE for ; Thu, 4 Mar 2010 08:36:02 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24Ga2fJ013568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 4 Mar 2010 10:36:04 -0600 Message-Id: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> From: Dean Willis To: dispatch@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 10:35:55 -0600 X-Mailer: Apple Mail (2.936) Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:36:06 -0000 Richard Shockey said: > And as for TRIP ..been there heard that argument before ..no one is > going to > deploy a BGP like function for this. Not going to happen no more > stacks in > the proxy's we need to deal with the protocols we have not try and > invent > new ones. I'm starting another thread from this comment, because it raises a really good question. TRIP was designed to exchange phone-number reachability information between SIP nodes. Nobody uses it. Why? Is the problem with TRIP is that it's yet another protocol (as Richard suggests above), or is the problem that it doesn't convey the right information, just doesn't work, or something else? What if the route-exchange function were done in SIP, perhaps something like an event package for routing? Here's a possible model using an event package for routing. One might subscribe to the "routing" event package at a node, resulting in being NOTIFY-ed with a list of route vectors being advertised by that node. This allows some interesting things: 1) Since SUBSCRIBE provides the information to specify "who is asking", the NOTIFY responses could contain route-tables customized for the recipient. This provides the location context sensitivity missing from ENUM queries. 2) Route-table entries could be vectors, something like "I, proxy B, have a route to proxy A, which offered me a route to example.com", allowing for selective route-redistribution. 3) Having gotten a preliminary routing table from subscribing to a peer, one could then query the peer's peers by subscribing directly to their routing updates. This establishes SIP reachability to those nodes (if the SUBSCRIBE works, you can reach them with SIP, and if their NOTIFY requests work, they can reach you). Further, it allows the peer's peer to make a determination of which routes they might want to offer you directly, as opposed to transitively via the first peer. 4) Filters in the SUBSCRIBE could be used to indicate an interest in a subset of routes. 5) The routing vector syntax could easily allow for both phone numbers and domain-names. -- Dean From mohamed.boucadair@orange-ftgroup.com Thu Mar 4 08:59:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3B328C123 for ; Thu, 4 Mar 2010 08:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 qkhsx8NufFCG for ; Thu, 4 Mar 2010 08:59:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 06D303A8D63 for ; Thu, 4 Mar 2010 08:59:42 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2CB659C3B8; Thu, 4 Mar 2010 17:59:42 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 14F364C013; Thu, 4 Mar 2010 17:59:42 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 4 Mar 2010 17:59:41 +0100 From: To: Dean Willis , "dispatch@ietf.org" Date: Thu, 4 Mar 2010 17:59:40 +0100 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq7uM8Iwy7Ey+JLSsqUy166UqWw9wAAtTdw Message-ID: <8777_1267721982_4B8FE6FE_8777_41410_1_94C682931C08B048B7A8645303FDC9F30EFBC79E1A@PUEXCB1B.nanterre.francetelecom.fr> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> In-Reply-To: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.4.163326 Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:59:43 -0000 Dear all, I'm wondering whether it is true to say that TRIP does not provide an answe= r to the inter-ITAD reachability issue. Whitout going into technical detail= s, why do we have continuous requests for TRIP ITAD identifiers? See http://www.iana.org/assignments/trip-parameters/trip-parameters.xhtml o= r the IANA reports. Cheers, Med =20 -----Message d'origine----- De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la par= t de Dean Willis Envoy=E9 : jeudi 4 mars 2010 17:36 =C0 : dispatch@ietf.org Objet : [dispatch] Why are we TRIPped out? Is there an sip-event alternativ= e? Richard Shockey said: > And as for TRIP ..been there heard that argument before ..no one is=20=20 > going to > deploy a BGP like function for this. Not going to happen no more=20=20 > stacks in > the proxy's we need to deal with the protocols we have not try and=20=20 > invent > new ones. I'm starting another thread from this comment, because it raises a=20=20 really good question. TRIP was designed to exchange phone-number reachability information=20=20 between SIP nodes. Nobody uses it. Why? Is the problem with TRIP is that it's yet another protocol (as Richard=20= =20 suggests above), or is the problem that it doesn't convey the right=20=20 information, just doesn't work, or something else? What if the route-exchange function were done in SIP, perhaps=20=20 something like an event package for routing? Here's a possible model using an event package for routing. One might=20=20 subscribe to the "routing" event package at a node, resulting in being=20= =20 NOTIFY-ed with a list of route vectors being advertised by that node. This allows some interesting things: 1) Since SUBSCRIBE provides the information to specify "who is=20=20 asking", the NOTIFY responses could contain route-tables customized=20=20 for the recipient. This provides the location context sensitivity=20=20 missing from ENUM queries. 2) Route-table entries could be vectors, something like "I, proxy B,=20=20 have a route to proxy A, which offered me a route to example.com",=20=20 allowing for selective route-redistribution. 3) Having gotten a preliminary routing table from subscribing to a=20=20 peer, one could then query the peer's peers by subscribing directly to=20= =20 their routing updates. This establishes SIP reachability to those=20=20 nodes (if the SUBSCRIBE works, you can reach them with SIP, and if=20=20 their NOTIFY requests work, they can reach you). Further, it allows=20=20 the peer's peer to make a determination of which routes they might=20=20 want to offer you directly, as opposed to transitively via the first=20=20 peer. 4) Filters in the SUBSCRIBE could be used to indicate an interest in=20=20 a subset of routes. 5) The routing vector syntax could easily allow for both phone numbers=20= =20 and domain-names. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From D.Malas@CableLabs.com Thu Mar 4 09:05:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE29C3A8D56 for ; Thu, 4 Mar 2010 09:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E1gPUSwwlAH for ; Thu, 4 Mar 2010 09:05:39 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B5CE03A8D4F for ; Thu, 4 Mar 2010 09:05:39 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o24H5eDC003331; Thu, 4 Mar 2010 10:05:40 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 4 Mar 2010 10:05:40 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 4 Mar 2010 10:05:40 -0700 From: Daryl Malas To: "'Dean Willis'" , "dispatch@ietf.org" Date: Thu, 4 Mar 2010 10:05:39 -0700 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq7uM22b61m3N9wT9SCFQ2mF02RcwAAh4CA Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> In-Reply-To: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:05:43 -0000 Dean, It has been a long time, since I read the RFC. If I recall correctly, the = biggest problem with TRIP was the issue of Number Portability. Unlike BGP = where there is a common rule of summarizing IP address blocks into class A'= s or B's, you cannot do the same with E.164 addresses. Before number porta= bility, TRIP would work good, because you can say I have NPA-NX1 through NP= A-NX3. If you want to reach them go here. Now, there are rarely any conti= guous blocks for any service provider. If SSPs used TRIP, they would have = to put in every single E.164 address (e.g. NPA-NXX-XXXX) into a route table= . This would make route tables contain millions of lines, which would slow= down routing considerably...not to mention the maintenance nightmare...not= to mention the route convergence would be ugly. Perhaps there could be a = 3rd party application that searches for contiguous ranges, but this too wou= ld be maintenance heavy as TNs are ported from one SSP to another; and, the= re is no guarantee it would significantly improve the routing database issu= e. Perhaps I am just way off on this, but this is my recollection. Regards, Daryl=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dean Willis Sent: Thursday, March 04, 2010 9:36 AM To: dispatch@ietf.org Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternati= ve? Richard Shockey said: > And as for TRIP ..been there heard that argument before ..no one is=20 > going to deploy a BGP like function for this. Not going to happen no=20 > more stacks in the proxy's we need to deal with the protocols we have=20 > not try and invent new ones. I'm starting another thread from this comment, because it raises a really g= ood question. TRIP was designed to exchange phone-number reachability information between= SIP nodes. Nobody uses it. Why? Is the problem with TRIP is that it's yet another protocol (as Richard sugg= ests above), or is the problem that it doesn't convey the right information= , just doesn't work, or something else? What if the route-exchange function were done in SIP, perhaps something lik= e an event package for routing? Here's a possible model using an event package for routing. One might subsc= ribe to the "routing" event package at a node, resulting in being NOTIFY-ed= with a list of route vectors being advertised by that node. This allows some interesting things: 1) Since SUBSCRIBE provides the information to specify "who is asking", the= NOTIFY responses could contain route-tables customized for the recipient. = This provides the location context sensitivity missing from ENUM queries. 2) Route-table entries could be vectors, something like "I, proxy B, have a= route to proxy A, which offered me a route to example.com", allowing for s= elective route-redistribution. 3) Having gotten a preliminary routing table from subscribing to a peer, on= e could then query the peer's peers by subscribing directly to their routin= g updates. This establishes SIP reachability to those nodes (if the SUBSCRI= BE works, you can reach them with SIP, and if their NOTIFY requests work, t= hey can reach you). Further, it allows the peer's peer to make a determinat= ion of which routes they might want to offer you directly, as opposed to tr= ansitively via the first peer. 4) Filters in the SUBSCRIBE could be used to indicate an interest in a sub= set of routes. 5) The routing vector syntax could easily allow for both phone numbers and = domain-names. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From D.Malas@cablelabs.com Thu Mar 4 09:12:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525C33A8D81 for ; Thu, 4 Mar 2010 09:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+1b+jKF03X4 for ; Thu, 4 Mar 2010 09:12:08 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 0404B3A8D93 for ; Thu, 4 Mar 2010 09:12:07 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o24HC7G8003911; Thu, 4 Mar 2010 10:12:07 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 4 Mar 2010 10:12:07 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 4 Mar 2010 10:12:07 -0700 From: Daryl Malas To: "'Dwight, Timothy M (Tim)'" , "PFAUTZ, PENN L (ATTCORP)" Date: Thu, 4 Mar 2010 10:12:07 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPwAAMs4TAABSXPgAAATcwwAAO4knAACNv0sAAb7HcA Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1srvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:12:29 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, Personally, I think the question of how the information if uniquely conveye= d to each individual SSP is an implementation issue. I have seen it work i= n different methods. My may concern with the draft is to create uniformity= in how the information is conveyed to the SIP/ENUM agent. Regards, Daryl ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, March 03, 2010 9:08 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl, I agree that defining a best practice often has the impact you suggest. IMHO the technique you describe has merit. What's not clear is how a diffe= rent response is generated per querying domain. The draft shows response f= ormats that would be appropriate for SSP1, but not appropriate for any othe= r domain. This implies that the response would be somehow tailored for eac= h querying domain. I think some elaboration on how that works (e.g., what = has to be provisioned, by whom, to make it happen) would be helpful. tim ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 6:02 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Tim, Thank you for the additional context. I think we are in sync regarding the= purposes of the draft as you indicate below. Regarding placing a route he= ader into a local non-ENUM database is obviously outside the scope of the d= raft. If you use a local private ENUM server to add your own route header = (or egress route) to the NAPTR URI, is implementation specific and up to yo= u. Even in this implementation specific case, I believe defining a best pr= actice for defining and including egress information in the NAPTR URI will = provide better industry adoption and implementation consistency. Do you ag= ree. Regards, Daryl ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, March 03, 2010 4:34 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl, I guess our use cases differ. The draft illustrates a NAPTR producing a URI whose host part is the ingres= s point to SSP2's network through which SSP2 prefers to receive session req= uests targeted at the example TN. It then talks about mechanisms to includ= e in the ENUM response, information that "steer" the session request messag= e through the "egress point" from SSP1's network, desired by SSP1. I get that. I've done it, in a private ENUM, so I know it's possible. It'= s a little trickier to manage in the context of a shared registry, but stil= l seems within the capabilities of the commercial ENUM servers with which I= 'm familiar. Thinking of the "route header" solution, SSP1 could maintain = in the registry a table that instructs the registry provider to append a ro= ute header identifying SBE2 to any URI whose host part was "SBE3.ssp2.examp= le.com". Although this sort of detail isn't subject to standardization I a= ssume you have something like that in mind. This seems workable in large part because SSP1 and SSP2 will in practice kn= ow quite a lot about their interconnection. If SSP1 had no prior knowledge= of the "ingress points" (e.g., SBE3) to SSP2's networks, it would be impos= sible to maintain such a table. But in practice it will know these ingress= points; moreover it will know how its own "egress points" are connected to= them (e.g., via a partial mesh of IPsec tunnels). Again I'm assuming you = have something like this in mind. What I meant to propose, was a different use case. Suppose SSP2 doesn't id= entify its ingress point in the URI resulting from the NAPTR it returns. S= uppose instead it returns a URI whose host part is something like "call-ser= ver-1.ssp2.example.com". This is the FQDN of the call server (e.g., softsw= itch, application server) in SSP2 network that will serve calls to the exam= ple TN. Returning such a value avoids SSP2 having to make another routing = decision after receiving the call from SSP1. But if you do that, you may also want to "steer" the session request to an = ingress point (SBE3 in the draft). This could be done using e.g., a ROUTE = header imbedded in the URI in the NAPTR. The logic to determine the conten= t of this ROUTE header is simple since it depends only on where the call is= going not where it came from; and easily administered since it would be sp= ecified by the same entity that serves the example TN. SSP1 might also want to steer the call through SBE2, which could be done vi= a any of the mechanisms in the draft, or via some table maintained outside = of ENUM. The 2 approaches are AFAIK both possible with existing standards and suppor= table by currently available products. Were it up to me, based on my curre= nt (probably flawed and incomplete) understanding, I'd probably do the form= er (identification of the "ingress point" to the serving domain) in the ENU= M database or registry, and the latter (identification of the "egress point= " from the querying domain, as a function of the URI returned in an ENUM re= sponse) either via some non-ENUM database, or via some "private data" in my= local ENUM servers (private meaning not managed by the registry service). Anyway I appreciated and enjoyed the draft, and appreciate the technical ex= change. Best regards, Tim ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 3:45 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Tim, SSP2 does provide their preferred "ingress point." This information is sti= ll in the ENUM response regardless of whether an additional egress route va= riable has been added or not. I am not sure I understand your second paragraph. Regards, Daryl ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Sent: Wednesday, March 03, 2010 12:25 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Why not let SSP2 provide their preferred "ingress point" for session reques= ts addressed to the queried TN, in the ENUM response? That would presumabl= y be the same for all querying networks, and it is data for which the SSP s= erving the queried TN (SSP2) is authoritative. In the common case of "mated peering points" (e.g., a pair of SBCs in SSP1 = connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local tabl= e mapping the remote-network ingress points received in ENUM responses, to = its own egress points (i.e., its SBCs that are connected via IPsec to the i= ngress point in the ENUM response). tim ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Wednesday, March 03, 2010 12:01 PM To: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, I think what you're describing is leaning towards implementation specific q= uestions. I apologize, my example below is backwards, but the principle is= the same. SSP2 provisions their numbers and "routes" into the ENUM server= . SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify= their own egress routes in the same ENUM server. The method for SSP1's egress routes for SSP2 to be received into a "local c= opy" is implementation specific, imo. This being said, obviously, SSP3 and= SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 whe= n they query the ENUM server. If this is resolved in some "for queries fro= m here give this" or "here is a local copy of peer numbers and routes plus = *your* egress routes" is implementation specific. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl I was a little confused by this since I thought the call was from SSP1 to S= SP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get th= e SSP2 data and wants to add their egress routes in their local copy I can = see that but I wouldn't expect the resulting elaborated NAPTRs to be in the= Registry. Have I got this right now? Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Penn, The use case for this application is SSP1 (or someone on their behalf) prov= isions their numbers and relative routes into the LUF associated with their= federation. SSP2 reviews SSP1's "routes" available to them in the LUF bas= ed on what SSP1 provisioned. They then add an egress route and associate i= t with the ingress route SSP1 provisioned. Let me know if this makes sense. Regards, Daryl ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 Daryl: I want to be sure I understand what you're proposing. In what name server = would the modified records be? One local to SSP1 or some general industry D= NS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. Thanks, Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 All, A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP Egress Route Use in ENUM Author(s) : D. Malas Filename : draft-malas-dispatch-sip-egress-route-00.txt Pages : 11 Date : 2010-03-01 In some cases a UA (or proxy) within a Session Initiation Protocol [RFC3261] Service Provider (SSP) has multiple parallel egress proxy options to reach an ingress proxy within another SSP to reach the target UA. If the originating SSP uses ENUM to identify the ingress proxy of the target SSP, there is currently no way for the ENUM NAPTR response to identify a specific preferred egress proxy from the set of multiple parallel proxies. This draft solves this problem by defining a method for returning deterministic routing information within an ENUM NAPTR response enabling the UA (or proxy) to choose a preferred egress proxy. Using this information, the originating UA now sends the SIP request through the predetermined preferred egress proxy to reach the target SSP's proxy. This document describes several methods to make this determination by incorporating variables into a SIP service URI contained in the E.164 Number Mapping (ENUM) response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-0= 0.txt Regards, Daryl --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Tim,
 
Personally, I think the question of how the informati= on if=20 uniquely conveyed to each individual SSP is an implementation issue.  = I=20 have seen it work in different methods.  My may concern with the draft= is=20 to create uniformity in how the information is conveyed to the SIP/ENUM=20 agent.
 
Regards,
 
Daryl

From: Dwight, Timothy M (Tim)=20 [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March 03, 2= 010=20 9:08 PM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP)
Cc:=20 dispatch@ietf.org
Subject: RE: [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl,

&nb= sp;

I agree = that=20 defining a best practice often has the impact you=20 suggest.

&nb= sp;

IMHO the= =20 technique you describe has merit.  What’s not clear is how a dif= ferent=20 response is generated per querying domain.  The draft shows response=20 formats that would be appropriate for SSP1, but not appropriate for any oth= er=20 domain.  This implies that the response would be somehow tailored for = each=20 querying domain.  I think some elaboration on how that works (e.g., wh= at=20 has to be provisioned, by whom, to make it happen) would be=20 helpful.

&nb= sp;

tim=

&nb= sp;

From: Daryl=20 Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 6:02= =20 PM
To: Dwight, Timothy M= (Tim);=20 PFAUTZ, PENN L (ATTCORP)
Cc:= =20 dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

Thank you for th= e=20 additional context.  I think we are in sync regarding the=20 purposes of the draft as you indicate below.  Regarding placing a rout= e=20 header into a local non-ENUM database is obviously outside the scope of the= =20 draft.  If you use a local private ENUM server to add your own route h= eader=20 (or egress route) to the NAPTR URI, is implementation specific and up to=20 you.  Even in this implementation specific case, I believe defining a = best=20 practice for defining and including egress information in the NAPTR URI wil= l=20 provide better industry adoption and implementation consistency.  Do y= ou=20 agree.

 

Regards,<= /FONT>

 

Daryl

 

From: Dwight,=20 Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March 03, 2010 4:34= =20 PM
To: Daryl Malas; PFAU= TZ,=20 PENN L (ATTCORP)
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl,

&nb= sp;

I guess = our use=20 cases differ.  

&nb= sp;

The draf= t=20 illustrates a NAPTR producing a URI whose host part is the ingress point to= =20 SSP2’s network through which SSP2 prefers to receive session requests= targeted=20 at the example TN.  It then talks about mechanisms to include in the E= NUM=20 response, information that “steer” the session request message = through the=20 “egress point” from SSP1’s network, desired by=20 SSP1.

&nb= sp;

I get=20 that.  I’ve done it, in a private ENUM, so I know it’s pos= sible.  It’s=20 a little trickier to manage in the context of a shared registry, but still = seems=20 within the capabilities of the commercial ENUM servers with which I’m= =20 familiar.  Thinking of the “route header” solution, SSP1 c= ould maintain in=20 the registry a table that instructs the registry provider to append a route= =20 header identifying SBE2 to any URI whose host part was “SBE3.ssp2.exa= mple.com”.=20  Although this sort of detail isn’t subject to standardization I= assume you=20 have something like that in mind.

&nb= sp;

This see= ms=20 workable in large part because SSP1 and SSP2 will in practice know quite a = lot=20 about their interconnection.  If SSP1 had no prior knowledge of the=20 “ingress points” (e.g., SBE3) to SSP2’s networks, it woul= d be impossible to=20 maintain such a table.  But in practice it will know these ingress poi= nts;=20 moreover it will know how its own “egress points” are connected= to them (e.g.,=20 via a partial mesh of IPsec tunnels).  Again I’m assuming you ha= ve=20 something like this in mind.

&nb= sp;

&nb= sp;

What I m= eant to=20 propose, was a different use case.  Suppose SSP2 doesn’t identif= y its=20 ingress point in the URI resulting from the NAPTR it returns.  Suppose= =20 instead it returns a URI whose host part is something like=20 “call-server-1.ssp2.example.com”.  This is the FQDN of the= call server=20 (e.g., softswitch, application server) in SSP2 network that will serve call= s to=20 the example TN.  Returning such a value avoids SSP2 having to make ano= ther=20 routing decision after receiving the call from=20 SSP1.

&nb= sp;

But if y= ou do=20 that, you may also want to “steer” the session request to an in= gress point (SBE3=20 in the draft).  This could be done using e.g., a ROUTE header imbedded= in=20 the URI in the NAPTR.  The logic to determine the content of this ROUT= E=20 header is simple since it depends only on where the call is going not where= it=20 came from; and easily administered since it would be specified by the same= =20 entity that serves the example TN.

&nb= sp;

SSP1 mig= ht also=20 want to steer the call through SBE2, which could be done via any of the=20 mechanisms in the draft, or via some table maintained outside of ENUM.=20

&nb= sp;

The 2=20 approaches are AFAIK both possible with existing standards and supportable = by=20 currently available products.  Were it up to me, based on my current=20 (probably flawed and incomplete) understanding, I’d probably do the f= ormer=20 (identification of the “ingress point” to the serving domain) i= n the ENUM=20 database or registry, and the latter (identification of the “egress p= oint” from=20 the querying domain, as a function of the URI returned in an ENUM response)= =20 either via some non-ENUM database, or via some “private data” i= n my local ENUM=20 servers (private meaning not managed by the registry=20 service).

&nb= sp;

Anyway I= =20 appreciated and enjoyed the draft, and appreciate the technical=20 exchange.

&nb= sp;

Best=20 regards,

&nb= sp;

Tim=

&nb= sp;

&nb= sp;

From: Daryl=20 Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 3:45= =20 PM
To: Dwight, Timothy M= (Tim);=20 PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

SSP2 does provid= e their=20 preferred "ingress point."  This information is still in the ENUM resp= onse=20 regardless of whether an additional egress route variable has been added or= =20 not.

 

I am not sure I= =20 understand your second paragraph.

 

Regards,<= /FONT>

 

Daryl

 

From: Dwight,=20 Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March 03, 2010 12:2= 5=20 PM
To: Daryl Malas; PFAU= TZ,=20 PENN L (ATTCORP)
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Why not = let=20 SSP2 provide their preferred “ingress point” for session reques= ts addressed to=20 the queried TN, in the ENUM response?  That would presumably be the sa= me=20 for all querying networks, and it is data for which the SSP serving the que= ried=20 TN (SSP2) is authoritative.

&nb= sp;

In the c= ommon=20 case of “mated peering points” (e.g., a pair of SBCs in SSP1 co= nnected to a pair=20 of SBCs in SSP2 via IPsec) SSP2 could keep a local table mapping the=20 remote-network ingress points received in ENUM responses, to its own egress= =20 points (i.e., its SBCs that are connected via IPsec to the ingress point in= the=20 ENUM response).

&nb= sp;

tim=

&nb= sp;

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Wednesday, March 03, 2010 12:0= 1=20 PM
To: 'PFAUTZ, PENN L=20 (ATTCORP)'; dispatch@ietf.org
Subject: Re: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

I think what you= 're=20 describing is leaning towards implementation specific questions.  I=20 apologize, my example below is backwards, but the principle is the same.&nb= sp;=20 SSP2 provisions their numbers and "routes" into the ENUM server.  SSP1= can=20 see the ingress routes for SSP2 numbers.  SSP1 can then specify their = own=20 egress routes in the same ENUM server.

 

The method=20 for SSP1's egress routes for SSP2 to be received into a "loc= al=20 copy" is implementation specific, imo.  This being said, obviously, SS= P3=20 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 = when=20 they query the ENUM server.  If this is resolved in some "for queries = from=20 here give this" or "here is a local copy of peer numbers and routes plus *y= our*=20 egress routes" is implementation specific.

 

Regards,<= /FONT>

 

Daryl

 

From: PFAUTZ,=20 PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Wednesday, March 03, 2010 10:3= 8=20 AM
To: Daryl Malas;=20 dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl=20

I was a lit= tle=20 confused by this since I thought the call was from SSP1 to SSP2 and that SS= P2=20 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wa= nts=20 to add their egress routes in their local copy I can see that but I wouldn&= #8217;t=20 expect the resulting elaborated NAPTRs to be in the Registry.=20

Have I got = this=20 right now?

 =

Penn=20 Pfautz

AT&T Acce= ss=20 Management

+1-732-420-49= 62=

From: Daryl=20 Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March 03, 2010 11:2= 2=20 AM
To: PFAUTZ, PENN L=20 (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] I-D Action:= =20 draft-malas-dispatch-sip-egress-route-00

=

 

Penn,

 

The use case for= this=20 application is SSP1 (or someone on their behalf) provisions their numbers a= nd=20 relative routes into the LUF associated with their federation.  S= SP2=20 reviews SSP1's "routes" available to them in the LUF based on what SSP= 1=20 provisioned.  They then add an egress route and associate it with the= =20 ingress route SSP1 provisioned.

 

Let me know if t= his=20 makes sense.

 

Regards,<= /FONT>

 

Daryl

 

From: PFAUTZ,=20 PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, 2010 12:24= =20 PM
To: Daryl Malas;=20 dispatch@ietf.org
Subject: RE:=20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

Daryl:=

I want to b= e sure=20 I understand what you’re proposing.  In what name server would t= he modified=20 records be? One local to SSP1 or some general industry DNS? I’m tryin= g to=20 understand how SSP1 modifies an RR for an SSP2=20 number.

 =

Thanks,

 =

Penn=20 Pfautz

AT&T Acce= ss=20 Management

+1-732-420-49= 62=

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51=20 PM
To:=20 'dispatch@ietf.org'
Subject:= =20 [dispatch] I-D Action:=20 draft-malas-dispatch-sip-egress-route-00

=

 

All,=

 

A New Internet-Draft is avail= able=20 from the on-line Internet-Drafts directories.
 
Title : SIP Egr= ess=20 Route Use in ENUM
Author(s) : D. Malas
Filename :=20 draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date :=20 2010-03-01
 
In some cases a UA (or proxy) within a Session=20 Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple paral= lel=20 egress proxy
options to reach an ingress proxy within another SSP to re= ach=20 the
target UA. If the originating SSP uses ENUM to identify the ingress= =20
proxy of the target SSP, there is currently no way for the ENUM NAPTR=20
response to identify a specific preferred egress proxy from the set of=20 multiple parallel proxies. This draft solves this problem by
defining a= =20 method for returning deterministic routing information
within an ENUM N= APTR=20 response enabling the UA (or proxy) to choose a
preferred egress proxy.= =20 Using this information, the originating UA
now sends the SIP request th= rough=20 the predetermined preferred egress
proxy to reach the target SSP's prox= y.=20 This document describes
several methods to make this determination by=20 incorporating variables
into a SIP service URI contained in the E.164 N= umber=20 Mapping (ENUM)
response.
 
A URL for this Internet-Draft is= :=20
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip= -egress-route-00.txt=20

 

Regards,

 

Daryl

 

---------------------------

Daryl=20 Malas

Project Director, IP=20 Interconnects

w - +1 303 661=20 3302

mailto:d.malas@cablelabs.com=

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1srvxchg_-- From dean.willis@softarmor.com Thu Mar 4 09:21:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAA63A8D93 for ; Thu, 4 Mar 2010 09:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX+GaDCeYl2H for ; Thu, 4 Mar 2010 09:21:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CE1BF3A8DA9 for ; Thu, 4 Mar 2010 09:21:03 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24HL3fo014049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 11:21:04 -0600 Message-Id: <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 11:20:57 -0600 References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:21:07 -0000 On Mar 4, 2010, at 11:05 AM, Daryl Malas wrote: > Dean, > > It has been a long time, since I read the RFC. If I recall > correctly, the biggest problem with TRIP was the issue of Number > Portability. Unlike BGP where there is a common rule of summarizing > IP address blocks into class A's or B's, you cannot do the same with > E.164 addresses. Before number portability, TRIP would work good, > because you can say I have NPA-NX1 through NPA-NX3. If you want to > reach them go here. Now, there are rarely any contiguous blocks for > any service provider. If SSPs used TRIP, they would have to put in > every single E.164 address (e.g. NPA-NXX-XXXX) into a route table. > This would make route tables contain millions of lines, which would > slow down routing considerably...not to mention the maintenance > nightmare...not to mention the route convergence would be ugly. > Perhaps there could be a 3rd party application that searches for > contiguous ranges, but this too would be maintenance heavy as TNs > are ported from one SSP to another; and, there is no guarantee it > would significantly improve the routing database issue. > Ok, that's good input. Really good. I attempt a rephrase: Due to the sparse characteristic of number ranges resulting from LNP, route aggregation just doesn't work for phone numbers. TRIP is based on effective route aggregation; without it, the route-sets grow excessively large. Therefore, an ENUM style model of mapping phone- number to provider (effectively global, relatively static associations that are cacheable) works much better. We expect to do at least one ENUM dip per phone-number in order to find out who the provider for that phone number is. I argue that doing further ENUM dips to find the routes to that provider are a Bad Idea, as this sort of information is arguably not well-suited to a DNS style database. Yes, one can hack together lots of heavily customized- locally-provisioned ENUM servers, but it's still a major operational suckage event. Given this, there would appear to be no reasonable requirement for dynamic routing (BGP/OSPF/TRIP) based on telephone numbers. However, given the inter-provider peering model, there remains a requirement for dynamic routing based on peer identifiers (which I presume to be domain names). So what we need is something that expresses the dynamic and shifting associations of inter-provider peerings and their associated weights and costs, and provides for disseminating this information to our SIP routing nodes. Further, the routing vectors involved are not always single-hops, but need to be able to express multiple-hop vectors. Conversely, the routing vectors need to be able to express aggregate weighting vectors while optionally suppressing remote hops, as such might be needed for masking remote peering agreements. -- Dean From richard@shockey.us Thu Mar 4 09:52:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04BF3A8DC8 for ; Thu, 4 Mar 2010 09:52:34 -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 tcw5AYF47kx3 for ; Thu, 4 Mar 2010 09:52:33 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 782B63A8DCA for ; Thu, 4 Mar 2010 09:52:33 -0800 (PST) Received: (qmail 25707 invoked by uid 0); 4 Mar 2010 17:52:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 4 Mar 2010 17:52:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kGGCoE6Cwjnk5nvAPU0MWVvDX+IZVpplcgbtC7q8VGcxEnJsBHR+w0Mi4lQd8J0vuFcF65IP854zWPBZhhnXUNQUHArnMjXweIflcb+cLM1PsTneY9ceH0jMZWBcfyBW; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NnFDv-0001UZ-G8; Thu, 04 Mar 2010 10:52:35 -0700 From: "Richard Shockey" To: References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <8777_1267721982_4B8FE6FE_8777_41410_1_94C682931C08B048B7A8645303FDC9F30EFBC79E1A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <8777_1267721982_4B8FE6FE_8777_41410_1_94C682931C08B048B7A8645303FDC9F30EFBC79E1A@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 4 Mar 2010 12:52:33 -0500 Message-ID: <004501cabbc3$78397a10$68ac6e30$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7uM8Iwy7Ey+JLSsqUy166UqWw9wAAtTdwAAHtrqA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:52:34 -0000 Asterisk DUNDI ... they use it extensively. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange-ftgroup.com Sent: Thursday, March 04, 2010 12:00 PM To: Dean Willis; dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Dear all, I'm wondering whether it is true to say that TRIP does not provide an answer to the inter-ITAD reachability issue. Whitout going into technical details, why do we have continuous requests for TRIP ITAD identifiers? See http://www.iana.org/assignments/trip-parameters/trip-parameters.xhtml or the IANA reports. Cheers, Med From richard@shockey.us Thu Mar 4 09:55:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0A728C0F2 for ; Thu, 4 Mar 2010 09:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.601 X-Spam-Level: * X-Spam-Status: No, score=1.601 tagged_above=-999 required=5 tests=[AWL=-4.200, BAYES_00=-2.599, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppGAKdDax7Qm for ; Thu, 4 Mar 2010 09:55:34 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 2E57D3A8DC8 for ; Thu, 4 Mar 2010 09:55:34 -0800 (PST) Received: (qmail 873 invoked by uid 0); 4 Mar 2010 17:55:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 4 Mar 2010 17:55:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=X06uMNcieokX/q/rfPxYQPKOX6O1xHJRm6QA+U1+D7T8qF6SfdT/Yw36V/HuTL42Qw/tE4mta9fTuuiExjkHBT5k3DOnhRMVqDGZVQ8nUvrsQNwo+clzr6yp0Rfcag6R; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NnFGp-0003sL-UK; Thu, 04 Mar 2010 10:55:36 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , "'Dean Willis'" , References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> Date: Thu, 4 Mar 2010 12:55:33 -0500 Message-ID: <004601cabbc3$e3cfbe60$ab6f3b20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7uM22b61m3N9wT9SCFQ2mF02RcwAAh4CAAAImC1A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:55:35 -0000 +1 .. you cannot route on number blocks due to LNP. 90% of the NPA NXX 1000 blocks are already broken. How many times to I have to remind people of that? And I don't even work for NSR anymore. And BGP is too heavy weight -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Thursday, March 04, 2010 12:06 PM To: 'Dean Willis'; dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Dean, It has been a long time, since I read the RFC. If I recall correctly, the biggest problem with TRIP was the issue of Number Portability. Unlike BGP where there is a common rule of summarizing IP address blocks into class A's or B's, you cannot do the same with E.164 addresses. Before number portability, TRIP would work good, because you can say I have NPA-NX1 through NPA-NX3. If you want to reach them go here. Now, there are rarely any contiguous blocks for any service provider. If SSPs used TRIP, they would have to put in every single E.164 address (e.g. NPA-NXX-XXXX) into a route table. This would make route tables contain millions of lines, which would slow down routing considerably...not to mention the maintenance nightmare...not to mention the route convergence would be ugly. Perhaps there could be a 3rd party application that searches for contiguous ranges, but this too would be maintenance heavy as TNs are ported from one SSP to another; and, there is no guaran tee it would significantly improve the routing database issue. Perhaps I am just way off on this, but this is my recollection. Regards, Daryl -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, March 04, 2010 9:36 AM To: dispatch@ietf.org Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Richard Shockey said: > And as for TRIP ..been there heard that argument before ..no one is > going to deploy a BGP like function for this. Not going to happen no > more stacks in the proxy's we need to deal with the protocols we have > not try and invent new ones. I'm starting another thread from this comment, because it raises a really good question. TRIP was designed to exchange phone-number reachability information between SIP nodes. Nobody uses it. Why? Is the problem with TRIP is that it's yet another protocol (as Richard suggests above), or is the problem that it doesn't convey the right information, just doesn't work, or something else? What if the route-exchange function were done in SIP, perhaps something like an event package for routing? Here's a possible model using an event package for routing. One might subscribe to the "routing" event package at a node, resulting in being NOTIFY-ed with a list of route vectors being advertised by that node. This allows some interesting things: 1) Since SUBSCRIBE provides the information to specify "who is asking", the NOTIFY responses could contain route-tables customized for the recipient. This provides the location context sensitivity missing from ENUM queries. 2) Route-table entries could be vectors, something like "I, proxy B, have a route to proxy A, which offered me a route to example.com", allowing for selective route-redistribution. 3) Having gotten a preliminary routing table from subscribing to a peer, one could then query the peer's peers by subscribing directly to their routing updates. This establishes SIP reachability to those nodes (if the SUBSCRIBE works, you can reach them with SIP, and if their NOTIFY requests work, they can reach you). Further, it allows the peer's peer to make a determination of which routes they might want to offer you directly, as opposed to transitively via the first peer. 4) Filters in the SUBSCRIBE could be used to indicate an interest in a subset of routes. 5) The routing vector syntax could easily allow for both phone numbers and domain-names. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Thu Mar 4 10:05:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46E63A8DB5 for ; Thu, 4 Mar 2010 10:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpu3p0YARgIN for ; Thu, 4 Mar 2010 10:05:18 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 484673A8B8F for ; Thu, 4 Mar 2010 10:05:18 -0800 (PST) Received: (qmail 28670 invoked by uid 0); 4 Mar 2010 18:05:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 4 Mar 2010 18:05:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=JQtzvOlgGGKL0DbwsR7QwCvIHb63he3L26G5KwrRUUYHDB+YXu7rxJr69ehnC6Fn8OWirsWyY3zTRer/p0zvMQaxMaNB/U7Surl1oWOL52CgqoHHhr4WYBBUKcF6Ux+C; Received: from pool-96-241-62-33.washdc.fios.verizon.net ([96.241.62.33] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NnFQG-0001ee-6v; Thu, 04 Mar 2010 11:05:20 -0700 From: "Richard Shockey" To: "'Dean Willis'" , References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> In-Reply-To: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> Date: Thu, 4 Mar 2010 13:05:17 -0500 Message-ID: <005901cabbc5$4006f670$c014e350$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq7uMu8lHE7YW2PTMmVWiuSYiMmwgACyAOA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.62.33 authed with richard@shockey.us} Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 18:05:19 -0000 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, March 04, 2010 11:36 AM To: dispatch@ietf.org Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Richard Shockey said: > And as for TRIP ..been there heard that argument before ..no one is > going to > deploy a BGP like function for this. Not going to happen no more > stacks in > the proxy's we need to deal with the protocols we have not try and > invent > new ones. I'm starting another thread from this comment, because it raises a really good question. TRIP was designed to exchange phone-number reachability information between SIP nodes. Nobody uses it. Why? RS> Heard of LNP? Is the problem with TRIP is that it's yet another protocol (as Richard suggests above), or is the problem that it doesn't convey the right information, just doesn't work, or something else? RS> IMHO more the former rather than the latter. What if the route-exchange function were done in SIP, perhaps something like an event package for routing? RS> Nahh.. the routing paths change you want a query mechanism that can dynamically change targets based on both internal network topology as well as source identification. Here's a possible model using an event package for routing. One might subscribe to the "routing" event package at a node, resulting in being NOTIFY-ed with a list of route vectors being advertised by that node. This allows some interesting things: 1) Since SUBSCRIBE provides the information to specify "who is asking", the NOTIFY responses could contain route-tables customized for the recipient. This provides the location context sensitivity missing from ENUM queries. RS> You are on to something here which is the dynamic "who is asking" but the response could be lots of things including a SPID or network identifier if the target is truly PSTN and the target URI is a matter of bilateral agreement. This is really about the function of the local proxy directory in a carrier network. I want to simply send an invite but not get back a 302 ..something else which may be some form of routing meta data. 2) Route-table entries could be vectors, something like "I, proxy B, have a route to proxy A, which offered me a route to example.com", allowing for selective route-redistribution. 3) Having gotten a preliminary routing table from subscribing to a peer, one could then query the peer's peers by subscribing directly to their routing updates. This establishes SIP reachability to those nodes (if the SUBSCRIBE works, you can reach them with SIP, and if their NOTIFY requests work, they can reach you). Further, it allows the peer's peer to make a determination of which routes they might want to offer you directly, as opposed to transitively via the first peer. 4) Filters in the SUBSCRIBE could be used to indicate an interest in a subset of routes. 5) The routing vector syntax could easily allow for both phone numbers and domain-names. RS> maybe but gee .. ITS ALL ABOUT PHONE NUMBERS. :-) -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From timothy.dwight@verizon.com Wed Mar 3 20:09:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1101228C4F7 for ; Wed, 3 Mar 2010 20:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vU8ezFC64jZ for ; Wed, 3 Mar 2010 20:09:13 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 547553A8BB6 for ; Wed, 3 Mar 2010 20:09:13 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYQ00FMGOTOFM10@firewall.verizonbusiness.com> for dispatch@ietf.org; Thu, 04 Mar 2010 04:08:12 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYQ00DG6OTOW900@pdcismtp03.vzbi.com> for dispatch@ietf.org; Thu, 04 Mar 2010 04:08:12 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYQ00D1QOTNTZ00@pdcismtp03.vzbi.com> for dispatch@ietf.org; Thu, 04 Mar 2010 04:08:12 +0000 (GMT) Received: from ASHEVS017.vzbi.com ([153.39.71.100]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 04 Mar 2010 04:08:11 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CABB50.4E1AA24B" Date: Thu, 04 Mar 2010 04:08:09 +0000 Message-id: In-reply-to: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPwAAMs4TAABSXPgAAATcwwAAO4knAACNv0sA== References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> From: "Dwight, Timothy M (Tim)" To: Daryl Malas , "PFAUTZ, PENN L (ATTCORP)" X-OriginalArrivalTime: 04 Mar 2010 04:08:11.0576 (UTC) FILETIME=[4E1CAB80:01CABB50] X-Mailman-Approved-At: Thu, 04 Mar 2010 12:00:11 -0800 Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 04:09:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABB50.4E1AA24B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daryl, =20 I agree that defining a best practice often has the impact you suggest. =20 IMHO the technique you describe has merit. What's not clear is how a different response is generated per querying domain. The draft shows response formats that would be appropriate for SSP1, but not appropriate for any other domain. This implies that the response would be somehow tailored for each querying domain. I think some elaboration on how that works (e.g., what has to be provisioned, by whom, to make it happen) would be helpful. =20 tim =20 ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 6:02 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Tim, =20 Thank you for the additional context. I think we are in sync regarding the purposes of the draft as you indicate below. Regarding placing a route header into a local non-ENUM database is obviously outside the scope of the draft. If you use a local private ENUM server to add your own route header (or egress route) to the NAPTR URI, is implementation specific and up to you. Even in this implementation specific case, I believe defining a best practice for defining and including egress information in the NAPTR URI will provide better industry adoption and implementation consistency. Do you agree. =20 Regards, =20 Daryl =20 ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 03, 2010 4:34 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl, =20 I guess our use cases differ. =20 =20 The draft illustrates a NAPTR producing a URI whose host part is the ingress point to SSP2's network through which SSP2 prefers to receive session requests targeted at the example TN. It then talks about mechanisms to include in the ENUM response, information that "steer" the session request message through the "egress point" from SSP1's network, desired by SSP1. =20 I get that. I've done it, in a private ENUM, so I know it's possible. It's a little trickier to manage in the context of a shared registry, but still seems within the capabilities of the commercial ENUM servers with which I'm familiar. Thinking of the "route header" solution, SSP1 could maintain in the registry a table that instructs the registry provider to append a route header identifying SBE2 to any URI whose host part was "SBE3.ssp2.example.com". Although this sort of detail isn't subject to standardization I assume you have something like that in mind. =20 This seems workable in large part because SSP1 and SSP2 will in practice know quite a lot about their interconnection. If SSP1 had no prior knowledge of the "ingress points" (e.g., SBE3) to SSP2's networks, it would be impossible to maintain such a table. But in practice it will know these ingress points; moreover it will know how its own "egress points" are connected to them (e.g., via a partial mesh of IPsec tunnels). Again I'm assuming you have something like this in mind. =20 =20 What I meant to propose, was a different use case. Suppose SSP2 doesn't identify its ingress point in the URI resulting from the NAPTR it returns. Suppose instead it returns a URI whose host part is something like "call-server-1.ssp2.example.com". This is the FQDN of the call server (e.g., softswitch, application server) in SSP2 network that will serve calls to the example TN. Returning such a value avoids SSP2 having to make another routing decision after receiving the call from SSP1. =20 But if you do that, you may also want to "steer" the session request to an ingress point (SBE3 in the draft). This could be done using e.g., a ROUTE header imbedded in the URI in the NAPTR. The logic to determine the content of this ROUTE header is simple since it depends only on where the call is going not where it came from; and easily administered since it would be specified by the same entity that serves the example TN. =20 SSP1 might also want to steer the call through SBE2, which could be done via any of the mechanisms in the draft, or via some table maintained outside of ENUM.=20 =20 The 2 approaches are AFAIK both possible with existing standards and supportable by currently available products. Were it up to me, based on my current (probably flawed and incomplete) understanding, I'd probably do the former (identification of the "ingress point" to the serving domain) in the ENUM database or registry, and the latter (identification of the "egress point" from the querying domain, as a function of the URI returned in an ENUM response) either via some non-ENUM database, or via some "private data" in my local ENUM servers (private meaning not managed by the registry service). =20 Anyway I appreciated and enjoyed the draft, and appreciate the technical exchange. =20 Best regards, =20 Tim =20 =20 ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 3:45 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Tim, =20 SSP2 does provide their preferred "ingress point." This information is still in the ENUM response regardless of whether an additional egress route variable has been added or not. =20 I am not sure I understand your second paragraph. =20 Regards, =20 Daryl =20 ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 03, 2010 12:25 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Why not let SSP2 provide their preferred "ingress point" for session requests addressed to the queried TN, in the ENUM response? That would presumably be the same for all querying networks, and it is data for which the SSP serving the queried TN (SSP2) is authoritative. =20 In the common case of "mated peering points" (e.g., a pair of SBCs in SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local table mapping the remote-network ingress points received in ENUM responses, to its own egress points (i.e., its SBCs that are connected via IPsec to the ingress point in the ENUM response). =20 tim =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Wednesday, March 03, 2010 12:01 PM To: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 I think what you're describing is leaning towards implementation specific questions. I apologize, my example below is backwards, but the principle is the same. SSP2 provisions their numbers and "routes" into the ENUM server. SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify their own egress routes in the same ENUM server. =20 The method for SSP1's egress routes for SSP2 to be received into a "local copy" is implementation specific, imo. This being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when they query the ENUM server. If this is resolved in some "for queries from here give this" or "here is a local copy of peer numbers and routes plus *your* egress routes" is implementation specific. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl=20 I was a little confused by this since I thought the call was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local copy I can see that but I wouldn't expect the resulting elaborated NAPTRs to be in the Registry.=20 Have I got this right now? =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 The use case for this application is SSP1 (or someone on their behalf) provisions their numbers and relative routes into the LUF associated with their federation. SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned. They then add an egress route and associate it with the ingress route SSP1 provisioned. =20 Let me know if this makes sense. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl: I want to be sure I understand what you're proposing. In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. =20 Thanks, =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 All, =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : SIP Egress Route Use in ENUM=20 Author(s) : D. Malas=20 Filename : draft-malas-dispatch-sip-egress-route-00.txt=20 Pages : 11=20 Date : 2010-03-01=20 =20 In some cases a UA (or proxy) within a Session Initiation Protocol=20 [RFC3261] Service Provider (SSP) has multiple parallel egress proxy=20 options to reach an ingress proxy within another SSP to reach the=20 target UA. If the originating SSP uses ENUM to identify the ingress=20 proxy of the target SSP, there is currently no way for the ENUM NAPTR=20 response to identify a specific preferred egress proxy from the set=20 of multiple parallel proxies. This draft solves this problem by=20 defining a method for returning deterministic routing information=20 within an ENUM NAPTR response enabling the UA (or proxy) to choose a=20 preferred egress proxy. Using this information, the originating UA=20 now sends the SIP request through the predetermined preferred egress=20 proxy to reach the target SSP's proxy. This document describes=20 several methods to make this determination by incorporating variables=20 into a SIP service URI contained in the E.164 Number Mapping (ENUM)=20 response.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout e-00.txt=20 =20 Regards, =20 Daryl =20 --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com =20 =20 ------_=_NextPart_001_01CABB50.4E1AA24B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Daryl,

 

I agree = that defining a best practice often has the impact you = suggest.

 

IMHO the technique you describe has merit.  What’s not clear is how a = different response is generated per querying domain.  The draft shows = response formats that would be appropriate for SSP1, but not appropriate for any other = domain.  This implies that the response would be somehow tailored for each querying = domain.  I think some elaboration on how that works (e.g., what has to be = provisioned, by whom, to make it happen) would be helpful.

 

tim

 

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 6:02 PM
To: Dwight, Timothy M = (Tim); PFAUTZ, PENN L (ATTCORP)
Cc: dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

Thank you for the additional context.  I think we are in sync regarding the purposes = of the draft as you indicate below.  Regarding placing a route header into = a local non-ENUM database is obviously outside the scope of the = draft.  If you use a local private ENUM server to add your own route header (or = egress route) to the NAPTR URI, is implementation specific and up to you.  = Even in this implementation specific case, I believe defining a best practice = for defining and including egress information in the NAPTR URI will provide = better industry adoption and implementation consistency.  Do you = agree.

 

Regards,

 

Daryl

 

From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March = 03, 2010 4:34 PM
To: Daryl Malas; PFAUTZ, = PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl,

 

I guess = our use cases differ.  

 

The = draft illustrates a NAPTR producing a URI whose host part is the ingress point = to SSP2’s network through which SSP2 prefers to receive session = requests targeted at the example TN.  It then talks about mechanisms to = include in the ENUM response, information that “steer” the session = request message through the “egress point” from SSP1’s = network, desired by SSP1.

 

I get = that.  I’ve done it, in a private ENUM, so I know it’s possible.  It’s a little trickier to manage in the context of a shared registry, but still seems within the capabilities of the commercial ENUM servers with which I’m familiar.  Thinking of the = “route header” solution, SSP1 could maintain in the registry a table that instructs the registry provider to append a route header identifying = SBE2 to any URI whose host part was “SBE3.ssp2.example.com”. =  Although this sort of detail isn’t subject to standardization I assume you = have something like that in mind.

 

This = seems workable in large part because SSP1 and SSP2 will in practice know quite = a lot about their interconnection.  If SSP1 had no prior knowledge of the “ingress points” (e.g., SBE3) to SSP2’s networks, it = would be impossible to maintain such a table.  But in practice it will know = these ingress points; moreover it will know how its own “egress = points” are connected to them (e.g., via a partial mesh of IPsec tunnels).  = Again I’m assuming you have something like this in = mind.

 

 

What I = meant to propose, was a different use case.  Suppose SSP2 doesn’t = identify its ingress point in the URI resulting from the NAPTR it returns. =  Suppose instead it returns a URI whose host part is something like “call-server-1.ssp2.example.com”.  This is the FQDN of = the call server (e.g., softswitch, application server) in SSP2 network that = will serve calls to the example TN.  Returning such a value avoids SSP2 = having to make another routing decision after receiving the call from = SSP1.

 

But if = you do that, you may also want to “steer” the session request to an ingress point (SBE3 in the draft).  This could be done using e.g., = a ROUTE header imbedded in the URI in the NAPTR.  The logic to determine = the content of this ROUTE header is simple since it depends only on where = the call is going not where it came from; and easily administered since it would = be specified by the same entity that serves the example = TN.

 

SSP1 = might also want to steer the call through SBE2, which could be done via any of the mechanisms in the draft, or via some table maintained outside of ENUM. =

 

The 2 = approaches are AFAIK both possible with existing standards and supportable by = currently available products.  Were it up to me, based on my current = (probably flawed and incomplete) understanding, I’d probably do the former (identification of the “ingress point” to the serving = domain) in the ENUM database or registry, and the latter (identification of the “egress point” from the querying domain, as a function of = the URI returned in an ENUM response) either via some non-ENUM database, or via = some “private data” in my local ENUM servers (private meaning not managed by the registry service).

 

Anyway I appreciated and enjoyed the draft, and appreciate the technical = exchange.

 

Best = regards,

 

Tim

 

 

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 3:45 PM
To: Dwight, Timothy M = (Tim); PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

SSP2 does provide their preferred "ingress point."  This information is still in the ENUM = response regardless of whether an additional egress route variable has been added = or not.

 

I am not sure I understand your = second paragraph.

 

Regards,

 

Daryl

 

From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March = 03, 2010 12:25 PM
To: Daryl Malas; PFAUTZ, = PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Why not = let SSP2 provide their preferred “ingress point” for session requests addressed to the queried TN, in the ENUM response?  That would = presumably be the same for all querying networks, and it is data for which the SSP = serving the queried TN (SSP2) is authoritative.

 

In the = common case of “mated peering points” (e.g., a pair of SBCs in SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local = table mapping the remote-network ingress points received in ENUM responses, to = its own egress points (i.e., its SBCs that are connected via IPsec to the = ingress point in the ENUM response).

 

tim

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Wednesday, March = 03, 2010 12:01 PM
To: 'PFAUTZ, PENN L = (ATTCORP)'; dispatch@ietf.org
Subject: Re: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

I think what you're describing is = leaning towards implementation specific questions.  I apologize, my example = below is backwards, but the principle is the same.  SSP2 provisions their numbers and "routes" into the ENUM server.  SSP1 can see = the ingress routes for SSP2 numbers.  SSP1 can then specify their own = egress routes in the same ENUM server.

 

The method for SSP1's egress = routes for SSP2 to be received into a "local copy" is implementation specific, imo.  This being said, obviously, SSP3 and = SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when = they query the ENUM server.  If this is resolved in some "for = queries from here give this" or "here is a local copy of peer numbers and = routes plus *your* egress routes" is implementation = specific.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Wednesday, March = 03, 2010 10:38 AM
To: Daryl Malas; = dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl =

I was a = little confused by this since I thought the call was from SSP1 to SSP2 and that = SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and = wants to add their egress routes in their local copy I can see that but I wouldn’t expect the resulting elaborated NAPTRs to be in the = Registry.

Have I got = this right now?

 <= /o:p>

Penn = Pfautz

AT&T = Access Management

+1-732-420-496= 2

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 11:22 AM
To: PFAUTZ, PENN L = (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

The use case for this application = is SSP1 (or someone on their behalf) provisions their numbers and = relative routes into the LUF associated with their federation.  SSP2 = reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned.  They then add an egress route and associate it with = the ingress route SSP1 provisioned.

 

Let me know if this makes = sense.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, = 2010 12:24 PM
To: Daryl Malas; = dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl:<= /o:p>

I want to = be sure I understand what you’re proposing.  In what name server would = the modified records be? One local to SSP1 or some general industry DNS? = I’m trying to understand how SSP1 modifies an RR for an SSP2 = number.

 <= /o:p>

Thanks,=

 <= /o:p>

Penn = Pfautz

AT&T = Access Management

+1-732-420-496= 2

From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, = 2010 6:51 PM
To: = 'dispatch@ietf.org'
Subject: [dispatch] I-D = Action: draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR =
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a =
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress =
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables =
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch= -sip-egress-route-00.txt

 

Regards,

 

Daryl

 

---------------------------

Daryl Malas

Project Director, IP = Interconnects

w - +1 303 661 3302

 

------_=_NextPart_001_01CABB50.4E1AA24B-- From timothy.dwight@verizon.com Thu Mar 4 09:42:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD7D3A8B6E for ; Thu, 4 Mar 2010 09:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RzdV5gEgmvz for ; Thu, 4 Mar 2010 09:41:45 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 096FE3A8AB9 for ; Thu, 4 Mar 2010 09:41:45 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYR008GMQCT8NA0@firewall.verizonbusiness.com> for dispatch@ietf.org; Thu, 04 Mar 2010 17:38:54 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYR007IZQCTI000@pdcismtp03.vzbi.com> for dispatch@ietf.org; Thu, 04 Mar 2010 17:38:53 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0KYR00769QCSCK00@pdcismtp03.vzbi.com> for dispatch@ietf.org; Thu, 04 Mar 2010 17:38:53 +0000 (GMT) Received: from ASHEVS017.vzbi.com ([153.39.71.100]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 04 Mar 2010 17:38:52 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CABBC1.8EB7562B" Date: Thu, 04 Mar 2010 17:38:51 +0000 Message-id: In-reply-to: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-index: Acq5mgbTn34+wcFPRqmc6NbP0kve4AAo+LZQACtHrQAAAzHmkAAAUuPwAAMs4TAABSXPgAAATcwwAAO4knAACNv0sAAb7HcAAACmJ7A= References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D1@srvxchg> From: "Dwight, Timothy M (Tim)" To: Daryl Malas , "PFAUTZ, PENN L (ATTCORP)" X-OriginalArrivalTime: 04 Mar 2010 17:38:52.0872 (UTC) FILETIME=[8E956C80:01CABBC1] X-Mailman-Approved-At: Thu, 04 Mar 2010 12:00:11 -0800 Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:42:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABBC1.8EB7562B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daryl, =20 Maybe it would be sufficient to know that there is at least one way it could be done. That way need not be recommended let alone mandatory. Just a demonstration that there is some feasible way to construct the black box that would produce the externally visible behavior the draft describes. That would at least address skepticism about whether it could be built. =20 Ideally though I think we'd want to know more about the applicability of the mechanism; which could either be discussed explicitly or revealed implicitly by the nature of the "straw man" implementation. =20 Tim =20 =20 ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Thursday, March 04, 2010 11:12 AM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Tim, =20 Personally, I think the question of how the information if uniquely conveyed to each individual SSP is an implementation issue. I have seen it work in different methods. My may concern with the draft is to create uniformity in how the information is conveyed to the SIP/ENUM agent. =20 Regards, =20 Daryl =20 ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 03, 2010 9:08 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl, =20 I agree that defining a best practice often has the impact you suggest. =20 IMHO the technique you describe has merit. What's not clear is how a different response is generated per querying domain. The draft shows response formats that would be appropriate for SSP1, but not appropriate for any other domain. This implies that the response would be somehow tailored for each querying domain. I think some elaboration on how that works (e.g., what has to be provisioned, by whom, to make it happen) would be helpful. =20 tim =20 ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 6:02 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Tim, =20 Thank you for the additional context. I think we are in sync regarding the purposes of the draft as you indicate below. Regarding placing a route header into a local non-ENUM database is obviously outside the scope of the draft. If you use a local private ENUM server to add your own route header (or egress route) to the NAPTR URI, is implementation specific and up to you. Even in this implementation specific case, I believe defining a best practice for defining and including egress information in the NAPTR URI will provide better industry adoption and implementation consistency. Do you agree. =20 Regards, =20 Daryl =20 ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 03, 2010 4:34 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl, =20 I guess our use cases differ. =20 =20 The draft illustrates a NAPTR producing a URI whose host part is the ingress point to SSP2's network through which SSP2 prefers to receive session requests targeted at the example TN. It then talks about mechanisms to include in the ENUM response, information that "steer" the session request message through the "egress point" from SSP1's network, desired by SSP1. =20 I get that. I've done it, in a private ENUM, so I know it's possible. It's a little trickier to manage in the context of a shared registry, but still seems within the capabilities of the commercial ENUM servers with which I'm familiar. Thinking of the "route header" solution, SSP1 could maintain in the registry a table that instructs the registry provider to append a route header identifying SBE2 to any URI whose host part was "SBE3.ssp2.example.com". Although this sort of detail isn't subject to standardization I assume you have something like that in mind. =20 This seems workable in large part because SSP1 and SSP2 will in practice know quite a lot about their interconnection. If SSP1 had no prior knowledge of the "ingress points" (e.g., SBE3) to SSP2's networks, it would be impossible to maintain such a table. But in practice it will know these ingress points; moreover it will know how its own "egress points" are connected to them (e.g., via a partial mesh of IPsec tunnels). Again I'm assuming you have something like this in mind. =20 =20 What I meant to propose, was a different use case. Suppose SSP2 doesn't identify its ingress point in the URI resulting from the NAPTR it returns. Suppose instead it returns a URI whose host part is something like "call-server-1.ssp2.example.com". This is the FQDN of the call server (e.g., softswitch, application server) in SSP2 network that will serve calls to the example TN. Returning such a value avoids SSP2 having to make another routing decision after receiving the call from SSP1. =20 But if you do that, you may also want to "steer" the session request to an ingress point (SBE3 in the draft). This could be done using e.g., a ROUTE header imbedded in the URI in the NAPTR. The logic to determine the content of this ROUTE header is simple since it depends only on where the call is going not where it came from; and easily administered since it would be specified by the same entity that serves the example TN. =20 SSP1 might also want to steer the call through SBE2, which could be done via any of the mechanisms in the draft, or via some table maintained outside of ENUM.=20 =20 The 2 approaches are AFAIK both possible with existing standards and supportable by currently available products. Were it up to me, based on my current (probably flawed and incomplete) understanding, I'd probably do the former (identification of the "ingress point" to the serving domain) in the ENUM database or registry, and the latter (identification of the "egress point" from the querying domain, as a function of the URI returned in an ENUM response) either via some non-ENUM database, or via some "private data" in my local ENUM servers (private meaning not managed by the registry service). =20 Anyway I appreciated and enjoyed the draft, and appreciate the technical exchange. =20 Best regards, =20 Tim =20 =20 ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 3:45 PM To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Tim, =20 SSP2 does provide their preferred "ingress point." This information is still in the ENUM response regardless of whether an additional egress route variable has been added or not. =20 I am not sure I understand your second paragraph. =20 Regards, =20 Daryl =20 ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, March 03, 2010 12:25 PM To: Daryl Malas; PFAUTZ, PENN L (ATTCORP) Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Why not let SSP2 provide their preferred "ingress point" for session requests addressed to the queried TN, in the ENUM response? That would presumably be the same for all querying networks, and it is data for which the SSP serving the queried TN (SSP2) is authoritative. =20 In the common case of "mated peering points" (e.g., a pair of SBCs in SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local table mapping the remote-network ingress points received in ENUM responses, to its own egress points (i.e., its SBCs that are connected via IPsec to the ingress point in the ENUM response). =20 tim =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Wednesday, March 03, 2010 12:01 PM To: 'PFAUTZ, PENN L (ATTCORP)'; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 I think what you're describing is leaning towards implementation specific questions. I apologize, my example below is backwards, but the principle is the same. SSP2 provisions their numbers and "routes" into the ENUM server. SSP1 can see the ingress routes for SSP2 numbers. SSP1 can then specify their own egress routes in the same ENUM server. =20 The method for SSP1's egress routes for SSP2 to be received into a "local copy" is implementation specific, imo. This being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when they query the ENUM server. If this is resolved in some "for queries from here give this" or "here is a local copy of peer numbers and routes plus *your* egress routes" is implementation specific. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Wednesday, March 03, 2010 10:38 AM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl=20 I was a little confused by this since I thought the call was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local copy I can see that but I wouldn't expect the resulting elaborated NAPTRs to be in the Registry.=20 Have I got this right now? =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: Daryl Malas [mailto:D.Malas@cablelabs.com]=20 Sent: Wednesday, March 03, 2010 11:22 AM To: PFAUTZ, PENN L (ATTCORP); dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 Penn, =20 The use case for this application is SSP1 (or someone on their behalf) provisions their numbers and relative routes into the LUF associated with their federation. SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned. They then add an egress route and associate it with the ingress route SSP1 provisioned. =20 Let me know if this makes sense. =20 Regards, =20 Daryl =20 ________________________________ From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]=20 Sent: Tuesday, March 02, 2010 12:24 PM To: Daryl Malas; dispatch@ietf.org Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Daryl: I want to be sure I understand what you're proposing. In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number. =20 Thanks, =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Monday, March 01, 2010 6:51 PM To: 'dispatch@ietf.org' Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 =20 All, =20 A New Internet-Draft is available from the on-line Internet-Drafts directories.=20 =20 Title : SIP Egress Route Use in ENUM=20 Author(s) : D. Malas=20 Filename : draft-malas-dispatch-sip-egress-route-00.txt=20 Pages : 11=20 Date : 2010-03-01=20 =20 In some cases a UA (or proxy) within a Session Initiation Protocol=20 [RFC3261] Service Provider (SSP) has multiple parallel egress proxy=20 options to reach an ingress proxy within another SSP to reach the=20 target UA. If the originating SSP uses ENUM to identify the ingress=20 proxy of the target SSP, there is currently no way for the ENUM NAPTR=20 response to identify a specific preferred egress proxy from the set=20 of multiple parallel proxies. This draft solves this problem by=20 defining a method for returning deterministic routing information=20 within an ENUM NAPTR response enabling the UA (or proxy) to choose a=20 preferred egress proxy. Using this information, the originating UA=20 now sends the SIP request through the predetermined preferred egress=20 proxy to reach the target SSP's proxy. This document describes=20 several methods to make this determination by incorporating variables=20 into a SIP service URI contained in the E.164 Number Mapping (ENUM)=20 response.=20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout e-00.txt=20 =20 Regards, =20 Daryl =20 --------------------------- Daryl Malas Project Director, IP Interconnects w - +1 303 661 3302 mailto:d.malas@cablelabs.com =20 =20 ------_=_NextPart_001_01CABBC1.8EB7562B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Daryl,

 

Maybe it = would be sufficient to know that there is at least one way it could be = done.  That way need not be recommended let alone mandatory.  Just a demonstration that = there is some feasible way to construct the black box that would produce the = externally visible behavior the draft describes.  That would at least address = skepticism about whether it could be built.

 

Ideally = though I think we’d want to know more about the applicability of the = mechanism; which could either be discussed explicitly or revealed implicitly by the = nature of the “straw man” implementation.

 

Tim

 

 

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Thursday, March 04, = 2010 11:12 AM
To: Dwight, Timothy M = (Tim); PFAUTZ, PENN L (ATTCORP)
Cc: dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

Personally, I think the question of = how the information if uniquely conveyed to each individual SSP is an implementation issue.  I have seen it work in different = methods.  My may concern with the draft is to create uniformity in how the = information is conveyed to the SIP/ENUM agent.

 

Regards,

 

Daryl

 

From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March = 03, 2010 9:08 PM
To: Daryl Malas; PFAUTZ, = PENN L (ATTCORP)
Cc: dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl,

 

I agree = that defining a best practice often has the impact you = suggest.

 

IMHO the technique you describe has merit.  What’s not clear is how a different response is generated per querying domain.  The draft = shows response formats that would be appropriate for SSP1, but not appropriate = for any other domain.  This implies that the response would be somehow tailored for each querying domain.  I think some elaboration on how = that works (e.g., what has to be provisioned, by whom, to make it happen) = would be helpful.

 

tim

 

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 6:02 PM
To: Dwight, Timothy M = (Tim); PFAUTZ, PENN L (ATTCORP)
Cc: dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

Thank you for the additional context.  I think we are in sync regarding the purposes = of the draft as you indicate below.  Regarding placing a route header into = a local non-ENUM database is obviously outside the scope of the = draft.  If you use a local private ENUM server to add your own route header (or = egress route) to the NAPTR URI, is implementation specific and up to you.  = Even in this implementation specific case, I believe defining a best practice = for defining and including egress information in the NAPTR URI will provide = better industry adoption and implementation consistency.  Do you = agree.

 

Regards,

 

Daryl

 

From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March = 03, 2010 4:34 PM
To: Daryl Malas; PFAUTZ, = PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl,

 

I guess = our use cases differ.  

 

The = draft illustrates a NAPTR producing a URI whose host part is the ingress point = to SSP2’s network through which SSP2 prefers to receive session = requests targeted at the example TN.  It then talks about mechanisms to = include in the ENUM response, information that “steer” the session = request message through the “egress point” from SSP1’s = network, desired by SSP1.

 

I get = that.  I’ve done it, in a private ENUM, so I know it’s possible.  It’s a little trickier to manage in the context of a shared registry, but still seems within the capabilities of the commercial ENUM servers with which I’m familiar.  Thinking of the = “route header” solution, SSP1 could maintain in the registry a table that instructs the registry provider to append a route header identifying = SBE2 to any URI whose host part was “SBE3.ssp2.example.com”. =  Although this sort of detail isn’t subject to standardization I assume you = have something like that in mind.

 

This = seems workable in large part because SSP1 and SSP2 will in practice know quite = a lot about their interconnection.  If SSP1 had no prior knowledge of the “ingress points” (e.g., SBE3) to SSP2’s networks, it = would be impossible to maintain such a table.  But in practice it will know = these ingress points; moreover it will know how its own “egress = points” are connected to them (e.g., via a partial mesh of IPsec tunnels).  = Again I’m assuming you have something like this in = mind.

 

 

What I = meant to propose, was a different use case.  Suppose SSP2 doesn’t = identify its ingress point in the URI resulting from the NAPTR it returns. =  Suppose instead it returns a URI whose host part is something like “call-server-1.ssp2.example.com”.  This is the FQDN of = the call server (e.g., softswitch, application server) in SSP2 network that = will serve calls to the example TN.  Returning such a value avoids SSP2 = having to make another routing decision after receiving the call from = SSP1.

 

But if = you do that, you may also want to “steer” the session request to an ingress point (SBE3 in the draft).  This could be done using e.g., = a ROUTE header imbedded in the URI in the NAPTR.  The logic to determine = the content of this ROUTE header is simple since it depends only on where = the call is going not where it came from; and easily administered since it would = be specified by the same entity that serves the example = TN.

 

SSP1 = might also want to steer the call through SBE2, which could be done via any of the mechanisms in the draft, or via some table maintained outside of ENUM. =

 

The 2 = approaches are AFAIK both possible with existing standards and supportable by = currently available products.  Were it up to me, based on my current = (probably flawed and incomplete) understanding, I’d probably do the former (identification of the “ingress point” to the serving = domain) in the ENUM database or registry, and the latter (identification of the “egress point” from the querying domain, as a function of = the URI returned in an ENUM response) either via some non-ENUM database, or via = some “private data” in my local ENUM servers (private meaning not managed by the registry service).

 

Anyway I appreciated and enjoyed the draft, and appreciate the technical = exchange.

 

Best = regards,

 

Tim

 

 

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 3:45 PM
To: Dwight, Timothy M = (Tim); PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Tim,

 

SSP2 does provide their preferred "ingress point."  This information is still in the ENUM = response regardless of whether an additional egress route variable has been added = or not.

 

I am not sure I understand your = second paragraph.

 

Regards,

 

Daryl

 

From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]
Sent: Wednesday, March = 03, 2010 12:25 PM
To: Daryl Malas; PFAUTZ, = PENN L (ATTCORP)
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Why not = let SSP2 provide their preferred “ingress point” for session requests addressed to the queried TN, in the ENUM response?  That would = presumably be the same for all querying networks, and it is data for which the SSP = serving the queried TN (SSP2) is authoritative.

 

In the = common case of “mated peering points” (e.g., a pair of SBCs in SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local = table mapping the remote-network ingress points received in ENUM responses, to = its own egress points (i.e., its SBCs that are connected via IPsec to the = ingress point in the ENUM response).

 

tim

 

From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Wednesday, March = 03, 2010 12:01 PM
To: 'PFAUTZ, PENN L = (ATTCORP)'; dispatch@ietf.org
Subject: Re: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

I think what you're describing is = leaning towards implementation specific questions.  I apologize, my example = below is backwards, but the principle is the same.  SSP2 provisions their numbers and "routes" into the ENUM server.  SSP1 can see = the ingress routes for SSP2 numbers.  SSP1 can then specify their own = egress routes in the same ENUM server.

 

The method for SSP1's egress = routes for SSP2 to be received into a "local copy" is implementation specific, imo.  This being said, obviously, SSP3 and = SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when = they query the ENUM server.  If this is resolved in some "for = queries from here give this" or "here is a local copy of peer numbers and = routes plus *your* egress routes" is implementation = specific.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Wednesday, March = 03, 2010 10:38 AM
To: Daryl Malas; = dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl =

I was a = little confused by this since I thought the call was from SSP1 to SSP2 and that = SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and = wants to add their egress routes in their local copy I can see that but I wouldn’t expect the resulting elaborated NAPTRs to be in the = Registry.

Have I got = this right now?

 <= /o:p>

Penn = Pfautz

AT&T = Access Management

+1-732-420-496= 2

From: Daryl = Malas [mailto:D.Malas@cablelabs.com]
Sent: Wednesday, March = 03, 2010 11:22 AM
To: PFAUTZ, PENN L = (ATTCORP); dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

 

Penn,

 

The use case for this application = is SSP1 (or someone on their behalf) provisions their numbers and = relative routes into the LUF associated with their federation.  SSP2 = reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned.  They then add an egress route and associate it with = the ingress route SSP1 provisioned.

 

Let me know if this makes = sense.

 

Regards,

 

Daryl

 

From: PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com]
Sent: Tuesday, March 02, = 2010 12:24 PM
To: Daryl Malas; = dispatch@ietf.org
Subject: RE: [dispatch] = I-D Action: = draft-malas-dispatch-sip-egress-route-00

Daryl:<= /o:p>

I want to = be sure I understand what you’re proposing.  In what name server would = the modified records be? One local to SSP1 or some general industry DNS? = I’m trying to understand how SSP1 modifies an RR for an SSP2 = number.

 <= /o:p>

Thanks,=

 <= /o:p>

Penn = Pfautz

AT&T = Access Management

+1-732-420-496= 2

From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas
Sent: Monday, March 01, = 2010 6:51 PM
To: = 'dispatch@ietf.org'
Subject: [dispatch] I-D = Action: draft-malas-dispatch-sip-egress-route-00

 

All,

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01
 
In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR =
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a =
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress =
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables =
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch= -sip-egress-route-00.txt

 

Regards,

 

Daryl

 

---------------------------

Daryl Malas

Project Director, IP = Interconnects

w - +1 303 661 3302

 

------_=_NextPart_001_01CABBC1.8EB7562B-- From kpfleming@digium.com Thu Mar 4 14:21:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC5C3A8D27 for ; Thu, 4 Mar 2010 14:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZToTmK-T9jv for ; Thu, 4 Mar 2010 14:21:27 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 8BFA23A8CA3 for ; Thu, 4 Mar 2010 14:21:26 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NnJQ7-0001BQ-Oa; Thu, 04 Mar 2010 16:21:27 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A7E09D8007; Thu, 4 Mar 2010 16:21:27 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4h+e55ckGCu; Thu, 4 Mar 2010 16:21:27 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2CD2CD8003; Thu, 4 Mar 2010 16:21:27 -0600 (CST) Message-ID: <4B903266.40708@digium.com> Date: Thu, 04 Mar 2010 16:21:26 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Paul E. Jones" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> <002501caa30e$92abc240$b80346c0$@com> In-Reply-To: <002501caa30e$92abc240$b80346c0$@com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 22:21:29 -0000 Paul E. Jones wrote: > As an informational RFC, the objective would be nothing more than to > document the issues that have been identified. It does not try to address a > problem, but merely raise awareness to issues in a manner similar to many > other Informational RFCs over the years. It's been a few weeks, but we've finally also published the problem statement that focuses on SIP/SDP issues related to FAX over IP, and it is located here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,412/Itemid,261/ There has been some discussion amongst our SIP Forum working group about possibly combining the initial problem statement and this new one as step towards making a document that is more likely to be accepted (and relevant) as an informational RFC. Are there others here who feel that would be a worthwhile exercise? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From dean.willis@softarmor.com Thu Mar 4 21:19:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C77A3A8AEA for ; Thu, 4 Mar 2010 21:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 AwewwlbRGTHg for ; Thu, 4 Mar 2010 21:19:11 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5145628C1C5 for ; Thu, 4 Mar 2010 21:19:09 -0800 (PST) Received: from [192.168.2.118] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o255J9wM018309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Mar 2010 23:19:11 -0600 Message-ID: <4B909448.9080803@softarmor.com> Date: Thu, 04 Mar 2010 23:19:04 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <005901cabbc5$4006f670$c014e350$@us> In-Reply-To: <005901cabbc5$4006f670$c014e350$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 05:19:14 -0000 Richard Shockey wrote: > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Thursday, March 04, 2010 11:36 AM > To: dispatch@ietf.org > Subject: [dispatch] Why are we TRIPped out? Is there an sip-event > alternative? > > Richard Shockey said: > > >> And as for TRIP ..been there heard that argument before ..no one is >> going to >> deploy a BGP like function for this. Not going to happen no more >> stacks in >> the proxy's we need to deal with the protocols we have not try and >> invent >> new ones. >> > > I'm starting another thread from this comment, because it raises a > really good question. > > TRIP was designed to exchange phone-number reachability information > between SIP nodes. Nobody uses it. Why? > > RS> Heard of LNP? > > Is the problem with TRIP is that it's yet another protocol (as Richard > suggests above), or is the problem that it doesn't convey the right > information, just doesn't work, or something else? > > RS> IMHO more the former rather than the latter. > > What if the route-exchange function were done in SIP, perhaps > something like an event package for routing? > > RS> Nahh.. the routing paths change you want a query mechanism that can > dynamically change targets based on both internal network topology as well > as source identification. an event package could satisfy both of those. > > RS> You are on to something here which is the dynamic "who is asking" but > the response could be lots of things including a SPID or network identifier > if the target is truly PSTN and the target URI is a matter of bilateral > agreement. This is really about the function of the local proxy directory in > a carrier network. I want to simply send an invite but not get back a 302 > ..something else which may be some form of routing meta data. > > But hoe does the local proxy learn this stuff? This still calls for a dynamically modeled routing topology. > RS> maybe but gee .. ITS ALL ABOUT PHONE NUMBERS. :-) > but you just said route aggregationon phone numbers doesn't work due to lnp! -- dean From mohamed.boucadair@orange-ftgroup.com Thu Mar 4 23:38:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB7428C1CF for ; Thu, 4 Mar 2010 23:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 vq+yNBqLopxT for ; Thu, 4 Mar 2010 23:38:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id E1F0E3A63EB for ; Thu, 4 Mar 2010 23:38:19 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 70A661B880B; Fri, 5 Mar 2010 08:38:20 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 58854384066; Fri, 5 Mar 2010 08:38:20 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 5 Mar 2010 08:38:20 +0100 From: To: Dean Willis , Daryl Malas Date: Fri, 5 Mar 2010 08:38:19 +0100 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq7vxjuU57+6RO5TdKA2pHBbN9rtAAdg9lg Message-ID: <22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> In-Reply-To: <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.5.64228 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 07:38:22 -0000 =20 Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Partners in= volved in that study all agreed that a more distributed mode and dynamic mo= de is suitable to meet the global reachability requirement and also to allo= w for a more flexible interconnection model. A consensus has been reached a= mong participant, that placing communications would involve several ITAD in= the path and thus this characteristic should be known before selecting the= next ITAD domain for the delivery of a call (e.g., avoid domains of compet= ing SPs, avoid black listed ITADs, avoid congested links, allow multiple IP= telephony paths, minimize interconnection cost, and in general allow for m= ore traffic engineering at the telephony level, etc.)=20 Below is listed a set of recommendations that has been proposed but the P18= 53 study when specifying and designing an interconnection model for session= -based services. These recommendations have been drawn from the perspective= of IP telephony services but are valid for presence, Instant Message, etc: 1. Adopt the same interconnection model for various services relying on loo= kup function. Particularly: IP telephony, video, IM and presence. 2. Implement a cascaded model (i.e., several ITAD hop for placing a call): . For flexibility and scalability reasons; . Offers both peering and transit modes; . Does not lead to a frozen service architecture; 3. Functional separation between the lookup service and session management = (i.e., initiation, terminating, modify, etc.). In particular, SIP is a sess= ion management protocol and ** not ** a telephony routing protocol; 4. Activate dynamic means to exchange telephony routing information: . Abolish the usage of static practices and "file" based model; . The protocol can be used to interconnect internal service platforms and a= lso with external ones; . Convey information to assess the telephony routes. 5. Encourage aggregation-based advertisement model: . Optimise the telephony routing tables/ENUM records, etc.; . Check how number portability affects aggregation; . How to support roaming. 6. Adopt a model supporting both closed and open communities which supports= the federation scheme and compatible with IP telephony Exchange points pre= sence; 7. Investigate means to assess the stability and the convergence of the ove= rall IP telephony interconnection model; 8. Promote interconnection practices which are ** agnostic ** to the used s= ignaling and media protocol; 9. Use "Media trunks" instead of individual streams: reduce messages overhe= ad, bandwidth optimisation, etc.; 10. Standardize/share/promote SIA (Service Interconnection Agreement) templ= ate and its technical clauses; 11. Investigate means/procedures to negotiate SIAs; 12. Adapt the billing/charging model for inter-domain IP telephony services; 13. Elaborate an inter-domain monitoring model including a template, method= ology, etc.; 14. Specify means to enable sophisticated service engineering: load balanci= ng, SIA optimisation, cost optimisation, avoid congestion and loops, enhanc= e QoS, etc.; 15. Activate automatic failure/degradation detection and recovery means at = the service level; 16. Promote means to ensure synchronization between the service and network= layers; 17. Provisioning considerations: routing information, access control, polic= ies, SIA to network nodes; 18. Consider legal recommendations (e.g. legal intercept); 19. Encourage a "Service Provider SIP/H.323 profile": this reduces the comp= lexity of required functions in SBC nodes, protocol repair functions may be= obsolete, etc.; 20. Interconnection model/solution should support planned maintenance opera= tions (e.g. update physical card, link, add new node, etc.); 21. Extended TRIP protocol is suggested to be used as base for IP Telephony= routing; 22. Use simple coherent SIA profiling for homogeneous traffic and to avoid = added complexity in routing optimisation. Interconnection Agreements should= constantly be reviewed and a minimum utilization threshold defined. Interc= onnections with low usage should be cancelled to reduce cost and complexity; 23. Employ active, non-intrusive measurements on live traffic with probes t= o ensure that interconnections meet the agreed requirements, maintain high = service quality, increase reliability, detect and avoid failures even befor= e they occur, avoid misuse (e.g. SPIT) in the network, etc. A monitoring te= mplate should be determined before deployment; 24. In the SIAs to ensure quality, with a minimum MOS score of 3.6, prefera= bly above 4.0, one-way delay less than 250 ms (even for transatlantic links= ) and packet loss below 2%. Active measurements should be employed to updat= e and confirm SIAs. Cheers, Med -----Message d'origine----- De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la par= t de Dean Willis Envoy=E9 : jeudi 4 mars 2010 18:21 =C0 : Daryl Malas Cc : dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? On Mar 4, 2010, at 11:05 AM, Daryl Malas wrote: > Dean, > > It has been a long time, since I read the RFC. If I recall=20=20 > correctly, the biggest problem with TRIP was the issue of Number=20=20 > Portability. Unlike BGP where there is a common rule of summarizing=20= =20 > IP address blocks into class A's or B's, you cannot do the same with=20= =20 > E.164 addresses. Before number portability, TRIP would work good,=20=20 > because you can say I have NPA-NX1 through NPA-NX3. If you want to=20=20 > reach them go here. Now, there are rarely any contiguous blocks for=20= =20 > any service provider. If SSPs used TRIP, they would have to put in=20=20 > every single E.164 address (e.g. NPA-NXX-XXXX) into a route table.=20=20= =20 > This would make route tables contain millions of lines, which would=20=20 > slow down routing considerably...not to mention the maintenance=20=20 > nightmare...not to mention the route convergence would be ugly.=20=20=20 > Perhaps there could be a 3rd party application that searches for=20=20 > contiguous ranges, but this too would be maintenance heavy as TNs=20=20 > are ported from one SSP to another; and, there is no guarantee it=20=20 > would significantly improve the routing database issue. > Ok, that's good input. Really good. I attempt a rephrase: Due to the sparse characteristic of number ranges resulting from LNP,=20=20 route aggregation just doesn't work for phone numbers. TRIP is based=20=20 on effective route aggregation; without it, the route-sets grow=20=20 excessively large. Therefore, an ENUM style model of mapping phone-=20 number to provider (effectively global, relatively static associations=20= =20 that are cacheable) works much better. We expect to do at least one ENUM dip per phone-number in order to=20=20 find out who the provider for that phone number is. I argue that doing=20= =20 further ENUM dips to find the routes to that provider are a Bad Idea,=20=20 as this sort of information is arguably not well-suited to a DNS style=20= =20 database. Yes, one can hack together lots of heavily customized-=20 locally-provisioned ENUM servers, but it's still a major operational=20=20 suckage event. Given this, there would appear to be no reasonable requirement for=20=20 dynamic routing (BGP/OSPF/TRIP) based on telephone numbers. However,=20=20 given the inter-provider peering model, there remains a requirement=20=20 for dynamic routing based on peer identifiers (which I presume to be=20=20 domain names). So what we need is something that expresses the dynamic and shifting=20=20 associations of inter-provider peerings and their associated weights=20=20 and costs, and provides for disseminating this information to our SIP=20=20 routing nodes. Further, the routing vectors involved are not always=20=20 single-hops, but need to be able to express multiple-hop vectors.=20=20 Conversely, the routing vectors need to be able to express aggregate=20=20 weighting vectors while optionally suppressing remote hops, as such=20=20 might be needed for masking remote peering agreements. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From laura.liess.dt@googlemail.com Fri Mar 5 04:37:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1EB28C0DC for ; Fri, 5 Mar 2010 04:37:37 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Xc+qaKrkwerS for ; Fri, 5 Mar 2010 04:37:36 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 483273A6816 for ; Fri, 5 Mar 2010 04:37:36 -0800 (PST) Received: by wyb40 with SMTP id 40so2032288wyb.31 for ; Fri, 05 Mar 2010 04:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7N3UAxEwdfDT6cm6coeBetrNF3On+hVq0NXt1Ptvx6k=; b=jgV1RycYBlPEFpoNla/4ZaNxd8HmxQ0M1/sE/FTTHEin8LHjOLVfwQ9nfQcEzmTP8e O/1TEkTahlBpR9+P162g009I+xkqv889w1XfJNnhVv6lKVwEYbLmOEbS7Lwm6GvJAPv9 1Hn06J3b6/kMDTsYoPLnalvljrrrcN+R6NrqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=n0sA/pAfSWiF+VknreSojc8eBB2kYwv2Ju209W0qlrgJC+imi6wL7qiUYnGy9hXgVB GNn1QtE6ykaXYz3DtAF3FlJOnhzIlVBxycyHwtBVyCnKRyKYkh0e+hqRb62M6PLvcP1x k523rMFSd4JSU0R6P0EWX4XW4Hd8sBkh66M8Y= MIME-Version: 1.0 Received: by 10.216.157.1 with SMTP id n1mr51765wek.188.1267792654346; Fri, 05 Mar 2010 04:37:34 -0800 (PST) Date: Fri, 5 Mar 2010 13:37:34 +0100 Message-ID: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> From: Laura Liess To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 05 Mar 2010 05:51:00 -0800 Subject: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 12:37:37 -0000 Hi, We submitted a new version of the Alert-Info URN draft. The new version incorporates the ML discussions where we think we already reached a clear agreement. There are still open points. The most important changes are: - Requirements added/changed to incorporate the "semantic vs. non-semantic" discussion and the new non-semantic examples from the list. - New alert-identifier "ringback" added. - Chapter 4.2 "Public telephone network tones" deleted. "Busy", "intrusion" and "record" were not correct anyway. Country list for ringback tones deleted, reference to ISO 3166-1. - Section 4.3.6 on crisis deleted - "tone" and "ringback" combination deleted from chapter "Combinations of URN". - Chapter "Combination Rules for Alert URN Indications" upgraded. We hope the rules are much more simple now when we distinguish between ring tones and ringback tones. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Alert-Info URNs for the Session Initiation Protocol (SIP) Author(s) : D. Alexeitsev, et al. Filename : draft-liess-dispatch-alert-info-urns-01.txt Pages : 20 Date : 2010-02-26 The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Kind regards, Laura From pkyzivat@cisco.com Fri Mar 5 07:37:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B98928C17F for ; Fri, 5 Mar 2010 07:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.16 X-Spam-Level: X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAGl8eBnaVMX for ; Fri, 5 Mar 2010 07:37:56 -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 0523E28C178 for ; Fri, 5 Mar 2010 07:37:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ+0kEtAZnwN/2dsb2JhbACbRXOeP5hfgleCJgSDFw X-IronPort-AV: E=Sophos;i="4.49,587,1262563200"; d="scan'208";a="90853632" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Mar 2010 15:37:57 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o25FbvXm009856; Fri, 5 Mar 2010 15:37:57 GMT Message-ID: <4B912555.4020604@cisco.com> Date: Fri, 05 Mar 2010 10:37:57 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> In-Reply-To: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 15:37:57 -0000 Laura, Comments inline and at the end. Laura Liess wrote: > Hi, > > We submitted a new version of the Alert-Info URN draft. > > The new version incorporates the ML discussions where we think we > already reached a clear agreement. There are still open points. > > The most important changes are: > - Requirements added/changed to incorporate the "semantic vs. > non-semantic" discussion and the new non-semantic examples from the > list. > - New alert-identifier "ringback" added. > - Chapter 4.2 "Public telephone network tones" deleted. "Busy", > "intrusion" and "record" were not correct anyway. Country list for > ringback tones deleted, reference to ISO 3166-1. > - Section 4.3.6 on crisis deleted Then why is it still mentioned in REQ-2? > - "tone" and "ringback" combination deleted from chapter "Combinations of URN". > - Chapter "Combination Rules for Alert URN Indications" upgraded. We > hope the rules are much more simple now when we distinguish between > ring tones and ringback tones. ---------- Section 1: This specification does not change the usage of the SIP Alert-Info- header defined in the RFC3261. The Alert-Info-header can be used in INVITE requests and 180 Ringing responses. IMO it would make sense to make an extension to 3261 to permit this header in any 18x response. This could help resolve issues about what ought to be rendered to the caller in case of 182 or 183. Section 3: ... The left-most label is called "alert-category" and is separated from right-side of the alert-identifier, the alert-indication, by a semicolon... urn:alert:tone:{tone-indication} The text says "semicolon" but the example uses colon, and the ABNF also shows colon. Section 4: The way the word "tone" is used in this section could cause confusion, after having gone to the trouble of explaining that this mechanism is for indicating semantic intent that might not be rendered as tones. Its further confused because section 4.1 PBX Tones are encoded using urn:alert:tone, but that 4.2 Service Tones are encoded using urn:alert:service. I suggest using some other word than "tone" in cases when audio rendering may not be used. For example "indication". Perhaps "caller indication" could be used instead of ringback, and "callee indication" could be used instead of "ring". (Thats in descriptive text. Perhaps the alert-category of "tone" should be changed too, but I'm not ready to propose that yet.) Sections 4.2.6, 4.2.7, 4.2.8: These talk about "this sub-level". But sub-level isn't defined anywhere. There is "sub-indication" in the ABNF, but the examples given in these sections don't use that. These are shown as urn:alert:tone, which means they can only be used for callee indication, not caller indication. Is that intended? I know this might open old wounds, but perhaps it would be better to make these values simply be sub-indications on those values where it makes sense. But if you don't want to go there I understand. Section 4.3: Aren't there also country-specific ring tones? (I know the British ones in the movies are different from the American ones.) Should there be provision for specifying these? See more on this below. Why no provision for non-country-specific ringbacks? This is potentially a case for customization - perhaps the callee's presence status could be used by the callee to select an appropriate ringback to the caller. Section 4.4: Are all combinations potentially valid? Or can there be at most one per category? How about having alert:modifier as a category? Then all the other categories could be mutually exclusive, and zero or more modifiers would adjust whatever one was supplied. In that case, priority, zip, and delayed would be modifiers. (Maybe normal also ought to be a modifier, and maybe country code should also be a modifier - urn:alert:modifier:country:za.) Section 5: I think it would be a good idea to mention something about what a UA should do with these in more complex cases: - alert-info received but in-band media also received - an invite was forked and the UAC is getting responses from multiple early dialogs, containing conflicting alert-info and/or in-band media. It occurs to me that in some cases early media should preempt the rendering of alert-info, but in other cases it should not. Maybe that should be left to implementor discretion, but maybe there are cases where this should be deterministic - I haven't thought about it enough to have a firm opinion. Rolling all that up into some overall suggestions: You have some things that only apply to the "ring", some that only apply to the "ringback" and some that apply to both. And then there are things that can act as modifiers to any of the others. But the distinction between ring and ringback is redundant with the message it travels in. So how about: urn:alert:service:xxx has all the things you have as services plus all the things you have as "tones". In an INVITE external/internal describe the caller, and in a 18x they describe the callee. Maybe some additional values that are useful for describing the callee status. urn:alert:modifier:xxx where xxx is priority/zip/delayed or country.cc where cc is a country code. Combinations allowed are one service, and one or more distinct modifiers. (Must be distinct based on top-level.) From bernard_aboba@hotmail.com Fri Mar 5 08:29:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0F93A8CAB for ; Fri, 5 Mar 2010 08:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjZq0eC1r4HJ for ; Fri, 5 Mar 2010 08:29:47 -0800 (PST) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by core3.amsl.com (Postfix) with ESMTP id 9B76B3A8965 for ; Fri, 5 Mar 2010 08:29:47 -0800 (PST) Received: from BLU137-DS9 ([65.55.111.135]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 08:29:49 -0800 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 5 Mar 2010 08:29:50 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01CABC3E.06563E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acq8gNbfkSTm+NtsRgSL1Qj1eFUAKg== Content-Language: en-us X-OriginalArrivalTime: 05 Mar 2010 16:29:49.0775 (UTC) FILETIME=[1384BDF0:01CABC81] Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 16:29:51 -0000 ------=_NextPart_000_0085_01CABC3E.06563E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kevin Fleming said: "It's been a few weeks, but we've finally also published the problem statement that focuses on SIP/SDP issues related to FAX over IP, and it is located here: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,41 2/Itemid,261/ There has been some discussion amongst our SIP Forum working group about possibly combining the initial problem statement and this new one as step towards making a document that is more likely to be accepted (and relevant) as an informational RFC. Are there others here who feel that would be a worthwhile exercise?" [BA] The original document was largely focused on issues outside the IETF (e.g. problems with T.38). That can't be said about this document. Given that, it might make more sense to focus on the new document rather than combining it with the previous statement. ------=_NextPart_000_0085_01CABC3E.06563E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kevin = Fleming said:

 

“It's been a few weeks, but we've finally = also published the problem statement that focuses on SIP/SDP issues = related to FAX over IP, and it is located here:

 

http://www.sipforum.org/component/option,com_do= cman/task,doc_download/gid,412/Itemid,261/

 

There = has been some discussion amongst our SIP Forum working group about = possibly combining the initial problem statement and this new one as = step towards making a document that is more likely to be accepted (and = relevant) as an informational RFC.

 

Are = there others here who feel that would be a worthwhile = exercise?”

 

 

[BA] = The original document was largely focused on issues outside the IETF = (e.g. problems with T.38).  That can’t be said about this = document.  Given that, it might make more sense to focus on the new = document rather than combining it with the previous statement. =

------=_NextPart_000_0085_01CABC3E.06563E30-- From fluffy@cisco.com Fri Mar 5 08:54:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979DF3A8B1F for ; Fri, 5 Mar 2010 08:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAhMRYmftpOv for ; Fri, 5 Mar 2010 08:54:10 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9153D3A8965 for ; Fri, 5 Mar 2010 08:54:10 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMjFkEurRN+J/2dsb2JhbACbSHOeeJhYhHcEgxc X-IronPort-AV: E=Sophos;i="4.49,588,1262563200"; d="scan'208";a="96458548" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Mar 2010 16:54:13 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o25GsC8a000957; Fri, 5 Mar 2010 16:54:12 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4B903266.40708@digium.com> Date: Fri, 5 Mar 2010 09:54:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> <002501caa30e$92abc240$b80346c0$@com> <4B903266.40708@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1077) Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 16:54:11 -0000 In my previous email about this documents needs, I put=20 >>> The more important part to publish IMHO is >>> documenting some issues, problems, deficiencies and/or bugs in some >>> IETF specifications that are leading to lack of interoperability in >>> deployments. That type of problem statement would be great = information >>> to get written down in a concrete form that allows the appropriate = WG >>> to go fix the problems. The stuff you have in=20 > = http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,= 412/Itemid,261/ is exactly the sort of level of detail I was hoping for.=20 Some of these items are about issues which ITU-T protocol which are = probably not appropriate for an IETF document but many of them are = issues with IETF protocols, or limitations where the some other protocol = may require new parameters in SDP to resolve the issues. All these seem = very appropriate for an IETF document.=20 So I certainly think combining some of this would result in a draft that = was more useful for the IETF to help fix fax problems.=20 Cullen=20 On Mar 4, 2010, at 3:21 PM, Kevin P. Fleming wrote: > Paul E. Jones wrote: >=20 >> As an informational RFC, the objective would be nothing more than to >> document the issues that have been identified. It does not try to = address a >> problem, but merely raise awareness to issues in a manner similar to = many >> other Informational RFCs over the years. >=20 > It's been a few weeks, but we've finally also published the problem > statement that focuses on SIP/SDP issues related to FAX over IP, and = it > is located here: >=20 > = http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,= 412/Itemid,261/ >=20 > There has been some discussion amongst our SIP Forum working group = about > possibly combining the initial problem statement and this new one as > step towards making a document that is more likely to be accepted (and > relevant) as an informational RFC. >=20 > Are there others here who feel that would be a worthwhile exercise? >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dean.willis@softarmor.com Fri Mar 5 10:16:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E0F28C154 for ; Fri, 5 Mar 2010 10:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiPmWYKkg+oK for ; Fri, 5 Mar 2010 10:16:02 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 624913A897A for ; Fri, 5 Mar 2010 10:16:02 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25IFwZX025276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Mar 2010 12:16:00 -0600 Message-Id: From: Dean Willis To: "" In-Reply-To: <22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary=Apple-Mail-4--404538706 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 12:15:53 -0600 References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> <22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 18:16:03 -0000 --Apple-Mail-4--404538706 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 5, 2010, at 1:38 AM, wrote: > > Dear Dean, all, > > In the last year, we have undertaken a study about IP telephony > interconnect at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp) > . I'm having a hard time resolving this link, as it appears to be 404. Perhaps there's a typo? With respect to: > > 21. Extended TRIP protocol is suggested to be used as base for IP > Telephony routing; We've heard here that TRIP, as currently modeled, doesn't work due to the LNP problem. What sorts of extensions id you have in mind? Were they intended to address this problem? -- Dean --Apple-Mail-4--404538706 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable


Dear Dean, all,

In the last year, we have = undertaken a study about IP telephony interconnect at large scale (URL: = http://www.eurescom.eu/m= essage/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_= study_P1853.asp).

I'm having a = hard time resolving this link, as it appears to be 404. Perhaps there's = a typo?

With respect = to:


21. Extended TRIP protocol is = suggested to be used as base for IP Telephony = routing;

We've heard here that = TRIP, as currently modeled, doesn't work due to the LNP problem. What = sorts of extensions id you have in mind? Were they intended to address = this = problem?

--
Dean

= --Apple-Mail-4--404538706-- From BPenfield@acmepacket.com Fri Mar 5 10:25:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F193A8DAD for ; Fri, 5 Mar 2010 10:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItU2qCExBQkz for ; Fri, 5 Mar 2010 10:25:25 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 957453A8612 for ; Fri, 5 Mar 2010 10:25:24 -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.375.2; Fri, 5 Mar 2010 13:25:24 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 5 Mar 2010 13:25:24 -0500 From: Bob Penfield To: Dean Willis , "" Date: Fri, 5 Mar 2010 13:25:22 -0500 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j/gRuau34yg2SFuH9ih4ttQebQAAQ9nA Message-ID: <429446390BA91242867940DBE798A06B7B26BBBB5F@mail> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> <22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_429446390BA91242867940DBE798A06B7B26BBBB5Fmail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 18:25:30 -0000 --_000_429446390BA91242867940DBE798A06B7B26BBBB5Fmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It does not like the trailing ")", this one worked for me: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of= _IP_telephony_Eurescom_study_P1853.asp From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dean Willis Sent: Friday, March 05, 2010 1:16 PM To: Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? On Mar 5, 2010, at 1:38 AM, > > wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). I'm having a hard time resolving this link, as it appears to be 404. Perhap= s there's a typo? With respect to: 21. Extended TRIP protocol is suggested to be used as base for IP Tel= ephony routing; We've heard here that TRIP, as currently modeled, doesn't work due to the L= NP problem. What sorts of extensions id you have in mind? Were they intende= d to address this problem? -- Dean --_000_429446390BA91242867940DBE798A06B7B26BBBB5Fmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It does not like the trailing “)”, this one work= ed for me:

 

http://www.eurescom.eu/message/messageMay2009/Interconnectio= n_challenges_of_IP_telephony_Eurescom_study_P1853.asp

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Friday, March 05, 2010 1:16 PM
To: <mohamed.boucadair@orange-ftgroup.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-even= t alternative?

 

 




Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/mes= sage/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_stu= dy_P1853.asp).

 

I'm having a hard time reso= lving this link, as it appears to be 404. Perhaps there's a typo?

 

With respect to:=

 

 

21.       Extended TRIP protocol is suggested to be used as base for IP Telephony routing;

 

We've heard here that TRIP,= as currently modeled, doesn't work due to the LNP problem. What sorts of extensions id you have in mind? Were they intended to address this problem?=

 

--

Dean

 

--_000_429446390BA91242867940DBE798A06B7B26BBBB5Fmail_-- From bernard_aboba@hotmail.com Fri Mar 5 11:03:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C341828C312 for ; Fri, 5 Mar 2010 11:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duPKPE7Bct7x for ; Fri, 5 Mar 2010 11:03:47 -0800 (PST) Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by core3.amsl.com (Postfix) with ESMTP id F200128C154 for ; Fri, 5 Mar 2010 11:03:46 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.136]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 11:03:49 -0800 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 5 Mar 2010 11:03:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CABC53.88BA5220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acq8loXQUfzRv9EOQ6aTocpySYi2JQ== Content-Language: en-us X-OriginalArrivalTime: 05 Mar 2010 19:03:49.0504 (UTC) FILETIME=[96D38000:01CABC96] Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 19:03:49 -0000 ------=_NextPart_000_0023_01CABC53.88BA5220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean Willis said: "I'm having a hard time resolving this link, as it appears to be 404. Perhaps there's a typo?" [BA] Try this . The study seems to be available on a password-protected link here: http://www.eurescom.eu/Public/Projects/P1800-series/P1853/ ------=_NextPart_000_0023_01CABC53.88BA5220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean = Willis said:

 

“I'm having a hard time resolving this link, = as it appears to be 404.  Perhaps there's a = typo?”

 

[BA] Try this. =

 

The study seems to be available on a = password-protected link here:

http:= //www.eurescom.eu/Public/Projects/P1800-series/P1853/

<= p class=3DMsoNormal> 

 

------=_NextPart_000_0023_01CABC53.88BA5220-- From richard@shockey.us Fri Mar 5 11:11:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3875428C0F0 for ; Fri, 5 Mar 2010 11:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 f4y-1wJ4HFly for ; Fri, 5 Mar 2010 11:11:29 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 11F5128C129 for ; Fri, 5 Mar 2010 11:11:29 -0800 (PST) Received: (qmail 26808 invoked by uid 0); 5 Mar 2010 19:11:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 5 Mar 2010 19:11:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=X4zu9Zrb4Yh4bqsPsLjfrmPJ2JJqRJfqoJ4/j52k6UQIuWO16+F4Xs/1tRxQLTEuOd24Kfi+r/sTU7MjRPW7PpCk0SshZOJORkb0GTEjyT9lN89ZH8oHTo4aZaxMxzIu; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nncvr-0002Qd-77; Fri, 05 Mar 2010 12:11:31 -0700 From: "Richard Shockey" To: "'Cullen Jennings'" , "'Kevin P. Fleming'" References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> <002501caa30e$92abc240$b80346c0$@com> <4B903266.40708@digium.com> In-Reply-To: Date: Fri, 5 Mar 2010 14:11:28 -0500 Message-ID: <01e501cabc97$a9338550$fb9a8ff0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq8hH10QfKpkUN+RJ6U2RlBJrZjCQAEjl7g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 19:11:31 -0000 In line... In my previous email about this documents needs, I put >>> The more important part to publish IMHO is >>> documenting some issues, problems, deficiencies and/or bugs in some >>> IETF specifications that are leading to lack of interoperability in >>> deployments. That type of problem statement would be great information >>> to get written down in a concrete form that allows the appropriate WG >>> to go fix the problems. The stuff you have in > http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,41 2/Itemid,261/ is exactly the sort of level of detail I was hoping for. Some of these items are about issues which ITU-T protocol which are probably not appropriate for an IETF document but many of them are issues with IETF protocols, or limitations where the some other protocol may require new parameters in SDP to resolve the issues. All these seem very appropriate for an IETF document. RS> Cullen, respectfully, I'm not sure I completely agree with that sentiment. Since this is purely a Informational document that describes issues with Real-time Communications in SIP I don't understand why it would be inappropriate to discuss possible issues and interactions with ITU protocols. I don't understand why things like that are "out of bounds". We have published documents in the past that discuss issues orthogonal to IETF protocols. http://www.ietf.org/rfc/rfc3482.txt being a good example. RS> The problems we are seeing in fax are directly related to the interaction of SIP and T.38 how can we propose solutions without directly addressing the problem? So I certainly think combining some of this would result in a draft that was more useful for the IETF to help fix fax problems. Cullen On Mar 4, 2010, at 3:21 PM, Kevin P. Fleming wrote: > Paul E. Jones wrote: > >> As an informational RFC, the objective would be nothing more than to >> document the issues that have been identified. It does not try to address a >> problem, but merely raise awareness to issues in a manner similar to many >> other Informational RFCs over the years. > > It's been a few weeks, but we've finally also published the problem > statement that focuses on SIP/SDP issues related to FAX over IP, and it > is located here: > > http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,41 2/Itemid,261/ > > There has been some discussion amongst our SIP Forum working group about > possibly combining the initial problem statement and this new one as > step towards making a document that is more likely to be accepted (and > relevant) as an informational RFC. > > Are there others here who feel that would be a worthwhile exercise? > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Fri Mar 5 12:05:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1234728C327 for ; Fri, 5 Mar 2010 12:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 PrxSqwLRSrla for ; Fri, 5 Mar 2010 12:05:02 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 96B143A8C01 for ; Fri, 5 Mar 2010 12:05:02 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25K53uJ026075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 5 Mar 2010 14:05:04 -0600 Message-Id: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> From: Dean Willis To: dispatch@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 14:04:58 -0600 X-Mailer: Apple Mail (2.936) Subject: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:05:05 -0000 Fundamental routing problem: The fundamental SIP routing problem is this: I've been given a message that is addressed either to a telephone number or to a user@domain name. Where do I send this SIP request to next? For "really stupid nodes", the question is easily answered: if the destination isn't "me", I send the request to my default proxy and let it deal with the problem. The default proxy might route the message itself, or it might send back a 302 informing the me as to where to send the request. It is important to note that in general, this "next hop" decision represents a singular hop. We have no way to 302-respond with a vector that specifies a sequence of relays to be used. For a smarter host on "the open Internet", the answer is also easy. If the target identifier is a "user@domain" URI, then I look up the domain part in DNS and send the request there. If the target identifier is a phone number, I use ENUM to look up an associated SIP URI, and I send the request to that URI. Local routing tables that have much the same effect may also be used, but are not specified in the governing RFCs. But the "real world" (at least as we have allowed it to become perverted) doesn't work that way. In this unhappy place, we don't have direct end-to-end SIP routability. Instead, for many reasons good, bad, and mostly practical, we must transit a set of relay nodes to get from point A to B. Further complicating matters, we may not even know what the whole set of nodes are, as various portions of the vector may be "topology hidden." So in practice, a "really stupid node" like a phone-gateway or PBX sends its request to a routing proxy, which then uses a combination of ENUM, DNS, and local policy to select a next-hop relay. Note that this decision-making process tends to repeat at each relay node, since 1) we don't have away to represent a multi-hop vector in a 302 response, and 2) each node has limited view of the end-to-end visibility, in part due to topology hiding. There's no good exchange mechanism for this information, and no standard way to inform SIP nodes about how to use it. We've seen proposals for source-context-sensitive private ENUM solutions, mutagenic SIP proxy servers that return 302s, various web- service approaches, and others. TRIP: A solution? TRIP proposes one model, wherein the "smart" nodes (called LS, or Location Servers) exchange reachability information with each other using a variant of BGP. This provides us a rich fabric for advertising routes, control peering policy, deciding what parts of stuff to "topology hide", and so on. Where BGP uses IP addresses (or the prefixes thereof) as routing targets, TRIP uses telephone numbers (or the prefixes thereof). Like BGP, it allows for "internal" routing using a flood model, and "external" routing using more controlled policy. In shortest essence, TRIP allows a first LS to say to an external LS "For the following phone numbers and phone number ranges, I suggest you use this other node or set of nodes (by IP or DNS name) as your next hop(s). And I heard this from node X, who heard it from node Y, who heard it from node Z." It allows allows a first LS to say to its internal peer "Here are all the routes I know; feel free to use them and please tell me about any you know that I don't." But TRIP has not caught on. I've heard mixed answers, which boil down to 1) its aggregation model for routes is broken, meaning Too Many Routes (as a product of LNP which makes phone numbers messy), 2) it's too complicated, and 3) Cisco owns the IPR, and I'm not sure they want to share. I'm not sure I believe this is all there is to it. The REAL problem with TRIP may be its fundamental routing model. It assumes that the routing of a phone number is a property of a given phone number (or aggregation range), and doesn't capitalize on the actual peering relationships. Further, it doesn't really allows us to talk about "routes to domains". just "routes to phone numbers", so it doesn't help with a call to "sip:user@example.com" at all. And as we know, given the peering models, RFC 3263 is also inadequate for "sip@user@example.com ". We can't go from here to there using "example.com"'s SIP SRV record. Instead, we need to find the right peering partner who can get us there, and we don't have a good way to do that. Another model: Inter-ITAD routing: If we assume that each SIP Service Provider (SSP) is essentially the same thing as an ITAD (Internet Telephony Administrative Domain), and that ITADs peer with each other along well-defined channels (using Session Border Elements, SBEs, known by other acronyms including Little Spawns of Satan etc.), then this gives us another routing topology to consider. Assume a routing protocol that tells ITAD A that to reach ITAD Z, the request should be sent to ITAD Q (or perhaps to a vector of Q and T) who will act as an intermediary. If ITAD A can directly reach Q, then A knows how to route the request. A can send the request to A's SBE that is adjacent to Q, which then hands it to Q's SBE (adjacent to A), which then consults its own routing tables to figure out how to move the request on, either to Z, to the previously declared secondary route T, or to some other ITAD known to Q that will serve as a relay. With this model, we don't need to know the route for a given E.164 number (or @domain part). All we need to know is which ITAD that target is associated with. We then consult the ITAD routing table to send the request. This means that the largest dynamic routing table required is the inter-ITAD map, which is exponentially smaller than the number of telephone routes. So, given a dynamic inter/intra ITAD routing protocol that can tell us what SBE to use to move towards a given ITAD, all we need to know is a way to translate a phone number or a domain-part into an ITAD. This is the easy part. ENUM gives us an excellent mechanism for turning phone numbers into either numeric or domain-style ITAD identifiers. The mapping of phone number (or phone number range) to ITAD is relatively static, globally valid, and well-suited to the recursive-lookup and cache model that ENUM inherited from DNS. This gives us a new simple model for call routing at the LS for phone- number targeted calls 1) If the number isn't locally known, look up its ITAD in ENUM. This might be range-matched or fully qualified; it's just a standard ENUM lookup. 2) Consult the ITAD routing table to select an SBE (and possibly additional transit ITADs) to find the routing vector consisting of one or more SBEs and zero or more transit ITADs. 3) Canonicalize the request URI and add the SBEs/ITADs as loose route hops 4) Send the request. For domain-targeted calls, we might also get to add in "Check to see if the destination is reachable via RFC 3263, and if so, use that" somewhere in the process. The short form of this model is 1) Find the ITAD of the destination. 2) Find a route to that ITAD (which might be one or more intermediaries. 3) Send the request there. Conclusion: So, other than a dynamic routing protocol that meets inter/intra-ITAD routing requirements and could be derived from TRIP (or built using some other model, such as a SIP event package), what are we missing? -- Dean From fluffy@cisco.com Fri Mar 5 12:15:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21593A8E3C for ; Fri, 5 Mar 2010 12:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kiqz2KR-d8Kc for ; Fri, 5 Mar 2010 12:15:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id ADB143A9022 for ; Fri, 5 Mar 2010 12:14:56 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABP1kEurR7Hu/2dsb2JhbACbSXOePJhkhHcEgxc X-IronPort-AV: E=Sophos;i="4.49,588,1262563200"; d="scan'208";a="161442154" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2010 20:14:58 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o25KEuSP010363; Fri, 5 Mar 2010 20:14:57 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <01e501cabc97$a9338550$fb9a8ff0$@us> Date: Fri, 5 Mar 2010 13:14:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <717A6E04-F54D-4E59-82F7-0A13004CC447@cisco.com> References: <013401ca679d$3a926700$afb73500$@us> <00cd01ca8387$9b46ea20$d1d4be60$@com> <4B32DEE9.5000302@softarmor.com> <007301ca84b7$343dd6f0$9cb984d0$@us> <4B33D01C.9000006@cisco.com> <4B39AE2C.9090304@softarmor.com> <503D76D3-A725-4EE2-9999-C7BD07A4E23A@standardstrack.com> <1AA2A44A-3C89-4903-879C-9F74E459C93D@softarmor.com> <4B433B4B.1030407@digium.com> <80D99821-B111-4C94-BC68-536CB65DD15E@softarmor.com> <4B43D7C5.1050306@cisco.com> <004f01ca8eb3$7659d790$630d86b0$@com> <4B44AC4E.4020309@cisco.com> <4B44AE40.2060104@digium.com> <00d101ca8f15$c91915b0$5b4b4110$@com> <02c901ca9026$a26cd980$e7468c80$@com> <53E8E549-E3C0-4E5C-92A1-B5AC9B06EBC5@softarmor.com> <02ee01ca902b$9e4e5e50$daeb1af0$@com> <002501caa30e$92abc240$b80346c0$@com> <4B903266.40708@digium.com> <01e501cabc97$a9338550$fb9a8ff0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1077) Cc: dispatch@ietf.org Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:15:06 -0000 On Mar 5, 2010, at 12:11 PM, Richard Shockey wrote: > In line... >=20 > In my previous email about this documents needs, I put=20 >=20 >>>> The more important part to publish IMHO is >>>> documenting some issues, problems, deficiencies and/or bugs in some >>>> IETF specifications that are leading to lack of interoperability in >>>> deployments. That type of problem statement would be great = information >>>> to get written down in a concrete form that allows the appropriate = WG >>>> to go fix the problems. >=20 > The stuff you have in=20 >>=20 > = http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,= 41 > 2/Itemid,261/ > is exactly the sort of level of detail I was hoping for.=20 >=20 > Some of these items are about issues which ITU-T protocol which are = probably > not appropriate for an IETF document but many of them are issues with = IETF > protocols, or limitations where the some other protocol may require = new > parameters in SDP to resolve the issues. All these seem very = appropriate for > an IETF document.=20 >=20 >=20 > RS> Cullen, respectfully, I'm not sure I completely agree with that > sentiment. Since this is purely a Informational document that = describes > issues with Real-time Communications in SIP I don't understand why it = would > be inappropriate to discuss possible issues and interactions with ITU > protocols. > I don't understand why things like that are "out of bounds". We > have published documents in the past that discuss issues orthogonal to = IETF > protocols. >=20 > http://www.ietf.org/rfc/rfc3482.txt That document was to document knowledge needed about PSTN such that = future people updating the IETF PS documents in this area would have = enough information to not mess it up. As you of all people remember, = there has been a lot of energy spend educating people about phones = numbers. I certainly did not say I thought discussion "possible issues = and interactions with ITU protocols is out of scope". I think I actually = said the opposite of that. However, to try and make the point clearer. = The IETF is usually caution in saying "SDO X really did a bad job of = protocol X". That often has no real value but, at times, it is the = right thing the IETF does do roughly that. There has been more than one = IETF document that shared that sentiment and often have a title like "X = considered harmful".=20 I have been trying to encourage a document that is useful in that it = leads to helping the IETF know what the IETF needs to do to make fax = work better. If you think this is the wrong direction to be going, I'm = totally open to suggestions. What are is it you are actually trying to = accomplish with a publication here?=20 >=20 > being a good example. >=20 > RS> The problems we are seeing in fax are directly related to the > interaction of SIP and T.38 how can we propose solutions without = directly > addressing the problem?=20 >=20 >=20 > So I certainly think combining some of this would result in a draft = that was > more useful for the IETF to help fix fax problems.=20 >=20 > Cullen=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From kpfleming@digium.com Fri Mar 5 12:30:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7009128C1D0 for ; Fri, 5 Mar 2010 12:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPEHC0jAbd7y for ; Fri, 5 Mar 2010 12:29:59 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 250673A8A33 for ; Fri, 5 Mar 2010 12:29:59 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Nne9p-0003eQ-6r; Fri, 05 Mar 2010 14:30:01 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 263DDD8004; Fri, 5 Mar 2010 14:30:01 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw6BTtWvNqw6; Fri, 5 Mar 2010 14:30:00 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B1E25D8003; Fri, 5 Mar 2010 14:30:00 -0600 (CST) Message-ID: <4B9169C8.7040402@digium.com> Date: Fri, 05 Mar 2010 14:30:00 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dean Willis References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> In-Reply-To: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:30:00 -0000 Dean Willis wrote: > This is the easy part. ENUM gives us an excellent mechanism for turning > phone numbers into either numeric or domain-style ITAD identifiers. The > mapping of phone number (or phone number range) to ITAD is relatively > static, globally valid, and well-suited to the recursive-lookup and > cache model that ENUM inherited from DNS. Define 'relatively static' in this context... With LNP in North America at least, there are thousands upon thousands of phone numbers being moved from one provider to another every week day. > This gives us a new simple model for call routing at the LS for > phone-number targeted calls > > 1) If the number isn't locally known, look up its ITAD in ENUM. This > might be range-matched or fully qualified; it's just a standard ENUM > lookup. > 2) Consult the ITAD routing table to select an SBE (and possibly > additional transit ITADs) to find the routing vector consisting of one > or more SBEs and zero or more transit ITADs. > 3) Canonicalize the request URI and add the SBEs/ITADs as loose route hops > 4) Send the request. It is my understanding that at the SS7 level in areas where LNP has been deployed, the initial route for any number is still the provider who was assigned the block containing that number; if the number has since been ported, that provider's switch will reply with what is effectively a 302 to the new provider servicing that number. This was done because of the same reasons you are talking about here... a routing table that could route to the phone-number level would be enormous. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From dean.willis@softarmor.com Fri Mar 5 13:10:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF40228C35E for ; Fri, 5 Mar 2010 13:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 olGm2q9nX3vU for ; Fri, 5 Mar 2010 13:10:24 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9588528C173 for ; Fri, 5 Mar 2010 13:10:24 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25LAOUn026723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Mar 2010 15:10:25 -0600 Message-Id: <7157CEC4-F1DD-4D09-BA42-461FE3050B75@softarmor.com> From: Dean Willis To: "Kevin P. Fleming" In-Reply-To: <4B9169C8.7040402@digium.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 15:10:18 -0600 References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> <4B9169C8.7040402@digium.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 21:10:25 -0000 On Mar 5, 2010, at 2:30 PM, Kevin P. Fleming wrote: > Dean Willis wrote: > >> This is the easy part. ENUM gives us an excellent mechanism for >> turning >> phone numbers into either numeric or domain-style ITAD identifiers. >> The >> mapping of phone number (or phone number range) to ITAD is relatively >> static, globally valid, and well-suited to the recursive-lookup and >> cache model that ENUM inherited from DNS. > > Define 'relatively static' in this context... With LNP in North > America > at least, there are thousands upon thousands of phone numbers being > moved from one provider to another every week day. Yep, and there are hundred of thousands of DNS records changing every day. This is still handily in the design-model for DNS. > >> This gives us a new simple model for call routing at the LS for >> phone-number targeted calls >> >> 1) If the number isn't locally known, look up its ITAD in ENUM. This >> might be range-matched or fully qualified; it's just a standard ENUM >> lookup. >> 2) Consult the ITAD routing table to select an SBE (and possibly >> additional transit ITADs) to find the routing vector consisting of >> one >> or more SBEs and zero or more transit ITADs. >> 3) Canonicalize the request URI and add the SBEs/ITADs as loose >> route hops >> 4) Send the request. > > It is my understanding that at the SS7 level in areas where LNP has > been > deployed, the initial route for any number is still the provider who > was > assigned the block containing that number; if the number has since > been > ported, that provider's switch will reply with what is effectively a > 302 > to the new provider servicing that number. This was done because of > the > same reasons you are talking about here... a routing table that could > route to the phone-number level would be enormous. > Hmm. I thought we were doing LNP dips for every phone number on call setup. Since the proposed ENUM dip handles both ported and non-ported cases, it seems like this would work well. Although it should be pointed out that porting MAY still send the call to the original ITAD for service until the TTL has exhausted, so the original ITAD has a little more work to do when effecting a port than just update one ENUM record. -- Dean From bernard_aboba@hotmail.com Sat Mar 6 13:47:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEAD3A8A33 for ; Sat, 6 Mar 2010 13:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0PA3JsXBRfU for ; Sat, 6 Mar 2010 13:47:04 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id 5BC9E3A8A2C for ; Sat, 6 Mar 2010 13:47:04 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:47:07 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sat, 6 Mar 2010 13:47:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CABD33.A0AAF2A0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acq9dq4zjcLPLZXbQ+OgUNKEWYr8xg== Content-Language: en-us X-OriginalArrivalTime: 06 Mar 2010 21:47:07.0532 (UTC) FILETIME=[9151ACC0:01CABD76] Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 21:47:08 -0000 ------=_NextPart_000_002F_01CABD33.A0AAF2A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean said: "So, other than a dynamic routing protocol that meets inter/intra-ITAD routing requirements and could be derived from TRIP (or built using some other model, such as a SIP event package), what are we missing?" [BA] I think there is quite a bit missing, actually. In practice, a video call may need to be routed differently from a pure voice call, even in the case of an INVITE with a Request-URI that represents a phone number. For example, a PBX might typically be set up to route calls to a SIP trunk based on the phone number in the Request-URI. However, if the SSP is not be capable of supporting video, a number of undesirable things might happen: the call might succeed but only bring up audio due to "SDP scrubbing" by the SSP, or call setup might fail entirely. There are multiple ways to handle the problem today. One way is to dual-register the endpoints, with one of the registrations being to a special "video network" that might assign real (or bogus) "phone numbers" to the endpoints, allowing them to call each other as if they were all attached to a single pseudo-PBX. Another way is to first try to route the call via mechanisms that try to find routes less likely to lose functionality (e.g. an "ENUM trunk", a "DUNDI trunk" or a "VIPR trunk"). However, those mechanisms are somewhat under-developed today. ------=_NextPart_000_002F_01CABD33.A0AAF2A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean said:

“So, other than a dynamic routing protocol = that meets inter/intra-ITAD routing requirements and could be derived from = TRIP (or built using some other model, such as a SIP event package), what are we missing?”

 

[BA] I think there is quite a bit missing, = actually.  In practice, a video call may need to be routed differently from a pure = voice call, even in the case of an INVITE with a Request-URI that represents a = phone number.  For example, a PBX might typically be set up to route = calls to a SIP trunk based on the phone number in the Request-URI. =  However, if the SSP is not be capable of supporting video, a number of undesirable = things might happen:  the call might succeed but only bring up audio due = to “SDP scrubbing” by the SSP, or call setup might fail entirely.  = There are multiple ways to handle the problem today.  One way is to = dual-register the endpoints, with one of the registrations being to a special = “video network” that might assign real (or bogus) “phone = numbers” to the endpoints, allowing them to call each other as if they were all = attached to a single pseudo-PBX.  Another way is to first try to route the call = via mechanisms that try to find routes less likely to lose functionality (e.g. an = “ENUM trunk”, a “DUNDI trunk” or a “VIPR = trunk”).  However, those mechanisms are somewhat under-developed today. =

------=_NextPart_000_002F_01CABD33.A0AAF2A0-- From pkyzivat@cisco.com Sat Mar 6 14:53:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D2B28C20A for ; Sat, 6 Mar 2010 14:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blvBkjxmBMKB for ; Sat, 6 Mar 2010 14:53:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 75F7C28C1B9 for ; Sat, 6 Mar 2010 14:53:15 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABNskktAZnwN/2dsb2JhbACbSXOePJgNhHgEgxc X-IronPort-AV: E=Sophos;i="4.49,596,1262563200"; d="scan'208";a="161845027" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2010 22:53:18 +0000 Received: from [10.86.242.189] (che-vpn-cluster-2-189.cisco.com [10.86.242.189]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o26MrHp7015384; Sat, 6 Mar 2010 22:53:18 GMT Message-ID: <4B92DCDD.4000703@cisco.com> Date: Sat, 06 Mar 2010 17:53:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 22:53:16 -0000 Am I the only one that finds it absurd that one would have to route the signaling differently based on the media in the call? Among other things, this means that INVITEs without offers may well not get the desired result, and mid-call addition of media may not work. Thanks, Paul Bernard Aboba wrote: > Dean said: > > “So, other than a dynamic routing protocol that meets inter/intra-ITAD > routing requirements and could be derived from TRIP (or built using some > other model, such as a SIP event package), what are we missing?” > > > > [BA] I think there is quite a bit missing, actually. In practice, a > video call may need to be routed differently from a pure voice call, > /even in the case of an INVITE with a Request-URI that represents a > phone number./ For example, a PBX might typically be set up to route > calls to a SIP trunk based on the phone number in the Request-URI. > However, if the SSP is not be capable of supporting video, a number of > undesirable things might happen: the call might succeed but only bring > up audio due to “SDP scrubbing” by the SSP, or call setup might fail > entirely. There are multiple ways to handle the problem today. One way > is to dual-register the endpoints, with one of the registrations being > to a special “video network” that might assign real (or bogus) “phone > numbers” to the endpoints, allowing them to call each other as if they > were all attached to a single pseudo-PBX. Another way is to first try > to route the call via mechanisms that try to find routes less likely to > lose functionality (e.g. an “ENUM trunk”, a “DUNDI trunk” or a “VIPR > trunk”). However, those mechanisms are somewhat under-developed today. > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From bernard_aboba@hotmail.com Sat Mar 6 15:40:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C93928C212 for ; Sat, 6 Mar 2010 15:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 DCstV-6r+M45 for ; Sat, 6 Mar 2010 15:40:22 -0800 (PST) Received: from blu0-omc4-s30.blu0.hotmail.com (blu0-omc4-s30.blu0.hotmail.com [65.55.111.169]) by core3.amsl.com (Postfix) with ESMTP id 61BD728C1FF for ; Sat, 6 Mar 2010 15:40:22 -0800 (PST) Received: from BLU137-DS12 ([65.55.111.135]) by blu0-omc4-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 15:40:25 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Paul Kyzivat'" References: <4B92DCDD.4000703@cisco.com> In-Reply-To: <4B92DCDD.4000703@cisco.com> Date: Sat, 6 Mar 2010 15:41:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq9f8/nwoU/P7u8Soi5qyg3I2QWXgABSlXA Content-Language: en-us X-OriginalArrivalTime: 06 Mar 2010 23:40:25.0481 (UTC) FILETIME=[65365F90:01CABD86] Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 23:40:23 -0000 I don't think you are alone here. The current state of things is barely workable for intra-domain operation, let alone inter-domain. Many of the hacks required either have lots of failure modes or have such limited applicability or scaling characteristics they are barely worth the effort to configure them. Given the current state of things, I have seen situations where customers have chosen public services like Skype, Live Messenger or GoogleTalk over SIP. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Saturday, March 06, 2010 2:53 PM To: Bernard Aboba Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) Am I the only one that finds it absurd that one would have to route the signaling differently based on the media in the call? Among other things, this means that INVITEs without offers may well not get the desired result, and mid-call addition of media may not work. Thanks, Paul Bernard Aboba wrote: > Dean said: > > "So, other than a dynamic routing protocol that meets inter/intra-ITAD > routing requirements and could be derived from TRIP (or built using some > other model, such as a SIP event package), what are we missing?" > > > > [BA] I think there is quite a bit missing, actually. In practice, a > video call may need to be routed differently from a pure voice call, > /even in the case of an INVITE with a Request-URI that represents a > phone number./ For example, a PBX might typically be set up to route > calls to a SIP trunk based on the phone number in the Request-URI. > However, if the SSP is not be capable of supporting video, a number of > undesirable things might happen: the call might succeed but only bring > up audio due to "SDP scrubbing" by the SSP, or call setup might fail > entirely. There are multiple ways to handle the problem today. One way > is to dual-register the endpoints, with one of the registrations being > to a special "video network" that might assign real (or bogus) "phone > numbers" to the endpoints, allowing them to call each other as if they > were all attached to a single pseudo-PBX. Another way is to first try > to route the call via mechanisms that try to find routes less likely to > lose functionality (e.g. an "ENUM trunk", a "DUNDI trunk" or a "VIPR > trunk"). However, those mechanisms are somewhat under-developed today. > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From lconroy@insensate.co.uk Sun Mar 7 03:04:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8436B28C11C for ; Sun, 7 Mar 2010 03:04:38 -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 Z7TDetD5CHcb for ; Sun, 7 Mar 2010 03:04:37 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 387673A7D92 for ; Sun, 7 Mar 2010 03:04:37 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 495981125A6; Sun, 7 Mar 2010 11:04:39 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Lawrence Conroy In-Reply-To: <4B92DCDD.4000703@cisco.com> Date: Sun, 7 Mar 2010 11:04:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B92DCDD.4000703@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1077) Cc: Bernard Aboba , dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 11:04:38 -0000 Hi Paul, folks, Nope. You are not. This discussion was raised a Loooooong time ago (in = the London/SLC meetings, IIRC), so people have had your view for at = least that long. The consensus then was that even if one had separate identities for = separate services with separate media features, these would be subsumed = by a single registrar-proxy, and you would have one common "outward = facing" identity. That proxy would fork any requests as needed. SIP = would negotiate any service-specific routing, so there was no problem. In call capability negotiation would handle the rest. The issue I had with that at the time was that "joe punter" might get = SIP service from a set of CSPs, each of which was severely limited in = the media features it handled. Voice might be handled by one CSP whilst = IM might come from another CSP. There would be no practical leverage for = mortals to convince those providers to offer full service, or to = convince (for example) AT&T systems to register with a front-end MCI = proxy. SIP full service might not be provided, regardless of the logic = in the IETF's argument. In those cases where the end user has fully functional devices, and is = supported by fully functional CSPs, it all works. (Re-)routing based on = media features is not an issue. In the real world... one has to ask oneself what's absurd? all the best, Lawrence On 6 Mar 2010, at 22:53, Paul Kyzivat wrote: > Am I the only one that finds it absurd that one would have to route = the signaling differently based on the media in the call? >=20 > Among other things, this means that INVITEs without offers may well = not get the desired result, and mid-call addition of media may not work. >=20 > Thanks, > Paul >=20 > Bernard Aboba wrote: >> Dean said: >> =93So, other than a dynamic routing protocol that meets = inter/intra-ITAD routing requirements and could be derived from TRIP (or = built using some other model, such as a SIP event package), what are we = missing?=94 >> [BA] I think there is quite a bit missing, actually. In practice, a = video call may need to be routed differently from a pure voice call, = /even in the case of an INVITE with a Request-URI that represents a = phone number./ For example, a PBX might typically be set up to route = calls to a SIP trunk based on the phone number in the Request-URI. = However, if the SSP is not be capable of supporting video, a number of = undesirable things might happen: the call might succeed but only bring = up audio due to =93SDP scrubbing=94 by the SSP, or call setup might fail = entirely. There are multiple ways to handle the problem today. One way = is to dual-register the endpoints, with one of the registrations being = to a special =93video network=94 that might assign real (or bogus) = =93phone numbers=94 to the endpoints, allowing them to call each other = as if they were all attached to a single pseudo-PBX. Another way is to = first try to route the call via mechanisms that try to find routes less = likely to lose functionality (e.g. an =93ENUM trunk=94, a =93DUNDI = trunk=94 or a =93VIPR trunk=94). However, those mechanisms are somewhat = under-developed today. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dean.willis@softarmor.com Sun Mar 7 10:38:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED8B28C18A for ; Sun, 7 Mar 2010 10:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p7W8zDh2OT9 for ; Sun, 7 Mar 2010 10:38:00 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E563128C130 for ; Sun, 7 Mar 2010 10:37:59 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o27Ic1AQ009620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Mar 2010 12:38:02 -0600 Message-Id: <0B1EFC80-1C39-427C-8F53-C74AAAE4F9BD@softarmor.com> From: Dean Willis To: Bernard Aboba In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-13--230416937 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 7 Mar 2010 12:37:55 -0600 References: X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 18:38:01 -0000 --Apple-Mail-13--230416937 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Mar 6, 2010, at 3:47 PM, Bernard Aboba wrote: > Dean said: > =93So, other than a dynamic routing protocol that meets inter/intra-=20= > ITAD routing requirements and could be derived from TRIP (or built =20 > using some other model, such as a SIP event package), what are we =20 > missing?=94 > > [BA] I think there is quite a bit missing, actually. In practice, a =20= > video call may need to be routed differently from a pure voice call, =20= > even in the case of an INVITE with a Request-URI that represents a =20 > phone number. For example, a PBX might typically be set up to route =20= > calls to a SIP trunk based on the phone number in the Request-URI. =20= > However, if the SSP is not be capable of supporting video, a number =20= > of undesirable things might happen: the call might succeed but only =20= > bring up audio due to =93SDP scrubbing=94 by the SSP, or call setup =20= > might fail entirely. There are multiple ways to handle the problem =20= > today. One way is to dual-register the endpoints, with one of the =20 > registrations being to a special =93video network=94 that might assign = =20 > real (or bogus) =93phone numbers=94 to the endpoints, allowing them to = =20 > call each other as if they were all attached to a single pseudo-=20 > PBX. Another way is to first try to route the call via mechanisms =20 > that try to find routes less likely to lose functionality (e.g. an =20 > =93ENUM trunk=94, a =93DUNDI trunk=94 or a =93VIPR trunk=94). = However, those =20 > mechanisms are somewhat under-developed today. Most of that routing would seem to be done between the terminating-=20 AOR's service proxy and the user agent. which is an entirely separate =20= part of the routing problem that is currently handled by registration. =20= I'll admit that I've also proposed a different sort of dynamic routing =20= as an alternative to registration, but whatever that is, it doesn't =20 feel like BGP, and might well have service-specific aspects (as does =20 REGISTER, via RFC 3840/3841). -- Dean =20= --Apple-Mail-13--230416937 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Mar 6, 2010, = at 3:47 PM, Bernard Aboba wrote:

Dean = said:
=93So, other than a dynamic routing protocol = that meets inter/intra-ITAD routing requirements and could be derived = from TRIP (or built using some other model, such as a SIP event = package), what are we missing?=94
[BA] I think there is quite a bit missing, = actually.  In practice, a video call may need to be routed = differently from a pure voice call, even in the case of an = INVITE with a Request-URI that represents a phone number.  For = example, a PBX might typically be set up to route calls to a SIP trunk = based on the phone number in the Request-URI.  However, if the SSP = is not be capable of supporting video, a number of undesirable things = might happen:  the call might succeed but only bring up audio due = to =93SDP scrubbing=94 by the SSP, or call setup might fail = entirely.  There are multiple ways to handle the problem = today.  One way is to dual-register the endpoints, with one of the = registrations being to a special =93video network=94 that might assign = real (or bogus) =93phone numbers=94 to the endpoints, allowing them to = call each other as if they were all attached to a single = pseudo-PBX.  Another way is to first try to route the call via = mechanisms that try to find routes less likely to lose functionality = (e.g. an =93ENUM trunk=94, a =93DUNDI trunk=94 or a =93VIPR = trunk=94).  However, those mechanisms are somewhat under-developed = today.

Most= of that routing would seem to be done between the terminating-AOR's = service proxy and the user agent. which is an entirely separate part of = the routing problem that is currently handled by registration. I'll = admit that I've also proposed a different sort of dynamic routing as an = alternative to registration, but whatever that is, it doesn't feel like = BGP, and might well have service-specific aspects (as does REGISTER, via = RFC = 3840/3841).

--
Dean
 = --Apple-Mail-13--230416937-- From Ray.Bellis@nominet.org.uk Mon Mar 8 01:39:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C483A684E for ; Mon, 8 Mar 2010 01:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRIdaBZhhXum for ; Mon, 8 Mar 2010 01:39:40 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 7AA503A6803 for ; Mon, 8 Mar 2010 01:39:39 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=TyfYd/Yqu9qq64nU6NT7nz0D7wIvN6cTe4uzN/U9QLBORhax9YWkcK9s JKk29dWN0DnpW1h/ccegnmpMgNFkdb4AMGxWXo3smiKRD4ywW2/Ibhs8P dplOAbW2BfW8Aqt; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268041183; x=1299577183; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[disp atch]=20Thoughts=20on=20SIP=20routing,=20TRIP,=20and=20EN UM=20(Long!)|Date:=20Mon,=208=20Mar=202010=2009:39:41=20+ 0000|Message-ID:=20|To:=20Dean=20Willis =20|Cc:=20dispatch@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<7157CEC4-F1DD-4D09-B A42-461FE3050B75@softarmor.com>|References:=20<85FD2EC8-3 11C-44E8-A699-0E7B577463D4@softarmor.com>=09<4B9169C8.704 0402@digium.com>=20<7157CEC4-F1DD-4D09-BA42-461FE3050B75@ softarmor.com>; bh=BsyA9aG64XVVwSnO7njInP/5W8T2i3ozBHwp1F2IHQg=; b=HPHBgXsUQ/gzfotaf9ypOg3pzPrC5ZPHSR8SYSbvURDrbx7PCRaF8QTY sUy2NNmUDrkOdipRSncw8Rh+U53EMflOeTfInfOHfB/1UNSwHm0M7JlYb mb6xJelHmP1ccJO; X-IronPort-AV: E=Sophos;i="4.49,601,1262563200"; d="txt'?scan'208";a="16833450" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 08 Mar 2010 09:39:41 +0000 In-Reply-To: <7157CEC4-F1DD-4D09-BA42-461FE3050B75@softarmor.com> References: <85FD2EC8-311C-44E8-A699-0E7B577463D4@softarmor.com> <4B9169C8.7040402@digium.com> <7157CEC4-F1DD-4D09-BA42-461FE3050B75@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 8 Mar 2010 09:39:41 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/03/2010 09:39:41 AM Content-Type: multipart/mixed; boundary="=_mixed 003511FF802576E0_=" Cc: dispatch@ietf.org Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:39:42 -0000 --=_mixed 003511FF802576E0_= Content-Type: multipart/alternative; boundary="=_alternative 003511FF802576E0_=" --=_alternative 003511FF802576E0_= Content-Type: text/plain; charset="US-ASCII" Dean, Please see attached an (unsubmitted) draft I started writing a couple of years ago before DRINKS really took off (in the wrong direction, IMHO). The bilaterally exchanged information described there in could be your ITAD routing system. What this does have (but your notes don't have) is the concept that an ITAD actually needs to be broken into smaller parts to achieve optimal routing. At least in the EU/UK, carriers like "far end handover", because it's cheaper to keep the call in your own network and drop it into the recipient network as close to the called party as possible. This more fine-grained split is the "destination group" term now used in DRINKS. kind regards, Ray --=_alternative 003511FF802576E0_= Content-Type: text/html; charset="US-ASCII" Dean,

Please see attached an (unsubmitted) draft I started writing a couple of years ago before DRINKS really took off (in the wrong direction, IMHO).

The bilaterally exchanged information described there in could be your ITAD routing system.  What this does have (but your notes don't have) is the concept that an ITAD actually needs to be broken into smaller parts to achieve optimal routing.  At least in the EU/UK, carriers like "far end handover", because it's cheaper to keep the call in your own network and drop it into the recipient network as close to the called party as possible.  This more fine-grained split is the "destination group" term now used in DRINKS.

kind regards,

Ray

--=_alternative 003511FF802576E0_=-- --=_mixed 003511FF802576E0_= Content-Type: text/plain; name="draft-bellis-enum-destgroups-00pre.txt" Content-Disposition: attachment; filename="draft-bellis-enum-destgroups-00pre.txt" Content-Transfer-Encoding: quoted-printable =0A=0A=0ASpeermint R. = Bellis=0AInternet-Draft Nomi= net UK=0AExpires: November 3, 2008 May 02= , 2008=0A=0A=0A IANA Registrations for the 'Destination Group' Enumserv= ice for=0A Infrastructure ENUM=0A = draft-bellis-enum-destgroups-00pre=0A=0AStatus of this Memo=0A=0A By su= bmitting this Internet-Draft, each author represents that any=0A applicab= le patent or other IPR claims of which he or she is aware=0A have been or= will be disclosed, and any of which he or she becomes=0A aware will be d= isclosed, in accordance with Section 6 of BCP 79.=0A=0A Internet-Drafts a= re working documents of the Internet Engineering=0A Task Force (IETF), it= s areas, and its working groups. Note that=0A other groups may also dist= ribute working documents as Internet-=0A Drafts.=0A=0A Internet-Drafts = are draft documents valid for a maximum of six months=0A and may be updat= ed, replaced, or obsoleted by other documents at any=0A time. It is inap= propriate to use Internet-Drafts as reference=0A material or to cite them= other than as "work in progress."=0A=0A The list of current Internet-Dra= fts can be accessed at=0A http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A The list of Internet-Draft Shadow Directories can be accessed at=0A = http://www.ietf.org/shadow.html.=0A=0A This Internet-Draft will expire o= n November 3, 2008.=0A=0AAbstract=0A=0A This document requests IANA regis= tration of an Enumservice=0A 'Destination Group' and a 'dg' URI scheme. = A Destination Group is an=0A opaque reference used to lookup interconnect= ion data for inter-=0A provider SIP sessions.=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0ABellis Expires November 3, 2008 [P= age 1]=0A=0C=0AInternet-Draft Destination Group Enumservice = May 2008=0A=0A=0ATable of Contents=0A=0A 1. Introduction . . . . . = . . . . . . . . . . . . . . . . . . . . 3=0A=0A 2. Terminology . . . . .= . . . . . . . . . . . . . . . . . . . . . 3=0A=0A 3. ENUM Service Regis= tration for "Destination Group" . . . . . . . 3=0A=0A 4. IANA Registrati= on Template for URI Scheme "dg" . . . . . . . . 4=0A=0A 5. Description = . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A=0A 6. Examples = . . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A=0A 7. DNS Co= nsiderations . . . . . . . . . . . . . . . . . . . . . . 5=0A=0A 8. Sec= urity Considerations . . . . . . . . . . . . . . . . . . . . 5=0A=0A 9. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5=0A=0A 1= 0. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6=0A=0A = 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6=0A= =0A 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6= =0A 12.1. Normative References . . . . . . . . . . . . . . . . . . . 6= =0A 12.2. Informative References . . . . . . . . . . . . . . . . . . 6= =0A=0A Author's Address . . . . . . . . . . . . . . . . . . . . . . . . = . 7=0A Intellectual Property and Copyright Statements . . . . . . . . . = . 8=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0ABellis= Expires November 3, 2008 [Page 2]=0A=0C=0A= Internet-Draft Destination Group Enumservice May 2008=0A= =0A=0A1. Introduction=0A=0A The requirements [RFC5067] for Infrastructur= e ENUM=0A [I-D.ietf-enum-infrastructure] (I-ENUM) specifies that=0A "In= frastructure ENUM SHALL support RRs providing a URI that can=0A identify = a point of interconnection for delivery to the carrier-of-=0A record of c= ommunications addressed to the E.164 number."=0A=0A However storing a dir= ect end-point URI in a publicly visible I-ENUM=0A tree poses two problems= :=0A=0A 1. It does not permit a different answer to be given to differen= t=0A interconnect partners.=0A 2. It exposes information about int= erconnection infrastructure to=0A parties who are not expected to hav= e this information.=0A=0A These issues are not explicitly addressed (nor = prohibited) by the=0A I-ENUM Requirements, but are well understood. See = e.g. [ghuston]=0A=0A Both issues could in theory be resolved by using DN= S views to return=0A different answers to different DNS clients. However= this is not=0A considered to scale well, particularly when the number of= views=0A required might number in the hundreds or thousands. Nor would = this=0A be practical if parts of the I-ENUM database are managed by a cen= tral=0A authority without delegation of individual number ranges to the= =0A terminating carriers.=0A=0A The proposed solution is therefore to r= egister a new Enumservice and=0A URI type (in line with [I-D.ietf-enum-en= umservices-guide]) which=0A returns an opaque reference to the real inter= connection data. The=0A interpretation of that opaque reference is then = a matter of bi-=0A lateral agreement between carriers.=0A=0A=0A2. Termin= ology=0A=0A The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL= NOT",=0A "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in= this=0A document are to be interpreted as described in [RFC2119].=0A=0A= =0A3. ENUM Service Registration for "Destination Group"=0A=0A The follow= ing template contains information required for the IANA=0A registrations = of the 'Destination Group' Enumservice:=0A=0A Enumservice Name: Destinati= on Group=0A=0A=0A=0A=0ABellis Expires November 3, 2008 = [Page 3]=0A=0C=0AInternet-Draft Destination Group Enumse= rvice May 2008=0A=0A=0A Enum service Class: Ancillary Applica= tion Enumservice=0A=0A Enumservice Type: DG=0A=0A Enumservice Subtype: = n/a=0A=0A URI Schemes: dg=0A=0A Functional Specification: TODO=0A=0A = Security Considerations: see Section 8=0A=0A Intended Usage: COMMON=0A=0A= Author: Ray Bellis =0A=0A=0A4. IANA R= egistration Template for URI Scheme "dg"=0A=0A URI scheme name: dg=0A=0A = Status: provisional=0A=0A URI scheme syntax: (in ABNF [RFC5234])=0A=0A= =0A dguri =3D ( "dg:" dglabel )=0A = dglabel =3D 1*255dgchar=0A dgchar =3D ALPHA / DIGIT / "= ." / "-"=0A=0A=0A URI scheme semantics: The URI contains opaque informati= on that is=0A used as a lookup key into an interconnection database.=0A= =0A Encoding considerations: None - all valid characters are in the US=0A= ASCII character set.=0A=0A Applications: Infrastructure ENUM [I-D.ietf= -enum-infrastructure]=0A=0A Interoperability considerations: none=0A=0A = Security considerations: see Section 8=0A=0A Contact: Ray Bellis =0A=0A=0A=0A=0A=0A=0A=0ABellis = Expires November 3, 2008 [Page 4]=0A=0C=0AInternet-Draft = Destination Group Enumservice May 2008=0A=0A=0A5. Descript= ion=0A=0A A Destination Group URI must be globally unique. To avoid the = need=0A for a register of known Destination Groups it is RECOMMENDED that= =0A each carrier generate a locally unique string for each of their=0A = Destination Groups and then append the name of a domain name over=0A whic= h they have control.=0A=0A Should an I-ENUM lookup return a Destination G= roup URI which is=0A unknown to the originating carrier then the originat= ing carrier=0A SHOULD assume that no VoIP interconnect is available and t= he call=0A delivered over other interconnect methods (e.g. PSTN)=0A=0A= =0A6. Examples=0A=0A TODO=0A=0A=0A7. DNS Considerations=0A=0A TODO=0A= =0A Notes - only one DG NAPTR per RRset, thus order / priority fields=0A = irrelevant.=0A=0A Q: could multiple NAPTRs be used to allow alternate r= outes?=0A=0A Wildcards - OK=0A=0A Non-empty leaf nodes (single numbers = or blocks) - OK=0A=0A Intermediate nodes - not OK=0A=0A=0A8. Security Co= nsiderations=0A=0A TODO=0A=0A=0A9. IANA Considerations=0A=0A This docu= ment requests the IANA registration of the Enumservice=0A 'Destination Gr= oup' with Type 'DG' according to the definitions in=0A this document, RFC= xxxx [I-D.ietf-enum-enumservices-guide] and=0A RFC3761bis [I-D.ietf-enum-= 3761bis]. The required template is=0A contained in Section 3.=0A=0A=0A= =0A=0ABellis Expires November 3, 2008 [Page= 5]=0A=0C=0AInternet-Draft Destination Group Enumservice = May 2008=0A=0A=0A This document requests an update to the IANA registrat= ion of the URI=0A scheme 'dg' according to the definitions in this docume= nt and=0A following the process described in [RFC4395]. The required tem= plate=0A is contain in Section 4.=0A=0A=0A10. Change Log=0A=0A draft-b= ellis-drinks-destgroups-00=0A Initial draft=0A=0A=0A11. Acknowledgeme= nts=0A=0A=0A12. References=0A=0A12.1. Normative References=0A=0A [I-D.i= etf-enum-3761bis]=0A Bradner, S., Conroy, L., and K. Fujiwara,= "The E.164 to=0A Uniform Resource Identifiers (URI) Dynamic D= elegation=0A Discovery System (DDDS) Application (ENUM)",=0A = draft-ietf-enum-3761bis-03 (work in progress), March 2008.=0A= =0A [I-D.ietf-enum-infrastructure]=0A Livingood, J., "The E.= 164 to Uniform Resource Identifiers=0A (URI) Dynamic Delegatio= n Discovery System (DDDS)=0A Application for Infrastructure E= NUM",=0A draft-ietf-enum-infrastructure-07 (work in progress),= =0A December 2007.=0A=0A [RFC2119] Bradner, S., "Key words = for use in RFCs to Indicate=0A Requirement Levels", BCP 14, RF= C 2119, March 1997.=0A=0A [RFC5067] Lind, S. and P. Pfautz, "Infrastruct= ure ENUM=0A Requirements", RFC 5067, November 2007.=0A=0A [R= FC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A = Specifications: ABNF", STD 68, RFC 5234, January 2008.=0A=0A12.2. Info= rmative References=0A=0A [I-D.ietf-enum-enumservices-guide]=0A = Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA=0A Re= gistration of Enumservices: Guide, Template and IANA=0A Consid= erations", draft-ietf-enum-enumservices-guide-09=0A (work in p= rogress), May 2008.=0A=0A=0A=0ABellis Expires November 3, = 2008 [Page 6]=0A=0C=0AInternet-Draft Destination Grou= p Enumservice May 2008=0A=0A=0A [RFC4395] Hansen, T., Hardie= , T., and L. Masinter, "Guidelines and=0A Registration Procedu= res for New URI Schemes", BCP 115,=0A RFC 4395, February 2006.= =0A=0A [ghuston] Huston, G., "Infrastructure ENUM", April 2007,=0A = .=0A=0A=0AAut= hor's Address=0A=0A Ray Bellis=0A Nominet UK=0A Edmund Halley Road=0A= Oxford OX4 4DQ=0A United Kingdom=0A=0A Phone: +44 1865 332211=0A = Email: ray.bellis@nominet.org.uk=0A URI: http://www.nominet.org.uk/=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0ABellis Expires November 3, 2008 = [Page 7]=0A=0C=0AInternet-Draft Destination Group Enumserv= ice May 2008=0A=0A=0AFull Copyright Statement=0A=0A Copyright= (C) The IETF Trust (2008).=0A=0A This document is subject to the rights,= licenses and restrictions=0A contained in BCP 78, and except as set fort= h therein, the authors=0A retain all their rights.=0A=0A This document = and the information contained herein are provided on an=0A "AS IS" basis = and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A OR IS SPONSORE= D BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A THE INTERNET E= NGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A OR IMPLIED, INC= LUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A THE INFORMATION= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A WARRANTIES OF MERC= HANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=0A=0AIntellectual Prope= rty=0A=0A The IETF takes no position regarding the validity or scope of a= ny=0A Intellectual Property Rights or other rights that might be claimed = to=0A pertain to the implementation or use of the technology described in= =0A this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A = made any independent effort to identify any such rights. Information=0A = on the procedures with respect to rights in RFC documents can be=0A found= in BCP 78 and BCP 79.=0A=0A Copies of IPR disclosures made to the IETF S= ecretariat and any=0A assurances of licenses to be made available, or the= result of an=0A attempt made to obtain a general license or permission f= or the use of=0A such proprietary rights by implementers or users of this= =0A specification can be obtained from the IETF on-line IPR repository at= =0A http://www.ietf.org/ipr.=0A=0A The IETF invites any interested part= y to bring to its attention any=0A copyrights, patents or patent applicat= ions, or other proprietary=0A rights that may cover technology that may b= e required to implement=0A this standard. Please address the information= to the IETF at=0A ietf-ipr@ietf.org.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= Bellis Expires November 3, 2008 [Page 8]=0A= =0C=0A= --=_mixed 003511FF802576E0_=-- From mohamed.boucadair@orange-ftgroup.com Mon Mar 8 06:32:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E083A69BC for ; Mon, 8 Mar 2010 06:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 cLuXXOWnS9hz for ; Mon, 8 Mar 2010 06:32:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id DF86C3A69B4 for ; Mon, 8 Mar 2010 06:32:45 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 2CE282AD143; Mon, 8 Mar 2010 15:32:48 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 03258384069; Mon, 8 Mar 2010 15:32:48 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 8 Mar 2010 15:32:48 +0100 From: To: Dean Willis Date: Mon, 8 Mar 2010 15:32:46 +0100 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j+6o6c1MOz+jQyGq+55MeiM4hwCNy+vQ Message-ID: <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg> <37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com> <22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F30EFC0180ABPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.8.141230 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:32:48 -0000 --_000_94C682931C08B048B7A8645303FDC9F30EFC0180ABPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dean, all, Please see inline. Cheers, Med ________________________________ De : Dean Willis [mailto:dean.willis@softarmor.com] Envoy=E9 : vendredi 5 mars 2010 19:16 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Daryl Malas; dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? On Mar 5, 2010, at 1:38 AM, > > wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challeng= es_of_IP_telephony_Eurescom_study_P1853.asp I'm having a hard time resolving this link, as it appears to be 404. Perhap= s there's a typo? With respect to: 21. Extended TRIP protocol is suggested to be used as base for IP Telephony= routing; We've heard here that TRIP, as currently modeled, doesn't work due to the L= NP problem. What sorts of extensions id you have in mind? Were they intende= d to address this problem? [Med] An alternative would be to use TRIP in conjunction with a the current= Number Portability infrastructure as used in PSTN infrastructure for placi= ng inter-ITAD calls (this means that the owner domain will always advertise= its aggregate in TRIP, but a NPDB (Network Portability Database) should qu= estioned first). Examples of extensions to TRIP (or whatever dynamic telephony routing) woul= d be: - Avoid AS (Autonomous System) spiral: the media traffic can cross the same= AS several times - Ability to maintain multiple inter-ITAD paths - Ability to enforce some advanced TE such as: Avoid that my VoIP traffic t= o cross a given AS domain (TRIP only maintain an ITAD list) - Ability to avoid congestionned links - etc. BTW, TRIP is only considered as starting point, this does not preclude to i= nvestigate any new solution to meet the recommendations we identified. BTW,= In the recommendations list we have identified the need to encourage aggre= gation-based models. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_000_94C682931C08B048B7A8645303FDC9F30EFC0180ABPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Dear Dean, all,
 
Please see inline.
Cheers,
Med

De : Dean Willis=20 [mailto:dean.willis@softarmor.com]
Envoy=E9 : vendredi 5 ma= rs 2010=20 19:16
=C0 : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc :=20 Daryl Malas; dispatch@ietf.org
Objet : Re: [dispatch] Why ar= e we=20 TRIPped out? Is there an sip-event alternative?


On Mar 5, 2010, at 1:38 AM, <mohamed.boucadair@oran= ge-ftgroup.com>=20 <mohamed.boucadair@oran= ge-ftgroup.com>=20 wrote:


Dear Dean, all,

In the last year, we have undertaken a st= udy=20 about IP telephony interconnect at large scale (URL: http://www.eurescom.eu/m= essage/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_s= tudy_P1853.asp).
Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_chal= lenges_of_IP_telephony_Eurescom_study_P1853.asp  
I'm having a hard time resolving this link, as it appears to be 404.= =20 Perhaps there's a typo?

With respect to:


21. E= xtended=20 TRIP protocol is suggested to be used as base for IP Telephony=20 routing;

We've heard here that TRIP, as currently modeled, doesn't work due to = the=20 LNP problem. What sorts of extensions id you have in mind? Were they intend= ed to=20 address this problem?
[Med] An alternative would be to use TRIP in conjunction= with a=20 the current Number Portability infrastructure as used in PST= N=20 infrastructure for placing inter-ITAD calls (this means that= the=20 owner domain will always advertise its aggregate in TRIP, but a NPDB= =20 (Network Portability Database) should questioned=20 first). 
 
Examples of extensions to TRIP (or whatever dynamic telephony rout= ing)=20 would be:
- Avoid AS (Autonomous System) spiral: the media traffic can cross= the=20 same AS several times
- Ability to maintain multiple inter-ITAD paths
- Ability to enforce some advanced TE such as: Avoid that my VoIP = traffic=20 to cross a given AS domain (TRIP only maintain an ITAD=20 list)
- Ability to avoid congestionned links
- etc.
 
BTW, TRIP is only considered as starting point, this does not prec= lude to=20 investigate any new solution to meet the recommendations we identified. BTW= , In=20 the recommendations list we have identified the need to encourage=20 aggregation-based models.
 
*********************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
--_000_94C682931C08B048B7A8645303FDC9F30EFC0180ABPUEXCB1Bnante_-- From pp3129@att.com Mon Mar 8 15:27:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2AE3A6767 for ; Mon, 8 Mar 2010 15:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa2aJho1a7lG for ; Mon, 8 Mar 2010 15:27:00 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 60A313A677C for ; Mon, 8 Mar 2010 15:27:00 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1268090822!21363129!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24218 invoked from network); 8 Mar 2010 23:27:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2010 23:27:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o28NQq9r026868 for ; Mon, 8 Mar 2010 18:26:52 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o28NQkDU026727 for ; Mon, 8 Mar 2010 18:26:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABF16.D7A8F857" Date: Mon, 8 Mar 2010 18:26:49 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j+6o6c1MOz+jQyGq+55MeiM4hwCNy+vQABO7wMA= References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> From: "PFAUTZ, PENN L (ATTCORP)" To: , "Dean Willis" Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:27:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABF16.D7A8F857 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just a word of caution re number portability. In some countries access = to this data is restricted to legally qualified carriers. Will ITADs = always correspond to such entities? Looking at the IANA list so far = that's not my impression. You may find that the entities that do have = access to NP databases may not be the ones interested in a TRIP-like = mechanism and vice versa. =20 Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange-ftgroup.com Sent: Monday, March 08, 2010 9:33 AM To: Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event = alternative? =20 =20 Dear Dean, all, =20 Please see inline. Cheers, Med =20 ________________________________ De : Dean Willis [mailto:dean.willis@softarmor.com]=20 Envoy=E9 : vendredi 5 mars 2010 19:16 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Daryl Malas; dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event = alternative? =20 On Mar 5, 2010, at 1:38 AM, = wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony = interconnect at large scale (URL: = http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_= of_IP_telephony_Eurescom_study_P1853.asp). Med: = http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_= of_IP_telephony_Eurescom_study_P1853.asp = =20 I'm having a hard time resolving this link, as it appears to be 404. = Perhaps there's a typo? =20 With respect to: =20 =20 21. Extended TRIP protocol is suggested to be used as base for IP = Telephony routing; =20 We've heard here that TRIP, as currently modeled, doesn't work due to = the LNP problem. What sorts of extensions id you have in mind? Were they = intended to address this problem? [Med] An alternative would be to use TRIP in conjunction with a the = current Number Portability infrastructure as used in PSTN infrastructure = for placing inter-ITAD calls (this means that the owner domain will = always advertise its aggregate in TRIP, but a NPDB (Network Portability = Database) should questioned first).=20 =20 Examples of extensions to TRIP (or whatever dynamic telephony routing) = would be: - Avoid AS (Autonomous System) spiral: the media traffic can cross the = same AS several times - Ability to maintain multiple inter-ITAD paths - Ability to enforce some advanced TE such as: Avoid that my VoIP = traffic to cross a given AS domain (TRIP only maintain an ITAD list) - Ability to avoid congestionned links - etc. =20 BTW, TRIP is only considered as starting point, this does not preclude = to investigate any new solution to meet the recommendations we = identified. BTW, In the recommendations list we have identified the need = to encourage aggregation-based models. =20 ********************************* This message and any attachments (the "message") are confidential and = intended solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, = changed or falsified. If you are not the intended addressee of this message, please cancel it = immediately and inform the sender. ******************************** ------_=_NextPart_001_01CABF16.D7A8F857 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just a word of caution re number portability. In some = countries access to this data is restricted to legally qualified carriers.=A0 Will = ITADs always correspond to such entities? Looking at the IANA list so far = that’s not my impression. You may find that the entities that do have access to = NP databases may not be the ones interested in a TRIP-like mechanism and = vice versa.

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange-ftgroup.com
Sent: Monday, March 08, 2010 9:33 AM
To: Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why are we TRIPped out? Is there an = sip-event alternative?

 

 

Dear Dean, all,

 

Please see inline.

Cheers,

Med

 

De : = Dean Willis [mailto:dean.willis@softarmor.com]
Envoy=E9 : vendredi 5 mars 2010 19:16
=C0 : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Daryl Malas; dispatch@ietf.org
Objet : Re: [dispatch] Why are we TRIPped out? Is there an = sip-event alternative?

 




Dear Dean, all,

In the last year, we have undertaken a study about IP telephony = interconnect at large scale (URL: http://www.eurescom.eu= /message/messageMay2009/Interconnection_challenges_of_IP_telephony_Euresc= om_study_P1853.asp).

I'm having a hard time resolving this link, as it = appears to be 404. Perhaps there's a typo?

 

With respect to:

 

 

21. Extended = TRIP protocol is suggested to be used as base for IP Telephony routing;

 

We've heard here that TRIP, as currently modeled, = doesn't work due to the LNP problem. What sorts of extensions id you have in = mind? Were they intended to address this problem?

[Med] An alternative would be to use TRIP in = conjunction with a the current Number Portability infrastructure as used in PSTN infrastructure for placing inter-ITAD calls = (this means that the owner domain will always advertise its aggregate in TRIP, but a NPDB (Network Portability Database) should questioned = first). 

 

Examples of extensions to TRIP (or whatever dynamic = telephony routing) would be:

- Avoid AS (Autonomous System) spiral: the media traffic can = cross the same AS several times

- Ability to maintain multiple inter-ITAD = paths

- Ability to enforce some advanced TE such as: Avoid that my = VoIP traffic to cross a given AS domain (TRIP only maintain an ITAD = list)

- Ability to avoid congestionned links

- etc.

 

BTW, TRIP is only considered as starting point, this does = not preclude to investigate any new solution to meet the recommendations we identified. BTW, In the recommendations list we have identified the need = to encourage aggregation-based models.

 

*********************************
This message =
and any attachments (the "message") are confidential and =
intended solely for the addressees. 
Any =
unauthorised use or dissemination is =
prohibited.
Messages are susceptible to alteration. =

France Telecom Group shall not be liable for the =
message if altered, changed or falsified.
If you =
are not the intended addressee of this message, please cancel it =
immediately and inform the =
sender.
********************************<=
/pre>
------_=_NextPart_001_01CABF16.D7A8F857-- From mohamed.boucadair@orange-ftgroup.com Mon Mar 8 23:16:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441D13A6765 for ; Mon, 8 Mar 2010 23:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 Ej25Ls1vl-UL for ; Mon, 8 Mar 2010 23:16:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 037D03A65A6 for ; Mon, 8 Mar 2010 23:16:43 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C3EA5104552; Tue, 9 Mar 2010 08:16:46 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A737A4C01C; Tue, 9 Mar 2010 08:16:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 9 Mar 2010 08:16:46 +0100 From: To: "PFAUTZ, PENN L (ATTCORP)" , Dean Willis Date: Tue, 9 Mar 2010 08:16:44 +0100 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j+6o6c1MOz+jQyGq+55MeiM4hwCNy+vQABO7wMAAD8soYA== Message-ID: <32317_1268119006_4B95F5DE_32317_48247_1_94C682931C08B048B7A8645303FDC9F30EFC01829B@PUEXCB1B.nanterre.francetelecom.fr> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F30EFC01829BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.9.64230 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 07:16:46 -0000 --_000_94C682931C08B048B7A8645303FDC9F30EFC01829BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Penn, I fully agree with you about this "legal" frontier. Then, do such ITADs (which have no access to NPDB) concerned about NP? Do t= hese operators offer telephony services or only VoIP (i.e., no emergency ca= lls, no NP, no legal intercept, and all the legal requirements)? If these domains want to offer global telephony reachability they must have= contract(s) with one or several PSTN (or mobile) operators (seen as defaul= t route). NP should be handled downstream. Cheers, Med ________________________________ De : PFAUTZ, PENN L (ATTCORP) [mailto:pp3129@att.com] Envoy=E9 : mardi 9 mars 2010 00:27 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; Dean Willis Cc : dispatch@ietf.org Objet : RE: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? Just a word of caution re number portability. In some countries access to t= his data is restricted to legally qualified carriers. Will ITADs always co= rrespond to such entities? Looking at the IANA list so far that's not my im= pression. You may find that the entities that do have access to NP database= s may not be the ones interested in a TRIP-like mechanism and vice versa. Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of mohamed.boucadair@orange-ftgroup.com Sent: Monday, March 08, 2010 9:33 AM To: Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? Dear Dean, all, Please see inline. Cheers, Med ________________________________ De : Dean Willis [mailto:dean.willis@softarmor.com] Envoy=E9 : vendredi 5 mars 2010 19:16 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Daryl Malas; dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? On Mar 5, 2010, at 1:38 AM, > > wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challeng= es_of_IP_telephony_Eurescom_study_P1853.asp I'm having a hard time resolving this link, as it appears to be 404. Perhap= s there's a typo? With respect to: 21. Extended TRIP protocol is suggested to be used as base for IP Telephony= routing; We've heard here that TRIP, as currently modeled, doesn't work due to the L= NP problem. What sorts of extensions id you have in mind? Were they intende= d to address this problem? [Med] An alternative would be to use TRIP in conjunction with a the current= Number Portability infrastructure as used in PSTN infrastructure for placi= ng inter-ITAD calls (this means that the owner domain will always advertise= its aggregate in TRIP, but a NPDB (Network Portability Database) should qu= estioned first). Examples of extensions to TRIP (or whatever dynamic telephony routing) woul= d be: - Avoid AS (Autonomous System) spiral: the media traffic can cross the same= AS several times - Ability to maintain multiple inter-ITAD paths - Ability to enforce some advanced TE such as: Avoid that my VoIP traffic t= o cross a given AS domain (TRIP only maintain an ITAD list) - Ability to avoid congestionned links - etc. BTW, TRIP is only considered as starting point, this does not preclude to i= nvestigate any new solution to meet the recommendations we identified. BTW,= In the recommendations list we have identified the need to encourage aggre= gation-based models. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_000_94C682931C08B048B7A8645303FDC9F30EFC01829BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Penn,
 
I fully agree with you about this "legal"=20 frontier. 
 
Then, do such ITADs (which have no access to NPD= B)=20 concerned about NP? Do these operators offer telephony services or onl= y=20 VoIP (i.e., no emergency calls, no NP, no legal intercept, and all the lega= l=20 requirements)?
 
If these domains want to offer global= =20 telephony reachability they must have contract(s) with one or several PSTN = (or=20 mobile) operators (seen as default route). NP should be=20 handled downstream.
 
Cheers,
Med

De : PFAUTZ, PENN L (ATTCORP)=20 [mailto:pp3129@att.com]
Envoy=E9 : mardi 9 mars 2010=20 00:27
=C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; Dean=20 Willis
Cc : dispatch@ietf.org
Objet : RE:=20 [dispatch] Why are we TRIPped out? Is there an sip-event=20 alternative?

Just=20 a word of caution re number portability. In some countries access to this d= ata=20 is restricted to legally qualified carriers.  Will ITADs always corres= pond=20 to such entities? Looking at the IANA list so far that=92s not my impressio= n. You=20 may find that the entities that do have access to NP databases may not be t= he=20 ones interested in a TRIP-like mechanism and vice versa.<= /P>

 

From:<= /B>=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 mohamed.boucadair@orange-ftgroup.com
Sent: Monday, March 08, = 2010=20 9:33 AM
To: Dean Willis
Cc:=20 dispatch@ietf.org
Subject: Re: [dispatch] Why are we TRIPped out?= Is=20 there an sip-event alternative?

 

 

Dear Dea= n,=20 all,

 

Please s= ee=20 inline.

Cheers,<= /SPAN>

Med

 

De : De= an Willis=20 [mailto:dean.willis@softarmor.com]
Envoy=E9 : vendredi 5 ma= rs 2010=20 19:16
=C0 : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc :=20 Daryl Malas; dispatch@ietf.org
Objet : Re: [dispatch] Why ar= e we=20 TRIPped out? Is there an sip-event alternative?

 

On Mar 5, 2010, at 1:38 AM, <mohamed.boucadair@oran= ge-ftgroup.com>=20 <mohamed.boucadair@oran= ge-ftgroup.com>=20 wrote:




Dear Dean, all,

In the last year, we have= =20 undertaken a study about IP telephony interconnect at large scale (URL: http://www.eurescom.eu/mes= sage/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_stu= dy_P1853.asp).

Med: http://ww= w.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telep= hony_Eurescom_study_P1853.asp  

<= /DIV>

I'm having a hard time resolving this link, as it appe= ars to=20 be 404. Perhaps there's a typo?

 

With respect to:

 

 

21. Extended TRI= P=20 protocol is suggested to be used as base for IP Telephony=20 routing;

 

We've heard here that TRIP, as currently modeled, does= n't=20 work due to the LNP problem. What sorts of extensions id you have in mind? = Were=20 they intended to address this problem?

[Med]&nb= sp;An=20 alternative would be to use TRIP in conjunction with a the=20 current Number Portability infrastructure as used in PSTN=20 infrastructure for placing inter-ITAD calls (this means that= the=20 owner domain will always advertise its aggregate in TRIP, but a NPDB= =20 (Network Portability Database) should questioned=20 first). 

 

Examples= of=20 extensions to TRIP (or whatever dynamic telephony routing) would=20 be:

- Avoid = AS=20 (Autonomous System) spiral: the media traffic can cross the same AS several= =20 times

- Abilit= y to=20 maintain multiple inter-ITAD paths

- Abilit= y to=20 enforce some advanced TE such as: Avoid that my VoIP traffic to cross a=20 given AS domain (TRIP only maintain an ITAD=20 list)

- Abilit= y to=20 avoid congestionned links

-=20 etc.

 

BTW, TRI= P is=20 only considered as starting point, this does not preclude to investigate an= y new=20 solution to meet the recommendations we identified. BTW, In the recommendat= ions=20 list we have identified the need to encourage aggregation-based=20 models.

 

**********************=
***********
This message and any attachments (the "mes=
sage") are confidential and intended solely for the addressees. =

Any unauthorised use or dissemination is prohibited.<=
/PRE>
Messages are susceptible to alteration. 
Fra=
nce Telecom Group shall not be liable for the message if altered, changed o=
r falsified.
If you are not the intended addressee of =
this message, please cancel it immediately and inform the sender.
********************************
***=
******************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
--_000_94C682931C08B048B7A8645303FDC9F30EFC01829BPUEXCB1Bnante_-- From D.Malas@cablelabs.com Tue Mar 9 08:04:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247C13A68D0 for ; Tue, 9 Mar 2010 08:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 dx8Hm9BdscKw for ; Tue, 9 Mar 2010 08:04:48 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6F0F43A6830 for ; Tue, 9 Mar 2010 08:04:48 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o29G4qQm020439; Tue, 9 Mar 2010 09:04:52 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 9 Mar 2010 09:04:52 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 9 Mar 2010 09:04:52 -0700 From: Daryl Malas To: "'Dean Willis'" , Adam Roach Date: Tue, 9 Mar 2010 09:04:52 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq7tfa1YgzDIpbxSnmJ8ZI91Mcy3gD67OrA Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> In-Reply-To: <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 16:04:49 -0000 Dean et. al, I am thankful my draft spurred on this discussion on potentially resolving = a larger issue. With this being said, the purpose of the draft is to be a = potential component of the larger solution. I got lost on whether or not t= he general community understands and sees the overall value of defining an = egress method, for ensuring a consistent approach between SSPs and vendors. Regards, Daryl=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, March 04, 2010 9:16 AM To: Adam Roach Cc: Daryl Malas; 'dispatch@ietf.org' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 3, 2010, at 3:42 PM, Adam Roach wrote: > On 3/3/10 1:26 PM, Dean Willis wrote: >> >> We really need a SIP-targeted analog of the BGP/OSPF route-exchange=20 >> protocols to solve the general problem. > > So, what, like TRIP, but for things other than phone numbers? > Yep. Imagine a TRIP extended to say "I have a SIP peering agreement with do= main X". Or better yet, imagine something that actually works and is widely= implemented that allows sharing such route information. A caveat: we also have simple phone-number-peering issues, and TRIP hasn't = caught on there. Therefore, I suspect that TRIP isn't quite right. A thorou= gh post-mortem analysis might be interesting. -- Dean From dean.willis@softarmor.com Tue Mar 9 09:28:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF783A68E5 for ; Tue, 9 Mar 2010 09:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 JTszfx0WTgHI for ; Tue, 9 Mar 2010 09:28:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 42E053A68D5 for ; Tue, 9 Mar 2010 09:28:04 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o29HS4vl032506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Mar 2010 11:28:06 -0600 Message-Id: <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Mar 2010 11:27:58 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 17:28:05 -0000 On Mar 9, 2010, at 10:04 AM, Daryl Malas wrote: > Dean et. al, > > I am thankful my draft spurred on this discussion on potentially > resolving a larger issue. With this being said, the purpose of the > draft is to be a potential component of the larger solution. I got > lost on whether or not the general community understands and sees > the overall value of defining an egress method, for ensuring a > consistent approach between SSPs and vendors. I definitely see the need for defining a method by which to inform nodes inside an ITAD of egress routes from that ITAD to other domains. I think that most of the people who have responded on this thread agree that there is such a need. We also seem to see a need for dissemination of inter-ITAD routing information, although we're still discussing the relationships between phone numbers, ITADs, and routes. Where we have a disagreement is on mechanism. While your proposed use of ITAD-specific private ENUM servers is not completely inconsistent with recent trends in ENUM, I have to say we've done a lot of things in ENUM that I don't like, and this is pushing the envelope further in that direction. There are a lot of people running private DNS spaces, too, but we haven't standardized the discovery of default routes within an Intranet using private DNS for very good reasons, and those same reasons apply to ENUM used in the same pattern. Yes, it can be made to work, but it creates massive operational headaches. We have several arguments in favor of some sort of "dynamic routing protocol" solution or solutions. Open questions include: 1) Are different interior and exterior routing protocols (BGP vs OSPF, for instance) required, or can one common protocol meet the full set f requirements? 2) Is a standalone protocol such as TRIP more appropriate than something "inside" SIP (or DNS, XMPP, whatever)? If so, does this apply to both interior and exterior roles? 3) Can TRIP be made to work? This has related questions about aggregation models, LNP access, LNP fragmentation of aggregation, etc. 4) Can inter-ITAD routing be accomplished based on number-to-ITAD transformations (which ENUM gives us) accompanied by a dynamic inter- ITAD route exchange protocol? This may also have to factor in the LNP problem. 5) Can we do something combining TRIP (maybe with modifications) and ENUM that solves the problems? If so, will anybody deploy it, or do they prefer striking themselves repeatedly in the face with blunt objects over extended periods of time? All-in-all, this is excellent material for the sort of problem- exploration process that might lead to a working group. -- Dean From dean.willis@softarmor.com Tue Mar 9 10:25:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC373A699E for ; Tue, 9 Mar 2010 10:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4gg4UmlMzBa for ; Tue, 9 Mar 2010 10:25:08 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 47EF43A692D for ; Tue, 9 Mar 2010 10:25:08 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o29IP5bU000426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Mar 2010 12:25:07 -0600 Message-Id: From: Dean Willis To: "Dwight, Timothy M (Tim)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4--58392363 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Mar 2010 12:24:59 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F1AE@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, Daryl Malas Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:25:11 -0000 --Apple-Mail-4--58392363 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Mar 3, 2010, at 10:08 PM, Dwight, Timothy M (Tim) wrote: > Daryl, > > I agree that defining a best practice often has the impact you =20 > suggest. > > IMHO the technique you describe has merit. What=92s not clear is how =20= > a different response is generated per querying domain. The draft =20 > shows response formats that would be appropriate for SSP1, but not =20 > appropriate for any other domain. This implies that the response =20 > would be somehow tailored for each querying domain. I think some =20 > elaboration on how that works (e.g., what has to be provisioned, by =20= > whom, to make it happen) would be helpful. > Good questions. I'm assuming (and we all know where that leads) that =20 the following describes the solution as Daryl has proposed it: SSP1 runs its own private ENUM database, which it fully manages and =20 provisions using whatever tools it has available. All nodes at SSP1 =20 query SSP1's ENUM servers, which return responses tailored to the SSP1 =20= domain. SSP2 runs its own private ENUM database, which it fully manages and =20 provisions using whatever tools it has available. All nodes at SSP2 =20 query SSP2's ENUM servers, which return responses tailored to the SSP2 =20= domain. ... SSPn runs its own private ENUM database, which it fully manages and =20 provisions using whatever tools it has available. All nodes at SSPn =20 query SSPn's ENUM servers, which return responses tailored to the SSPn =20= domain. Within each SSP, each querying node must be provisioned (via some =20 unspecified process) to use the SSP's private enum servers. Like private DNS, none of the private ENUM servers is queried by the =20 "outside world". Unlike private DNS the private ENUM servers also do not query the =20 outside world , because SIP routing lacks the concept of a "default =20 route". Essentially, we're hacking a DNS infrastructure to provide the =20= routing-knowlegde that in an IP network would be provided by RIP and/=20 or DHCP. And that's what makes this much messier than private DNS, =20 which is already its own world of headaches. Each external route must =20= be manually provisioned into each private-enum root server. With this proposal, each private ENUM domain maintained by an SSP is a =20= completely independent name-service island, equipped with its own root =20= server. Some benefit of DNS caching and zone transfer may occur, as it =20= is only necessary to manually provisioning the zone files into the =20 master or "primary" private-domain root server at each SSP. Secondary =20= roots (once provisioned to use the correct primary) acquire zone files =20= via zone transfer, and caching servers (once provisioned to use one or =20= more roots) simply do a recursive lookup towards the local root and =20 cache the result until its TTL expires. But one is gaining little of =20 the benefit of a global name service, and the potential for ugly =20 mistakes is relatively high with any faked-root DNS model. -- Dean --Apple-Mail-4--58392363 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Mar 3, 2010, = at 10:08 PM, Dwight, Timothy M (Tim) wrote:

Daryl,
I agree that defining a best practice = often has the impact you suggest.
IMHO the technique you describe has merit. =  What=92s not clear is how a different response is generated per = querying domain.  The draft shows response formats that would be = appropriate for SSP1, but not appropriate for any other domain.  = This implies that the response would be somehow tailored for each = querying domain.  I think some elaboration on how that works (e.g., = what has to be provisioned, by whom, to make it happen) would be = helpful.

Unlike private DNS the private = ENUM servers also do not query the outside world , because SIP routing = lacks the concept of a "default route". Essentially, we're hacking a DNS = infrastructure to provide the routing-knowlegde that in an IP network = would be provided by RIP and/or DHCP. And that's what makes this much = messier than private DNS, which is already its own world of headaches. = Each external route must be manually provisioned into each private-enum = root server.

With this proposal, each private = ENUM domain maintained by an SSP is a completely independent = name-service island, equipped with its own root server. Some benefit of = DNS caching and zone transfer may occur, as it is only necessary to = manually provisioning the zone files into the master or "primary" = private-domain root server at each SSP. Secondary roots (once = provisioned to use the correct primary) acquire zone files via zone = transfer, and caching servers (once provisioned to use one or more = roots) simply do a recursive lookup towards the local root and cache the = result until its TTL expires. But one is gaining little of the benefit = of a global name service, and the potential for ugly mistakes is = relatively high with any faked-root DNS = model.

--
Dean 


= --Apple-Mail-4--58392363-- From adam.uzelac@gmail.com Tue Mar 9 11:48:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B53A694F for ; Tue, 9 Mar 2010 11:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew8E5ND-RD+P for ; Tue, 9 Mar 2010 11:48:46 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 66A813A6996 for ; Tue, 9 Mar 2010 11:48:46 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 8so32739qwh.31 for ; Tue, 09 Mar 2010 11:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/CAy4n2CDhGQungd39cbL1xVUEUenk02EG+4YFX+WQY=; b=TV+Q7NrRbb8GjaqsEqQaTUTovSRzcvdPGgOcO9Z7zYfIorC5KGvsEHv/xK0Z+rtoyV C2Q0aR3n8G9YoW3+HorJRvn+L28i8TUADyxMaEQihY5g1wpx88HIVoa/z7tcQY/SbQhs A2sa9S/q+9/fAtM+TYu+qMBNMULeXrUZtrfJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sZ4hhZwe4kraec3AKPi/LqX9n4pd6ESQjLj9e1sNGerSEsX9Ao7Emh6HbrHQsodtQ3 +RxkvP9APSgs+b9bxTlJr8rWjQUhiS2etr9LoEk94zbV019MH5ojuQVDzLD/AFYU0uxD kBAQ1RQj/ldIZ3cd3OVx+kLrAAhhvFNyeJYUY= MIME-Version: 1.0 Received: by 10.229.251.69 with SMTP id mr5mr362393qcb.91.1268164127156; Tue, 09 Mar 2010 11:48:47 -0800 (PST) In-Reply-To: References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> Date: Tue, 9 Mar 2010 14:48:47 -0500 Message-ID: <3d58c41e1003091148g274d8873u47c5d0797983dcda@mail.gmail.com> From: Adam Uzelac To: Dean Willis Content-Type: multipart/alternative; boundary=0016363b912050ebab048163781a Cc: dispatch@ietf.org, "Dwight, Timothy M \(Tim\)" , Daryl Malas Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 19:48:48 -0000 --0016363b912050ebab048163781a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The only thing I would add to Dean's comments below is: *" ....which return responses tailored to the SSPX domain."* for the _SAME_ target destination in every "hop" through the myriad of networks. It doesn't really help at the end of the day. Each SSP domain will return something different based on the source of the query, and again, it's all f= o the same target (phone number, URI, etc). Holy complexity, Batman! Adam Uzelac Global Crossing On Tue, Mar 9, 2010 at 1:24 PM, Dean Willis wrot= e: > > On Mar 3, 2010, at 10:08 PM, Dwight, Timothy M (Tim) wrote: > > Daryl, > > I agree that defining a best practice often has the impact you suggest. > > IMHO the technique you describe has merit. What=92s not clear is how a > different response is generated per querying domain. The draft shows > response formats that would be appropriate for SSP1, but not appropriate = for > any other domain. This implies that the response would be somehow tailor= ed > for each querying domain. I think some elaboration on how that works (e.= g., > what has to be provisioned, by whom, to make it happen) would be helpful. > > > > > Good questions. I'm assuming (and we all know where that leads) that the > following describes the solution as Daryl has proposed it: > > SSP1 runs its own private ENUM database, which it fully manages and > provisions using whatever tools it has available. All nodes at SSP1 query > SSP1's ENUM servers, which return responses tailored to the SSP1 domain. > > > SSP2 runs its own private ENUM database, which it fully manages and > provisions using whatever tools it has available. All nodes at SSP2 query > SSP2's ENUM servers, which return responses tailored to the SSP2 domain. > > ... > > SSPn runs its own private ENUM database, which it fully manages and > provisions using whatever tools it has available. All nodes at SSPn query > SSPn's ENUM servers, which return responses tailored to the SSPn domain. > > > Within each SSP, each querying node must be provisioned (via some > unspecified process) to use the SSP's private enum servers. > > Like private DNS, none of the private ENUM servers is queried by the > "outside world". > > Unlike private DNS the private ENUM servers also do not query the outside > world , because SIP routing lacks the concept of a "default route". > Essentially, we're hacking a DNS infrastructure to provide the > routing-knowlegde that in an IP network would be provided by RIP and/or > DHCP. And that's what makes this much messier than private DNS, which is > already its own world of headaches. Each external route must be manually > provisioned into each private-enum root server. > > With this proposal, each private ENUM domain maintained by an SSP is a > completely independent name-service island, equipped with its own root > server. Some benefit of DNS caching and zone transfer may occur, as it is > only necessary to manually provisioning the zone files into the master or > "primary" private-domain root server at each SSP. Secondary roots (once > provisioned to use the correct primary) acquire zone files via zone > transfer, and caching servers (once provisioned to use one or more roots) > simply do a recursive lookup towards the local root and cache the result > until its TTL expires. But one is gaining little of the benefit of a glob= al > name service, and the potential for ugly mistakes is relatively high with > any faked-root DNS model. > > -- > Dean > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0016363b912050ebab048163781a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The only thing I would add to Dean's comments below is:
=A0
" ....which return responses tailored to the SSPX domain.&quo= t; for the _SAME_ target destination in every "hop" through = the myriad of networks.=A0 It doesn't really help at the end of the day= . Each SSP domain will return something different based on the source of th= e query, and again, it's all fo the same target (phone number, URI, etc= ).
=A0
Holy complexity, Batman!
=A0
=A0
Adam Uzelac
Global Crossing


=A0
On Tue, Mar 9, 2010 at 1:24 PM, Dean Willis <dean.willis@= softarmor.com> wrote:

On Mar 3, 2010, at 10:08 PM, Dwight, Timothy M (Tim) wrote:

Daryl,
=A0
I agree that defining a best practice often has the impact you suggest.
=A0
IMHO the technique you describe has merit. =A0What=92s not clear is how a = different response is generated per querying domain. =A0The draft shows res= ponse formats that would be appropriate for SSP1, but not appropriate for a= ny other domain.=A0 This implies that the response would be somehow tailore= d for each querying domain. =A0I think some elaboration on how that works (= e.g., what has to be provisioned, by whom, to make it happen) would be help= ful.
=A0


Good questions. I'm assuming (and we all know where that leads) th= at the following describes the solution as Daryl has proposed it:

SSP1 runs its own private ENUM database, which it fully manages and pr= ovisions using whatever tools it has available. All nodes at SSP1 query SSP= 1's ENUM servers, which return responses tailored to the SSP1 domain.
=A0
=A0
=A0

SSP2 runs its own private ENUM database, which it fully manages and pr= ovisions using whatever tools it has available. All nodes at SSP2 query SSP= 2's ENUM servers, which return responses tailored to the SSP2 domain.

...

SSPn runs its own private ENUM database, which it fully manages and pr= ovisions using whatever tools it has available. All nodes at SSPn query SSP= n's ENUM servers, which return responses tailored to the SSPn domain.


Within each SSP, each querying node must be provisioned (via some unsp= ecified process) to use the SSP's private enum servers.=A0

Like private DNS, none of the private ENUM servers is queried by the &= quot;outside world".=A0

Unlike private DNS the private ENUM servers also do not query the outs= ide world , because SIP routing lacks the concept of a "default route&= quot;. Essentially, we're hacking a DNS infrastructure to provide the r= outing-knowlegde that in an IP network would be provided by RIP and/or DHCP= . And that's what makes this much messier than private DNS, which is al= ready its own world of headaches. Each external route must be manually prov= isioned into each private-enum root server.

With this proposal, each private ENUM domain maintained by an SSP is a= completely independent name-service island, equipped with its own root ser= ver. Some benefit of DNS caching and zone transfer may occur, as it is only= necessary to manually provisioning the zone files into the master or "= ;primary" private-domain root server at each SSP. Secondary roots (onc= e provisioned to use the correct primary) acquire zone files via zone trans= fer, and caching servers (once provisioned to use one or more roots) simply= do a recursive lookup towards the local root and cache the result until it= s TTL expires. But one is gaining little of the benefit of a global name se= rvice, and the potential for ugly mistakes is relatively high with any fake= d-root DNS model.

--
Dean=A0



___________________________________________= ____
dispatch mailing list
dispa= tch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0016363b912050ebab048163781a-- From lendl@nic.at Tue Mar 9 13:16:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CAA3A69FE for ; Tue, 9 Mar 2010 13:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uae2ipvnJjTl for ; Tue, 9 Mar 2010 13:16:26 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 629283A698D for ; Tue, 9 Mar 2010 13:16:23 -0800 (PST) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 1D06D4CD8F; Tue, 9 Mar 2010 22:16:26 +0100 (CET) Message-ID: <4B96BAAA.3010900@nic.at> Date: Tue, 09 Mar 2010 22:16:26 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> In-Reply-To: <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 21:16:41 -0000 On 09.03.2010 18:27, Dean Willis wrote: > > I definitely see the need for defining a method by which to inform nodes > inside an ITAD of egress routes from that ITAD to other domains. I think > that most of the people who have responded on this thread agree that > there is such a need. Yes, there is. > Where we have a disagreement is on mechanism. While your proposed use of > ITAD-specific private ENUM servers is not completely inconsistent with > recent trends in ENUM, I have to say we've done a lot of things in ENUM > that I don't like, and this is pushing the envelope further in that > direction. As I see the problem space, we're conflating two independent problems: a) how is routing-information exchanged between SSPs? Here we have one approach which favors registries which digest routing-information and spit out suitable database dumps for provisioning the SSPs boxes. The other approach is to get some real routing-protocol up and running between SSPs (like BGP4 for IP layer 3 routing). b) how is this routing-information conferred to the proxies/SBCs/... which do the actual SIP message processing / forwarding? Now, if these proxies are actually participating in a dynamic routing protocol (or receive full dumps from a routing registry), then b) is internal to the proxy. Just as there is no protocol for moving routes from the BGP table of a router to the actual packet forwarding engine, this is purely internal to the box. If, on the other hand, some entity distinct from the actual SIP devices handles the routing information (either by talking to a registry, or by running a dynamic routing protocol), then the SIP device needs a protocol to query that routing-oracle on what to do with a given call. It seems to me that this is what ENUM is increasingly used for within SSPs. IMHO this is the wrong protocol choice for this task. Why? * ENUM is a very simple DNS application. The only key to the lookup is the destination number, the only return value is an URL. (more or less) * If you look at a good number of recent drafts you notice that people feel that this is not enough: they need "ID of the SIP device" or "caller-ID" in the query, and a sh*tload of URI-parameters (trunk-id, ...) in the answer. See draft-mayrhofer-drinks-sed-elements for further data that might need to get stuffed into an ENUM response. ENUM was never intended as call-control protocol where a proxy outsources its complete routing intelligence to an external party. It's a simple key->URI directory lookup. The LRF (RFC 3263) and the intelligence was supposed to be within the SIP proxy. Now, what we need here is something closer to RADIUS than to ENUM: a protocol where the SIP device can pack up all the information it has about the SIP INVITE into one request to the routing-oracle which then answers with a details set of parameters (the SED) on what the stupid proxy is supposed to do now. Trying to expand ENUM into doing just that is bound to fail. cheers, otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From lconroy@insensate.co.uk Tue Mar 9 14:30:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B1F3A6A3D for ; Tue, 9 Mar 2010 14:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEZt7suuO4mp for ; Tue, 9 Mar 2010 14:30:42 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 4DE773A69DC for ; Tue, 9 Mar 2010 14:30:39 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9803C11374F; Tue, 9 Mar 2010 22:30:42 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <4B96BAAA.3010900@nic.at> Date: Tue, 9 Mar 2010 22:30:42 +0000 Content-Transfer-Encoding: 7bit Message-Id: <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <4B96BAAA.3010900@nic.at> To: Otmar Lendl X-Mailer: Apple Mail (2.1077) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 22:30:44 -0000 Hi Otmar, Dean, folks, OK -- this has hit my "respond" threshold. Long post, but (summary @ end). I recall thinking at the time that TRIP was not right and couldn't readily be fixed, and was unsurprised that it just faded away. Thus I am decidedly sceptical of attempts to resuscitate what is no longer even a ripe corpse. It's a dead horse - stop flogging and get off. There is no such thing as an ENUM server -- there are only DNS servers. Thus the idea of providing different answers to the same DNS query depending on who asked is at best limited (as in "broken"). Dispatch is sure not the place for it (nor, I would have thought, is DRINKS). Providing a "who's asking?"-dependent response is going to require some fancy footwork with DNS messages, so it *has* to be a DNSEXT thing. ENUM might, just possibly, be used alone under certain limited scenarios: IF THERE ARE RELATIVELY FEW OPTIONS (say, <= 10), each could be put into its own NAPTR with its own rococo parameters. The ENUM client would use those parameters as its "local knowledge" to reject the ones it couldn't/shouldn't use. Personally, I think that this is pushing ENUM a loooooong way, but YMMV. Problem is, *any* selective query/response protocol (RADIUS, LDAP, HTTP, ...) that gives the entire answer to any question from dumb proxies is going to be scale/performance limited. LNP makes every single query potentially have a different answer from every other query, so this is a BIG database and/or each answer has to be synthesised by the server in real time. There ARE a lot of parameters to fit into each exchange, and lots of such exchanges (for every call). This seems to be an Apps area issue -- good luck. Some of the DNS based alternatives seem to be trying to split the problem into sets of different data. IIUC, the NICC proposals were sending part of the answer, and the client was expected to use its local knowledge to interpret those answers. That "local knowledge" would be delivered by other means -- not by DNS. This is NOT the same as a "who's asking?" scheme. Is that ENUM? -- not as specified in the 3761 and (for SIP) in 3764. Is that ENUM-like? Could be. Don't assume that a single ENUM query delivering the whole answer is the only way to use DNS. I simply do not believe that there needs to be an entirely distinct and discrete answer given for each (queriant/target number). There ARE a limited number of egress points from within any ITAD, and providing a hint on the egress point to use is enough, most of the time. If not, then looking up the current address of that egress point should be HEAVILY cached by clients (and might be authenticated/secured/slower). Summary -- it doesn't have to be one grand unified solution (A or B or ...). Discounting DNS or ENUM because it doesn't give the whole answer may be shortsighted. DNS may be *part* of the solution. all the best, Lawrence On 9 Mar 2010, at 21:16, Otmar Lendl wrote: > On 09.03.2010 18:27, Dean Willis wrote: >> >> I definitely see the need for defining a method by which to inform nodes >> inside an ITAD of egress routes from that ITAD to other domains. I think >> that most of the people who have responded on this thread agree that >> there is such a need. > > Yes, there is. > >> Where we have a disagreement is on mechanism. While your proposed use of >> ITAD-specific private ENUM servers is not completely inconsistent with >> recent trends in ENUM, I have to say we've done a lot of things in ENUM >> that I don't like, and this is pushing the envelope further in that >> direction. > > As I see the problem space, we're conflating two independent problems: > > a) how is routing-information exchanged between SSPs? > > Here we have one approach which favors registries which digest > routing-information and spit out suitable database dumps for provisioning > the SSPs boxes. The other approach is to get some real routing-protocol up > and running between SSPs (like BGP4 for IP layer 3 routing). > > b) how is this routing-information conferred to the proxies/SBCs/... which > do the actual SIP message processing / forwarding? > > Now, if these proxies are actually participating in a dynamic routing > protocol (or receive full dumps from a routing registry), then b) is > internal to the proxy. Just as there is no protocol for moving routes from > the BGP table of a router to the actual packet forwarding engine, this is > purely internal to the box. > > If, on the other hand, some entity distinct from the actual SIP devices > handles the routing information (either by talking to a registry, or by > running a dynamic routing protocol), then the SIP device needs a protocol > to query that routing-oracle on what to do with a given call. > > It seems to me that this is what ENUM is increasingly used for within SSPs. > > IMHO this is the wrong protocol choice for this task. > > Why? > > * ENUM is a very simple DNS application. The only key to the lookup is the > destination number, the only return value is an URL. (more or less) > > * If you look at a good number of recent drafts you notice that people feel > that this is not enough: they need "ID of the SIP device" or "caller-ID" in > the query, and a sh*tload of URI-parameters (trunk-id, ...) in the answer. > See draft-mayrhofer-drinks-sed-elements for further data that might need to > get stuffed into an ENUM response. > > ENUM was never intended as call-control protocol where a proxy outsources > its complete routing intelligence to an external party. It's a simple > key->URI directory lookup. The LRF (RFC 3263) and the intelligence was > supposed to be within the SIP proxy. > > Now, what we need here is something closer to RADIUS than to ENUM: a > protocol where the SIP device can pack up all the information it has about > the SIP INVITE into one request to the routing-oracle which then answers > with a details set of parameters (the SED) on what the stupid proxy is > supposed to do now. > > Trying to expand ENUM into doing just that is bound to fail. > > cheers, > > otmar > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Tue Mar 9 17:43:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598663A6AC7 for ; Tue, 9 Mar 2010 17:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCBAHq89k8J2 for ; Tue, 9 Mar 2010 17:43:24 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id B24A33A69ED for ; Tue, 9 Mar 2010 17:43:24 -0800 (PST) Received: (qmail 22409 invoked by uid 0); 10 Mar 2010 01:43:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 10 Mar 2010 01:43:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=TMIvnGFTYSC4Z1sIj03DmxyWwWErZrKXmtIh2T1wdCnGjRWTF2V8UEqC4vOmyizGhVEPbgDhHcZ2r2BPtZ65E6/R/9OIGJh2JBpFfOsLhKbNG6WtA/CUZmk/XB/HQ2tI; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NpAxM-0002WA-Ag; Tue, 09 Mar 2010 18:43:28 -0700 From: "Richard Shockey" To: , , "'MARTINI'" Date: Tue, 9 Mar 2010 20:43:25 -0500 Message-ID: <028201cabff3$13cc1360$3b643a20$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0283_01CABFC9.2AF60B60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/uZOrLwXMolSnQeyPKU4g86oIkg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: [dispatch] SIP Forum Luncheon at IETF 77 Monday 11:30 13:00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 01:43:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0283_01CABFC9.2AF60B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SIP Forum is going to hold a open meeting for the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical issues that relate to IETF WG's. The agenda for this luncheon will be to review current activities in the SIP Forum and seek additional technical input from the RAI community on mutual concerns. As many of you know the SIP Forum is the principal sponsor of the SIPit interoperability events and currently has 4 Task groups operating. BTW registration for SIPit 26 will be open soon. Our principal technical initiatives are: 1. SIP Connect 1.1 which is developing an enhanced profile of IETF Standards for PBX to SSP interoperability. As part of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP. 2. FAX over SIP is investigating the interoperability of SIP in T.38 networks with a goal of possible recommendations to the relevant SDO's on how fax can work better. 3. Client User Agent Configuration which has a pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP User Agents 4. SIP in the SmartGrid. This is a Special Interest Group that is evaluating the appropriateness of using SIP as a protocol for a number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) deployments. Information on the SIP Forum is available at http//www.sipforum.org If you are interested in attending this event we have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( 150 Maximum) lunch will be provided. Location .. Monday 11:30 13:00 the Laguna room and its located on the 4th floor of the Anaheim Hilton The link to the poll is: http://www.doodle.com/hde57nbpcdykzqfz Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ------=_NextPart_000_0283_01CABFC9.2AF60B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The SIP Forum is going to hold a open meeting for = the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical = issues that relate to IETF WG’s. The agenda for this luncheon will be to = review current activities in the SIP Forum and seek additional technical input = from the RAI community on mutual concerns.

 

As many of you know the SIP Forum is the principal = sponsor of the SIPit interoperability events and currently has 4 Task groups = operating.

 

BTW registration for SIPit 26 will be open = soon.

 

Our principal technical initiatives = are:

 

1.      SIP Connect 1.1 which is developing an enhanced  profile of IETF Standards for PBX to SSP interoperability. As part = of that work the IETF MARTINI WG was formed to redefine the so called = Implicit registration procedure in SIP.

2.      FAX over SIP is investigating the = interoperability of SIP in T.38 networks with a goal of possible recommendations to the = relevant SDO’s on how fax can work better.

3.      Client User Agent Configuration which has a = pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP = User Agents

4.      SIP in the SmartGrid. This is a Special Interest = Group that is evaluating the appropriateness of using SIP as a protocol for a = number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) = deployments.

 

Information on the SIP Forum is available at =

 

http//www.sipforum.org

 

If you are interested in attending this event we = have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( = 150 Maximum) lunch will be provided.

 

Location .. Monday 11:30 13:00 the Laguna room and its = located on the 4th floor of the Anaheim Hilton

The link to the poll = is:

http://www.doodle.com/hde57nbpcdykzqfz

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype: rshockey101
LinkedIn : http://www.linkedin.com/i= n/rshockey101

 

------=_NextPart_000_0283_01CABFC9.2AF60B60-- From dean.willis@softarmor.com Tue Mar 9 20:09:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0A13A6B34 for ; Tue, 9 Mar 2010 20:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 06736lRlEKWt for ; Tue, 9 Mar 2010 20:09:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1C3533A6782 for ; Tue, 9 Mar 2010 20:09:44 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2A49i1O004403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Mar 2010 22:09:46 -0600 Message-Id: <6C3409D4-F2E0-4443-BCFA-F9E507B3CFD6@softarmor.com> From: Dean Willis To: Adam Uzelac In-Reply-To: <3d58c41e1003091148g274d8873u47c5d0797983dcda@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Mar 2010 22:09:39 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B3@srvxchg> <35FE871E2B085542A35726420E29DA6B0374F5E8@gaalpa1msgusr7a.ugd.att.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66BD@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66C5@srvxchg> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66CE@srvxchg> <3d58c41e1003091148g274d8873u47c5d0797983dcda@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, "Dwight, Timothy M \(Tim\)" , Daryl Malas Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 04:09:44 -0000 On Mar 9, 2010, at 1:48 PM, Adam Uzelac wrote: > The only thing I would add to Dean's comments below is: > > " ....which return responses tailored to the SSPX domain." for the > _SAME_ target destination in every "hop" through the myriad of > networks. It doesn't really help at the end of the day. Each SSP > domain will return something different based on the source of the > query, and again, it's all fo the same target (phone number, URI, > etc). > Even worse, the SSPX server will return a different value based not on the source of the query, but on the location of the SSPX server. We have an implicit assumption that the queries are coming from the same location, which is how the ENUM server manages to return locally- scoped answer. The server and all its knowledge are locally-scoped, and getting that knowledge in there is the guano in somebody else's batcave. -- Dean From dean.willis@softarmor.com Tue Mar 9 21:56:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527DF3A6BAE for ; Tue, 9 Mar 2010 21:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKqb5KWTz4HO for ; Tue, 9 Mar 2010 21:56:40 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CBCB43A6BAC for ; Tue, 9 Mar 2010 21:56:39 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2A5ufW4004853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Mar 2010 23:56:43 -0600 Message-Id: <1985C859-BE1C-4BF4-B056-D13C373956C2@softarmor.com> From: Dean Willis To: Lawrence Conroy In-Reply-To: <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> Content-Type: multipart/alternative; boundary=Apple-Mail-25--16896031 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Mar 2010 23:56:36 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <4B96BAAA.3010900@nic.at> <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 05:56:43 -0000 --Apple-Mail-25--16896031 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 9, 2010, at 4:30 PM, Lawrence Conroy wrote: > > I recall thinking at the time that TRIP was not right and couldn't > readily > be fixed, and was unsurprised that it just faded away. Thus I am > decidedly > sceptical of attempts to resuscitate what is no longer even a ripe > corpse. > It's a dead horse - stop flogging and get off. > TRIP was either a wong solution to a right problem, or a right solution to a wrong problem. Somewhere out there is something kindof like TRIP (and kindof NOT like TRIP) that actually solves the right problem. First we have to decide what the "right problem" is, and analysis of the faults of TRIP is one way to work backwards to that problem definition. > ... > Summary -- it doesn't have to be one grand unified solution (A or B > or ...). > Discounting DNS or ENUM because it doesn't give the whole answer may > be shortsighted. DNS may be *part* of the solution. I really do think that ENUM provides an excellent means for finding the "destination" that is ultimately responsible for a given phone number. What it does NOT do is find an optimal route for getting from the source to the destination, given all the session-border-elements that have to be visited in between. We do have a lot of history on "finding optimal routes", and approaches for doing that look more like TRIP than they look like ENUM. So, we need something that adds the missing pieces to ENUM, and that thing (or set of things) CANOOT be ENUM in and of themselves, because their operational model is by definition different from that of DNS. Let's think about routing at the IP level. My Mac here has only one route, called a "default route" that gets it to my Linksys NAT-router. My Mac learns this route from DHCP (but if it were statically configured, the default route would also be statically configured, aka "provisioned"). The Linksys router also learns its default route via DHCP. The next router out, however, appears to be participating in a dynamic routing table (I can see it sometimes makes different routing decisions). It's probably running OSPF within my ISP's network, and exchanges its static subscriber-facing routing information dynamically with other routers in the ISP-cloud, while learning from those routers about their own adjacencies. Eventually my traffic hits the edge of my ISP's network, where the routers are peering with other ISPs, advertising and learning routes with BGP. Notice we haven't said anything yet about DNS. That's because DNS is entirely separate from routing. I think I'm actually using Google's DNS servers at the moment, and I suspect Google really knows very little about the peering topology of my ISP. So when I type "http://www.ietf.org " into my browser, DNS translates the name into a destination address, and then a combination of default, interior, and exterior routing are used to get my request to the IETF's web server. We're not asking every router along the way to look up "www.ietf.org" in the DNS again. But for call routing to work similarly, we need 1) an analog of the "default route", which is probably provided by conventional configuration and might be well described in draft-ietf-sip-outbound, 2) a dynamic routing protocol inside the local ISP network that helps my traffic get routed to an egress router, and 3) a dynamic routing protocol that helps get the requested from my ISP's external-facing SBE (an "egress route" in Daryl's draft) to an "ingress" route (and maybe through more egress and ingress and SBEs as it moves along through and between peering domains. Note that each of those peering domains probably have their own interior routing topology with steering SBCs and the like. Both 2 and 3 are "something vaguely like TRIP" that is NOT TRIP. But I'd really like to concentrate on what they are, without everybody popping up and saying "You can't have a dynamic routing protocol because TRIP failed to catch on, and therefore dynamic routing protocols are a Bad Idea and we must instead rely on static configuration for everything." -- Dean --Apple-Mail-25--16896031 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 9, 2010, = at 4:30 PM, Lawrence Conroy wrote:

I recall thinking at the time that TRIP was = not right and couldn't readily
be fixed, and was unsurprised that it = just faded away. Thus I am decidedly
sceptical of attempts to = resuscitate what is no longer even a ripe corpse.
It's a dead horse - = stop flogging and get = off.


TRIP was either a = wong solution to a right problem, or a right solution to a wrong = problem. Somewhere out there is something kindof like TRIP (and kindof = NOT like TRIP) that actually solves the right = problem.

First we have to decide what the = "right problem" is, and analysis of the faults of TRIP is one way to = work backwards to that problem = definition.

...

Summary -- it doesn't have to be one grand unified = solution (A or B or ...).
Discounting DNS or ENUM because it doesn't = give the whole answer may
be shortsighted. DNS may be *part* of the = solution.

I really do think that = ENUM provides an excellent means for finding the "destination" that is = ultimately responsible for a given phone number. What it does NOT do is = find an optimal route for getting from the source to the destination, = given all the session-border-elements that have to be visited in = between. We do have a lot of history on "finding optimal routes", and = approaches for doing that look more like TRIP than they look like ENUM. = So, we need something that adds the missing pieces to ENUM, and that = thing (or set of things) CANOOT be ENUM in and of themselves, because = their operational model is by definition different from that of = DNS.

Let's think about routing at the IP level. = My Mac here has only one route, called a "default route" that gets it to = my Linksys NAT-router. My Mac learns this route from DHCP (but if it = were statically configured, the default route would also be statically = configured, aka "provisioned"). 

The = Linksys router also learns its default route via = DHCP. 

The next router out, however, = appears to be participating in a dynamic routing table (I can see it = sometimes makes different routing decisions). It's probably running OSPF = within my ISP's network, and exchanges its static subscriber-facing = routing information dynamically with other routers in the ISP-cloud, = while learning from those routers about their own adjacencies. =  Eventually my traffic hits the edge of my ISP's network, where the = routers are peering with other ISPs, advertising and learning routes = with BGP.

Notice we haven't said anything yet = about DNS. That's because DNS is entirely separate from routing. I think = I'm actually using Google's DNS servers at the moment, and I suspect = Google really knows very little about the peering topology of my ISP. So = when I type "http://www.ietf.org" = into my browser, DNS translates the name into a destination address, and = then a combination of default, interior, and exterior routing are used = to get my request to the IETF's web server. We're not asking every = router along the way to look up "www.ietf.org" in the DNS = again.

But for call routing to work similarly, = we need 1) an analog of the "default route", which is probably provided = by conventional configuration and might be well described in = draft-ietf-sip-outbound, 2) a dynamic routing protocol inside the local = ISP network that helps my traffic get routed to an egress router, and 3) = a dynamic routing protocol that helps get the requested from my ISP's = external-facing SBE (an "egress route" in Daryl's draft) to an "ingress" = route (and maybe through more egress and ingress and SBEs as it moves = along through and between peering domains. Note that each of those = peering domains probably have their own interior routing topology with = steering SBCs and the like.

Both 2 and 3 are = "something vaguely like TRIP" that is NOT TRIP. But I'd really like to = concentrate on what they are, without everybody popping up and saying = "You can't have a dynamic routing protocol because TRIP failed to catch = on, and therefore dynamic routing protocols are a Bad Idea and we must = instead rely on static configuration for = everything."

--
Dean



= --Apple-Mail-25--16896031-- From lendl@nic.at Wed Mar 10 02:35:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A403A6813 for ; Wed, 10 Mar 2010 02:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgO6EJV-+OaB for ; Wed, 10 Mar 2010 02:35:38 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 78B233A67AD for ; Wed, 10 Mar 2010 02:35:37 -0800 (PST) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id C64894CCB2; Wed, 10 Mar 2010 11:35:40 +0100 (CET) Message-ID: <4B9775FD.7010608@nic.at> Date: Wed, 10 Mar 2010 11:35:41 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Lawrence Conroy References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <4B96BAAA.3010900@nic.at> <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> In-Reply-To: <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 10:35:39 -0000 Lawrence, On 09.03.2010 23:30, Lawrence Conroy wrote: > > Summary -- it doesn't have to be one grand unified solution (A or B or ...). > Discounting DNS or ENUM because it doesn't give the whole answer may > be shortsighted. DNS may be *part* of the solution. As I see it, DNS/ENUM is perfect as the LUF protocol: mapping a number to some sort of destination identifier (ITAD, Destination-Group, Destination-Doamin, ...). This is largely independent of who's asking and perfectly suited for DNS' delegation hierarchy and caching architecture. The problem starts when you add the LRF: feeding that function could be static configuration (simple leaf SSPs), simple fallback routing (leaf SSP with two upstreams), or a full-blown routing protocol keying off the LUF's result (ITAD, DG, ... see above). As long as the LRF is colocated with the SIP proxy, then we just need that routing protocol in addition to ENUM as LUF. If it isn't (the SIP proxy is dumb and needs to ask some routing oracle what do to), then we have basically two choices: a) the SIP proxy could still do LUF itself, and then ask the routing oracle how to process a call to a given destination group. b) the SIP proxy doesn't even do the LUF itself and asks the routing oracle what to do with a call to a given E.164 number. -------- If one were to do a), then this would be open to various caching optimizations. The draft that sparked this discussion tries to strong-arm ENUM into doing b). That is IMHO a bad idea. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From Milan.Patel@InterDigital.com Wed Mar 10 05:39:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951BC3A67F8 for ; Wed, 10 Mar 2010 05:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPVTT5ze+WjU for ; Wed, 10 Mar 2010 05:39:48 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 3DD023A680E for ; Wed, 10 Mar 2010 05:39:46 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 08:39:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC057.28CB6DB5" Date: Wed, 10 Mar 2010 08:39:51 -0500 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000D763866@SABRE.InterDigital.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-patel-dispatch-cpc-oli-parameter-02 Thread-Index: AcrAVyhu9u8U5E4LRq6gk7ASqrc83w== From: "Patel, Milan" To: X-OriginalArrivalTime: 10 Mar 2010 13:39:50.0748 (UTC) FILETIME=[287D79C0:01CAC057] Subject: [dispatch] draft-patel-dispatch-cpc-oli-parameter-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 13:39:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC057.28CB6DB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 My understanding is draft-patel-dispatch-cpc-oli-parameter-02 and the Internet Draft for the DAI tel URI parameter are to be handled in a mini working group. I am currently working with the authors of the DAI draft to provide a charter. The latest version of the draft for CPC and OLI tel URI parameters includes a syntax which as been approved by 3GPP and within 3GPP CPC and OLI are a release 7 requirement.=20 =20 I am requesting for further comments on the draft. I am aware I need to change my contact details on the draft.=20 =20 Best regards, Milan ------_=_NextPart_001_01CAC057.28CB6DB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

My understanding is = draft-patel-dispatch-cpc-oli-parameter-02 and the Internet Draft for the DAI tel URI parameter are to be handled = in a mini working group. I am currently working with the authors of the DAI = draft to provide a charter. The latest version of the draft for CPC and OLI tel = URI parameters includes a syntax which as been approved by 3GPP and within = 3GPP CPC and OLI are a release 7 requirement.

 

I am requesting for further comments on the = draft. I am aware I need to change my contact details on the draft. =

 

Best regards,

Milan

------_=_NextPart_001_01CAC057.28CB6DB5-- From pkyzivat@cisco.com Wed Mar 10 06:59:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934B13A6AB6 for ; Wed, 10 Mar 2010 06:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.281 X-Spam-Level: X-Spam-Status: No, score=-10.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfoaLCD1yHeo for ; Wed, 10 Mar 2010 06:59:23 -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 7EB963A689A for ; Wed, 10 Mar 2010 06:59:20 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMRCl0tAZnwM/2dsb2JhbACbB3OkS5hSgk0BBgSCIQSDF4sbQg X-IronPort-AV: E=Sophos;i="4.49,614,1262563200"; d="scan'208";a="91656129" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2010 14:59:24 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2AExOJe009495; Wed, 10 Mar 2010 14:59:24 GMT Message-ID: <4B97B3CC.4070400@cisco.com> Date: Wed, 10 Mar 2010 09:59:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jon Peterson References: <0913B6CD18F370498CD65864CF254E900AFC3BBD@zharhxm1.corp.nortel.com> <4ACE4F9B.5090909@neustar.biz> In-Reply-To: <4ACE4F9B.5090909@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Milan Patel , DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:59:24 -0000 I just got around to reading this draft. I have all of the concerns that Jon does, plus some others: Many of these properties are in fact properties of the *call*, not properties of the *caller*. That is especially true of the oli values: - some are a function of the called number rather than the caller: * 30 Intercept (blank) - for calls to unassigned directory number (DN) * 31 Intercept (trouble) - for calls to directory numbers (DN) that have been manually placed in trouble-busy state by Telco personnel * 32 Intercept (regular) - for calls to recently changed or disconnected numbers - the value can be assigned mid-call, as a result of call handling: * 34 Telco Operator Handled Call - after the Telco Operator Services System has handled a call for an IC, it may change the standard ANI digits to "34", before outpulsing the sequence to the IC, when the Telco performs all call handling functions, e.g., billing. The code tells the IC that the BOC has performed billing on the call and the IC only has to complete the call. * 52 Outward Wide Area Telecommunications Service (OUTWATS) - this service allows customers to make calls to a certain zone(s) or band(s) on a direct dialed basis for a flat monthly charge or for a charge based on accumulated usage. OUTWATS lines can dial station-to-station calls directly to points within the selected band(s) or zone(s). The LEC performs a screening function to determine the correct charging and routing for OUTWATS calls based on the customer's class of service and the service area of the call party. When these calls are routed to the interexchange carrier via a combined WATS-POTS trunk group, it is necessary to identify the WATS calls with the ANI code "52". - (this is not an exhaustive list.) Putting the value in From is problematic if it is a function of something other than the caller. Its even more problematic if it can change mid-call, since changing it breaks Identity. Even when the information is a property of the caller, it seems likely that it will often be added by something other than the UAC, since the UAC is unlikely to be trusted to provide it. If this is information that is a property of the call rather than caller, and it can change along the signaling path, then IMO it belongs in some other header, in a field that may be changed along the path. Also a NIT: The "oli" parameter with value 29 indicates that the device that the call is initiated from is located within a prison. An "oli" with value "prison" is equally valid. The ABNF doesn't permit a value of "prison" for the oli parameter - only digits. Jon Peterson wrote: > > In evaluating proposals to add capabilities to SIP via a tel URI, the > first question we ask is, "Would this be useful in SIP requests that do > NOT use telephone numbers?" If the answer is "yes," then probably the > capability should be added to SIP in a way that works with and without > the tel URI. (The draft is very slightly unclear about whether or not > you can include this parameter in SIP URIs that do not contain embedded > tel URIs but do contain non-tel-URI representations of telephone numbers > - but I'm speaking here to the overall intention to couple the use of > OLI/CPC information to telephone numbers exclusively.) > > While the draft focuses on the use case where SIP is gatewaying to ISUP, > and thus where telephone numbers are likely to be used, I would be > hesitant to rule out uses that do not involve telephone numbers - > especially when the motivating use case given is REGISTER in an > emergency context. Encapsulating the opaque numeric values of OLI into a > SIP parameter also more or less restricts the use of this to entities > that understand ISUP. This begs the obvious question: should there be a > way in SIP (outside of gatewaying) to express these same concepts? > Since you already translate the CPC values into human-readable > equivalents ("operator", "payphone", "test"), is there some reason why > OLI can't receive the same treatment? The only example of the semantics > of OLI that you give ("oli=29" meaning "prison") indeed seems it could > admit of that translation. If there is some good reason why CPC should > be translated and OLI should be encapsulated, the draft should > explicitly motivate it. > > By the by, since the Acks mention that I submitted a version of this > proposal prior to Rohan's, just as an historical aside I in fact split > that out from the original draft-ietf-sip-privacy-04 by Flemming and > Bill Marshall, which for some reason had it tacked into an appendix. The > parameter proposed in that document (which can still be found via > Google), the Nature of Party ("np") parameter, maps to a set of > human-readable literals like "ordinary", "police", "payphone", > "emergency", and so on. The document then proposes a mapping to the ANI > II digits; one could just as easily be provided for OLI or CPC in the > ISUP variants of interest. The example given in that appendix shows this > being used in a URI that doesn't contain a telephone number. In any > event, if you want to have a pedigree of the idea in your Acks, you > shouldn't leave out that document. > > Jon Peterson > NeuStar, Inc. > > Milan Patel wrote: >> Hi, >> >> A new version of the Internet Draft for the Calling Party's Category and >> Originating Line Identity URI Parameters is now available. >> http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt >> >> This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 >> >> Best regards, >> Milan >> >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 08 >> October 2009 18:40 >> To: Patel, Milan (MOP:EP10) >> Cc: r.jesske@telekom.de; mdolly@att.com >> Subject: New Version Notification for >> draft-patel-dispatch-cpc-oli-parameter-00 >> >> A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has >> been successfuly submitted by Milan Patel and posted to the IETF >> repository. >> >> Filename: draft-patel-dispatch-cpc-oli-parameter >> Revision: 00 >> Title: Uniform Resource Identifier (URI) Parameters for >> indicating the Calling Party's Catagory and Originating Line Identity >> Creation_date: 2009-10-08 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document defines two new URI parameters to describe the calling >> party's category and toll class of service originating line >> information which are parameters also used in SS7 ISUP and other >> telephony signalling protocols. The intended use of these URI >> parameters is for the "tel" URI or equivalent SIP URI representation. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From emcho@sip-communicator.org Wed Mar 10 07:08:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113733A6AA6 for ; Wed, 10 Mar 2010 07:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Lwe2EuiwoOf for ; Wed, 10 Mar 2010 07:08:37 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 9F9323A6817 for ; Wed, 10 Mar 2010 07:08:37 -0800 (PST) Received: by ewy8 with SMTP id 8so1329116ewy.28 for ; Wed, 10 Mar 2010 07:08:39 -0800 (PST) Received: by 10.213.24.21 with SMTP id t21mr5046145ebb.99.1268233715725; Wed, 10 Mar 2010 07:08:35 -0800 (PST) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id 13sm3973763ewy.1.2010.03.10.07.08.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 07:08:33 -0800 (PST) Message-ID: <4B97B5F0.3030905@sip-communicator.org> Date: Wed, 10 Mar 2010 16:08:32 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Subject: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 15:08:39 -0000 Hey all, A couple of months ago we had a discussion here about how SIP-XMPP clients would discover and authenticate against its SIP and XMPP parts. Enrico and I have recently posted a draft [1] detailing the problem and summarizing two ways of addressing it. We'd be happy to be able to discuss this in Anaheim and comments are of course welcome at any time. Cheers, Emil [1] - http://tools.ietf.org/html/draft-ivov-sipxmpp-auth-01 -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From lendl@nic.at Wed Mar 10 07:44:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE553A6B3D for ; Wed, 10 Mar 2010 07:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wEcclQS-vFJ for ; Wed, 10 Mar 2010 07:44:02 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 89A183A6B42 for ; Wed, 10 Mar 2010 07:44:00 -0800 (PST) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id B9D7A4CDA1; Wed, 10 Mar 2010 16:44:03 +0100 (CET) Message-ID: <4B97BE44.2060302@nic.at> Date: Wed, 10 Mar 2010 16:44:04 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "PFAUTZ, PENN L (ATTCORP)" References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 15:44:03 -0000 Penn, On 09.03.2010 00:26, PFAUTZ, PENN L (ATTCORP) wrote: > Just a word of caution re number portability. In some countries access > to this data is restricted to legally qualified carriers. Will ITADs > always correspond to such entities? Looking at the IANA list so far > that's not my impression. You may find that the entities that do have > access to NP databases may not be the ones interested in a TRIP-like > mechanism and vice versa. This is indeed a relevant point. >From my perspective, this is, while true, mostly a red herring erected by carriers who try to shield the actual market numbers from the public. For example, in Austria NP data used to be private and carriers (plus their lobbyists) worked hard to keep it that way. Then one day we finally implemented mobile NP in Austria. As calling towards mobiles is comparatively expensive and the tariff varies by destination network, the regulator mandated that callers have to be notified via a voice announcement if a number has been ported. (The price for a call might have changed from 0 cents/min (on-net for some deals) to 30 cents/min due to a porting operation. So this was a legitimate consumer protection issue.) In other words, we went from a "keep this info private" mindset to a "annoy end-users with this information on each call" within a year. So: if there is a legitimate reason why the general public needs this information (e.g. to do correct least-cost routing on multi-homed PBXs) then this can change quickly. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From pp3129@att.com Wed Mar 10 08:23:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C57B3A6951 for ; Wed, 10 Mar 2010 08:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtGVtbmEY6G3 for ; Wed, 10 Mar 2010 08:23:32 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 52B0A3A6A2F for ; Wed, 10 Mar 2010 08:23:10 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1268238193!23050230!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13925 invoked from network); 10 Mar 2010 16:23:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2010 16:23:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2AGN3db005012 for ; Wed, 10 Mar 2010 11:23:03 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2AGMu2Y004857 for ; Wed, 10 Mar 2010 11:22:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 11:23:05 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0384131D@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4B97BE44.2060302@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] is this TRIP necessary? Thread-Index: AcrAaIz0F9sT5cH8SuSO2jVIeZ35WQAAOYeg References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> <4B97BE44.2060302@nic.at> From: "PFAUTZ, PENN L (ATTCORP)" To: "Otmar Lendl" Cc: dispatch@ietf.org Subject: Re: [dispatch] is this TRIP necessary? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 16:23:34 -0000 Otmar: I hear you (although in the US we didn't do calling-party-pays and carriers generally don't reflect different termination rates in their retail toll prices so we won't have *that* problem.) But I'd really like to raise what I think is a larger issue - just what are we trying to accomplish? All the LRF and TRIP stuff seems to be tending toward a kind of link-by-link call routing model that to me seems redolent of the kind of trunk group by trunk group routing in the PSTN. I thought that that was what we were trying to get away from in moving to IP!=20 The original promise of ENUM was that it would identify the target and basic Internet connectivity would then get you there. As you've pointed out elsewhere, that original vision didn't really work for most carriers, but carriers have tried to replicate parts of it with approaches like the GSMA IPX to provide a secure IP fabric for connecting. That allows connectivity management via selective advertising in BGP so that the SIP INVITES based on same ENUM query response is appropriately routed from different originating networks. The same techniques support direct bilateral interconnection which is how much of the traffic will flow anyway. So, when would you want something TRIP like? To me the remaining case seems to be when you're searching for the best intermediary when you're neither directly connected nor linked to some kind of IPX like fabric that can get to the target. I expect intermediaries to compete and scale to matter. When I need an intermediary I'll generally prefer that they handle the whole job. Some pricing tables will let me choose and I'm not sure I need/want those coming across the NNI as reachability advertisements.=20 Add to this the downward pressure on rates that is only going accelerate and I wonder how much need there really is. I may be biased from my vantage point though and perhaps someone can provide the compelling use case. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Wednesday, March 10, 2010 10:44 AM To: PFAUTZ, PENN L (ATTCORP) Cc: mohamed.boucadair@orange-ftgroup.com; Dean Willis; dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Penn, On 09.03.2010 00:26, PFAUTZ, PENN L (ATTCORP) wrote: > Just a word of caution re number portability. In some countries access > to this data is restricted to legally qualified carriers. Will ITADs > always correspond to such entities? Looking at the IANA list so far > that's not my impression. You may find that the entities that do have > access to NP databases may not be the ones interested in a TRIP-like > mechanism and vice versa. This is indeed a relevant point. >From my perspective, this is, while true, mostly a red herring erected by carriers who try to shield the actual market numbers from the public. For example, in Austria NP data used to be private and carriers (plus their lobbyists) worked hard to keep it that way. Then one day we finally implemented mobile NP in Austria. As calling towards mobiles is comparatively expensive and the tariff varies by destination network, the regulator mandated that callers have to be notified via a voice announcement if a number has been ported. (The price for a call might have changed from 0 cents/min (on-net for some deals) to 30 cents/min due to a porting operation. So this was a legitimate consumer protection issue.) In other words, we went from a "keep this info private" mindset to a "annoy end-users with this information on each call" within a year. So: if there is a legitimate reason why the general public needs this information (e.g. to do correct least-cost routing on multi-homed PBXs) then this can change quickly. otmar --=20 // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From D.Malas@cablelabs.com Wed Mar 10 08:23:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788F63A6920 for ; Wed, 10 Mar 2010 08:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3] 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 RYj9uMxI7BjR for ; Wed, 10 Mar 2010 08:23:57 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id C71D03A6827 for ; Wed, 10 Mar 2010 08:23:56 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2AGO15X017932; Wed, 10 Mar 2010 09:24:01 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 10 Mar 2010 09:24:01 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 10 Mar 2010 09:24:01 -0700 From: Daryl Malas To: "'Dean Willis'" Date: Wed, 10 Mar 2010 09:24:00 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrAFnsGMisEOqp0QrC5jnk1IegBnAAVY7LQ Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F671D@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <4B96BAAA.3010900@nic.at> <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> <1985C859-BE1C-4BF4-B056-D13C373956C2@softarmor.com> In-Reply-To: <1985C859-BE1C-4BF4-B056-D13C373956C2@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F671Dsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 16:23:58 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F671Dsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dean, One of the challenges is at what layer the information is routed. Using yo= ur example below, after the FQDN is converted into an IP address, your Mac = now routes the payload entirely through "layer 1-3" elements to reach the d= estination server. With SIP, it should be considered, after the FQDN for t= he domain is converted into an IP address it is routed through "layer 1-3" = elements to a "layer 5" element, which is not the destination. Our existin= g routing protocols (e.g. RIP (just wanted to throw this one in), OSPF, BGP= , etc.) focus on layer 3. The address space and the ability to summarize t= his space is well understood and defined in the industry. I think the reas= on we are struggling with varying solutions, whether it is TRIP or ENUM or = whatever, is because we are working in an undefined address space, leveragi= ng multiple layers. Even if I am able to dynamically exchange domain names with other peers, so= I can do my ENUM look-up, resolve to a URI, and then do a DNS look-up on t= he URI domain; I am still faced with layer 3 potentially routing me non-opt= imally to my next layer 5 hop. The reason for this is, simply, my layer 3 = routers are not layer 5 aware. I either statically define layer 3 or layer= 5, but these are the only two options I see at this point. The other thing to consider is layer 5 providers (SSPs), in my perception, = are far more paranoid than layer 3 providers (SPs). I believe this is the = perception of the redundant, redundant, diversified, diversified super dupe= r extra stable telephony infrastructure that was built over a 100 years. I= n another 60 years, SPs will be the same as IP is leveraged more and more f= or "time sensitive" applications. Regards, Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dean Willis Sent: Tuesday, March 09, 2010 10:57 PM To: Lawrence Conroy Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 9, 2010, at 4:30 PM, Lawrence Conroy wrote: I recall thinking at the time that TRIP was not right and couldn't readily be fixed, and was unsurprised that it just faded away. Thus I am decidedly sceptical of attempts to resuscitate what is no longer even a ripe corpse. It's a dead horse - stop flogging and get off. TRIP was either a wong solution to a right problem, or a right solution to = a wrong problem. Somewhere out there is something kindof like TRIP (and kin= dof NOT like TRIP) that actually solves the right problem. First we have to decide what the "right problem" is, and analysis of the fa= ults of TRIP is one way to work backwards to that problem definition. ... Summary -- it doesn't have to be one grand unified solution (A or B or ...)= . Discounting DNS or ENUM because it doesn't give the whole answer may be shortsighted. DNS may be *part* of the solution. I really do think that ENUM provides an excellent means for finding the "de= stination" that is ultimately responsible for a given phone number. What it= does NOT do is find an optimal route for getting from the source to the de= stination, given all the session-border-elements that have to be visited in= between. We do have a lot of history on "finding optimal routes", and appr= oaches for doing that look more like TRIP than they look like ENUM. So, we = need something that adds the missing pieces to ENUM, and that thing (or set= of things) CANOOT be ENUM in and of themselves, because their operational = model is by definition different from that of DNS. Let's think about routing at the IP level. My Mac here has only one route, = called a "default route" that gets it to my Linksys NAT-router. My Mac lear= ns this route from DHCP (but if it were statically configured, the default = route would also be statically configured, aka "provisioned"). The Linksys router also learns its default route via DHCP. The next router out, however, appears to be participating in a dynamic rout= ing table (I can see it sometimes makes different routing decisions). It's = probably running OSPF within my ISP's network, and exchanges its static sub= scriber-facing routing information dynamically with other routers in the IS= P-cloud, while learning from those routers about their own adjacencies. Ev= entually my traffic hits the edge of my ISP's network, where the routers ar= e peering with other ISPs, advertising and learning routes with BGP. Notice we haven't said anything yet about DNS. That's because DNS is entire= ly separate from routing. I think I'm actually using Google's DNS servers a= t the moment, and I suspect Google really knows very little about the peeri= ng topology of my ISP. So when I type "http://www.ietf.org" into my browser= , DNS translates the name into a destination address, and then a combinatio= n of default, interior, and exterior routing are used to get my request to = the IETF's web server. We're not asking every router along the way to look = up "www.ietf.org" in the DNS again. But for call routing to work similarly, we need 1) an analog of the "defaul= t route", which is probably provided by conventional configuration and migh= t be well described in draft-ietf-sip-outbound, 2) a dynamic routing protoc= ol inside the local ISP network that helps my traffic get routed to an egre= ss router, and 3) a dynamic routing protocol that helps get the requested f= rom my ISP's external-facing SBE (an "egress route" in Daryl's draft) to an= "ingress" route (and maybe through more egress and ingress and SBEs as it = moves along through and between peering domains. Note that each of those pe= ering domains probably have their own interior routing topology with steeri= ng SBCs and the like. Both 2 and 3 are "something vaguely like TRIP" that is NOT TRIP. But I'd re= ally like to concentrate on what they are, without everybody popping up and= saying "You can't have a dynamic routing protocol because TRIP failed to c= atch on, and therefore dynamic routing protocols are a Bad Idea and we must= instead rely on static configuration for everything." -- Dean --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F671Dsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dean,
 
One of the challenges is at what layer the infor= mation=20 is routed.  Using your example below, after the FQDN is converted into= an=20 IP address, your Mac now routes the payload entirely through "layer 1-3"=20 elements to reach the destination server.  With SIP, it should be=20 considered, after the FQDN for the domain is converted into an IP address i= t is=20 routed through "layer 1-3" elements to a "layer 5" element, which is not th= e=20 destination.  Our existing routing protocols (e.g. RIP (just wanted to= =20 throw this one in), OSPF, BGP, etc.) focus on layer 3.  The addre= ss=20 space and the ability to summarize this space is well understood = and=20 defined in the industry.  I think the reason we are struggling with va= rying=20 solutions, whether it is TRIP or ENUM or whatever, is because we are workin= g in=20 an undefined address space, leveraging multiple layers.
 
Even if I am able to dynamically exchange domain= names=20 with other peers, so I can do my ENUM look-up, resolve to a URI, and then d= o a=20 DNS look-up on the URI domain; I am still faced with layer 3 potentially ro= uting=20 me non-optimally to my next layer 5 hop.  The reason for this is, simp= ly,=20 my layer 3 routers are not layer 5 aware.  I either statically define = layer=20 3 or layer 5, but these are the only two options I see at this=20 point.
 
The other thing to consider is layer 5 providers= =20 (SSPs), in my perception, are far more paranoid than layer 3 providers=20 (SPs).  I believe this is the perception of the redundant, redundant,= =20 diversified, diversified super duper extra stable telephony infrastructure = that=20 was built over a 100 years.  In another 60 years, SPs will be the same= as=20 IP is leveraged more and more for "time sensitive"=20 applications.
 
Regards,
 
Daryl

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean=20 Willis
Sent: Tuesday, March 09, 2010 10:57 PM
To: Lawre= nce=20 Conroy
Cc: dispatch@ietf.org
Subject: Re: [dispatch] I-= D=20 Action: draft-malas-dispatch-sip-egress-route-00


On Mar 9, 2010, at 4:30 PM, Lawrence Conroy wrote:

I recall t= hinking=20 at the time that TRIP was not right and couldn't readily
be fixed, and= was=20 unsurprised that it just faded away. Thus I am decidedly
sceptical of= =20 attempts to resuscitate what is no longer even a ripe corpse.
It's a d= ead=20 horse - stop flogging and get off.


TRIP was either a wong solution to a right problem, or a right solutio= n to=20 a wrong problem. Somewhere out there is something kindof like TRIP (and kin= dof=20 NOT like TRIP) that actually solves the right problem.

First we have to decide what the "right problem" is, and analysis of t= he=20 faults of TRIP is one way to work backwards to that problem definition.

...

Summary -- it doesn't have to be one grand unified solution (A or B = or=20 ...).
Discounting DNS or ENUM because it doesn't give the whole answer= =20 may
be shortsighted. DNS may be *part* of the=20 solution.

I really do think that ENUM provides an excellent means for finding th= e=20 "destination" that is ultimately responsible for a given phone number. What= it=20 does NOT do is find an optimal route for getting from the source to the=20 destination, given all the session-border-elements that have to be visited = in=20 between. We do have a lot of history on "finding optimal routes", and appro= aches=20 for doing that look more like TRIP than they look like ENUM. So, we need=20 something that adds the missing pieces to ENUM, and that thing (or set of=20 things) CANOOT be ENUM in and of themselves, because their operational mode= l is=20 by definition different from that of DNS.

Let's think about routing at the IP level. My Mac here has only one ro= ute,=20 called a "default route" that gets it to my Linksys NAT-router. My Mac lear= ns=20 this route from DHCP (but if it were statically configured, the default rou= te=20 would also be statically configured, aka "provisioned"). 

The Linksys router also learns its default route via DHCP. 

The next router out, however, appears to be participating in a dynamic= =20 routing table (I can see it sometimes makes different routing decisions). I= t's=20 probably running OSPF within my ISP's network, and exchanges its static=20 subscriber-facing routing information dynamically with other routers in the= =20 ISP-cloud, while learning from those routers about their own adjacencies.=20  Eventually my traffic hits the edge of my ISP's network, where the ro= uters=20 are peering with other ISPs, advertising and learning routes with BGP.

Notice we haven't said anything yet about DNS. That's because DNS is=20 entirely separate from routing. I think I'm actually using Google's DNS ser= vers=20 at the moment, and I suspect Google really knows very little about the peer= ing=20 topology of my ISP. So when I type "http://www.ietf.org" into my browser, DNS= =20 translates the name into a destination address, and then a combination of=20 default, interior, and exterior routing are used to get my request to the I= ETF's=20 web server. We're not asking every router along the way to look up "www.ietf.org" in the DNS again.

But for call routing to work similarly, we need 1) an analog of the=20 "default route", which is probably provided by conventional configuration a= nd=20 might be well described in draft-ietf-sip-outbound, 2) a dynamic routing=20 protocol inside the local ISP network that helps my traffic get routed to a= n=20 egress router, and 3) a dynamic routing protocol that helps get the request= ed=20 from my ISP's external-facing SBE (an "egress route" in Daryl's draft) to a= n=20 "ingress" route (and maybe through more egress and ingress and SBEs as it m= oves=20 along through and between peering domains. Note that each of those peering= =20 domains probably have their own interior routing topology with steering SBC= s and=20 the like.

Both 2 and 3 are "something vaguely like TRIP" that is NOT TRIP. But I= 'd=20 really like to concentrate on what they are, without everybody popping up a= nd=20 saying "You can't have a dynamic routing protocol because TRIP failed to ca= tch=20 on, and therefore dynamic routing protocols are a Bad Idea and we must inst= ead=20 rely on static configuration for everything."

--
Dean



--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F671Dsrvxchg_-- From kcartwright@tnsi.com Wed Mar 10 09:11:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965E03A6BD6; Wed, 10 Mar 2010 09:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UJIrov2Ugod; Wed, 10 Mar 2010 09:10:51 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 717553A6C03; Wed, 10 Mar 2010 09:10:37 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41334725; Wed, 10 Mar 2010 12:10:30 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 10 Mar 2010 12:10:31 -0500 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L (ATTCORP)" , "mohamed.boucadair@orange-ftgroup.com" , Dean Willis Date: Wed, 10 Mar 2010 12:10:29 -0500 Thread-Topic: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? Thread-Index: Acq8j+6o6c1MOz+jQyGq+55MeiM4hwCNy+vQABO7wMAAVoMlQA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D8925D533@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_" MIME-Version: 1.0 Cc: "drinks@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 17:11:02 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ...taking this discussion onto a related tangent.... These regulatory and contractual limitations on access to TN->Carrier assig= nments are one of the reasons that existing systems that currently provide = the envisioned LUF feature (query a TN to find out the responsible carrier = currently assigned to that TN, more or less) are *required* to allow the LU= F responses to vary based on the querier. Additional requirements that nec= essitate this are: (1) This TN->CarrierAssignment data set is often/usually "layered", in = the sense that the a country code's Based Number Plan TN->CarrierAssignment= s comprise the foundation layer, that is then overlaid by (but not co-mingl= ed with) number portability TN->CarrierAssignmens, that is then overlaid by= (but not comingled with) TN->CarrierAssignments for TNs that are leased ac= ross carriers, that is then overlaid by TN->CarrierAssignments for TNs that= override any of the proceeding for any number of business or operational r= easons (although this last overlay is less structured and less relevant to = the overall point). (2) Regulatory, contractual, and business reasons currently determine, = for each country code, the layers and subsets of layers of TN->CarrierAssig= nments that any given querier is allowed to "see". (3) Some queriers simply do not want to see certain layers of TN->Carri= erAssignemnts for given country codes. (4) Because many country codes do not have a regulatory or any well def= ined source for TN->CarrierAssignments, the data is sourced from multiple p= arties. So even within a given country code, only portions of a given laye= r may be allowed to be seen by some queriers. So one way of looking at the problem space of the LUF is that the above req= uirements are not what we want to solve and standardize. What we want to s= olve and standardize is the much simpler and pristine end goal of ... all T= N->CarrierAssignment information is queriable by any organization and all t= hose organizations have legal access to all of it. We solve and standardiz= e this with the view of "build it and they will come". The other way of looking at the problem is that we solve the requirements s= tated above. Ken ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of PFAUTZ, PENN L (ATTCORP) Sent: Monday, March 08, 2010 6:27 PM To: mohamed.boucadair@orange-ftgroup.com; Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? Just a word of caution re number portability. In some countries access to t= his data is restricted to legally qualified carriers. Will ITADs always co= rrespond to such entities? Looking at the IANA list so far that's not my im= pression. You may find that the entities that do have access to NP database= s may not be the ones interested in a TRIP-like mechanism and vice versa. Penn Pfautz AT&T Access Management +1-732-420-4962 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of mohamed.boucadair@orange-ftgroup.com Sent: Monday, March 08, 2010 9:33 AM To: Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alter= native? Dear Dean, all, Please see inline. Cheers, Med ________________________________ De : Dean Willis [mailto:dean.willis@softarmor.com] Envoy=E9 : vendredi 5 mars 2010 19:16 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Daryl Malas; dispatch@ietf.org Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event altern= ative? On Mar 5, 2010, at 1:38 AM, > > wrote: Dear Dean, all, In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interc= onnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challeng= es_of_IP_telephony_Eurescom_study_P1853.asp I'm having a hard time resolving this link, as it appears to be 404. Perhap= s there's a typo? With respect to: 21. Extended TRIP protocol is suggested to be used as base for IP Telephony= routing; We've heard here that TRIP, as currently modeled, doesn't work due to the L= NP problem. What sorts of extensions id you have in mind? Were they intende= d to address this problem? [Med] An alternative would be to use TRIP in conjunction with a the current= Number Portability infrastructure as used in PSTN infrastructure for placi= ng inter-ITAD calls (this means that the owner domain will always advertise= its aggregate in TRIP, but a NPDB (Network Portability Database) should qu= estioned first). Examples of extensions to TRIP (or whatever dynamic telephony routing) woul= d be: - Avoid AS (Autonomous System) spiral: the media traffic can cross the same= AS several times - Ability to maintain multiple inter-ITAD paths - Ability to enforce some advanced TE such as: Avoid that my VoIP traffic t= o cross a given AS domain (TRIP only maintain an ITAD list) - Ability to avoid congestionned links - etc. BTW, TRIP is only considered as starting point, this does not preclude to i= nvestigate any new solution to meet the recommendations we identified. BTW,= In the recommendations list we have identified the need to encourage aggre= gation-based models. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

…taking this discussion onto a r= elated tangent….

 

These regulatory and contractual limit= ations on access to TN->Carrier assignments are one of the reasons that = existing systems that currently provide the envisioned LUF feature (query a TN to find out the responsible= carrier currently assigned to that TN, more or less) are *required* to allow the LUF responses to va= ry based on the querier.  Additional requirements that necessitate this are:

 

(1) =     This TN->CarrierAssignment data set is often/usually “= layered”, in the sense that the a country code’s Based Number Plan TN->CarrierAssignments comprise the foundation layer, that = is then overlaid by (but not co-mingled with) number portability TN->Car= rierAssignmens, that is then overlaid by (but not comingled with) TN->Ca= rrierAssignments for TNs that are leased across carriers, that is then overlaid by TN->CarrierAssignments for TN= s that override any of the proceeding for any number of business or operati= onal reasons (although this last overlay is less structured and less releva= nt to the overall point).

(2) =     Regulatory, contractual, and business reasons currently determi= ne, for each country code, the layers and subsets of layers of TN->CarrierAssignments that any given querier is allowed t= o “see”.

(3) =     Some queriers simply do not want to see certain layers of TN-&g= t;CarrierAssignemnts for given country codes.

(4) =     Because many country codes do not have a regulatory or any well= defined source for TN->CarrierAssignments, the data is sourced from multiple parties.  So even within a given countr= y code, only portions of a given layer may be allowed to be seen by some qu= eriers.

 

So one way of looking at the problem s= pace of the LUF is that the above requirements are not what we want to solv= e and standardize.  What we want to solve and standardize is the much simpler and pristine end= goal of … all TN->CarrierAssignment information is queriable by a= ny organization and all those organizations have legal access to all of it.=   We solve and standardize this with the view of “build it and they will come”.

 

The other way of looking at the proble= m is that we solve the requirements stated above.<= /p>

 

Ken

 

From: disp= atch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L = (ATTCORP)
Sent: Monday, March 08, 2010= 6:27 PM
To: mohamed.boucadair@orange= -ftgroup.com; Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why = are we TRIPped out? Is there an sip-event alternative?

 

= Just a w= ord of caution re number portability. In some countries access to this data= is restricted to legally qualified carriers.  Will ITADs always correspond to such entities? Looking at the IANA list so= far that’s not my impression. You may find that the entities that do= have access to NP databases may not be the ones interested in a TRIP-like = mechanism and vice versa.

= &nb= sp;

Penn Pfautz<= /span>

AT&T Acc= ess Management

+1-732-4= 20-4962

From: disp= atch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucada= ir@orange-ftgroup.com
Sent: Monday, March 08, 2010= 9:33 AM
To: Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Why = are we TRIPped out? Is there an sip-event alternative?

 

 

Dear Dean, all,

 

Please see inline.

Cheers,

Med

 

De : Dean Willis [mailto:dean.willis@softarmor.com]
Envoy=E9 : vendredi 5 m= ars 2010 19:16
=C0 : BOUCADAIR Mohamed= NCPI/NAD/TIP
Cc : Daryl Malas; dispa= tch@ietf.org
Objet : Re: [dispatch] = Why are we TRIPped out? Is there an sip-event alternative?

 

 


Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnec= t at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of= _IP_telephony_Eurescom_study_P1853.asp).

I'm having a hard time resolving this link, as it appears to be 404= . Perhaps there's a typo?

 

With respect to:

 

 

21. Extended TRIP protocol is suggested to be used as base for IP Teleph= ony routing;

 

We've heard here that TRIP, as currently modeled, doesn't work due = to the LNP problem. What sorts of extensions id you have in mind? Were they= intended to address this problem?

[Med] An alternative would be to use TRIP in conjunction wi= th a the current Number Portability infrastructure as used in&nbs= p;PSTN infrastructure for placing inter-ITAD calls (this means tha= t the owner domain will always advertise its aggregate in TRIP, but a = NPDB (Network Portability Database) should questioned first). <= /font>

 

Examples of extensions to TRIP (or whatever dynamic telephony routing= ) would be:

- Avoid AS (Autonomous System) spiral: the media traffic can cross th= e same AS several times

- Ability to maintain multiple inter-ITAD paths

- Ability to enforce some advanced TE such as: Avoid that my VoIP tra= ffic to cross a given AS domain (TRIP only maintain an ITAD list)

- Ability to avoid congestionned links

- etc.

 

BTW, TRIP is only considered as starting point, this does not preclud= e to investigate any new solution to meet the recommendations we identified. BTW, In the recommendations list we have identified the nee= d to encourage aggregation-based models.

 

*********************************
This message and any attachments (the "message") are confidentia=
l and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, chang=
ed or falsified.
If you are not the intended addressee of this message, please cancel it im=
mediately and inform the sender.
********************************

This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0D8925D533TNSMAILNAwin2_-- From D.Malas@cablelabs.com Wed Mar 10 15:16:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87FC3A6837 for ; Wed, 10 Mar 2010 15:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 8aXQBsbMyMzI for ; Wed, 10 Mar 2010 15:16:06 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id BD8843A690C for ; Wed, 10 Mar 2010 15:16:04 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2ANG9N5019406; Wed, 10 Mar 2010 16:16:09 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 10 Mar 2010 16:16:09 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 10 Mar 2010 16:16:09 -0700 From: Daryl Malas To: "'Dean Willis'" Date: Wed, 10 Mar 2010 16:16:09 -0700 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: Acq/reLmNghPZ6CGRRChjB0GuWrsLwA+D1vg Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> In-Reply-To: <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 23:16:07 -0000 Dean, Based on your assessment below, let me try and summarize: Two IETF efforts: 1) Egress Route Method for SIP (Intra-domain) 2) Dynamic Routing Method for SIP (Inter-domain) I attempted to provide my response to your questions below. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Tuesday, March 09, 2010 10:28 AM To: Daryl Malas Cc: Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 9, 2010, at 10:04 AM, Daryl Malas wrote: > Dean et. al, > > I am thankful my draft spurred on this discussion on potentially=20 > resolving a larger issue. With this being said, the purpose of the=20 > draft is to be a potential component of the larger solution. I got=20 > lost on whether or not the general community understands and sees the=20 > overall value of defining an egress method, for ensuring a consistent=20 > approach between SSPs and vendors. I definitely see the need for defining a method by which to inform nodes in= side an ITAD of egress routes from that ITAD to other domains. =20 I think that most of the people who have responded on this thread agree tha= t there is such a need. We also seem to see a need for dissemination of inter-ITAD routing informat= ion, although we're still discussing the relationships between phone number= s, ITADs, and routes. Where we have a disagreement is on mechanism. While your proposed use of IT= AD-specific private ENUM servers is not completely inconsistent with recen= t trends in ENUM, I have to say we've done a lot of things in ENUM that I d= on't like, and this is pushing the envelope further in that direction. Ther= e are a lot of people running private DNS spaces, too, but we haven't stand= ardized the discovery of default routes within an Intranet using private DN= S for very good reasons, and those same reasons apply to ENUM used in the s= ame pattern. Yes, it can be made to work, but it creates massive operationa= l headaches. We have several arguments in favor of some sort of "dynamic routing protoco= l" solution or solutions. Open questions include: 1) Are different interior and exterior routing protocols (BGP vs OSPF, for = instance) required, or can one common protocol meet the full set f requirem= ents? [DM] Good question. I think we need to have one that works for either befo= re we can determine whether it is internal for external only. 2) Is a standalone protocol such as TRIP more appropriate than something "= inside" SIP (or DNS, XMPP, whatever)? If so, does this apply to both interi= or and exterior roles? [DM] After some "hallway collaboration," I do not think TRIP will work, at = all, in it's current state. 3) Can TRIP be made to work? This has related questions about aggregation m= odels, LNP access, LNP fragmentation of aggregation, etc. [DM] Maybe; but whether you use domains or E.164 addresses, the underlying = layer 3-to-layer 5 issues still exists. 4) Can inter-ITAD routing be accomplished based on number-to-ITAD transform= ations (which ENUM gives us) accompanied by a dynamic inter- ITAD route exc= hange protocol? This may also have to factor in the LNP problem. [DM] I think this may be a more likely potential, but still has a lot of is= sues in forming the routing table. A lot of dissegrated user information w= ill cause a very large routing table. Using domains for the routing table = may be an option. I am not sure what value this provides over existing ENU= M solutions, though. Creating another solution for the same problem does n= ot always make for a more efficient solution. It may just create another s= olution, which will cause industry fragmentation in implementation preferen= ces. 5) Can we do something combining TRIP (maybe with modifications) and ENUM t= hat solves the problems? If so, will anybody deploy it, or do they prefer s= triking themselves repeatedly in the face with blunt objects over extended = periods of time? [DM] I worked through this scenario on a whiteboard for 30 minutes or so, a= nd I struggled to see any resolution to the problems. It just makes it mor= e complicated in a different way. All-in-all, this is excellent material for the sort of problem- exploration= process that might lead to a working group. -- Dean From dean.willis@softarmor.com Wed Mar 10 15:37:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDD03A69DE for ; Wed, 10 Mar 2010 15:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 orcQAlBjhhVz for ; Wed, 10 Mar 2010 15:37:53 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C4C283A687E for ; Wed, 10 Mar 2010 15:37:53 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2ANbrBU012487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Mar 2010 17:37:55 -0600 Message-Id: <9CF2CD97-BD9E-4EF5-A44F-38271F2CAC09@softarmor.com> From: Dean Willis To: "PFAUTZ, PENN L (ATTCORP)" In-Reply-To: <35FE871E2B085542A35726420E29DA6B0384131D@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Mar 2010 17:37:48 -0600 References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> <4B97BE44.2060302@nic.at> <35FE871E2B085542A35726420E29DA6B0384131D@gaalpa1msgusr7a.ugd.att.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org, Otmar Lendl Subject: Re: [dispatch] is this TRIP necessary? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 23:37:54 -0000 On Mar 10, 2010, at 10:23 AM, PFAUTZ, PENN L (ATTCORP) wrote: > > All the LRF and TRIP stuff seems to be tending toward a kind of > link-by-link call routing model that to me seems redolent of the > kind of > trunk group by trunk group routing in the PSTN. I thought that that > was > what we were trying to get away from in moving to IP! Excellent point. We're moving towards application-specific routing infrastructure and an "intelligent network." It rather turns my stomach. But building tools for this model that actually work well turns my stomach less than hacking up DNS to commit the same atrocities. On the other hand, "trunking" seems to be what people are actually willing to pay for. A democracy will get the government it deserves, and a market economy will get the products it buys. -- Dean From dean.willis@softarmor.com Wed Mar 10 15:46:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A133A6A1B for ; Wed, 10 Mar 2010 15:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, MANGLED_SHOP=2.3] 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 bmo0Ga-q-FLe for ; Wed, 10 Mar 2010 15:46:11 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 37FB33A69D1 for ; Wed, 10 Mar 2010 15:46:11 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2ANkD70012591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Mar 2010 17:46:14 -0600 Message-Id: <87B251AB-810A-4AE8-BB5C-4107DBA2113D@softarmor.com> From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F671D@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Mar 2010 17:46:07 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <4B96BAAA.3010900@nic.at> <57603224-371F-475B-9C9F-16A81AE6CCFB@insensate.co.uk> <1985C859-BE1C-4BF4-B056-D13C373956C2@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F671D@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 23:46:12 -0000 On Mar 10, 2010, at 10:24 AM, Daryl Malas wrote: > Dean, > > One of the challenges is at what layer the information is routed. > Using your example below, after the FQDN is converted into an IP > address, your Mac now routes the payload entirely through "layer > 1-3" elements to reach the destination server. With SIP, it should > be considered, after the FQDN for the domain is converted into an IP > address it is routed through "layer 1-3" elements to a "layer 5" > element, which is not the destination. Our existing routing > protocols (e.g. RIP (just wanted to throw this one in), OSPF, BGP, > etc.) focus on layer 3. The address space and the ability to > summarize this space is well understood and defined in the > industry. I think the reason we are struggling with varying > solutions, whether it is TRIP or ENUM or whatever, is because we are > working in an undefined address space, leveraging multiple layers. I agree. Further, what I think that we're doing is trying to build an applicational-level routing later that is structurally similar to the IP routing layer, but operates on this other address space. It's a classic example of an overlay network. "Names" are the next-level addresses. HIP and other locator-identifier separators are structurally very similar to what we're talking about doing with "domains" and "ITAD identifiers". > > Even if I am able to dynamically exchange domain names with other > peers, so I can do my ENUM look-up, resolve to a URI, and then do a > DNS look-up on the URI domain; I am still faced with layer 3 > potentially routing me non-optimally to my next layer 5 hop. The > reason for this is, simply, my layer 3 routers are not layer 5 > aware. I either statically define layer 3 or layer 5, but these are > the only two options I see at this point. RIght. What I think we've been fumbling toward is a dynamic Layer 5 routing fabric that itself is Layer 3 aware, and therefore handles > > The other thing to consider is layer 5 providers (SSPs), in my > perception, are far more paranoid than layer 3 providers (SPs). I > believe this is the perception of the redundant, redundant, > diversified, diversified super duper extra stable telephony > infrastructure that was built over a 100 years. In another 60 > years, SPs will be the same as IP is leveraged more and more for > "time sensitive" applications. We could have done what we needed to with RSVP, but the Net wasn't ready for resolving conflicts between real-time flows yet. In one possible future, everything on the Net that is real-time constrained has something like RSVP assuring its timeliness. In another, the "open Internet" is gone, replaced by lots of different application-level routing fabrics running over dedicated layer 3 that is over provisioned to handle it. I don't see a happy middle ground. -- Dean From dean.willis@softarmor.com Wed Mar 10 15:48:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E5A3A6956 for ; Wed, 10 Mar 2010 15:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 sPIoD07hmws5 for ; Wed, 10 Mar 2010 15:48:16 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 122563A6910 for ; Wed, 10 Mar 2010 15:48:16 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2ANmIYX012607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Mar 2010 17:48:19 -0600 Message-Id: From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Mar 2010 17:48:13 -0600 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 23:48:16 -0000 On Mar 10, 2010, at 5:16 PM, Daryl Malas wrote: > Dean, > > Based on your assessment below, let me try and summarize: > > Two IETF efforts: > 1) Egress Route Method for SIP (Intra-domain) > 2) Dynamic Routing Method for SIP (Inter-domain) It's possible both could be done by one protocol, possibly with two modes of operation. -- Dean From stpeter@stpeter.im Thu Mar 11 09:54:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51103A6BE5 for ; Thu, 11 Mar 2010 09:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnTmxMfyEywZ for ; Thu, 11 Mar 2010 09:54:13 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CCAD93A6BDA for ; Thu, 11 Mar 2010 09:33:13 -0800 (PST) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CEF3A40E14; Thu, 11 Mar 2010 10:33:18 -0700 (MST) Message-ID: <4B99295D.9090008@stpeter.im> Date: Thu, 11 Mar 2010 10:33:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Emil Ivov References: <4B97B5F0.3030905@sip-communicator.org> In-Reply-To: <4B97B5F0.3030905@sip-communicator.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000709060203000006020702" Cc: dispatch@ietf.org Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 17:54:13 -0000 This is a cryptographically signed message in MIME format. --------------ms000709060203000006020702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/10/10 8:08 AM, Emil Ivov wrote: > Hey all, >=20 > A couple of months ago we had a discussion here about how SIP-XMPP > clients would discover and authenticate against its SIP and XMPP parts.= >=20 > Enrico and I have recently posted a draft [1] detailing the problem and= > summarizing two ways of addressing it. We'd be happy to be able to > discuss this in Anaheim and comments are of course welcome at any time.= Regarding section 2, I have a few questions: 1. What kind of URI are you talking about? 2. Is this a URI that the SIP+XMPP service provides to the client? If so, how? 3. How exactly can a URI and a password be used for authentication in XMPP (i.e., using which SASL mechanism)? 4. Does the client derive a username from the URI so that it can use an authentication mechanism that experts a username and password? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000709060203000006020702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMTE3MzMxN1owIwYJKoZIhvcNAQkEMRYEFEc9XeXrwTb14oALz03T DH7RDUDYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOnFAyOkl9Zh8zWulvO7uYK/42LPBMKq+6fkw2XzH rSYTDva13X3MLhvIm2EshsFVYCjapuJ5sp/5lSKke1HLvltGJ1e2RiJZ76r9NIiwySBEiGb4 jMsMcEKMGhT1RUaZ+xzksbPBD/OE/5Wq20xJQTfpAlDFaU2dDADBkcNPg9nkyGdPk8waL7RA VSOSAexTPEZKYrax0WfjBjAyw6a7nSNe65YOMzqb1SEheketXc570M75nuH03EhAH/8BdxNO Rj+IvMvTr7Hoq6FEBkipe7xxMAZFYxdniwLzLtk1F3Z8xmsxhGL2ugDVRw4+fKPCs+RHPuym 4GPvAi97jH86PAAAAAAAAA== --------------ms000709060203000006020702-- From ranjit@motorola.com Thu Mar 11 10:42:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F613A6E74; Thu, 11 Mar 2010 10:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] 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 kk+5USYJWAut; Thu, 11 Mar 2010 10:41:29 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 1A3863A6CB7; Thu, 11 Mar 2010 10:11:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1268331072!40305302!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 23495 invoked from network); 11 Mar 2010 18:11:13 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-2.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Mar 2010 18:11:13 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o2BIBCOw025111; Thu, 11 Mar 2010 11:11:12 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o2BIBC8P015653; Thu, 11 Mar 2010 12:11:12 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o2BIB983015633; Thu, 11 Mar 2010 12:11:09 -0600 (CST) 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_01CAC146.2C9B8DFB" Date: Fri, 12 Mar 2010 02:10:42 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B8D173C.9070102@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: thread-topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: Acq6DxoGh5YtpP6wR3iO9pldHX5I1wHNcmBw References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 18:42:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC146.2C9B8DFB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All I am not able to upload the updated version (-04) of the I-D due to some issue with the I-D submission tool - (Says I can submit I-D only on 2010-03-22). Until then I am attaching a copy of the updated version (txt and html formats). Please review and comment. Thanks Note: Let me know if there is any other way to upload the I-D document and will be happy to do it. =20 Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, March 02, 2010 7:19 PM To: Avasarala Ranjit-A20990 Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] I think this all sounds good now. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Inline >=20 > >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 2:16 AM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 > inline... >=20 > Avasarala Ranjit-A20990 wrote: >=20 >> I'm still a little confused here. >> If phone is on and subscription is active, then in general=20 >> notification should be possible, regardless of registration. I=20 >> realize >=20 >> IMS doesn't permit that, but from a general standard perspective we=20 >> shouldn't assume it. The manifestation in this case is that the=20 >> NOTIFY >=20 >> would fail and the subscription would eventually be torn down. >> >> So I think the cases are: >> - there is a subscription and notification works >> - there is a subscription but notification fails >> - there is no subscription. >> >> Agreed. Actually instead of calling it as=20 >> Notification fails, we can say - not sending notification due to (1)=20 >> no match of filter criteria (2) phone not registered or outside=20 >> coverage area due to which there is no connectivity and hence=20 >> notification cannot be sent Anyway if no subscription, no > notification. >=20 > Are you suggesting that you might have a subscription, and have the=20 > filter criteria met, and yet not attempt to send a NOTIFY because the=20 > phone is not registered or has no network connectivity??? >=20 > That seems wrong. ISTM that either you would remove the subscription,=20 > or else you would try to send the NOTIFY and then discover that it fails. >=20 > yes the subscription could be removed when the device is > not reachable. >=20 > OTOH, this probably ought not to be within scope of what is discussed=20 > in this draft. >=20 > yes true not within the scope of this draft. >=20 >>> [3] in the example u suggested where sip:alice@atlanta.org with two >>> contacts: sip:line1@alice.office.atlanta.com and=20 >>> sip:line2@alice.home.atlanta.com and >>> both the phones ring, then it would be a case of parallel > forking. >>> Now say one or both the phones have set diversion rules, to divert=20 >>> the >> In this case, what does it mean for "one or both phones have set=20 >> diversion rules"? Does that somehow imply distinct rules for each > phone? >> I don't see how that could work. Aren't the diversion rules for the=20 >> *AOR*? >> >> Yes the diversion rules are for AoR. So when there=20 >> is >=20 >> a diversion rule set for the AoR and when diversions occur, the=20 >> notifications are Sent to the AoR. >=20 > Not sent to the AoR - sent to the remote contact of the dialog for=20 > each subscription to the AoR. Same point as below that you agreed with. >=20 > Yes agree with u.=20 >=20 >> I see they could be set/changed from either phone. But its a single=20 >> set of rules isn't it? So I might set the rules from the office, and=20 >> then cancel them from home. >> >> yes single set and could be set from either of the=20 >> phones. True. >> >>> call to say=20 >>> sip:voicemail@alice.atlanta.com, then the notifications would=20 >>> get >=20 >>> generated with respect to both the contacts. >> Again I'm confused by the terminology you use, and how it relates=20 >> operationally. The diversion happens on the AOR, and the=20 >> subscriptions >=20 >> are on the AOR, and the notifications are sent to the subscribers. I=20 >> don't see where the registered contacts enter into the picture at all. >> >> Ya agree with you on this. Sorry for the confusion. >> >> If you have something else in mind, I hope you can explain it better=20 >> in the draft. >> >>> [4] Yes the value of N is configurable and depends on how many=20 >>> diversions the subscribe wants to keep or could be dependent on=20 >>> server policy (some maximum >>> number). If the server policy is to send notifications as and=20 >>> when they occur and not keep any divsersions information, then the=20 >>> value of last N >>> diversions will be zero. But if the server chooses to retain the >>> last diversion always, then the value of N will be 1 and so on. >> All is straightforward for N>=3D1. >> >> For N=3D0 things are messy. If we are modeling this as state, and=20 >> notifications are about state changes, then the new diversion is=20 >> added >=20 >> to the (previously empty) state and that triggers notifications to=20 >> all >=20 >> current subscriptions. Then if you don't want to retain even this=20 >> much >=20 >> state (because N=3D0) you immediately remove that version from the > state. >> But that is again a state change, so you end up with another=20 >> notification of that state change. >> >> True. Actually the notifications are for informing=20 >> the subscriber of the call diversions that happen. The notifications=20 >> are not for informing the subscriber of state changes in the notifier >> or the number of diversions that occurred. As I mentioned in the=20 >> abstract as well as 24.604, the main intent of CDIVN service is to=20 >> inform the subscribers of communication diversions that occur on=20 >> their >=20 >> behalf in the network and this information will help them manage=20 >> their >=20 >> rules better. >=20 > I am not certain, but think we may still be talking past one another=20 > to some extent. >=20 > The state can be considered just a formalism for defining the service=20 > clearly, regardless of whether it has intrinsic value to the CDIV=20 > service. But it *is* a formalism. So if it is introduced, then its=20 > behavior can't be ignored when inconvenient. Defining the state with=20 > N=3D0 leads to some undesired behavior. The simplest way around that = is=20 > to insist that N be >=3D1. >=20 > Ok in that case we can say that value of N >=3D1 and the = > notifier has always maintains history of last diversion at a minimu.=20 > It can maintain more than 1 too depending on the policy. >=20 > If its important to you that no state be retained once a notification=20 > has been sent about the most recent diversion, then you will have to=20 > find some other way to specify the service, that still meets the=20 > expectations of 3265. I don't know if there is anything there that=20 > Adam would consider valid. We will have to get his opinion on that. >=20 > In that case I am OK maintaining the hostory of=20 > diversions that occurred as part of state information and retaining=20 > that state even after the notification for that diversion is sent - so > that in case I do not get a confirmation, I would be able to re-send the notification. > Also maintaining state of diversions would help when the notifications > need to sent only at a particular time (if fikter criteria mentions it). >=20 >=20 > Thanks, > Paul >=20 >> But if we want to include the information related to >> how many diversions have happened till time (say from 12 AM ) till=20 >> the >=20 >> time the notification is being sent, then as you say we can store the >> diversions. This would be useful when the subscriber specifies in the >> filter criteria to send notifications only during certain time like=20 >> between 5 and 6 PM and not whenever a diversion occurs. Then N is=20 >> grater than 1. >=20 >> I presume you don't want that behavior. If you can live with N>=3D1=20 >> then >=20 >> we don't have the problem at all. If you need to support N=3D0 and=20 >> don't >=20 >> want the extra notify, then we have to figure out if there is some=20 >> trick to how things are modeled to get the desired effect. I've=20 >> suggested something previously, but Adam didn't like it. >> >> This needs sorting out. >> >> Thanks, >> Paul >=20 ------_=_NextPart_001_01CAC146.2C9B8DFB Content-Type: text/plain; name="draft-avasarala-dispatch-comm-div-notification-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-avasarala-dispatch-comm-div-notification-04.txt Content-Disposition: attachment; filename="draft-avasarala-dispatch-comm-div-notification-04.txt" DQoNCg0KRElTUEFUQ0ggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFIuIEF2YXNhcmFsYSwgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNb3Rvcm9sYSBJbmMNCkludGVuZGVkIHN0YXR1czog SW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIEJha2tlcg0K RXhwaXJlczogU2VwdGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICAgUmVzZWFyY2ggaW4gTW90 aW9uIENvcnBvcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFNhaGENCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUklUIFNvbHV0aW9ucw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNo IDExLCAyMDEwDQoNCg0KDQogIEEgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIEV2 ZW50IFBhY2thZ2UgZm9yIENvbW11bmljYXRpb24NCiBEaXZlcnNpb24gSW5mb3JtYXRpb24gaW4g c3VwcG9ydCBvZiB0aGUgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpDQogICAgICAgICAg ICAgICAgICAgTm90aWZpY2F0aW9uIChDRElWTikgQ0RJViBzZXJ2aWNlDQogICAgICAgICBkcmFm dC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTA0LnR4dA0KDQpBYnN0 cmFjdA0KDQogICAzR1BQIGFuZCBUSVNQQU4gYXJlIGRlZmluaW5nIHRoZSBwcm90b2NvbCBzcGVj aWZpY2F0aW9uIGZvciB0aGUNCiAgIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKSBzZXJ2 aWNlIHVzaW5nIElQIE11bHRpbWVkaWEgKElNKSBDb3JlDQogICBOZXR3b3JrIChDTikgc3Vic3lz dGVtIHN1cHBsZW1lbnRhcnkgc2VydmljZS4gIEFzIHBhcnQgb2YgQ0RJViwgYSBTSVANCiAgIGJh c2VkIEV2ZW50IHBhY2thZ2UgZnJhbWV3b3JrIGlzIHVzZWQgZm9yIG5vdGlmeWluZyB1c2VycyBh Ym91dA0KICAgZGl2ZXJzaW9ucyAocmUtZGlyZWN0aW9ucyBvciBmb3J3YXJkaW5nKSBvZiB0aGVp ciBpbmNvbWluZw0KICAgY29tbXVuaWNhdGlvbiBzZXNzaW9ucy4gIFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgYSBuZXcgU0lQIGV2ZW50DQogICBwYWNrYWdlIGZvciBhbGxvd2luZyB1c2VycyB0byBz dWJzY3JpYmUgdG8gYW5kIHJlY2VpdmUgc3VjaA0KICAgbm90aWZpY2F0aW9ucy4gIFVzZXJzIGNh biBmdXJ0aGVyIGRlZmluZSBmaWx0ZXJzIHRvIGNvbnRyb2wgdGhlIHJhdGUNCiAgIGFuZCBjb250 ZW50IG9mIHN1Y2ggbm90aWZpY2F0aW9ucy4gIFRoZSBwcm9wb3NlZCBldmVudCBwYWNrYWdlIGlz DQogICBhcHBsaWNhYmxlIHRvIHRoZSBDRElWIHN1cHBsZW1lbnRhcnkgc2VydmljZSBpbiBJTVMg YW5kIG1heSBub3QgYmUNCiAgIGFwcGxpY2FibGUgdG8gdGhlIGdlbmVyYWwgaW50ZXJuZXQuDQoN ClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0 ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9m IEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl DQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0DQoNCg0KDQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0 ICBTSVAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAx MA0KDQoNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50 ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDEyLCAyMDEwLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9j dW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0 DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJv dmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBCU0QgTGljZW5z ZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIs IDIwMTAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21t dW5pY2F0aW9uIERpdmVyc2lvbiBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KVGFi bGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAyLiAgVGVybWlub2xvZ3kgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDMu ICBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNg0KICAgNC4gIEFiYnJldmlhdGlvbnMgYW5kIERlZmluaXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDQuMS4gIEFiYnJldmlhdGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgNC4yLiAg RGVmaW5pdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgNS4gIFJlcXVpcmVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA2LiAgUGFja2FnZSBEZWZpbml0aW9uIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgNi4xLiAgRXZlbnQg UGFja2FnZSBOYW1lIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0K ICAgICA2LjIuICBFdmVudCBQYWNrYWdlIFBhcmFtZXRlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA4DQogICAgIDYuMy4gIFNVQlNDUklCRSBib2RpZXMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgICAgNi40LiAgU3Vic2NyaXB0aW9u IER1cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICA2 LjUuICBOb3RpZnkgYm9kaWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA4DQogICAgIDYuNi4gIE5vdGlmaWVyIFByb2Nlc3Npbmcgb2YgU1VCU0NSSUJFIHJl cXVlc3RzICAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgICA2LjYuMS4gIEF1dGhlbnRpY2F0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAgIDYuNi4y LiAgQXV0aG9yaXphdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA5DQogICAgIDYuNy4gIE5vdGlmaWVyIEdlbmVyYXRpb24gb2YgTk9USUZZIHJlcXVlc3RzIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgNi44LiAgU3Vic2NyaWJlciBQcm9jZXNzaW5nIG9m IE5PVElGWSBSZXF1ZXN0cyAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA2LjkuICBIYW5kbGlu ZyBvZiBGb3JrZWQgUmVxdWVzdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQog ICAgIDYuMTAuIFJhdGUgb2YgTm90aWZpY2F0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTANCiAgICAgNi4xMS4gU3RhdGUgQWdlbnRzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgNy4gIENvbW0tZGl2LWluZm8gRG9j dW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICA4LiAg U3RydWN0dXJlIG9mIENvbW0tZGl2LWluZm8gRm9ybWF0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTENCiAgICAgOC4xLiAgQ29tbS1kaXYtaW5mbyBFbGVtZW50ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgIDguMS4xLiAgY29tbS1kaXYtc3Vicy1p bmZvIEVsZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAgICAgOC4xLjIu ICBDb21tLWRpdi1udGZ5LWluZm8gRWxlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTQNCiAgICAgICA4LjEuMy4gIENvbW0tZGl2LWluZm8tc2VsZWN0aW9uLWNyaXRlcmlhIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgICA4LjIuICBTYW1wbGUgTm90aWZpY2F0aW9uIGJvZHkg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAgICAgOC4yLjEuICBJbnN0 YW5jZSBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBzdWJzY3JpcHRpb24NCiAgICAgICAgICAg ICAgIGZpbHRlciBkb2N1bWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNw0KICAgICAgIDguMi4yLiAgSW5zdGFuY2Ugb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24g bm90aWZpY2F0aW9uDQogICAgICAgICAgICAgICBkb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgOC4zLiAgU2NoZW1hIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgOS4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIzDQogICAxMC4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMNCiAgICAgMTAuMS4gQ29tbXVuaWNhdGlvbiBEaXZlcnNp b24gSW5mb3JtYXRpb24gRXZlbnQgUGFja2FnZQ0KICAgICAgICAgICBSZWdpc3RyYXRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0DQogICAxMS4gQWNr bm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjQNCiAgIDEyLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyNA0KICAgICAxMi4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0DQogICAgIDEyLjIuIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUN CiAgIEFwcGVuZGl4IEEuICBDaGFuZ2UgbG9nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyNQ0KICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQoNCg0KDQoNCg0KDQpBdmFzYXJhbGEs IGV0IGFsLiAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0LURyYWZ0ICBTSVAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gTm90 aWZpY2F0aW9uICAgICAgTWFyY2ggMjAxMA0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgM0dQ UCBpcyBjdXJyZW50bHkgbWFpbnRhaW5pbmcgYW5kIHNwZWNpZnlpbmcgY29tbXVuaWNhdGlvbiBk aXZlcnNpb24NCiAgIG1lY2hhbmlzbXMgd2hpY2ggYWxsb3cgdXNlcnMgdG8gZm9yd2FyZCBhbmQv b3IgcmVkaXJlY3QgaW5jb21pbmcNCiAgIGNvbW11bmljYXRpb25zIHRvIG90aGVyIGRlc3RpbmF0 aW9ucy4gIFRoZSBpbnRlbnRpb24gb2Ygc3VjaA0KICAgbWVjaGFuaXNtcyBpcyB0byBwcm92aWRl IHVzZXJzIHdpdGggc3VmZmljaWVudCBmbGV4aWJpbGl0eSB0byBtYW5hZ2UNCiAgIHRoZWlyIGlu Y29taW5nIGNvbW11bmljYXRpb25zIGluIGEgYmV0dGVyIHdheS4gIFRoZSBtb3N0IGNvbW1vbg0K ICAgZXhhbXBsZSBpcyBDb21tdW5pY2F0aW9uIEZvcndhcmQgT24gQnVzeSAoQ0ZCKSB3aGVyZSBp biB1c2VycyBjYW4NCiAgIGZvcndhcmQgYW55IGluY29taW5nIGNhbGxzLCB3aGlsc3QgdGhleSBh cmUgYnVzeSBvbiBzb21lIG90aGVyIGNhbGwsDQogICB0byB0aGVpciB2b2ljZSBtYWlsIG9yIGEg c3VpdGFibGUgYWx0ZXJuYXRpdmUgKGUuZy4gc29tZSBvdGhlciB1c2VyKS4NCiAgIFNpbWlsYXJs eSBvdGhlciB2YXJpYW50cyBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBhcmUgd2VsbCBkZWZp bmVkDQogICBhbmQgdXNlZCBpbiBwcmFjdGljZSBzdWNoIGFzIENvbW11bmljYXRpb24gRm9yd2Fy ZCBvbiBObyBBbnN3ZXINCiAgIChDRk5BKSwgQ29tbXVuaWNhdGlvbiBGb3J3YXJkIFVuY29uZGl0 aW9uYWwgKENGVSkuICBTaW1pbGFybHkgM0dQUCBpcw0KICAgY3VycmVudGx5IG1haW50YWluaW5n IGFuZCBzcGVjaWZ5aW5nIGEgbWVjaGFuaXNtIGZvciBVc2VycyB0bw0KICAgY29uZmlndXJlIENv bW11bmljYXRpb24gRGl2ZXJzaW9uIFNlcnZpY2VzIChbMV0gYW5kIFsyXSkgZm9yIHRoZWlyDQog ICBpbmNvbWluZyBjb21tdW5pY2F0aW9ucy4gIFRoZSBpbnRlbnRpb24gb2Ygc3VjaCBtZWNoYW5p c21zIGlzIHRvDQogICBwcm92aWRlIFVzZXJzIHdpdGggc3VmZmljaWVudCBmbGV4aWJpbGl0eSB0 byBtYW5hZ2UgdGhlaXIgaW5jb21pbmcNCiAgIGNvbW11bmljYXRpb25zIGluIGEgYmV0dGVyIHdh eS4NCg0KICAgSG93ZXZlciwgd2l0aCB0aGUgaW5jcmVhc2luZyB1c2FnZSBvZiBDb21tdW5pY2F0 aW9uIERpdmVyc2lvbg0KICAgc2VydmljZXMsIHVzZXJzIG1heSBoYXZlIG1hbnkgZGlmZmVyZW50 IHZhcmlhbnRzIGFuZCBjb25maWd1cmF0aW9ucw0KICAgYWN0aXZlIGF0IHRoZSBzYW1lIHRpbWUu ICBGb3IgaW5zdGFuY2UsIGEgdXNlciBtYXkgaGF2ZSB2YXJpb3VzIENGVQ0KICAgc2VydmljZXMg Y29uZmlndXJlZCBkaWZmZXJlbnRseSBiYXNlZCBvbiB0aGUgdGltZS1vZi10aGUtZGF5IGFuZCB0 aGUNCiAgIENhbGxpbmcgcGFydHkncyBpZGVudGl0eSwgb3IgQ0ZCIGJhc2VkIG9uIHRoZSB0aW1l LW9mLXRoZS1kYXkuICBUaGlzDQogICBpcyBwb3NzaWJsZSBieSBoYXZpbmcgdmFyaW91cyBzdWNo IGNvbmZpZ3VyZWQgZGl2ZXJzaW9ucyBieQ0KICAgc3Vic2NyaWJpbmcgdG8gZGlmZmVyZW50IENv bW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKSBzZXJ2aWNlcyBhcw0KICAgc3BlY2lmaWVkIGJ5 IDNHUFAuICBUaG91Z2gsIHRoZXJlIGhhcyBiZWVuIHF1aXRlIGFjdGl2ZSB3b3JrIGluIHRoZQ0K ICAgYXJlYSBvZiBiZXR0ZXIgY3VzdG9taXphdGlvbiBhbmQgY29uZmlndXJhdGlvbiBvZiBzdWNo IENvbW11bmljYXRpb24NCiAgIERpdmVyc2lvbiBtZWNoYW5pc21zLCBub3QgbXVjaCBhdHRlbnRp b24gaGFzIGJlZW4gcGFpZCB0byBob3cgdGhlDQogICBVc2VycyBjYW4gbWFuYWdlIHRoZXNlIHNl cnZpY2VzIGluIGFuIGVmZmVjdGl2ZSBtYW5uZXIuICBXaXRoIHRoZQ0KICAgdmFyaW91cyBhZHZh bmNlZCBvcHRpb25zIGFuZCBoaWdoIGZsZXhpYmlsaXR5IHByb3ZpZGVkLCBpdCBpcw0KICAgcG9z c2libGUgdGhhdCB0aGUgdXNlciBsb3NlcyB0cmFjayBvZiB0aGUgdmFyaW91cyBDb21tdW5pY2F0 aW9uDQogICBEaXZlcnNpb24gY29uZmlndXJhdGlvbnMgb3Igc2VydmljZXMgdGhleSBoYXZlIHJl Z2lzdGVyZWQgZm9yLg0KDQogICBPbmUgb2YgdGhlIGJhc2ljIHdheXMsIGJ5IHdoaWNoIGEgdXNl ciBjYW4gbWFuYWdlIGEgQ0RJViBzZXJ2aWNlIGlzDQogICB0byBiZSBpbmZvcm1lZCBvZiB3aGlj aCBzZXJ2aWNlcyB0aGV5IGhhdmUgcmVnaXN0ZXJlZCBmb3IuICBGb3INCiAgIGV4YW1wbGUsIFsx XSBhbmQgWzJdIGFsbG93IGZvciBzdWNoIGluZGljYXRpb25zIHRvIGJlIHJlY2VpdmVkIGJ5IHRo ZQ0KICAgc3Vic2NyaWJlciwgYXQgdGhlIHRpbWUgb2YgaW5pdGlhdGluZyBhbiBvdXRnb2luZyBj YWxsLiAgSG93ZXZlciwNCiAgIHNpbXBseSBzaG93aW5nIHRoZSByZWdpc3RlcmVkIHNlcnZpY2Vz IGlzIG5vdCBzdWZmaWNpZW50LCBzaW5jZSBlYWNoDQogICBzZXJ2aWNlIG1heSBiZSBjdXN0b21p emVkIGluIG51bWVyb3VzIGFuZCBkaWZmZXJlbnQgd2F5cyBmb3INCiAgIGRpZmZlcmVudCBjcml0 ZXJpYS4gIEZvciBleGFtcGxlIHZhcmlvdXMgaW5zdGFudGlhdGlvbnMgb2YgQ0ZCIG1heSBiZQ0K ICAgY29uZmlndXJlZCBmb3IgZGlmZmVyZW50IHRpbWVzLW9mLXRoZS1kYXkgYW5kIGRpZmZlcmVu dCBjYWxsaW5nIHBhcnR5DQogICBpZGVudGl0aWVzLiAgRXZlbiBpZiBzdWJzY3JpYmVycyBhcmUg c2hvd24gaW5mb3JtYXRpb24gYWJvdXQgYWxsIHRoZQ0KICAgQ29tbXVuaWNhdGlvbiBEaXZlcnNp b24gc2VydmljZXMgYW5kIHRoZWlyIHZhcmlhbnRzIHRoYXQgdGhleSBhcmUNCiAgIHJlZ2lzdGVy ZWQgZm9yLCB0aGV5IG1heSBub3QgYmUgYWJsZSB0byBtYWtlIHNlbnNlIG9yIHZlcmlmeSB0aGF0 DQogICBlYWNoIG9mIHRoZW0gaXMgY29ycmVjdCBhcyBwZXIgdGhlaXIgZXhwZWN0YXRpb24uICBT dWNoIGEgbWlzbWF0Y2ggaW4NCiAgIHRlcm1zIG9mIHNlcnZpY2UgYmVoYXZpb3IgZXhwZWN0YXRp b24gYW5kIGFjdHVhbCBleGVjdXRpb24sIG1heQ0KICAgaGFwcGVuIGR1ZSB0byBpbmNvcnJlY3Qg Y29uZmlndXJhdGlvbiBvbiBiZWhhbGYgb2YgdGhlIFVzZXIsIHdoaWNoDQoNCg0KDQpBdmFzYXJh bGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICAg W1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICBTSVAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24g Tm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAxMA0KDQoNCiAgIGNhbm5vdCBiZSBlYXNpbHkgZGV0 ZWN0ZWQgaWYgdGhlcmUgYXJlIHZhcmlvdXMgY29tbXVuaWNhdGlvbg0KICAgZGl2ZXJzaW9uIHNl cnZpY2VzIGFuZCB0aGVpciBkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMgZm9yIGhhbmRsaW5nDQog ICBpbmNvbWluZyBjb21tdW5pY2F0aW9ucy4NCg0KICAgQSBwcm9iYWJsZSBhbmQgc3VpdGFibGUg aW5zdGFuY2UsIHdoZW4gdGhlIHN1YnNjcmliZXIgbWF5IGVhc2lseQ0KICAganVkZ2Ugd2hldGhl ciBhIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGlzIGNvcnJlY3QsIGlzIHdoZW4gaXQNCiAgIGFj dHVhbGx5IHRha2VzIHBsYWNlLiAgVGhlIHN1YnNjcmliZXIgaXMgYWxyZWFkeSBhd2FyZSBvZiB0 aGUgY3VycmVudA0KICAgY29uZGl0aW9ucyAodGltZS1vZi1kYXksIGN1cnJlbnQgcHJlc2VuY2Ug YW5kIGF2YWlsYWJpbGl0eSBldGMpIGFuZA0KICAgaGVuY2UgaXMgaW4gYSBwb3NpdGlvbiB0byBk ZWNpZGUsIHdoZXRoZXIgdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uDQogICB3aGljaCBqdXN0 IG9jY3VycmVkLCB3YXMgaW5kZWVkIGFzIHBlciB0aGVpciBleHBlY3RhdGlvbi4gIEZvciBlLmcu DQogICB0aGUgc3Vic2NyaWJlciB3YW50ZWQgdG8gZGl2ZXJ0IGFsbCBpbmNvbWluZyBjYWxscyB0 byB2b2ljZS1tYWlsLA0KICAgYmV0d2VlbiAzLjAwIHAubS4gdG8gNC4wMCBwLm0uICBZZXQsIGJ5 IG1pc3Rha2Ugc2hlIGNvbmZpZ3VyZXMgdGhlDQogICB0aW1lLWR1cmF0aW9uIGFzIDMuMDAgdG8g NC4wMCBwLm0uICBJdCB3b3VsZCBiZSB2ZXJ5IGRpZmZpY3VsdCBmb3INCiAgIGhlciB0byBzcG90 IHRoaXMgZXJyb3Igd2hpbGUgbWFudWFsbHkgcmV2aWV3aW5nIGhlciBjb21wbGV0ZSBzZXQgb2YN CiAgIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIHNlcnZpY2VzLCB3aXRoIHRoZWlyIHZhcmlvdXMg Y29uZmlndXJhdGlvbnMuDQogICBJbnN0ZWFkLCBpZiB0aGUgc3Vic2NyaWJlciByZWNlaXZlcyBh IHJlYWwtdGltZSBub3RpZmljYXRpb24gb2YgYW55DQogICBjb21tdW5pY2F0aW9uIGRpdmVyc2lv biBvY2N1cnJpbmcgYWZ0ZXIgNCBwLm0uLCBzaGUgd291bGQgYmUgYWJsZSB0bw0KICAgaW1tZWRp YXRlbHkgZ3Vlc3MgdGhhdCBzb21ldGhpbmcgaXMgJ3dyb25nJyBvciBub3QgYXMgcGVyIGhlcg0K ICAgaW50ZW50aW9uIGFuZCB0YWtlIGNvcnJlY3RpdmUgYWN0aW9uLiAgU3VjaCBjb3JyZWN0aXZl IGFjdGlvbiBjb3VsZA0KICAgYmUgbWFudWFsIHZlcmlmaWNhdGlvbiBvZiB0aGUgc3BlY2lmaWMg cnVsZSB3aGljaCB0cmlnZ2VyZWQgdGhlDQogICBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiwgd2hl cmVpbiBzaGUgd2lsbCBiZSBhYmxlIHRvIHNwb3QgdGhlDQogICAqbWlzdGFrZSogbW9yZSBlYXNp bHkuDQoNCiAgIFRodXMsIGZvciBlZmZlY3RpdmUgc3Vic2NyaWJlciBzZXJ2aWNlcyBtYW5hZ2Vt ZW50IG9mIG11bHRpcGxlDQogICBjb25maWd1cmF0aW9ucyBvZiB2YXJpb3VzIENvbW11bmljYXRp b24gRGl2ZXJzaW9uIHNlcnZpY2VzLCBhDQogICBub3RpZmljYXRpb24tYmFzZWQgbWVjaGFuaXNt IG1heSB3b3JrIHdlbGwuICBTdWNoIGEgbWVjaGFuaXNtIHdvdWxkDQogICBpbnZvbHZlIG5vdGlm eWluZyBzdWJzY3JpYmVycyBhYm91dCBkaXZlcnNpb25zIG9mIHRoZWlyIGluY29taW5nDQogICBj b21tdW5pY2F0aW9ucywgYXMgYW5kIHdoZW4gdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGhh cHBlbnMgb3INCiAgIHdpdGggYSBzbGlnaHQgZGVsYXkgKGFzIHBlciBzdWJzY3JpYmVyIHNlcnZp Y2UgY29uZmlndXJhdGlvbikuICBBcw0KICAgc3VjaCBkaXZlcnNpb24tcmVsYXRlZCBpbmZvcm1h dGlvbiBpcyBjb252ZXllZCBhbG1vc3QgaW5zdGFudGx5IG9yDQogICB3aXRoaW4gYSBzbWFsbCB0 aW1lLWZyYW1lLCB0aGUgc3Vic2NyaWJlcnMgY2FuIHZlcmlmeSB3aGV0aGVyIHRoZQ0KICAgcGFy dGljdWxhciBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBpcyBpbmRlZWQgY29ycmVjdCBhdCB0aGF0 IGluc3RhbnQNCiAgIG9mIHRpbWUuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFNJUCBl dmVudCBwYWNrYWdlIHRoYXQgYWxsb3dzIGEgU0lQIFVzZXINCiAgIEFnZW50cyB0byBzdWJzY3Jp YmUgdG8gYW5kIGJlIG5vdGlmaWVkIG9mIGNvbW11bmljYXRpb24gZGl2ZXJzaW9ucw0KICAgZW5h Y3RlZCBvbiB0aGVpciBiZWhhbGYuIC4NCg0KDQoNCjIuICBUZXJtaW5vbG9neQ0KDQogICBJbiB0 aGlzIGRvY3VtZW50LCB0aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwNCiAgICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwNCiAgIGFuZCAiT1BUSU9OQUwiIGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgWzNdIGFuZA0KICAgaW5kaWNhdGUgcmVxdWlyZW1l bnQgbGV2ZWxzIGZvciBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zLg0KDQoNCg0KDQoNCkF2YXNh cmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAgICAgICAgICAgICAg ICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5pY2F0aW9uIERpdmVyc2lv biBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KMy4gIEFwcGxpY2FiaWxpdHkgU3Rh dGVtZW50DQoNCiAgIEl0IGlzIGJlbGlldmVkIHRoYXQgdGhlIFNJUCBldmVudCBwYWNrYWdlIGRl ZmluZWQgaGVyZSBpcyBub3QNCiAgIGFwcGxpY2FibGUgdG8gdGhlIGdlbmVyYWwgSW50ZXJuZXQg YW5kIGhhcyBiZWVuIGRlc2lnbmVkIHRvIHNlcnZlIHRoZQ0KICAgYXJjaGl0ZWN0dXJlIG9mIHRo ZSBDRElWIHNlcnZpY2UgaW4gSU1TIGNvcmUgbmV0d29ya3MuICBUaGUgYWltIG9mDQogICB0aGlz IG1lbW8gaXMgdG8gZm9sbG93IHRoZSBwcm9jZWR1cmUgaW5kaWNhdGVkIGluIFJGQyAzNDI3IFs0 XSBhbmQgdG8NCiAgIHJlZ2lzdGVyIGEgbmV3IGV2ZW50IHBhY2thZ2Ugd2l0aCBldmVudCBuYW1l ICJjb21tLWRpdi1pbmZvIiB3aXRoDQogICBJQU5BLg0KDQoNCjQuICBBYmJyZXZpYXRpb25zIGFu ZCBEZWZpbml0aW9ucw0KDQo0LjEuICBBYmJyZXZpYXRpb25zDQoNCiAgICAgIENESVY6IENvbW11 bmljYXRpb24gRGl2ZXJzaW9uLg0KDQogICAgICBDRElWTjogQ29tbXVuaWNhdGlvbiBEaXZlcnNp b24gTm90aWZpY2F0aW9uLg0KDQogICAgICBUSVNQQU46IFRlbGVjb21tdW5pY2F0aW9ucyBhbmQg SW50ZXJuZXQgQ29udmVyZ2VkIFNlcnZpY2VzIGFuZA0KICAgICAgUHJvdG9jb2xzIGZvciBBZHZh bmNlZCBOZXR3b3JraW5nLg0KDQo0LjIuICBEZWZpbml0aW9ucw0KDQogICAgICBTdWJzY3JpYmVy IC0gVGhlIFVzZXIgQWdlbnQgd2hvIGhhcyBzdWJzY3JpYmVkIHRvIHRoZQ0KICAgICAgQ29tbXVu aWNhdGlvbiBkaXZlcnNpb24gbm90aWZpY2F0aW9uIHNlcnZpY2UuDQoNCiAgICAgIFVzZXIgLSBB bm90aGVyIHRlcm0gZm9yIHRoZSBzdWJzY3JpYmVyLg0KDQogICAgICBEaXZlcnRpbmcgVXNlciAt IFRoZSBVc2VyIEFnZW50IHdobyBoYXMgY29uZmlndXJlZCBhIENvbW11bmljYXRpb24NCiAgICAg IERpdmVyc2lvbi4gIFRoaXMgY291bGQgYmUgdGhlIFVzZXIgQWdlbnQgd2hvIGhhcyBjb25maWd1 cmVkIHRoZQ0KICAgICAgQ29tbXVuaWNhdGlvbiBESXZlcnNpb24gc2VydmljZSBydWxlcyBpbiB0 aGUgbmV0d29yay4NCg0KICAgICAgRGl2ZXJ0ZWQtVG8gRW50aXR5L1VzZXIgLSBUaGUgVXNlciBB Z2VudCB3aG8gaXMgdGhlIG5ldyB0YXJnZXQgb2YNCiAgICAgIHRoZSBpbmNvbWluZyBjb21tdW5p Y2F0aW9uLCBwb3N0IGV4ZWN1dGlvbiBvZiBhbnkgY29uZmlndXJlZA0KICAgICAgQ29tbXVuaWNh dGlvbiBEaXZlcnNpb24gc2VydmljZS4NCg0KICAgICAgT3JpZ2luYXRpbmcgVXNlciAtIFRoZSBV c2VyIEFnZW50IHdobyBpcyB0aGUgb3JpZ2luYXRvciBvZiB0aGUNCiAgICAgIGluY29taW5nIGNv bW11bmljYXRpb24sIHdoaWNoIHdhcyBpbml0aWFsbHkgdGFyZ2V0ZWQgdG93YXJkcyB0aGUNCiAg ICAgIERpdmVydGluZyBVc2VyLCBidXQgZmluYWxseSBzZW50IHRvIHRoZSBEaXZlcnRlZC1UbyBV c2VyLiAgVGhlDQogICAgICBPcmlnaW5hdGluZyBVc2VyIGlzIGFsc28gcmVmZXJyZWQgdG8gYXMg dGhlIENhbGxlci4NCg0KICAgICAgSU1TIENvcmUgTmV0d29yayAtIFRoaXMgcmVmZXJzIHRvIHRo ZSBJTVMgYmFzZWQgU0lQIGJhc2VkIG5ldHdvcmsNCiAgICAgIHRoYXQgY29uZm9ybXMgdG8gdGhl IFs3XSBhbmQgbm90IHRoZSBnZW5lcmFsIFNJUCBuZXR3b3JrIGFzDQogICAgICBkZWZpbmVkIGlu IFs1XS4NCg0KDQoNCg0KDQoNCg0KQXZhc2FyYWxhLCBldCBhbC4gICAgICBFeHBpcmVzIFNlcHRl bWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAg U0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgIE1hcmNoIDIwMTAN Cg0KDQo1LiAgUmVxdWlyZW1lbnRzDQoNCiAgIEEgY29tcHJlaGVuc2l2ZSBkZXNjcmlwdGlvbiBv ZiBhbGwgdGhlIHJlcXVpcmVtZW50cyB0aGF0IGFmZmVjdCB0aGUNCiAgIENESVYgc2VydmljZSBk ZXZlbG9wZWQgYnkgM0dQUCBjYW4gYmUgZm91bmQgaW4gdGhlIDNHUFAgd2ViIHBhZ2UgYXQNCiAg IGh0dHA6Ly93d3cuM2dwcC5vcmcgYW5kIGh0dHA6Ly93d3cuZXRzaS5vcmcuDQoNCiAgIEZvciB0 aGUgc2FrZSBvZiBzaW1wbGljaXR5LCB3ZSBicmllZmx5IGRpc2N1c3MgaGVyZSB0aG9zZQ0KICAg cmVxdWlyZW1lbnRzIHRoYXQgYWZmZWN0IHRoZSBzb2x1dGlvbiBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudC4NCiAgIFRoZXNlIHJlcXVpcmVtZW50cyBjYW4gYmUgc3VtbWFyaXplZCBhcyBmb2xs b3dzOg0KDQogICBvICBUaGVyZSBtdXN0IGJlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIHN1YnNj cmliZXItY29udHJvbGxlZA0KICAgICAgbm90aWZpY2F0aW9uIG9mIGNvbW11bmljYXRpb24gZGl2 ZXJzaW9ucyB0byB0aGUgZGl2ZXJ0aW5nIHVzZXIsDQogICAgICBpbmNsdWRpbmcgdGhlIG9wdGlv biB0byBjb250cm9sIHdoaWNoIG5vdGlmaWNhdGlvbnMgdGhlIHVzZXIgd2FudHMNCiAgICAgIHRv IHJlY2VpdmUgYW5kIHRvIGNvbnRyb2wgdGhlIHJhdGUgYXQgd2hpY2ggbm90aWZpY2F0aW9ucyBh cmUNCiAgICAgIHJlY2VpdmVkLg0KDQogICBvICBUaGVyZSBtdXN0IGJlIGEgbWVjaGFuaXNtIHRo YXQgZW5hYmxlcyBmaWx0ZXJpbmcgb2Ygbm90aWZpY2F0aW9ucw0KICAgICAgb2YgY29tbXVuaWNh dGlvbiBkaXZlcnNpb24uDQoNCiAgIG8gIFRoZXJlIG11c3QgYmUgYSBtZWNoYW5pc20gdGhhdCBl bmFibGVzIHRyaWdnZXJpbmcgb2Ygbm90aWZpY2F0aW9ucw0KICAgICAgb2YgY29tbXVuaWNhdGlv biBkaXZlcnNpb24uDQoNCiAgIG8gIFRoZXJlIG11c3QgYmUgYSBtZWNoYW5pc20gdGhhdCBlbmFi bGVzIHNlbGVjdGluZyBpbmZvcm1hdGlvbiB0byBiZQ0KICAgICAgaW5jbHVkZWQgaW4gbm90aWZp Y2F0aW9ucyBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbi4NCg0KDQogICBUaGVzZSByZXF1aXJl bWVudHMgbGVhZCB0byBhIHNvbHV0aW9uIHdoZXJlYnkgdGhlIHVzZXIgY2FuIGluZGljYXRlDQog ICB0byBhIG5ldHdvcmsgbm9kZSBoaXMgaW50ZXJlc3QgaW4gcmVjZWl2aW5nIGNlcnRhaW4gdHlw ZSBvZg0KICAgbm90aWZpY2F0aW9ucyBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbi4gIFB1c2hp bmcgdGhlc2Ugc2V0dGluZ3MgdG8NCiAgIGEgbmV0d29yayBub2RlIGFsbG93cyB0aGUgbmV0d29y ayBub2RlIHRvIGNvbnNlcnZlIHNjYXJjZSByZXNvdXJjZXMNCiAgIHdoaWxlIHN0aWxsIG5vdGlm eWluZyB0aGUgdXNlciBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbnMgZW5hY3RpbmcNCiAgIG9u IHRoZSB1c2VyJ3MgYmVoYWxmLg0KDQoNCjYuICBQYWNrYWdlIERlZmluaXRpb24NCg0KICAgVGhp cyBzZWN0aW9uIGZpbGxzIGluIHRoZSBkZXRhaWxzIG5lZWRlZCBmb3IgYW4gZXZlbnQgcGFja2Fn ZSBhcw0KICAgZGVmaW5lZCBpbiBTZWN0aW9uIDQuNCBvZiBbNl0uDQoNCjYuMS4gIEV2ZW50IFBh Y2thZ2UgTmFtZQ0KDQogICBUaGUgU0lQIEV2ZW50cyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHBh Y2thZ2UgZGVmaW5pdGlvbnMgdG8gc3BlY2lmeQ0KICAgdGhlIG5hbWUgb2YgdGhlaXIgcGFja2Fn ZSBvciB0ZW1wbGF0ZS1wYWNrYWdlLg0KDQogICBUaGUgbmFtZSBvZiB0aGlzIHBhY2thZ2UgaXMg ImNvbW0tZGl2LWluZm8iLiAgQXMgc3BlY2lmaWVkIGluIFs2XSwNCiAgIHRoaXMgdmFsdWUgYXBw ZWFycyBpbiB0aGUgRXZlbnQgaGVhZGVyIHByZXNlbnQgaW4gU1VCU0NSSUJFIGFuZA0KICAgTk9U SUZZIHJlcXVlc3RzLg0KDQoNCg0KDQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2Vw dGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0 ICBTSVAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAx MA0KDQoNCjYuMi4gIEV2ZW50IFBhY2thZ2UgUGFyYW1ldGVycw0KDQogICBUaGUgU0lQIEV2ZW50 cyBzcGVjaWZpY2F0aW9uIFs2XSBhbGxvd3MgcGFja2FnZXMgdG8gZGVmaW5lIGFkZGl0aW9uYWwN CiAgIHBhcmFtZXRlcnMuICBUaGlzIGV2ZW50IHBhY2thZ2UgImNvbW0tZGl2LWluZm8iIGRvZXMg bm90IGRlZmluZQ0KICAgYWRkaXRpb25hbCBwYXJhbWV0ZXJzLiAuDQoNCjYuMy4gIFNVQlNDUklC RSBib2RpZXMNCg0KICAgVGhlIFNJUCBFdmVudHMgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyBwYWNr YWdlIG9yIHRlbXBsYXRlLXBhY2thZ2UNCiAgIGRlZmluaXRpb25zIHRvIGRlZmluZSB0aGUgdXNh Z2UsIGlmIGFueSwgb2YgYm9kaWVzIGluIFNVQlNDUklCRQ0KICAgcmVxdWVzdHMuDQoNCiAgIEEg U1VCU0NSSUJFIGZvciBDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBldmVudCBNQVkgY29udGFpbiBh IGJvZHkuDQogICBUaGUgcHVycG9zZSBvZiB0aGUgYm9keSBkZXBlbmRzIG9uIGl0cyB0eXBlLiAg U3Vic2NyaXB0aW9ucyB0byB0aGUNCiAgIENvbW0tZGl2LWluZm8gZXZlbnQgcGFja2FnZSBTSEFM TCBvbmx5IGluY2x1ZGUgYSBib2R5IG9mIE1JTUUgdHlwZQ0KICAgImFwcGxpY2F0aW9uL2NvbW0t ZGl2LWluZm8reG1sIi4NCg0KICAgQSBib2R5IG9mIHRoZSBTVUJTQ1JJQkUgcmVxdWVzdCB3aXRo IGNvbnRlbnQgdHlwZSBzZXQgdG8gTUlNRSB0eXBlDQogICAiYXBwbGljYXRpb24vY29tbS1kaXYt aW5mbyt4bWwiIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KICAgY29tbXVuaWNhdGlv biBkaXZlcnNpb24gbm90aWZpY2F0aW9uIGluZm9ybWF0aW9uIGZpbHRlciBjcml0ZXJpYSBhbmQN CiAgIG5vdGlmaWNhdGlvbiB0cmlnZ2VyIGNyaXRlcmlhLiAgVGhpcyBpbmZvcm1hdGlvbiBpcyBj b252ZXllZCB1c2luZw0KICAgdGhlIFhNTCBlbGVtZW50cyBkZWZpbmVkIGluIFNlY3Rpb24gOC4x LjEuMS4NCg0KNi40LiAgU3Vic2NyaXB0aW9uIER1cmF0aW9uDQoNCiAgIFRoZSBkZWZhdWx0IGV4 cGlyYXRpb24gdGltZSBmb3Igc3Vic2NyaXB0aW9ucyB3aXRoaW4gdGhpcyBwYWNrYWdlIGlzDQog ICAzNjAwIHNlY29uZHMuICBBcyBwZXIgWzZdLCB0aGUgc3Vic2NyaWJlciBNQVkgc3BlY2lmeSBh biBhbHRlcm5hdGUNCiAgIGV4cGlyYXRpb24gaW4gdGhlIEV4cGlyZXMgaGVhZGVyIGZpZWxkLg0K DQo2LjUuICBOb3RpZnkgYm9kaWVzDQoNCiAgIFRoZSBTSVAgRXZlbnRzIHNwZWNpZmljYXRpb24g cmVxdWlyZXMgcGFja2FnZSBkZWZpbml0aW9ucyB0byBkZWZpbmUgYQ0KICAgZGVmYXVsdCB2YWx1 ZSBmb3Igc3Vic2NyaXB0aW9uIGR1cmF0aW9ucywgYW5kIHRvIGRpc2N1c3MgcmVhc29uYWJsZQ0K ICAgY2hvaWNlcyBmb3IgZHVyYXRpb25zIHdoZW4gdGhleSBhcmUgZXhwbGljaXRseSBzcGVjaWZp ZWQuDQoNCiAgIFRoZSBOT1RJRlkgbWVzc2FnZSBjb250YWlucyBib2RpZXMuICBUaGlzIGJvZHkg aXMgYSBmb3JtYXQgbGlzdGVkIGluDQogICB0aGUgQWNjZXB0IGhlYWRlciBmaWVsZCBvZiB0aGUg U1VCU0NSSUJFIHJlcXVlc3Qgb3IgYSBwYWNrYWdlDQogICBzcGVjaWZpYyBkZWZhdWx0IGZvcm1h dCBpZiB0aGUgQWNjZXB0IGhlYWRlciBmaWVsZCB3YXMgb21pdHRlZCBmcm9tDQogICB0aGUgU1VC U0NSSUJFIHJlcXVlc3QuDQoNCiAgIEluIHRoaXMgZXZlbnQgcGFja2FnZSwgdGhlIGJvZHkgb2Yg dGhlIG5vdGlmaWNhdGlvbiBjb250YWlucyB0aGUNCiAgIGNvbW11bmljYXRpb24gZGl2ZXJzaW9u IGluZm9ybWF0aW9uIHBlcnRhaW5pbmcgdG8gdGhlIGRpdmVyc2lvbiB0aGF0DQogICBvY2N1cmVk IGluIHRoZSBuZXR3b3JrIG9uIGJlaGFsZiBvZiB0aGUgc3Vic2NyaWJlci4gIFRoZSBmb3JtYXQg b2YNCiAgIHRoZSBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBpbmZvcm1hdGlvbiBpcyBhbiBYTUwg ZG9jdW1lbnQgYXMgcGVyDQogICBlbGVtZW50cyBkZWZpbmVkIGluIFNlY3Rpb24gOC4xLjIuICBT ZWUgU2VjdGlvbiA4Lg0KDQogICBBbGwgc3Vic2NyaWJlcnMgYW5kIG5vdGlmaWVycyBvZiB0aGUg ImNvbW0tZGl2LWluZm8iIGV2ZW50IHBhY2thZ2UNCiAgIE1VU1Qgc3VwcG9ydCB0aGUgImFwcGxp Y2F0aW9uL2NvbW0tZGl2LWluZm8reG1sIiBkYXRhIGZvcm1hdA0KDQoNCg0KQXZhc2FyYWxhLCBl dCBhbC4gICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgIFtQYWdl IDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlm aWNhdGlvbiAgICAgIE1hcmNoIDIwMTANCg0KDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA4LiAg VGhlIFNVQlNDUklCRSByZXF1ZXN0IE1BWSBjb250YWluIGFuIEFjY2VwdA0KICAgaGVhZGVyIGZp ZWxkLiAgSWYgbm8gc3VjaCBoZWFkZXIgZmllbGQgaXMgcHJlc2VudCwgaXQgaGFzIGEgZGVmYXVs dA0KICAgdmFsdWUgb2YgImFwcGxpY2F0aW9uL2NvbW0tZGl2LWluZm8reG1sIiAoYXNzdW1pbmcg RXZlbnQgaGVhZGVyIGhhcyBhDQogICB2YWx1ZSBvZiAiY29tbS1kaXYtaW5mbyIpLiAgSWYgdGhl IEFjY2VwdCBoZWFkZXIgZmllbGQgaXMgcHJlc2VudCwgaXQNCiAgIE1VU1QgY29udGFpbiB0aGUg dmFsdWUgImFwcGxpY2F0aW9uL2NvbW0tZGl2LWluZm8reG1sIi4NCg0KNi42LiAgTm90aWZpZXIg UHJvY2Vzc2luZyBvZiBTVUJTQ1JJQkUgcmVxdWVzdHMNCg0KICAgVGhlIGNvbnRlbnRzIG9mIGEg ZG9jdW1lbnQgY29udGFpbmluZyBjb21tLWRpdi1pbmZvIGluZm9ybWF0aW9uIGNhbg0KICAgY29u dGFpbiBzZW5zaXRpdmUgaW5mb3JtYXRpb24gdGhhdCBjYW4gcmV2ZWFsIHNvbWUgcHJpdmFjeQ0K ICAgaW5mb3JtYXRpb24uICBUaGVyZWZvcmUsIHN1Y2ggY29tbS1kaXYtaW5mbyBkb2N1bWVudHMg TVVTVCBvbmx5IGJlDQogICBzZW50IHRvIGF1dGhvcml6ZWQgc3Vic2NyaWJlcnMuICBJbiBvcmRl ciB0byBkZXRlcm1pbmUgaWYgYQ0KICAgc3Vic2NyaXB0aW9uIG9yaWdpbmF0ZXMgaW4gYW4gYXV0 aG9yaXplZCB1c2VyLCB0aGUgc3Vic2NyaWJlciBNVVNUIGJlDQogICBhdXRoZW50aWNhdGVkIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYuNi4xIGFuZCB0aGVuIHRoZSB1c2VyIE1VU1QgYmUNCiAg IGF1dGhvcml6ZWQgdG8gYmUgYSBzdWJzY3JpYmVyIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYu Ni4yLg0KDQo2LjYuMS4gIEF1dGhlbnRpY2F0aW9uDQoNCiAgIE5vdGlmaWVycyBNVVNUIGF1dGhl bnRpY2F0ZSBhbGwgc3Vic2NyaXB0aW9uIHJlcXVlc3RzLiAgVGhpcw0KICAgYXV0aGVudGljYXRp b24gY2FuIGJlIGRvbmUgdXNpbmcgYW55IG9mIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gWzVd DQogICBhbmQgb3RoZXIgYXV0aGVudGljYXRpb24gZXh0ZW5zaW9ucy4NCg0KNi42LjIuICBBdXRo b3JpemF0aW9uDQoNCiAgIE9uY2UgYXV0aGVudGljYXRlZCwgdGhlIG5vdGlmaWVyIG1ha2VzIGFu IGF1dGhvcml6YXRpb24gZGVjaXNpb24uICBBDQogICBub3RpZmllciBNVVNUIE5PVCBhY2NlcHQg YSBzdWJzY3JpcHRpb24gdW5sZXNzIGF1dGhvcml6YXRpb24gaGFzIGJlZW4NCiAgIHByb3ZpZGVk IGJ5IHRoZSB1c2VyLiAgVGhlIG1lYW5zIGJ5IHdoaWNoIGF1dGhvcml6YXRpb24gYXJlIHByb3Zp ZGVkDQogICBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEF1dGhvcml6 YXRpb24gbWF5IGhhdmUgYmVlbg0KICAgcHJvdmlkZWQgYWhlYWQgb2YgdGltZSB0aHJvdWdoIGFj Y2VzcyBsaXN0cywgcGVyaGFwcyBzcGVjaWZpZWQgaW4gYQ0KICAgd2ViIHBhZ2UuICBBdXRob3Jp emF0aW9uIG1heSBoYXZlIGJlZW4gcHJvdmlkZWQgYnkgbWVhbnMgb2YgdXBsb2FkaW5nDQogICBz b21lIGtpbmQgb2Ygc3RhbmRhcmRpemVkIGFjY2VzcyBjb250cm9sIGxpc3QgZG9jdW1lbnQNCg0K Ni43LiAgTm90aWZpZXIgR2VuZXJhdGlvbiBvZiBOT1RJRlkgcmVxdWVzdHMNCg0KICAgVGhlIFNJ UCBFdmVudHMgc3BlY2lmaWNhdGlvbiBkZXRhaWxzIHRoZSBmb3JtYXR0aW5nIGFuZCBzdHJ1Y3R1 cmUgb2YNCiAgIE5PVElGWSBtZXNzYWdlcy4gIEhvd2V2ZXIsIHBhY2thZ2VzIGFyZSBtYW5kYXRl ZCB0byBwcm92aWRlIGRldGFpbGVkDQogICBpbmZvcm1hdGlvbiBvbiB3aGVuIHRvIHNlbmQgYSBO T1RJRlksIGhvdyB0byBjb21wdXRlIHRoZSBzdGF0ZSBvZiB0aGUNCiAgIHJlc291cmNlLCBob3cg dG8gZ2VuZXJhdGUgbmV1dHJhbCBvciBmYWtlIHN0YXRlIGluZm9ybWF0aW9uLCBhbmQNCiAgIHdo ZXRoZXIgc3RhdGUgaW5mb3JtYXRpb24gaXMgY29tcGxldGUgb3IgcGFydGlhbC4gIFRoaXMgc2Vj dGlvbg0KICAgZGVzY3JpYmVzIHRob3NlIGRldGFpbHMgZm9yIHRoZSAiY29tbS1kaXYtaW5mbyIg ZXZlbnQgcGFja2FnZS4NCg0KICAgQSBub3RpZmllciBNQVkgc2VuZCBhIE5PVElGWSBhdCBhbnkg dGltZS4gIFR5cGljYWxseSwgaXQgd2lsbCBzZW5kDQogICBvbmUgd2hlbiBhIGNvbW11bmljYXRp b24gZGl2ZXJzaW9uIGlzIGVuYWN0ZWQgb24gYmVoYWxmIG9mIHRoZSB1c2VyLg0KICAgVGhlIE5P VElGWSByZXF1ZXN0IE1BWSBjb250YWluIGEgYm9keSBjb250YWluaW5nIGEgY29tbS1kaXYtaW5m bw0KICAgZG9jdW1lbnQuICBUaGUgdGltZXMgYXQgd2hpY2ggdGhlIE5PVElGWSBpcyBzZW50IGZv ciBhIHBhcnRpY3VsYXINCiAgIHN1YnNjcmliZXIsIGFuZCB0aGUgY29udGVudHMgb2YgdGhlIGJv ZHkgd2l0aGluIHRoYXQgbm90aWZpY2F0aW9uLA0KICAgYXJlIHN1YmplY3QgdG8gYW55IHJ1bGVz IHNwZWNpZmllZCBieSB0aGUgYXV0aG9yaXphdGlvbiBwb2xpY3kgdGhhdA0KICAgZ292ZXJucyB0 aGUgc3Vic2NyaXB0aW9uIGFuZCB0byBwcmVmZXJlbmNlcyBpbmRpY2F0ZWQgYXQgdGhlIHRpbWUg b2YNCg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIw MTAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5p Y2F0aW9uIERpdmVyc2lvbiBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KICAgc3Vi c2NyaXB0aW9uLg0KDQogICBUaGUgYm9keSBvZiB0aGUgTk9USUZZIE1VU1QgYmUgc2VudCB1c2lu ZyB0aGUgdHlwZSAiYXBwbGljYXRpb24vDQogICBjb21tLWRpdi1pbmZvK3htbCIuDQoNCiAgIE5v dGlmaWVycyBjb3VsZCBkZXRlY3QgdGhhdCBhIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIHdhcyBl bmFjdGVkIG9uDQogICBiZWhhbGYgb2YgdGhlIHN1YnNjcmliZXIgdmlhIGEgIkhpc3RvcnktSW5m byIgaGVhZGVyIGZpZWxkIHZhbHVlLCBwZXINCiAgIFsyXSBvciBbMV0sIHNlbnQgZnJvbSBhbiBh cHBsaWNhdGlvbiBzZXJ2ZXIgaG9zdGluZyB0aGUgQ0RJVg0KICAgYXBwbGljYXRpb24uDQoNCiAg IEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIG5vdGlmaWVycyBkbyBtYWludGFpbiB0aGUgaGlz dG9yeSBvZiBsYXN0DQogICBOIGNvbW11bmljYXRpb24gZGl2ZXJzaW9ucyB0aGF0IG9jY3VycmVk LCB3aGVyZSB0aGUgdmFsdWUgTiA+PTEgYXMNCiAgIHBhcnQgb2Ygc3RhdGUgaW5mb3JtYXRpb24g Zm9yIHRoYXQgc2VydmVyLiAgVGhlIHZhbHVlIG9mIE4gY291bGQgYmUNCiAgIGNvbmZpZ3VyZWQg YW5kIGlzIGxlZnQgdG8gc2VydmVyIHBvbGljeSB0byBkZXRlcm1pbmUgYXBwcm9wcmlhdGUNCiAg IHZhbHVlLg0KDQogICBUaGUgc3RhdGUgaW5mb3JtYXRpb24gaXMgcmV0YWluZWQgZXZlbiBhZnRl ciB0aGUgbm90aWZpY2F0aW9uIGZvcg0KICAgdGhvc2UgZGl2ZXJzaW9ucyBhcmUgc2VudCB0byB0 aGUgc3Vic2NyaWJlciBhbmQgY2hhbmdlcyB3aGVuIG5ldw0KICAgZGl2ZXJzaW9uIG9jY3Vycy4g IFNvIGV2ZXJ5IHRpbWUgYSBuZXcgZGl2ZXJzaW9uIG9jY3VycywgdGhlIHN0YXRlDQogICBpbmZv cm1hdGlvbiBjaGFuZ2VzIHRvIHJlZmxlY3QgdGhlIGxhdGVzdCBkaXZlcnNpb24gcmVtb3Zpbmcg dGhlDQogICBvbGRlc3QgZGl2ZXJzaW9uIGluZm9ybWF0aW9uLg0KDQo2LjguICBTdWJzY3JpYmVy IFByb2Nlc3Npbmcgb2YgTk9USUZZIFJlcXVlc3RzDQoNCiAgIFRoZSBTSVAgRXZlbnRzIHNwZWNp ZmljYXRpb24gZXhwZWN0cyBldmVudCBwYWNrYWdlcyB0byBkZXNjcmliZSB0aGUNCiAgIHByb2Nl c3MgZm9sbG93ZWQgYnkgdGhlIHN1YnNjcmliZXIgdXBvbiByZWNlaXB0IG9mIGEgTk9USUZZIHJl cXVlc3QuDQogICBJbiB0aGlzIHNwZWNpZmljYXRpb24sIGVhY2ggTk9USUZZIHJlcXVlc3QgY29u dGFpbnMgYSBjb21tLWRpdi1pbmZvDQogICBkb2N1bWVudA0KDQo2LjkuICBIYW5kbGluZyBvZiBG b3JrZWQgUmVxdWVzdHMNCg0KICAgVGhlIFNJUCBFdmVudHMgc3BlY2lmaWNhdGlvbiByZXF1aXJl cyBlYWNoIHBhY2thZ2UgdG8gZGVzY3JpYmUNCiAgIGhhbmRsaW5nIG9mIGZvcmtlZCBSZXF1ZXN0 cy4NCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgYWxsb3dzIGEgc2luZ2xlIGRpYWxvZyB0 byBiZSBjb25zdHJ1Y3RlZCBhcyBhDQogICByZXN1bHQgb2YgZW1pdHRpbmcgYW4gaW5pdGlhbCBT VUJTQ1JJQkUgcmVxdWVzdC4gIFRoaXMgZ3VhcmFudGVlcw0KICAgdGhhdCBvbmx5IGEgc2luZ2xl IG5vdGlmaWVyIGlzIGdlbmVyYXRpbmcgbm90aWZpY2F0aW9ucyBmb3IgYQ0KICAgcGFydGljdWxh ciBzdWJzY3JpcHRpb24gdG8gYSBwYXJ0aWN1bGFyIHVzZXIuDQoNCjYuMTAuICBSYXRlIG9mIE5v dGlmaWNhdGlvbnMNCg0KICAgVGhlIFNJUCBFdmVudHMgc3BlY2lmaWNhdGlvbiByZXF1aXJlcyBl YWNoIHBhY2thZ2UgdG8gc3BlY2lmeSBtYXhpbXVtDQogICByYXRlIGF0IHdoaWNoIG5vdGlmaWNh dGlvbnMgY2FuIGJlIHNlbnQgLg0KDQogICBDb21tLWRpdi1pbmZvIG5vdGlmaWVycyBTSE9VTEQg Tk9UIGdlbmVyYXRlIG5vdGlmaWNhdGlvbnMgZm9yIGENCiAgIHNpbmdsZSBzdWJzY3JpcHRpb24g YXQgYSByYXRlIG9mIG1vcmUgdGhhbiBvbmNlIGV2ZXJ5IGZpdmUgc2Vjb25kcy4NCg0KDQoNCg0K DQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEyLCAyMDEwICAgICAg ICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICBTSVAgQ29tbXVuaWNhdGlvbiBE aXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAxMA0KDQoNCjYuMTEuICBTdGF0ZSBB Z2VudHMNCg0KICAgVGhlIG5vdGlpZmVycyBtYWludGFpbiB0aGUgc3RhdGUgb2YgbGFzdCBOIGNv bW11bmljYXRpb24gZGl2ZXJzaW9ucywNCiAgIHdoZXJlIE4+PTEgdGhhdCBvY2N1cnJlZCBpbiB0 aGUgbmV0d29yayBvbiBiZWhhbGYgb2YgdGhlIHN1YnNjcmliZXINCiAgIGV2ZW4gYWZ0ZXIgdGhl IG5vdGlmaWNhdGlvbnMgZm9yIHRob3NlIE4gY29tbXVuaWNhdGlvbnMgZGl2ZXJzaW9ucw0KICAg YXJlIHNlbnQgb3IgdW5zZW50LiAgVGhpcyBzdGF0ZSBpbmZvcm1hdGlvbiBnZXRzIHVwZGF0ZWQg d2l0aCB0aGUNCiAgIGxhdGVzdCBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiB0aGF0IG9jY3VycyBi eSByZW1vdmluZyB0aGUgb2xkZXN0DQogICBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBhbmQgYWRk aW5nIHRoZSBsYXRlc3QgZGl2ZXJzaW9uIHdoaWxlDQogICBtYWludGFpbmluZyB0aGUgbnVtYmVy IG9mIGRpdmVyc2lvbnMgYXQgTi4NCg0KICAgVGh1cyBhdCBhbnkgcG9pbnQgb2YgdGltZSBhIHN1 YnNjcmliZXIgTUFZIGtub3cgdGhlIHN0YXRlIG9mDQogICBjb21tdW5pY2F0aW9uIGRpdmVyc2lv bnMgZW5hY3RlZCBvbiBoaXMgb3IgaGVyIGJlaGFsZiBieSB0aGUgc2VydmVyLg0KDQoNCjcuICBD b21tLWRpdi1pbmZvIERvY3VtZW50DQoNCiAgIENvbW0tZGl2LWluZm8gZG9jdW1lbnQgaXMgYW4g WE1MIGRvY3VtZW50IFs4XSB0aGF0IE1VU1QgYmUgd2VsbC0NCiAgIGZvcm1lZCBhbmQgU0hPVUxE IGJlIHZhbGlkLiAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24NCiAgIGRvY3Vt ZW50cyBNVVNUIGJlIGJhc2VkIG9uIFhNTCAxLjAgYW5kIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBV VEYtOA0KICAgWzldLg0KDQoNCjguICBTdHJ1Y3R1cmUgb2YgQ29tbS1kaXYtaW5mbyBGb3JtYXQN Cg0KICAgQSBDb21tdW5pY2F0aW9ucyBEaXZlcnNpb24gSW5mb3JtYXRpb24gZG9jdW1lbnQgc3Rh cnRzIHdpdGggYSAiY29tbS0NCiAgIGRpdi1pbmZvIiBlbGVtZW50LiAgVGhlIGNvbW0tZGl2LWlu Zm8gZWxlbWVudCBoYXMgYSBzZXJpZXMgb2YNCiAgIGVsZW1lbnRzIGRlc2NyaWJpbmcgdGhlIHBh cnRpY3VsYXIgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24gb3IgdGhlDQogICBmaWx0ZXIgY3JpdGVy aWEgZm9yIHJlY2VpdmluZyB0aGUgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24NCiAgIGluZm9ybWF0 aW9uLg0KDQo4LjEuICBDb21tLWRpdi1pbmZvIEVsZW1lbnQNCg0KICAgVGhlIGNvbW0tZGl2LWlu Zm8gZWxlbWVudCBnaXZlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3BlY2lmaWMNCiAgIGNvbW11 bmljYXRpb24gZGl2ZXJzaW9uIG9yIGl0IGNvdWxkIGdpdmUgaW5mb3JtYXRpb24gYWJvdXQgYQ0K ICAgcGFydGljdWxhciBzZWxlY3Rpb24gY3JpdGVyaWEgZm9yIHRoZSB1c2VyIHJlY2VpdmluZyB0 aGUNCiAgIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGluZm9ybWF0aW9uLg0KDQo4LjEuMS4gIGNv bW0tZGl2LXN1YnMtaW5mbyBFbGVtZW50DQoNCiAgIFRoZSBjb21tLWRpdi1zdWJzLWluZm8gZWxl bWVudCBpcyB1c2VkIGJ5IHRoZSBzdWJzY3JpYmluZyB1c2VyIHRvDQogICBzcGVjaWZ5IHRoZSBj b21tdW5pY2F0aW9uIGRpdmVyc2lvbiBpbmZvcm1hdGlvbiBzZWxlY3Rpb24gY3JpdGVyaWENCiAg IGFuZCB0aGUgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24gbm90aWZpY2F0aW9uIHRyaWdnZXIgY3Jp dGVyaWEuICBJdA0KICAgY29udGFpbnMgdGhlIGZvbGxvd2luZyBlbGVtZW50czoNCg0KOC4xLjEu MS4gIGNvbW0tZGl2LXNlbGVjdGlvbi1jcml0ZXJpYQ0KDQogICBUaGlzIGVsZW1lbnQgY29udGFp bnMgaW5mb3JtYXRpb24gYWJvdXQgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24NCiAgIGluZm9ybWF0 aW9uIHNlbGVjdGlvbiBjcml0ZXJpYS4gIEl0IGNvbnRhaW5zIGZvbGxvd2luZyBzdWItZWxlbWVu dHMNCg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIw MTAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5p Y2F0aW9uIERpdmVyc2lvbiBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KICAgZm9y IHNwZWNpZnlpbmcgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYS4NCg0KOC4xLjEuMS4xLiAgb3JpZ2lu YXRpbmctdXNlci1zZWxlY3Rpb24tY3JpdGVyaWENCg0KICAgVGhpcyBlbGVtZW50IHNwZWNpZmll cyB0aGUgb3JpZ2luYXRpbmcgdXNlciBpbmZvcm1hdGlvbiBmb3IgdGhlDQogICBjb21tdW5pY2F0 aW9uIGkuZS4gdGhlIGNhbGxlci4gIFRoaXMgaXMgc3BlY2lmaWVkIGluIHRoZSBmb3JtIG9mDQog ICAidXNlci1uYW1lIiBhbmQgInVzZXItdXJpIi4gIEUuZy4gc2lwOkFsaWNlQGRvbWFpbi5jb20u ICBUaGUgVXNlcm5hbWUNCiAgIGFzIHdlbGwgYXMgVXNlci1VUkkgc3BlY2lmaWVkIHdpbGwgYmUg Y29tcGFyZWQgd2l0aCB0aGUgb3JpZ2luYXRpbmcNCiAgIHVzZXIgaW5mb3JtYXRpb24gb2YgdGhl IGN1cnJlbnQgdXNlciBhbmQgaWYgdGhlcmUgaXMgYSBtYXRjaCwgdGhlbg0KICAgaW5mb3JtYXRp b24gYWJvdXQgdGhlIGRpdmVyc2lvbiBvZiB0aGlzIHNwZWNpZmljIGNvbW11bmljYXRpb24gd291 bGQNCiAgIGJlIHNlbGVjdGVkIGZvciBub3RpZmljYXRpb24gdG8gdGhlIERpdmVydGluZyB1c2Vy LiAgSXQgY29uc2lzdHMgb2YNCiAgIHRoZSBmb2xsb3dpbmcgc3ViLWVsZW1lbnRzLg0KDQo4LjEu MS4xLjEuMS4gIHVzZXItaW5mbw0KDQogICBUaGlzIGVsZW1lbnQgZ2l2ZXMgdXNlciBkZXRhaWxz IGxpa2UgdXNlcm5hbWUgYW5kIFVSSS4gIFRoaXMgZWxlbWVudA0KICAgaGFzIGZ1cnRoZXIgc3Vi LWVsZW1lbnRzIGZvciBkZXNjcmliaW5nIHVzZXJuYW1lIGFuZCB1c2VyIFVSSQ0KDQo4LjEuMS4x LjEuMS4xLiAgVXNlci1uYW1lDQoNCiAgIFRoaXMgZWxlbWVudCBnaXZlcyBVc2VybmFtZS4gICJB bGljZSIuDQoNCjguMS4xLjEuMS4xLjIuICBVc2VyLVVSSQ0KDQogICBUaGlzIGVsZW1lbnQgZ2l2 ZXMgVXNlciBVUkkuICBFLmcgInNpcDpBbGljZUBkb21haW4uY29tIi4gIEl0IHRha2VzDQogICB0 aGUgZm9ybSBvZiBhbnkgVVJJIHNjaGVtZSBsaWtlIHNpcC4gc2lwcywgdGVsIG9yIGFueSBvdGhl ciBVUkkNCiAgIHNjaGVtZQ0KDQo4LjEuMS4xLjIuICBkaXZlcnNpb24tdGltZS1zZWxlY3Rpb24t Y3JpdGVyaWENCg0KICAgVGhpcyBlbGVtZW50IHNwZWNpZmllcyB0aGUgdGltZSByYW5nZSBmb3Ig cmVjZWl2aW5nIG5vdGlmaWNhdGlvbnMuDQogICBJdCBjb250YWlucyBmb2xsb3dpbmcgYWRkaXRp b25hbCBlbGVtZW50cyAuDQoNCjguMS4xLjEuMi4xLiAgdGltZS1yYW5nZQ0KDQogICBUaGlzIGVs ZW1lbnQgc3BlY2lmaWVzIHRoZSB0aW1lIHJhbmdlIGF0IHdoaWNoIG5vdGlmaWNhdGlvbnMgZm9y DQogICBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbnMgY2FuIGJlIHNlbnQgdG8gdGhlIHN1YnNjcmli ZXIuICBUaGlzIGNvdWxkDQogICBiZSBzcGVjaWZpZWQgaW4gdGhlIGZvcm0gb2YgYSB0aW1lLWlu dGVydmFsIHRvIGVuYWJsZSBwZXJpb2RpYw0KICAgdHJpZ2dlcmluZyBvZiBub3RpZmljYXRpb25z IG9mIGNvbW11bmljYXRpb24gZGl2ZXJzaW9ucyB3aGljaCB0b29rDQogICBwbGFjZSBpbiB0aGF0 IHRpbWUtaW50ZXJ2YWwuDQoNCiAgIE5PVEU6IElmIHRoZSB0aW1lLXJhbmdlIGVsZW1lbnQgaXMg bm90IHNwZWNpZmllZCwgdGhlbiBub3RpZmljYXRpb25zDQogICBhYm91dCBldmVyeSBjb21tdW5p Y2F0aW9uIGRpdmVyc2lvbiB0aGF0IG9jY3VycyBpcyBzZW50IHRvIHRoZQ0KICAgc3Vic2NyaWJl ci4NCg0KDQoNCg0KDQoNCg0KQXZhc2FyYWxhLCBldCBhbC4gICAgICBFeHBpcmVzIFNlcHRlbWJl ciAxMiwgMjAxMCAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgU0lQ IENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgIE1hcmNoIDIwMTANCg0K DQo4LjEuMS4xLjIuMS4xLiAgc3RhcnQtdGltZQ0KDQogICBUaGlzIGVsZW1lbnQgc3BlY2lmaWVz IHRoZSBzdGFydCB0aW1lIGZvciByZWNlaXZpbmcgbm90aWZpY2F0aW9ucy4NCiAgIEl0cyB2YWx1 ZSBpcyBleHByZXNzZWQgaW4gWVlZWTpNTTpERFRISDpNTTpTU1ogZm9ybWF0Lg0KDQo4LjEuMS4x LjIuMS4yLiAgZW5kLXRpbWUNCg0KICAgVGhpcyBlbGVtZW50IHNwZWNpZmllcyB0aGUgZW5kIHRp bWUgZm9yIHJlY2VpdmluZyBub3RpZmljYXRpb25zLiAgSXRzDQogICB2YWx1ZSBpcyBleHByZXNz ZWQgaW4gWVlZWTpNTTpERFRISDpNTTpTU1ogZm9ybWF0Lg0KDQo4LjEuMS4xLjMuICBkaXZlcnRp bmctdXNlci1zZWxlY3Rpb24tY3JpdGVyaWENCg0KICAgVGhpcyBlbGVtZW50IGdpdmVzIGRldGFp bHMgb2YgZGl2ZXJ0aW5nIHVzZXIuICBUaGlzIGVsZW1lbnQgY291bGQNCiAgIGNvbnRhaW4gdGhl IHZhbHVlIHByZXNlbnQgaW4gUC1DYWxsZWQtUGFydHktSUQgaGVhZGVyIGZpZWxkIGFzDQogICBk ZWZpbmVkIGluIFNlY3Rpb24gNC4yIG9mIFsxMF0gYW5kIGJ5IGluY2x1ZGluZyB0aGUgaWRlbnRp dHkgaW4gdGhlDQogICAiZGl2ZXJ0aW5nLXVzZXItaW5mbyIsIFRoZSBVQSBpZGVudGlmaWVzIHdo aWNoIGFkZHJlc3Mtb2YtcmVjb3JkLCBvdXQNCiAgIG9mIHNldmVyYWwgcmVnaXN0ZXJlZCBhZGRy ZXNzLW9mLXJlY29yZHMsIHRoZSBpbnZpdGF0aW9uIHdhcyBzZW50IHRvDQogICB3aGVuIGl0IHdh cyBkaXZlcnRlZCAoZm9yIGV4YW1wbGUsIHRoZSB1c2VyIG1heSBiZSBzaW11bHRhbmVvdXNseQ0K ICAgdXNpbmcgYSBwZXJzb25hbCBhbmQgYSBidXNpbmVzcyBTSVAgVVJJcyB0byByZWNlaXZlIGlu dml0YXRpb24gdG8NCiAgIHNlc3Npb25zKS4gIFRoZSBVUkkgc3BlY2lmaWVkIG92ZXIgaGVyZSB3 aWxsIGJlIGNvbXBhcmVkIHdpdGggdGhlDQogICBSZXF1ZXN0IFVSSSBvZiB0aGUgZGl2ZXJ0aW5n IHVzZXIgZm9yIHdob20gYSBjb21tdW5pY2F0aW9uIGhhcyBiZWVuDQogICBkaXZlcnRlZC4gIE9u bHkgaWYgdGhlcmUgaXMgYSBtYXRjaCwgdGhlbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgIGRp dmVyc2lvbiBvZiB0aGlzIHNwZWNpZmljIGNvbW11bmljYXRpb24gd291bGQgYmUgc2VsZWN0ZWQg Zm9yDQogICBub3RpZmljYXRpb24gdG8gdGhlIGRpdmVydGluZyB1c2VyLiAgVGhpcyBpcyBhbiBv cHRpb25hbCBwYXJhbWV0ZXIuDQogICBJZiBhYnNlbnQsIHRoZW4gY29tbXVuaWNhdGlvbiBkaXZl cnNpb25zIHRvd2FyZHMgYWxsIHJlZ2lzdGVyZWQNCiAgIGNvbnRhY3RzIG9mIHRoZSBzdWJzY3Jp YmluZyB1c2VyIHdvdWxkIGJlIGNvbnNpZGVyZWQgZm9yDQogICBub3RpZmljYXRpb24sIHN1Ympl Y3QgdG8gb3RoZXIgZmlsdGVyIGNyaXRlcmlhLiAgVGhpcyBlbGVtZW50DQogICBjb25zaXN0cyBv ZiBzdWItZWxlbWVudHMgZGVmaW5lZCBmb3IgInVzZXItaW5mbyIgZWxlbWVudA0KICAgU2VjdGlv biA4LjEuMS4xLjEuMS4xDQoNCjguMS4xLjEuNC4gIGRpdmVydGVkLXRvLXVzZXItc2VsZWN0aW9u LWNyaXRlcmlhDQoNCiAgIFRoaXMgZWxlbWVudCBnaXZlcyBkZXRhaWxzIG9mIHRoZSBmaW5hbCB0 YXJnZXQgb2YgdGhlIGNvbW11bmljYXRpb24sDQogICB0aGUgZGl2ZXJlZC10byB1c2VyLiAgVGhl IFVSSSBzcGVjaWZpZWQgaW4gdGhlIFJlcXVlc3QgVVJJIG9mIHRoZSBuZXcNCiAgIHJlcXVlc3Qg aXMgY29tcGFyZWQgd2l0aCB0aGUgc3BlY2lmaWVkIGRpdmVydGVkLXRvIFVSSS4gIE9ubHkgaWYN CiAgIHRoZXJlIGlzIGEgbWF0Y2gsIHRoZW4gaW5mb3JtYXRpb24gYWJvdXQgdGhlIGRpdmVyc2lv biBvZiB0aGlzDQogICBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIHdvdWxkIGJlIHNlbGVjdGVkIGZv ciBub3RpZmljYXRpb24gdG8gdGhlDQogICBEaXZlcnRpbmcgdXNlci4gIFRoaXMgZWxlbWVudCBj b25zaXN0cyBvZiBzdWItZWxlbWVudHMgZGVmaW5lZCBmb3INCiAgICJ1c2VyLWluZm8iIGVsZW1l bnQgU2VjdGlvbiA4LjEuMS4xLjEuMS4xLg0KDQo4LjEuMS4xLjUuICBkaXZlcnNpb24tcmVhc29u LXNlbGVjdGlvbi1jcml0ZXJpYQ0KDQogICBUaGlzIGVsZW1lbnQgY29udGFpbnMgdGhlIHJlYXNv biBmb3IgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24uICBJdA0KICAgY29udGFpbnMgZm9sbG93aW5n IHN1Yi1lbGVtZW50Og0KDQoNCg0KDQoNCg0KDQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDEyLCAyMDEwICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0 LURyYWZ0ICBTSVAgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFy Y2ggMjAxMA0KDQoNCjguMS4xLjEuNS4xLiAgZGl2ZXJzaW9uLXJlYXNvbi1pbmZvDQoNCiAgIFRo aXMgZWxlbWVudCBnaXZlcyB0aGUgYWN0dWFsIHJlYXNvbiBmb3IgdGhlIGNvbW11bmljYXRpb24g ZGl2ZXJzaW9uLg0KICAgRS5nLiAgIkNhbGwgRm9yd2FyZCBvbiBCdXN5Ii4NCg0KOC4xLjEuMi4g IGNvbW0tZGl2LW50ZnktdHJpZ2dlci1jcml0ZXJpYQ0KDQo4LjEuMS4yLjEuICBub3RpZmljYXRp b24tdGltZS1zZWxlY3Rpb24tY3JpdGVyaWENCg0KICAgVGhpcyBlbGVtZW50IGluZm9ybXMgdGhl IHNlcnZlciBhYm91dCB0aGUgdGltZSBhdCB3aGljaCB0aGUNCiAgIG5vdGlmaWNhdGlvbiBzaG91 bGQgYmUgdHJpZ2dlcmVkLg0KDQo4LjEuMS4yLjIuICBwcmVzZW5jZS1zdGF0dXMtc2VsZWN0aW9u LWNyaXRlcmlhDQoNCiAgIFRoaXMgZWxlbWVudCBnaXZlcyB0aGUgcHJlc2VuY2Ugc3RhdHVzIG9m IHRoZSBzdWJzY3JpYmVyLCBiYXNlZCBvbg0KICAgd2hpY2ggdGhlIGRlY2lzaW9uIGNhbiBiZSBt YWRlLCB3aGV0aGVyIHRoZSBzdWJzY3JpYmVyIHdpc2hlcyB0bw0KICAgcmVjZWl2ZSBub3RpZmlj YXRpb24gaW5mb3JtYXRpb24gb3Igbm90Lg0KDQo4LjEuMS4yLjIuMS4gIHByZXNlbmNlLXNlbGVj dGlvbi1pbmZvDQoNCiAgIFRoaXMgZWxlbWVudCBzcGVjaWZpZXMgdGhlIHByZXNlbmNlIHN0YXR1 cyBvZiB0aGUgc3Vic2NyaWJlciB3aXRoaW4NCiAgIHdoaWNoIHRoZSBzdWJzY3JpYmVyIGV4cGVj dHMgdG8gcmVjZWl2ZSBub3RpZmljYXRpb25zIGFib3V0DQogICBjb21tdW5pY2F0aW9uIGRpdmVy c2lvbnMuDQoNCjguMS4xLjIuMy4gIG5vdGlmaWNhdGlvbi1idWZmZXItaW50ZXJ2YWwNCg0KICAg VGhpcyBlbGVtZW50IHNwZWNpZmllcyBhbiBvcHRpb25hbCBlbGVtZW50IChpbiBzZWNvbmRzKSB0 byBvdmVyd3JpdGUNCiAgIHRoZSBDRElWTiBCdWZmZXIgVGltZXIgZm9yIHdoaWNoIHRoZSBDRElW TiBBcHBsaWNhdGlvbiBTZXJ2ZXIgc2hvdWxkDQogICBzdG9yZSB0aGUgQ0RJViBOb3RpZmljYXRp b24sIGlmIGl0IGNhbm5vdCBiZSBkZWxpdmVyZWQgdG8gdGhlDQogICBzdWJzY3JpYmVyLCBGb3Ig ZXhhbXBsZSB0aGlzIHdvdWxkIGJlIHJlcXVpcmVkIGZvciBidWZmZXJpbmcgdGhlDQogICBub3Rp ZmljYXRpb25zLCBpZiB0aGUgdXNlciBpcyBsb2dnZWQgb3V0IGFuZCB0aGUgZGl2ZXJzaW9uIGlz DQogICB0cmlnZ2VyZWQgZHVlIHRvIENGTkwvQ0ZOUmMsIHJlc3VsdGluZyBpbiBDRElWTiBmb3Ig dGhhdCBkaXZlcnNpb24uDQogICBUaGUgdXNlciBtYXkgc2V0IE5vdGlmaWNhdGlvbiBCdWZmZXIg SW50ZXJ2YWwgdmFsdWUgaW4gc2Vjb25kcyB0byBhDQogICBtYXhpbXVtIHZhbHVlIG9mIDEgZGF5 LiAgQWxzbywgaWYgbm90IGNvbmZpZ3VyZWQgYnkgdGhlIHVzZXIsIHRoZQ0KICAgZGVmYXVsdCB2 YWx1ZSBvZiAxIGRheSAoYXMgY29uZmlndXJlZCBieSB0aGUgbmV0d29yayBwcm92aWRlcikgaXMN CiAgIGFwcGxpY2FibGUuDQoNCjguMS4yLiAgQ29tbS1kaXYtbnRmeS1pbmZvIEVsZW1lbnQNCg0K ICAgVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24uICBUaGlz IGVsZW1lbnQgaGFzDQogICBmb2xsb3dpbmcgc3ViLWVsZW1lbnRzOg0KDQo4LjEuMi4xLiAgb3Jp Z2luYXRpbmctdXNlci1pbmZvDQoNCiAgIFJlZmVyIHRvIFNlY3Rpb24gOC4xLjEuMS4xIGZvciBk ZXRhaWxzIG9mIHRoaXMgZWxlbWVudC4NCg0KDQoNCg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0K SW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBOb3RpZmljYXRpb24g ICAgICBNYXJjaCAyMDEwDQoNCg0KOC4xLjIuMi4gIGRpdmVydGluZy11c2VyLWluZm8NCg0KICAg VGhpcyBlbGVtZW50IGdpdmVzIGRldGFpbHMgb2YgdGhlIGRpdmVydGluZyB1c2VyLiAgVGhpcyBp cyBhbg0KICAgb3B0aW9uYWwgZWxlbWVudCBhbmQgd291bGQgYmUgcHJlc2VudCBvbmx5IGlmIHRo ZSBzdWJzY3JpYmVyIGhhcw0KICAgcmVxdWVzdGVkIGl0LiBpZiBhYnNlbnQsIGl0IGlzIGFzc3Vt ZWQgdGhhdCB0aGUgZGl2ZXJzaW9uIG9jY3VycmVkIGF0DQogICBvbmUgb2YgdGhlIHJlZ2lzdGVy ZWQgY29udGFjdHMuDQoNCjguMS4yLjMuICBkaXZlcnRlZC10by11c2VyLWluZm8NCg0KICAgVGhp cyBlbGVtZW50IGdpdmVzIGRldGFpbHMgb2YgdGhlIGZpbmFsIHRhcmdldCBvZiB0aGUgY29tbXVu aWNhdGlvbg0KICAgaS5lIHRoZSBkaXZlcmVkLXRvIHVzZXIuICBUaGlzIGVsZW1lbnQgY29uc2lz dHMgb2Ygc3ViLWVsZW1lbnRzDQogICBkZWZpbmVkIGZvciAidXNlci1pbmZvIiBlbGVtZW50Lg0K DQo4LjEuMi40LiAgZGl2ZXJzaW9uLXRpbWUtaW5mbw0KDQogICBUaGlzIGVsZW1lbnQgZ2l2ZXMg dGhlIHRpbWUgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24uICBJdHMgdmFsdWUgaXMNCiAgIGV4 cHJlc3NlZCBpbiBZWVlZOk1NOkREVEhIOk1NOlNTIGZvcm1hdC4NCg0KOC4xLjIuNS4gIGRpdmVy c2lvbi1yZWFzb24taW5mbw0KDQogICBUaGlzIGVsZW1lbnQgZ2l2ZXMgdGhlIGFjdHVhbCByZWFz b24gZm9yIHRoZSBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbi4NCg0KOC4xLjMuICBDb21tLWRpdi1p bmZvLXNlbGVjdGlvbi1jcml0ZXJpYQ0KDQogICBUaGlzIGVsZW1lbnQgZ2l2ZXMgdGhlIHN1YnNj cmliZXIgdmFyaW91cyB0byBzZWxlY3QgY29tbXVuaWNhdGlvbg0KICAgZGl2ZXJzaW9uIGluZm9y bWF0aW9uLiAgVGhpcyBlbGVtZW50IGhhcyBmb2xsb3dpbmcgc3ViLWVsZW1lbnRzLg0KDQo4LjEu My4xLiAgZGlzYWJsZS1vcmlnaW5hdGluZy11c2VyLWluZm8NCg0KICAgVGhpcyBlbGVtZW50IGdp dmVzIHRoZSBzdWJzY3JpYmVyIG9wdGlvbiBvZiBhZGRpbmcgb3JpZ2luYXRpbmcgdXNlcg0KICAg aW5mb3JtYXRpb24gdG8gdGhlIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4gIFRoZSBkZWZhdWx0 IHZhbHVlIGlzDQogICBmYWxzZSB3aGljaCBtZWFucyB0aGUgc3Vic2NyaWJlciB3YW50cyB0aGUg b3JpZ2luYXRpbmctdXNlci1pbmZvDQogICBlbGVtZW50IHRvIGJlIHByZXNlbnQgaW4gdGhlIG5v dGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4NCg0KOC4xLjMuMi4gIGRpc2FibGUtZGl2ZXJ0aW5nLXVz ZXItaW5mbw0KDQogICBUaGlzIGVsZW1lbnQgZ2l2ZXMgdGhlIHN1YnNjcmliZXIgb3B0aW9uIG9m IGFkZGluZyBkaXZlcnRpbmctdXNlcg0KICAgaW5mb3JtYXRpb24gdG8gdGhlIG5vdGlmaWNhdGlv biBpbmZvcm1hdGlvbi4gIFRoZSBkZWZhdWx0IHZhbHVlIGlzDQogICBmYWxzZSB3aGljaCBtZWFu cyB0aGUgc3Vic2NyaWJlciB3YW50cyB0aGUgZGl2ZXJ0aW5nLXVzZXItaW5mbw0KICAgZWxlbWVu dCB0byBiZSBwcmVzZW50IGluIHRoZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24uDQoNCjguMS4z LjMuICBkaXNhYmxlLWRpdmVydGVkLXRvLXVzZXItaW5mbw0KDQogICBUaGlzIGVsZW1lbnQgZ2l2 ZXMgdGhlIHN1YnNjcmliZXIgb3B0aW9uIG9mIGFkZGluZyBkaXZlcnRpbmctdG8tdXNlcg0KICAg aW5mb3JtYXRpb24gdG8gdGhlIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4gIFRoZSBkZWZhdWx0 IHZhbHVlIGlzDQogICBmYWxzZSB3aGljaCBtZWFucyB0aGUgc3Vic2NyaWJlciB3YW50cyB0aGUg ZGl2ZXJ0ZWQtdG8tdXNlci1pbmZvDQogICBlbGVtZW50IHRvIGJlIHByZXNlbnQgaW4gdGhlIG5v dGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4NCg0KDQoNCg0KQXZhc2FyYWxhLCBldCBhbC4gICAgICBF eHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRl cm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAg IE1hcmNoIDIwMTANCg0KDQo4LjEuMy40LiAgZGlzYWJsZS1kaXZlcnNpb24tdGltZS1pbmZvDQoN CiAgIFRoaXMgZWxlbWVudCBnaXZlcyB0aGUgc3Vic2NyaWJlciBvcHRpb24gb2YgYWRkaW5nIGRp dmVyc2lvbi10aW1lDQogICBpbmZvcm1hdGlvbiB0byB0aGUgbm90aWZpY2F0aW9uIGluZm9ybWF0 aW9uLiAgVGhlIGRlZmF1bHQgdmFsdWUgaXMNCiAgIGZhbHNlIHdoaWNoIG1lYW5zIHRoZSBzdWJz Y3JpYmVyIHdhbnRzIHRoZSBkaXZlcnNpb24tdGltZS1pbmZvIHRvIGJlDQogICBwcmVzZW50IGlu IHRoZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24uDQoNCjguMS4zLjUuICBkaXNhYmxlLWRpdmVy c2lvbi1yZWFzb24NCg0KICAgVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBzdWJzY3JpYmVyIG9wdGlv biBvZiBhZGRpbmcgZGl2ZXJzaW9uLXRpbWUNCiAgIGluZm9ybWF0aW9uIHRvIHRoZSBub3RpZmlj YXRpb24gaW5mb3JtYXRpb24uICBUaGUgZGVmYXVsdCB2YWx1ZSBpcw0KICAgZmFsc2Ugd2hpY2gg bWVhbnMgdGhlIHN1YnNjcmliZXIgd2FudHMgdGhlIGRpdmVyc2lvbi1yZWFzb24NCiAgIGluZm9y bWF0aW9uIHRvIGJlIHByZXNlbnQgaW4gdGhlIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4NCg0K OC4xLjMuNi4gIGRpc2FibGUtZGl2ZXJzaW9uLXJ1bGUNCg0KICAgVGhpcyBlbGVtZW50IGdpdmVz IHRoZSBzdWJzY3JpYmVyIG9wdGlvbiBvZiBhZGRpbmcgZGl2ZXJzaW9uLXJ1bGUNCiAgIGluZm9y bWF0aW9uIHRvIHRoZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24uICBUaGUgZGVmYXVsdCB2YWx1 ZSBpcw0KICAgZmFsc2Ugd2hpY2ggbWVhbnMgdGhlIHN1YnNjcmliZXIgd2FudHMgdGhlIGRpdmVy c2lvbi1ydWxlIGluZm9ybWF0aW9uDQogICB0byBiZSBwcmVzZW50IGluIHRoZSBub3RpZmljYXRp b24gaW5mb3JtYXRpb24uDQoNCjguMi4gIFNhbXBsZSBOb3RpZmljYXRpb24gYm9keQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkF2YXNh cmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAgICAgICAgICAgICAg IFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5pY2F0aW9uIERpdmVyc2lv biBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KOC4yLjEuICBJbnN0YW5jZSBvZiBj b21tdW5pY2F0aW9uIGRpdmVyc2lvbiBzdWJzY3JpcHRpb24gZmlsdGVyIGRvY3VtZW50DQoNCg0K ICAgPGNvbW0tZGl2LWluZm8+DQogICAgIDxjb21tLWRpdi1zdWJzLWluZm8+DQogICAgICAgICA8 Y29tbS1kaXYtc2VsZWN0aW9uLWNyaXRlcmlhPg0KICAgICAgICAgICAgPG9yaWdpbmF0aW5nLXVz ZXItc2VsZWN0aW9uLWNyaXRlcmlhPg0KICAgICAgICAgICAgICA8dXNlci1pbmZvPg0KICAgICAg ICAgICAgICAgIDx1c2VyLW5hbWU+Qm9zczwvdXNlci1uYW1lPg0KICAgICAgICAgICAgICAgIDx1 c2VyLVVSST4NCiAgICAgICAgICAgICAgICAgIHNpcDpib3NzQG9mZmljZS5jb20NCiAgICAgICAg ICAgICAgICA8L3VzZXItVVJJPg0KICAgICAgICAgICAgICA8L3VzZXItaW5mbz4NCiAgICAgICAg ICAgIDwvb3JpZ2luYXRpbmctdXNlci1zZWxlY3Rpb24tY3JpdGVyaWE+DQogICAgICAgICAgICA8 ZGl2ZXJzaW9uLXRpbWUtc2VsZWN0aW9uLWNyaXRlcmlhPg0KICAgICAgICAgICAgICA8dGltZS1y YW5nZT4NCiAgICAgICAgICAgICAgIDxzdGFydC10aW1lPjE5OTktMDUtMzFUMTM6MjA6MDAtMDU6 MDBaPC9zdGFydC10aW1lPg0KICAgICAgICAgICAgICAgPGVuZC10aW1lPjIwMDYtMDUtMDZUMTM6 MjA6MDAtMDU6MDBaPC9lbmQtdGltZT4NCiAgICAgICAgICAgICAgPC90aW1lLXJhbmdlPg0KICAg ICAgICAgICAgPC9kaXZlcnNpb24tdGltZS1zZWxlY3Rpb24tY3JpdGVyaWE+DQogICAgICAgICAg ICA8ZGl2ZXJzaW9uLXJlYXNvbi1zZWxlY3Rpb24tY3JpdGVyaWE+DQogICAgICAgICAgICAgIDxk aXZlcnNpb24tcmVhc29uLWluZm8+NDA0IDMwMjwvZGl2ZXJzaW9uLXJlYXNvbi1pbmZvPg0KICAg ICAgICAgICAgPC9kaXZlcnNpb24tcmVhc29uLXNlbGVjdGlvbi1jcml0ZXJpYT4NCiAgICAgICAg ICA8L2NvbW0tZGl2LXNlbGVjdGlvbi1jcml0ZXJpYT4NCiAgICAgICAgICA8Y29tbS1kaXYtbnRm eS10cmlnZ2VyLWNyaXRlcmlhPg0KICAgICAgICAgICAgPG5vdGlmaWNhdGlvbi10aW1lLXNlbGVj dGlvbi1jcml0ZXJpYT4NCiAgICAgICAgICAgICAgPHRpbWUtcmFuZ2U+DQogICAgICAgICAgICAg ICA8c3RhcnQtdGltZT4xOTk5LTA1LTMxVDEzOjIwOjAwLTA1OjAwWjwvc3RhcnQtdGltZT4NCiAg ICAgICAgICAgICAgIDxlbmQtdGltZT4yMDA2LTA1LTA2VDEzOjIwOjAwLTA1OjAwWjwvZW5kLXRp bWU+DQogICAgICAgICAgICAgIDwvdGltZS1yYW5nZT4NCiAgICAgICAgICAgIDwvbm90aWZpY2F0 aW9uLXRpbWUtc2VsZWN0aW9uLWNyaXRlcmlhPg0KICAgICAgICAgIDwvY29tbS1kaXYtbnRmeS10 cmlnZ2VyLWNyaXRlcmlhPg0KICAgICAgPC9jb21tLWRpdi1zdWJzLWluZm8+DQogICA8L2NvbW0t ZGl2LWluZm8+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQXZhc2FyYWxhLCBl dCBhbC4gICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgW1BhZ2Ug MTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlm aWNhdGlvbiAgICAgIE1hcmNoIDIwMTANCg0KDQo4LjIuMi4gIEluc3RhbmNlIG9mIGNvbW11bmlj YXRpb24gZGl2ZXJzaW9uIG5vdGlmaWNhdGlvbiBkb2N1bWVudA0KDQoNCiAgIDxjb21tLWRpdi1p bmZvPg0KICAgICA8Y29tbS1kaXYtbnRmeS1pbmZvPg0KICAgICAgIDxvcmlnaW5hdGluZy11c2Vy LWluZm8+DQogICAgICAgICA8dXNlci1uYW1lPkJvc3M8L3VzZXItbmFtZT4NCiAgICAgICAgIDx1 c2VyLVVSST5zaXA6Ym9zc0BvZmZpY2UuY29tPC91c2VyLVVSST4NCiAgICAgICA8L29yaWdpbmF0 aW5nLXVzZXItaW5mbz4NCiAgICAgICA8ZGl2ZXJ0aW5nLXVzZXItaW5mbz4NCiAgICAgICAgIHNp cDphbGljZUBvZmZpY2UuY29tDQogICAgICAgPC9kaXZlcnRpbmctdXNlci1pbmZvPg0KICAgICAg IDxkaXZlcnRlZC10by11c2VyLWluZm8+DQogICAgICAgICBzaXA6Ym9iQG9mZmljZS5jb20NCiAg ICAgICA8L2RpdmVydGVkLXRvLXVzZXItaW5mbz4NCiAgICAgICA8ZGl2ZXJzaW9uLXRpbWUtaW5m bz4xOTk5LTA2LTAxVDEzOjIwOjAwLTA1OjAwWg0KICAgICAgIDwvZGl2ZXJzaW9uLXRpbWUtaW5m bz4NCiAgICAgICA8ZGl2ZXJzaW9uLXJlYXNvbi1pbmZvPjQwNA0KICAgICA8L2NvbW0tZGl2LW50 ZnktaW5mbz4NCiAgIDwvY29tbS1kaXYtaW5mbz4NCg0KDQo4LjMuICBTY2hlbWENCg0KDQo8P3ht bCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgPz4NCjx4czpzY2hlbWENCiAgdGFyZ2V0 TmFtZXNwYWNlPSJodHRwOi8vdXJpLmV0c2kub3JnL25nbi9wYXJhbXMveG1sL2NvbW0tZGl2LWlu Zm8iDQogIHhtbG5zOnRucz0iaHR0cDovL3VyaS5ldHNpLm9yZy9uZ24vcGFyYW1zL3htbC9jb21t LWRpdi1pbmZvIg0KICB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEi DQogIHhtbG5zPSJodHRwOi8vdXJpLmV0c2kub3JnL25nbi9wYXJhbXMveG1sL2NvbW0tZGl2LWlu Zm8iDQogIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIg0KICBhdHRyaWJ1dGVGb3JtRGVm YXVsdD0idW5xdWFsaWZpZWQiPg0KICA8IS0tDQogIFRoaXMgaW1wb3J0IGJyaW5ncyBpbiB0aGUg WE1MIGxhbmd1YWdlIGRlZmluaXRpb24NCiAgLS0+DQogIDx4czppbXBvcnQgbmFtZXNwYWNlPSJo dHRwOi8vd3d3LnczLm9yZy9YTUwvMTk5OC9uYW1lc3BhY2UiDQogICAgc2NoZW1hTG9jYXRpb249 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDMveG1sLnhzZCIvPg0KICA8IS0tDQogIENvbW11bmlj YXRpb24gRGl2ZXJzaW9uIEluZm9ybWF0aW9uLiBUaGlzIGlzIHRoZSB0b3AtbGV2ZWwgWE1MIGVs ZW1lbnQNCiAgLS0+DQogIDx4czplbGVtZW50IG5hbWU9ImNvbW0tZGl2LWluZm8iDQogICAgdHlw ZT0iY29tbS1kaXYtaW5mby10eXBlIiAvPg0KICA8IS0tDQogIENvbW11bmljYXRpb24gRGl2ZXJz aW9uIEluZm9ybWF0aW9uIFR5cGUuDQogIFRoaXMgaXMgdGhlIHRvcC1sZXZlbCBYTUwgZWxlbWVu dA0KICAtLT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImNvbW0tZGl2LWluZm8tdHlwZSI+DQoN Cg0KDQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEyLCAyMDEwICAg ICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICBTSVAgQ29tbXVuaWNhdGlv biBEaXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAxMA0KDQoNCiAgICA8eHM6c2Vx dWVuY2U+DQogIDx4czplbGVtZW50IG5hbWU9ImNvbW0tZGl2LXN1YnMtaW5mbyINCiAgICAgICAg dHlwZT0iY29tbS1kaXYtc3Vicy1pbmZvLXR5cGUiIG1pbk9jY3Vycz0iMCIgLz4NCiAgICAgIDx4 czplbGVtZW50IG5hbWU9ImNvbW0tZGl2LW50ZnktaW5mbyINCiAgICAgICAgdHlwZT0iY29tbS1k aXYtbnRmeS1pbmZvLXR5cGUiIG1pbk9jY3Vycz0iMCIgLz4NCiAgICAgIDx4czphbnkgbmFtZXNw YWNlPSIjI290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCINCiAgICAgICAgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogICAgPHhzOmF0 dHJpYnV0ZSBuYW1lPSJlbnRpdHkiIHR5cGU9InhzOmFueVVSSSINCiAgICAgIHVzZT0icmVxdWly ZWQiLz4NCiAgPC94czpjb21wbGV4VHlwZT4NCiAgPCEtLS0NCiAgQ29tbXVuaWNhdGlvbiBEaXZl cnNpb24gU3Vic2NyaXB0aW9uIFR5cGUuDQogIFVzZWQgYXQgU3Vic2NyaXB0aW9uIHRpbWUgdG8N CiAgICAgICAgc2VsZWN0IENvbW11bmljYXRpb24gRGl2ZXJzaW9ucyBmb3Igbm90aWZpY2F0aW9u LA0KICAgICAgICB3aGVuIHRvIG5vdGlmeSB0aGVtIGFuZA0KICAgICAgICB3aGF0IHRvIG5vdGlm eS4NCiAgLS0+DQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJjb21tLWRpdi1zdWJzLWluZm8tdHlw ZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iY29tbS1kaXYt c2VsZWN0aW9uLWNyaXRlcmlhIg0KICAgICAgICB0eXBlPSJjb21tLWRpdi1zZWxlY3Rpb24tY3Jp dGVyaWEtdHlwZSINCiAgICAgICAgbWluT2NjdXJzPSIwIiAvPg0KICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iY29tbS1kaXYtbnRmeS10cmlnZ2VyLWNyaXRlcmlhIg0KICAgICAgICB0eXBlPSJjb21t LWRpdi1udGZ5LXRyaWdnZXItY3JpdGVyaWEtdHlwZSINCiAgICAgICAgbWluT2NjdXJzPSIwIiAv Pg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iY29tbS1kaXYtaW5mby1zZWxlY3Rpb24tY3JpdGVy aWEiDQogICAgICAgIHR5cGU9ImNvbW0tZGl2LWluZm8tc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUi DQogICAgICAgIG1pbk9jY3Vycz0iMCIgLz4NCiAgICAgIDx4czphbnkgbmFtZXNwYWNlPSIjI290 aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCINCiAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1 cnM9InVuYm91bmRlZCIvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogICAgPHhzOmFueUF0dHJpYnV0 ZSBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4Ii8+DQogIDwveHM6Y29t cGxleFR5cGU+DQogIDwhLS0tDQogIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlv biBJbmZvcm1hdGlvbiBUeXBlDQogIFVzZWQgd2hpbGUgbm90aWZ5aW5nIHRoZSBVc2VyIGFib3V0 IHRoZSBDb21tdW5pY2F0aW9uIERpdmVyc2lvbg0KICAtLT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5h bWU9ImNvbW0tZGl2LW50ZnktaW5mby10eXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8 eHM6ZWxlbWVudCBuYW1lPSJvcmlnaW5hdGluZy11c2VyLWluZm8iDQogICAgICAgIHR5cGU9InVz ZXItaW5mby10eXBlIiBtaW5PY2N1cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJk aXZlcnRpbmctdXNlci1pbmZvIiB1c2U9Im9wdGlvbmFsIg0KICAgICAgICB0eXBlPSJ4czphbnlV UkkiIG1pbk9jY3Vycz0iMCIgLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImRpdmVydGVkLXRv LXVzZXItaW5mbyINCiAgICAgICAgdHlwZT0ieHM6YW55VVJJIiBtaW5PY2N1cnM9IjAiIC8+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tdGltZS1pbmZvIg0KICAgICAgICB0eXBl PSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiAvPg0KDQoNCg0KQXZhc2FyYWxhLCBldCBhbC4g ICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgW1BhZ2UgMTldDQoM DQpJbnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlv biAgICAgIE1hcmNoIDIwMTANCg0KDQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24t cmVhc29uLWluZm8iDQogICAgICAgIHR5cGU9ImRpdmVyc2lvbi1yZWFzb24taW5mby10eXBlIiBt aW5PY2N1cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tcnVsZS1p bmZvIg0KICAgICAgICB0eXBlPSJkaXZlcnNpb24tcnVsZS1pbmZvLXR5cGUiIG1pbk9jY3Vycz0i MCIgLz4NCiAgICAgIDx4czphbnkgbmFtZXNwYWNlPSIjI290aGVyIiBwcm9jZXNzQ29udGVudHM9 ImxheCINCiAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAg IDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQogIDwhLS0NCiAgQ09NTVVOSUNB VElPTiBESVZFUlNJT04gU0VMRUNUSU9OIENSSVRFUklBDQogIC0tPg0KICA8eHM6Y29tcGxleFR5 cGUgbmFtZT0iY29tbS1kaXYtc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUiPg0KICAgIDx4czpzZXF1 ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9Im9yaWdpbmF0aW5nLXVzZXItc2VsZWN0aW9u LWNyaXRlcmlhIg0KICAgICAgICB0eXBlPSJ1c2VyLXNlbGVjdGlvbi1jcml0ZXJpYS10eXBlIiBt aW5PY2N1cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnRpbmctdXNlci1z ZWxlY3Rpb24tY3JpdGVyaWEiDQogICAgICAgIHR5cGU9InhzOmFueVVSSSIgbWluT2NjdXJzPSIw IiAvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGl2ZXJ0ZWQtdG8tdXNlci1zZWxlY3Rpb24t Y3JpdGVyaWEiDQogICAgICAgIHR5cGU9InhzOmFueVVSSSIgbWluT2NjdXJzPSIwIiAvPg0KICAg ICAgPHhzOmVsZW1lbnQgbmFtZT0iZGl2ZXJzaW9uLXRpbWUtc2VsZWN0aW9uLWNyaXRlcmlhIg0K ICAgICAgICB0eXBlPSJ0aW1lLXJhbmdlLXNlbGVjdGlvbi1jcml0ZXJpYS10eXBlIg0KICAgICAg ICBtaW5PY2N1cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tcmVh c29uLXNlbGVjdGlvbi1jcml0ZXJpYSINCiAgICAgICAgdHlwZT0iZGl2ZXJzaW9uLXJlYXNvbi1z ZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSINCiAgICAgICAgbWluT2NjdXJzPSIwIiAvPg0KICAgICAg PHhzOmFueSBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4Ig0KICAgICAg ICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgPC94czpzZXF1ZW5j ZT4NCiAgPC94czpjb21wbGV4VHlwZT4NCiAgPCEtLQ0KICBDT01NVU5JQ0FUSU9OIERJVkVSU0lP TiBOT1RJRklDQVRJT04gVFJJR0dFUiBDUklURVJJQQ0KICAtLT4NCiAgPHhzOmNvbXBsZXhUeXBl IG5hbWU9ImNvbW0tZGl2LW50ZnktdHJpZ2dlci1jcml0ZXJpYS10eXBlIj4NCiAgICA8eHM6c2Vx dWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJub3RpZmljYXRpb24tdGltZS1zZWxlY3Rp b24tY3JpdGVyaWEiDQogICAgICAgIHR5cGU9InRpbWUtcmFuZ2Utc2VsZWN0aW9uLWNyaXRlcmlh LXR5cGUiDQogICAgICAgIG1pbk9jY3Vycz0iMCIgLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9 InByZXNlbmNlLXN0YXR1cy1zZWxlY3Rpb24tY3JpdGVyaWEiDQogICAgICAgIHR5cGU9InByZXNl bmNlLXN0YXR1cy1zZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSINCiAgICAgICAgbWluT2NjdXJzPSIw IiAvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9uLWJ1ZmZlci1pbnRlcnZh bCINCiAgICAgIG1pbk9jY3Vycz0iMCIgZGVmYXVsdD0iODY0MDAiPg0KICAgICAgICA8eHM6c2lt cGxlVHlwZT4NCiAgICAgICAgICA8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6aW50ZWdlciI+DQog ICAgICA8eHM6bWF4SW5jbHVzaXZlIHZhbHVlPSI4NjQwMCIvPg0KICAgICAgICAgIDwveHM6cmVz dHJpY3Rpb24+DQogICAgICAgIDwveHM6c2ltcGxlVHlwZT4NCiAgICAgIDwveHM6ZWxlbWVudD4N Cg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAg ICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5pY2F0 aW9uIERpdmVyc2lvbiBOb3RpZmljYXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KICAgICAgPHhz OmFueSBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4Ig0KICAgICAgICBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgPC94czpzZXF1ZW5jZT4N CiAgIDwveHM6Y29tcGxleFR5cGU+DQogIDwhLS0NCiAgQ09NTVVOSUNBVElPTiBESVZFUlNJT04g SU5GT1JNQVRJT04gU0VMRUNUSU9OIENSSVRFUklBDQogIC0tPg0KICA8eHM6Y29tcGxleFR5cGUg bmFtZT0iY29tbS1kaXYtaW5mby1zZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSI+DQogICAgPHhzOnNl cXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGlzYWJsZS1vcmlnaW5hdGluZy11c2Vy LWluZm8iDQogICAgICAgIHR5cGU9InhzOmJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNlIiBtaW5PY2N1 cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXNhYmxlLWRpdmVydGluZy11c2Vy LWluZm8iDQogICAgICAgIHR5cGU9InhzOmJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNlIiBtaW5PY2N1 cnM9IjAiIC8+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXNhYmxlLWRpdmVydGVkLXRvLXVz ZXItaW5mbyINCiAgICAgICAgdHlwZT0ieHM6Ym9vbGVhbiIgZGVmYXVsdD0iZmFsc2UiIG1pbk9j Y3Vycz0iMCIgLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImRpc2FibGUtZGl2ZXJzaW9uLXRp bWUtaW5mbyINCiAgICAgICAgdHlwZT0ieHM6Ym9vbGVhbiIgZGVmYXVsdD0iZmFsc2UiIG1pbk9j Y3Vycz0iMCIgLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9ImRpc2FibGUtZGl2ZXJzaW9uLXJl YXNvbi1pbmZvIg0KICAgICAgICB0eXBlPSJ4czpib29sZWFuIiBkZWZhdWx0PSJmYWxzZSIgbWlu T2NjdXJzPSIwIiAvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZGlzYWJsZS1kaXZlcnNpb24t cnVsZS1pbmZvIg0KICAgICAgICB0eXBlPSJ4czpib29sZWFuIiBkZWZhdWx0PSJmYWxzZSIgbWlu T2NjdXJzPSIwIiAvPg0KICAgICAgPHhzOmFueSBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3ND b250ZW50cz0ibGF4Ig0KICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVk Ii8+DQogICAgPC94czpzZXF1ZW5jZT4NCiAgIDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPCEtLSBV c2VyIEluZm8gVHlwZSAtLT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InVzZXItaW5mby10eXBl Ij4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ1c2VyLW5hbWUi IHR5cGU9InhzOnN0cmluZyINCiAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ1c2VyLVVSSSIgdHlwZT0ieHM6YW55VVJJIi8+DQogICAg PC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8IS0tDQogIERJVkVSU0lP TiBSRUFTT04gSU5GTw0KICAtLT4NCg0KICAgIDx4czpzaW1wbGVUeXBlIG5hbWU9ImRpdmVyc2lv bi1yZWFzb24taW5mby10eXBlcyI+DQogICAgICAgIDx4czpsaXN0IGl0ZW1UeXBlPSJkaXZlcnNp b24tcmVhc29uLWluZm8tdHlwZSIvPg0KICAgIDwveHM6c2ltcGxlVHlwZT4NCiAgPHhzOnNpbXBs ZVR5cGUgbmFtZT0iZGl2ZXJzaW9uLXJlYXNvbi1pbmZvLXR5cGUiPg0KICAgICAgICA8eHM6cmVz dHJpY3Rpb24gYmFzZT0ieHM6aW50ZWdlciI+DQogICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24g dmFsdWU9IjQwNCIvPg0KICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSI0ODYiLz4N CiAgICAgICAgICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iNDA4Ii8+DQogICAgICAgICAgICA8 eHM6ZW51bWVyYXRpb24gdmFsdWU9IjMwMiIvPg0KDQoNCg0KQXZhc2FyYWxhLCBldCBhbC4gICAg ICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbiAg ICAgIE1hcmNoIDIwMTANCg0KDQogICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IjQ4 NyIvPg0KICAgICAgICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSI0ODAiLz4NCiAgICAgICAg ICAgIDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iNTAzIi8+DQogICAgICAgIDwveHM6cmVzdHJpY3Rp b24+DQogIDwveHM6c2ltcGxlVHlwZT4NCiAgPCEtLQ0KICBESVZFUlNJT04gUlVMRSBJTkZPDQog IC0tPg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iZGl2ZXJzaW9uLXJ1bGUtaW5mby10eXBlIj4N CiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tcnVs ZSIgdHlwZT0ieHM6c3RyaW5nIi8+DQogICAgPC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4 VHlwZT4NCiAgPCEtLQ0KICBPUklHSU5BVElORyBVU0VSIFNFTEVDVElPTiBDUklURVJJQQ0KICAt LT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InVzZXItc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUi Pg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InVzZXItaW5mbyIN CiAgICAgICAgdHlwZT0idXNlci1pbmZvLXR5cGUiIG1pbk9jY3Vycz0iMCINCiAgICAgICAgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiIC8+DQogICAgPC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4 VHlwZT4NCiAgPCEtLQ0KICBESVZFUlNJT04gUkVBU09OIFNFTEVDVElPTiBDUklURVJJQQ0KICAt LT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImRpdmVyc2lvbi1yZWFzb24tc2VsZWN0aW9uLWNy aXRlcmlhLXR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9 ImRpdmVyc2lvbi1yZWFzb24taW5mbyINCiAgICAgICAgdHlwZT0iZGl2ZXJzaW9uLXJlYXNvbi1p bmZvLXR5cGVzIi8+DQogICAgPC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4VHlwZT4NCiAg PCEtLQ0KICBUSU1FIFJBTkdFIFNFTEVDVElPTiBDUklURVJJQQ0KICAtLT4NCiAgPHhzOmNvbXBs ZXhUeXBlIG5hbWU9InRpbWUtcmFuZ2Utc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUiPg0KICAgIDx4 czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9InRpbWUtcmFuZ2UiDQogICAgdHlw ZT0idGltZS1yYW5nZS10eXBlIiBtaW5PY2N1cnM9IjAiDQogICAgICAgIG1heE9jY3Vycz0idW5i b3VuZGVkIiAvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQogIDwh LS0NCiAgVElNRSBSQU5HRSBJTkZPDQogIC0tPg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0idGlt ZS1yYW5nZS10eXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6ZWxlbWVudCBuYW1l PSJzdGFydC10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSIgLz4NCg0KDQoNCkF2YXNhcmFsYSwgZXQg YWwuICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAgICAgICAgICAgICAgIFtQYWdlIDIy XQ0KDA0KSW50ZXJuZXQtRHJhZnQgIFNJUCBDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBOb3RpZmlj YXRpb24gICAgICBNYXJjaCAyMDEwDQoNCg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iZW5kLXRp bWUiIHR5cGU9InhzOmRhdGVUaW1lIiAvPg0KICAgIDwveHM6c2VxdWVuY2U+DQogIDwveHM6Y29t cGxleFR5cGU+DQogIDwhLS0NCiAgUFJFU0VOQ0UgU1RBVFVTIFNFTEVDVElPTiBDUklURVJJQQ0K ICAtLT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InByZXNlbmNlLXN0YXR1cy1zZWxlY3Rpb24t Y3JpdGVyaWEtdHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFt ZT0icHJlc2VuY2Utc3RhdHVzLWluZm8iDQogICAgICAgIHR5cGU9InByZXNlbmNlLXN0YXR1cy1p bmZvLXR5cGUiIG1pbk9jY3Vycz0iMCINCiAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiIC8+ DQogICAgPC94czpzZXF1ZW5jZT4NCiAgPC94czpjb21wbGV4VHlwZT4NCiAgPCEtLQ0KICBQUkVT RU5DRSBTVEFUVVMgSU5GTw0KICAtLT4NCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9InByZXNlbmNl LXN0YXR1cy1pbmZvLXR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50 IG5hbWU9InByZXNlbmNlLXN0YXR1cyIgdHlwZT0ieHM6c3RyaW5nIiAvPg0KICAgIDwveHM6c2Vx dWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQo8L3hzOnNjaGVtYT4NCg0KDQoNCjkuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBBdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBvZiBzdWJzY3JpcHRpb25zIGhhdmUgYmVlbiBkaXNjdXNzZWQNCiAgIGluIFNlY3Rpb24gNi42 LiAgTGFjayBvZiBhdXRoZW50aWNhdGlvbiBvciBhdXRob3JpemF0aW9uIG1heSBwcm92aWRlDQog ICBjb21tLWRpdi1pbmZvIGluZm9ybWF0aW9uIHRvIHVuYXV0aG9yaXplZCBwYXJ0aWVzIGFuZCBj YW4gcmV2ZWFsDQogICBzZW5zaXRpdmUgaW5mb3JtYXRpb24gd2l0aCByZWdhcmRzIHRvIHRoZSB1 c2VyJ3MgY2FsbCByZWNlaXZpbmcNCiAgIHBhdHRlcm5zLiAgRm9yIGV4YW1wbGUsIHdobyBjYWxs cyB0aGUgdXNlciBhbmQgYXQgd2hhdCB0aW1lLCBldGMuDQoNCiAgIEludGVncml0eSBwcm90ZWN0 aW9uIGFuZCBjb25maWRlbnRpYWxpdHkgb2Ygbm90aWZpY2F0aW9ucyBhcmUgYWxzbw0KICAgZGlz Y3Vzc2VkIGluIFNlY3Rpb24gNi43LiAgSWYgYSBub3RpZmllciBkb2VzIG5vdCBlbmNyeXB0IGJv ZGllcyBvZg0KICAgTk9USUZZIHJlcXVlc3RzLCBhbiBlYXZlc2Ryb3BwZXIgY291bGQgbGVhcm4g dGhlIHN0YXR1cyBvZiBhIFNJUCB1c2VyDQogICBhZ2VudCBhbmQgdXNlIGl0IHRvIGNyZWF0ZSBt YWxpY2lvdXMgc2Vzc2lvbnMuICBJZiB0aGUgbm90aWZpZXIgZG9lcw0KICAgbm90IGludGVncml0 eSBwcm90ZWN0IHRoZSBib2RpZXMgb2YgTk9USUZZIHJlcXVlc3RzLCBhIG1hbi1pbi0gdGhlLQ0K ICAgbWlkZGxlIGF0dGFja2VyIG9yIG1hbGljaW91cyBTSVAgcHJveHkgY291bGQgbW9kaWZ5IHRo ZSBjb250ZW50cyBvZg0KICAgdGhlIGNvbW0tZGl2LWluZm8gZXZlbnQgcGFja2FnZSBub3RpZmlj YXRpb24uICBBbHRob3VnaCB0aGlzIGRvZXMgbm90DQogICBjYXVzZSBoYXJtLCBpdCBjYW4gY3Jl YXRlIGFubm95YW5jZXMuDQoNCg0KMTAuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMg ZG9jdW1lbnQgcmVnaXN0ZXJzIHRoZSBuZXcgU0lQIEV2ZW50IFBhY2thZ2UuDQoNCg0KDQoNCg0K QXZhc2FyYWxhLCBldCBhbC4gICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAg ICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2 ZXJzaW9uIE5vdGlmaWNhdGlvbiAgICAgIE1hcmNoIDIwMTANCg0KDQoxMC4xLiAgQ29tbXVuaWNh dGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24gRXZlbnQgUGFja2FnZSBSZWdpc3RyYXRpb24NCg0K DQogICBQYWNrYWdlIE5hbWU6IENvbW0tZGl2LWluZm8NCg0KICAgVHlwZTogUGFja2FnZQ0KDQog ICBDb250YWN0OiAgSm9uIE1lcmRpdGgsIDxKb2huLm1lcmVkaXRoQDNncHAub3JnPg0KDQogICBQ dWJsaXNoZWQgU3BlY2lmaWNhdGlvbjogUkZDIFhYWFggKE5vdGUgdG8gUkZDIEVkaXRvcikNCg0K DQoNCjExLiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRv IHRoYW5rIFNhbWlyIFNha2xpa2FyIGZvciBlZGl0aW5nIGFuZCBiZWluZw0KICAgcGFydCBvZiB0 aGUgaW5pdGlhbCB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQgYW5kIEJhbiBBbC1CYWtyaSwgUm9sYW5k DQogICBKZXNza2UsIEpvc2UgTWlndWVsIFRvcnJlcywgUGF1bCBLeXppdmF0LCBKb2huIEVsd2Vs bCAsIEtlaXRoIERyYWdlICwNCiAgIEdvbnphbG8gQ2FtYXJpbGxvIGFuZCBEZWFuIFdpbGxpcyBm b3IgdGhlaXIgdmFsdWFibGUgY29tbWVudHMgYW5kDQogICBzdWdnZXN0aW9ucy4NCg0KDQoxMi4g IFJlZmVyZW5jZXMNCg0KMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgIDNH UFAsICJDb21tdW5pY2F0aW9uIERpdmVyc2lvbiAoQ0RJVikgdXNpbmcgSVAgTXVsdGltZWRpYQ0K ICAgICAgICAgKElNKUNvcmUgTmV0d29yayAoQ04pIHN1YnN5c3RlbTsgIFByb3RvY29sIHNwZWNp ZmljYXRpb24iLCAzR1BQDQogICAgICAgICBUUyAyNC42MDQgOC42LjAsIERlY2VtYmVyIDIwMDku DQoNCiAgIFsyXSAgIDNHUFAsICJUSVNQQU47IFBTVE4vSVNETiBzaW11bGF0aW9uIHNlcnZpY2Vz OiBDb21tdW5pY2F0aW9uDQogICAgICAgICBEaXZlcnNpb24gKENESVYpOyBQcm90b2NvbCBzcGVj aWZpY2F0aW9uIiwgM0dQUCBUUyAyNC40MDQNCiAgICAgICAgIDcuNS4wLCBKdW5lIDIwMDkuDQoN CiAgIFszXSAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZSBSZXF1aXJlbWVudA0KICAgICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFy Y2ggMTk5Ny4NCg0KICAgWzRdICAgTWFua2luLCBBLiwgQnJhZG5lciwgUy4sIE1haHksIFIuLCBX aWxsaXMsIEQuLCBPdHQsIEouLCBhbmQgQi4NCiAgICAgICAgIFJvc2VuLCAiQ2hhbmdlIFByb2Nl c3MgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCiAgICAgICAgIChTSVApIiwg UkZDIDM0MjcsIERlY2VtYmVyIDIwMDIuDQoNCiAgIFs1XSAgIFJvc2VuYmVyZywgSi4sIFNjaHVs enJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwgSm9obnN0b24sIEEuLA0KICAgICAgICAgUGV0ZXJz b24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiwgYW5kIEUuIFNjaG9vbGVyLCAiU0lQOg0K ICAgICAgICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAw Mi4NCg0KICAgWzZdICAgUm9hY2gsIEEuLCAiU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApLVNwZWNpZmljIEV2ZW50DQogICAgICAgICBOb3RpZmljYXRpb24iLCBSRkMgMzI2NSwgSnVu ZSAyMDAyLg0KDQoNCg0KDQpBdmFzYXJhbGEsIGV0IGFsLiAgICAgIEV4cGlyZXMgU2VwdGVtYmVy IDEyLCAyMDEwICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICBTSVAg Q29tbXVuaWNhdGlvbiBEaXZlcnNpb24gTm90aWZpY2F0aW9uICAgICAgTWFyY2ggMjAxMA0KDQoN CjEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFs3XSAgIDNHUFAsICJJbnRlcm5l dCBQcm90b2NvbCAoSVApIG11bHRpbWVkaWEgY2FsbCBjb250cm9sIHByb3RvY29sDQogICAgICAg ICBiYXNlZCBvbiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgYW5kIFNlc3Npb24N CiAgICAgICAgIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApOyBTdGFnZSAzIiwgM0dQUCBUUyAy NC4yMjkgNS4yMy4wLA0KICAgICAgICAgU2VwdGVtYmVyIDIwMDkuDQoNCiAgIFs4XSAgIEJyYXks IFQuLCBTcGVyYmVyZy1NY1F1ZWVuLCBDLiwgTWFsZXIsIEUuLCBhbmQgSi4gUGFvbGksDQogICAg ICAgICAiRXh0ZW5zaWJsZSBNYXJrdXAgTGFuZ3VhZ2UgKFhNTCkgMS4wIChTZWNvbmQgRWRpdGlv bikiLCBXb3JsZA0KICAgICAgICAgV2lkZSBXZWIgQ29uc29ydGl1bSBGaXJzdEVkaXRpb24gUkVD LXhtbC0yMDAwMTAwNiwNCiAgICAgICAgIE9jdG9iZXIgMjAwMCwgPGh0dHA6Ly93d3cudzMub3Jn L1RSLzIwMDAvUkVDLXhtbC0yMDAwMTAwNj4uDQoNCiAgIFs5XSAgIFNjaHVsenJpbm5lLCBILiwg VHNjaG9mZW5pZywgSC4sIE1vcnJpcywgSi4sIEN1ZWxsYXIsIEouLCBQb2xrLA0KICAgICAgICAg Si4sIGFuZCBKLiBSb3NlbmJlcmcsICJDb21tb24gUG9saWN5OiBBIERvY3VtZW50IEZvcm1hdCBm b3INCiAgICAgICAgIEV4cHJlc3NpbmcgUHJpdmFjeSBQcmVmZXJlbmNlcyIsIFJGQyA0NzQ1LCBG ZWJydWFyeSAyMDA3Lg0KDQogICBbMTBdICBHYXJjaWEtTWFydGluLCBNLiwgSGVucmlrc29uLCBF LiwgYW5kIEQuIE1pbGxzLCAiUHJpdmF0ZSBIZWFkZXINCiAgICAgICAgIChQLUhlYWRlcikgRXh0 ZW5zaW9ucyB0byB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApDQogICAgICAg ICBmb3IgdGhlIDNyZC1HZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIiwgUkZD IDM0NTUsDQogICAgICAgICBKYW51YXJ5IDIwMDMuDQoNCg0KQXBwZW5kaXggQS4gIENoYW5nZSBs b2cNCg0KDQogICBbUkZDIEVESVRPUiBOT1RFOiBQbGVhc2UgcmVtb3ZlIHRoaXMgc2VjdGlvbiB3 aGVuIHB1Ymxpc2hpbmddDQoNCg0KICAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWF2YXNhcmFsYS1kaXNw YXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMDMNCg0KICAgbyAgQWRkZWQgU3RhdGUgaW5mb3Jt YXRpb24gdG8gTm90aWZpZXJzLg0KDQogICBvICBFbmhhbmNlZCBkaXZlcnRpbmctdXNlci1pbmZv IGVsZW1lbnQgZGVmaW5pdGlvbi4NCg0KICAgQ2hhbmdlcyBmcm9tIGRyYWZ0LWF2YXNhcmFsYS1k aXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMDINCg0KICAgbyAgTW9kaWZpZWQgdGh3IGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50IHRvIG1ha2UgaXQgbW9yZSBJTVMgc3BlY2lmaWMuDQoNCiAg IG8gIEFkZGVkIGEgZGVmaW5pdGlvbiBmb3IgSU1TIENvcmUgbmV0d29yay4NCg0KICAgbyAgVXBk YXRlZCBhdXRob3JzIGxpc3QgYW5kIEFja25vd2xlZGdlbWVudCBzZWN0aW9ucy4NCg0KICAgQ2hh bmdlcyBmcm9tIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24t MDENCg0KICAgbyAgSW5jb3Jwb3JhdGVkIHJldmlldyBjb21tZW50cy4NCg0KICAgbyAgTW9kaWZp ZWQgY29udGFjdCBkZXRhaWxzIGZvciBjbyBhdXRob3IgU3ViaXIgU2FoYS4NCg0KDQoNCg0KQXZh c2FyYWxhLCBldCBhbC4gICAgICBFeHBpcmVzIFNlcHRlbWJlciAxMiwgMjAxMCAgICAgICAgICAg ICAgW1BhZ2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgU0lQIENvbW11bmljYXRpb24gRGl2ZXJz aW9uIE5vdGlmaWNhdGlvbiAgICAgIE1hcmNoIDIwMTANCg0KDQogICBDaGFuZ2VzIGZyb20gZHJh ZnQtYXZhc2FyYWxhLXNpcHBpbmctY29tbS1kaXYtbm90aWZpY2F0aW9uLTAwDQoNCiAgIG8gIENo YW5nZWQgY29udGFjdCBkZXRhaWxzIG9mIGNvIGF1dGhvciBTdWJpciBTYWhhLg0KDQogICBvICBN b3ZlZCBmcm9tIFNJUFBJTkcgdG8gRElTUEFUQ0ggV0cuDQoNCiAgIENoYW5nZXMgZnJvbSBkcmFm dC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTAwDQoNCiAgIG8gIEFk ZGVkIGNvbW0tZGl2LWluZm8gZG9jdW1lbnQgc3RydWN0dXJlIGluZm9ybWF0aW9uIGFuZCBzY2hl bWEgZm9yDQogICAgICB0aGUgZXZlbnQgcGFja2FnZS4NCg0KICAgbyAgQWRkZWQgbW9yZSBlbGFi b3JhdGUgZGVzY3JpcHRpb24gZm9yIHZhcmlvdXMgc2VjdGlvbnMgaW4gY29tbS1kaXYtDQogICAg ICBpbmZvIGRvY3VtZW50DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFJhbmppdCBBdmFz YXJhbGEgKGVkaXRvcikNCiAgIE1vdG9yb2xhIEluZGlhIFB2dCBMdGQNCiAgIEJhZ2FtYW5lIFRl Y2ggUGFyaywgQyBWIFJhbWFuIE5hZ2FyDQogICBCYW5nYWxvcmUgIDU2MDA5Mw0KICAgSW5kaWEN Cg0KICAgRW1haWw6IHJhbmppdEBtb3Rvcm9sYS5jb20NCg0KDQogICBKb2huIEx1YyBCYWtrZXIN CiAgIFJlc2VhcmNoIGluIE1vdGlvbiBDb3Jwb3JhdGlvbg0KICAgNTAwMCBSaXZlcnNpZGUgRHJp dmUsIEJ1aWxkaW5nIDYsIFN1aXRlIDEwMA0KICAgSXJ2aW5nLCBUZXhhcyAgNzUwMzkNCiAgIFVT QQ0KDQogICBFbWFpbDogamJha2tlckByaW0uY29tDQoNCg0KICAgU3ViaXIgU2FoYQ0KICAgQ0VP IFJJVCBTb2x1dGlvbnMNCiAgIEItNjAyLCBTYWxhcnB1cmlhIFNpbHZlcndvb2QsIEMgViBSYW1h biBOYWdhcg0KICAgQmFuZ2Fsb3JlICA1NjAwOTMNCiAgIEluZGlhDQoNCiAgIEVtYWlsOiBkcnN1 Ymlyc2FoYUB5YWhvby5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCkF2YXNhcmFsYSwgZXQgYWwuICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTIsIDIwMTAgICAgICAgICAgICAgIFtQYWdlIDI2XQ0KDA0K DQo= ------_=_NextPart_001_01CAC146.2C9B8DFB Content-Type: text/html; name="draft-avasarala-dispatch-comm-div-notification-04.html" Content-Transfer-Encoding: base64 Content-Description: draft-avasarala-dispatch-comm-div-notification-04.html Content-Disposition: attachment; filename="draft-avasarala-dispatch-comm-div-notification-04.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+PC90aXRsZT4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPgo8bWV0YSBuYW1lPSJkZXNjcmlw dGlvbiIgY29udGVudD0iIj4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJ4bWwycmZj IHYxLjM0IChodHRwOi8veG1sLnJlc291cmNlLm9yZy8pIj4KPHN0eWxlIHR5cGU9J3RleHQvY3Nz Jz48IS0tCiAgICAgICAgYm9keSB7CiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogdmVyZGFu YSwgY2hhcmNvYWwsIGhlbHZldGljYSwgYXJpYWwsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAg ICBmb250LXNpemU6IHNtYWxsOyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsK ICAgICAgICAgICAgICAgIG1hcmdpbjogMmVtOwogICAgICAgIH0KICAgICAgICBoMSwgaDIsIGgz LCBoNCwgaDUsIGg2IHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBoZWx2ZXRpY2EsIG1v bmFjbywgIk1TIFNhbnMgU2VyaWYiLCBhcmlhbCwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAg IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7CiAgICAgICAgfQogICAgICAg IGgxIHsgY29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyB0ZXh0LWFs aWduOiByaWdodDsgfQogICAgICAgIGgzIHsgY29sb3I6ICMzMzM7IGJhY2tncm91bmQtY29sb3I6 IHRyYW5zcGFyZW50OyB9CgogICAgICAgIHRkLlJGQ2J1ZyB7CiAgICAgICAgICAgICAgICBmb250 LXNpemU6IHgtc21hbGw7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICAgICAgICAgIHdp ZHRoOiAzMHB4OyBoZWlnaHQ6IDMwcHg7IHBhZGRpbmctdG9wOiAycHg7CiAgICAgICAgICAgICAg ICB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB2ZXJ0aWNhbC1hbGlnbjogbWlkZGxlOwogICAgICAgICAg ICAgICAgYmFja2dyb3VuZC1jb2xvcjogIzAwMDsKICAgICAgICB9CiAgICAgICAgdGQuUkZDYnVn IHNwYW4uUkZDIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBtb25hY28sIGNoYXJjb2Fs LCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlm OwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiAjNjY2OwogICAgICAg IH0KICAgICAgICB0ZC5SRkNidWcgc3Bhbi5ob3RUZXh0IHsKICAgICAgICAgICAgICAgIGZvbnQt ZmFtaWx5OiBjaGFyY29hbCwgbW9uYWNvLCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0 aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IG5v cm1hbDsgdGV4dC1hbGlnbjogY2VudGVyOyBjb2xvcjogI0ZGRjsKICAgICAgICB9CgogICAgICAg IHRhYmxlLlRPQ2J1ZyB7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1cHg7IH0KICAgICAgICB0ZC5U T0NidWcgewogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjogY2VudGVyOyB3aWR0aDogMzBweDsg aGVpZ2h0OiAxNXB4OwogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29s b3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIHRkLlRPQ2J1ZyBhIHsKICAgICAgICAgICAgICAg IGZvbnQtZmFtaWx5OiBtb25hY28sIGNoYXJjb2FsLCBnZW5ldmEsICJNUyBTYW5zIFNlcmlmIiwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7 IGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgICAgICAg ICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OwogICAgICAgIH0K CiAgICAgICAgdGQuaGVhZGVyIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBhcmlhbCwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IHgtc21hbGw7CiAgICAgICAgICAgICAg ICB2ZXJ0aWNhbC1hbGlnbjogdG9wOyB3aWR0aDogMzMlOwogICAgICAgICAgICAgICAgY29sb3I6 ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM2NjY7CiAgICAgICAgfQogICAgICAgIHRkLmF1dGhv ciB7IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXNpemU6IHgtc21hbGw7IG1hcmdpbi1sZWZ0OiA0 ZW07IH0KICAgICAgICB0ZC5hdXRob3ItdGV4dCB7IGZvbnQtc2l6ZTogeC1zbWFsbDsgfQoKICAg ICAgICAvKiBpbmZvIGNvZGUgZnJvbSBTYW50YUtsYXVzcyBhdCBodHRwOi8vd3d3Lm1hZGFib3V0 c3R5bGUuY29tL3Rvb2x0aXAyLmh0bWwgKi8KICAgICAgICBhLmluZm8gewogICAgICAgICAgICAg ICAgLyogVGhpcyBpcyB0aGUga2V5LiAqLwogICAgICAgICAgICAgICAgcG9zaXRpb246IHJlbGF0 aXZlOwogICAgICAgICAgICAgICAgei1pbmRleDogMjQ7CiAgICAgICAgICAgICAgICB0ZXh0LWRl Y29yYXRpb246IG5vbmU7CiAgICAgICAgfQogICAgICAgIGEuaW5mbzpob3ZlciB7CiAgICAgICAg ICAgICAgICB6LWluZGV4OiAyNTsKICAgICAgICAgICAgICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjOTAwOwogICAgICAgIH0KICAgICAgICBhLmluZm8gc3BhbiB7IGRpc3BsYXk6 IG5vbmU7IH0KICAgICAgICBhLmluZm86aG92ZXIgc3Bhbi5pbmZvIHsKICAgICAgICAgICAgICAg IC8qIFRoZSBzcGFuIHdpbGwgZGlzcGxheSBqdXN0IG9uIDpob3ZlciBzdGF0ZS4gKi8KICAgICAg ICAgICAgICAgIGRpc3BsYXk6IGJsb2NrOwogICAgICAgICAgICAgICAgcG9zaXRpb246IGFic29s dXRlOwogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbGVyOwogICAgICAgICAgICAgICAg dG9wOiAyZW07IGxlZnQ6IC01ZW07IHdpZHRoOiAxNWVtOwogICAgICAgICAgICAgICAgcGFkZGlu ZzogMnB4OyBib3JkZXI6IDFweCBzb2xpZCAjMzMzOwogICAgICAgICAgICAgICAgY29sb3I6ICM5 MDA7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBs ZWZ0OwogICAgICAgIH0KCiAgICAgICAgYSB7IGZvbnQtd2VpZ2h0OiBib2xkOyB9CiAgICAgICAg YTpsaW5rICAgIHsgY29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyB9 CiAgICAgICAgYTp2aXNpdGVkIHsgY29sb3I6ICM2MzM7IGJhY2tncm91bmQtY29sb3I6IHRyYW5z cGFyZW50OyB9CiAgICAgICAgYTphY3RpdmUgIHsgY29sb3I6ICM2MzM7IGJhY2tncm91bmQtY29s b3I6IHRyYW5zcGFyZW50OyB9CgogICAgICAgIHAgeyBtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4t cmlnaHQ6IDJlbTsgfQogICAgICAgIHAuY29weXJpZ2h0IHsgZm9udC1zaXplOiB4LXNtYWxsOyB9 CiAgICAgICAgcC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdodDogYm9sZDsgbWFy Z2luLWxlZnQ6IDNlbTsgfQogICAgICAgIHRhYmxlLnRvYyB7IG1hcmdpbjogMCAwIDAgM2VtOyBw YWRkaW5nOiAwOyBib3JkZXI6IDA7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRvcDsgfQogICAgICAg IHRkLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0OiBib2xkOyB2ZXJ0aWNhbC1h bGlnbjogdGV4dC10b3A7IH0KCiAgICAgICAgb2wudGV4dCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1h cmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgdWwudGV4dCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1h cmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgbGkgICAgICB7IG1hcmdpbi1sZWZ0OiAzZW07IH0K CiAgICAgICAgLyogUkZDLTI2MjkgPHNwYW54PnMgYW5kIDxhcnR3b3JrPnMuICovCiAgICAgICAg ZW0gICAgIHsgZm9udC1zdHlsZTogaXRhbGljOyB9CiAgICAgICAgc3Ryb25nIHsgZm9udC13ZWln aHQ6IGJvbGQ7IH0KICAgICAgICBkZm4gICAgeyBmb250LXdlaWdodDogYm9sZDsgZm9udC1zdHls ZTogbm9ybWFsOyB9CiAgICAgICAgY2l0ZSAgIHsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgZm9udC1z dHlsZTogbm9ybWFsOyB9CiAgICAgICAgdHQgICAgIHsgY29sb3I6ICMwMzY7IH0KICAgICAgICB0 dCwgcHJlLCBwcmUgZGZuLCBwcmUgZW0sIHByZSBjaXRlLCBwcmUgc3BhbiB7CiAgICAgICAgICAg ICAgICBmb250LWZhbWlseTogIkNvdXJpZXIgTmV3IiwgQ291cmllciwgbW9ub3NwYWNlOyBmb250 LXNpemU6IHNtYWxsOwogICAgICAgIH0KICAgICAgICBwcmUgewogICAgICAgICAgICAgICAgdGV4 dC1hbGlnbjogbGVmdDsgcGFkZGluZzogNHB4OwogICAgICAgICAgICAgICAgY29sb3I6ICMwMDA7 IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7CiAgICAgICAgfQogICAgICAgIHByZSBkZm4gIHsgY29s b3I6ICM5MDA7IH0KICAgICAgICBwcmUgZW0gICB7IGNvbG9yOiAjNjZGOyBiYWNrZ3JvdW5kLWNv bG9yOiAjRkZDOyBmb250LXdlaWdodDogbm9ybWFsOyB9CiAgICAgICAgcHJlIC5rZXkgeyBjb2xv cjogIzMzQzsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0KICAgICAgICBwcmUgLmlkICB7IGNvbG9yOiAj OTAwOyB9CiAgICAgICAgcHJlIC5zdHIgeyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjog I0NGRjsgfQogICAgICAgIHByZSAudmFsIHsgY29sb3I6ICMwNjY7IH0KICAgICAgICBwcmUgLnJl cCB7IGNvbG9yOiAjOTA5OyB9CiAgICAgICAgcHJlIC5vdGggeyBjb2xvcjogIzAwMDsgYmFja2dy b3VuZC1jb2xvcjogI0ZDRjsgfQogICAgICAgIHByZSAuZXJyIHsgYmFja2dyb3VuZC1jb2xvcjog I0ZDQzsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8dGV4dHRhYmxlPnMuICovCiAgICAgICAgdGFi bGUuYWxsLCB0YWJsZS5mdWxsLCB0YWJsZS5oZWFkZXJzLCB0YWJsZS5ub25lIHsKICAgICAgICAg ICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IHRleHQtYWxpZ246IGNlbnRlcjsgYm9yZGVyLXdpZHRo OiAycHg7CiAgICAgICAgICAgICAgICB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItY29sbGFw c2U6IGNvbGxhcHNlOwogICAgICAgIH0KICAgICAgICB0YWJsZS5hbGwsIHRhYmxlLmZ1bGwgeyBi b3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6IGJsYWNrOyB9CiAgICAgICAgdGFibGUu aGVhZGVycywgdGFibGUubm9uZSB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQogICAgICAgIHRoIHsK ICAgICAgICAgICAgICAgIGZvbnQtd2VpZ2h0OiBib2xkOyBib3JkZXItY29sb3I6IGJsYWNrOwog ICAgICAgICAgICAgICAgYm9yZGVyLXdpZHRoOiAycHggMnB4IDNweCAycHg7CiAgICAgICAgfQog ICAgICAgIHRhYmxlLmFsbCB0aCwgdGFibGUuZnVsbCB0aCB7IGJvcmRlci1zdHlsZTogc29saWQ7 IH0KICAgICAgICB0YWJsZS5oZWFkZXJzIHRoIHsgYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgc29s aWQgbm9uZTsgfQogICAgICAgIHRhYmxlLm5vbmUgdGggeyBib3JkZXItc3R5bGU6IG5vbmU7IH0K ICAgICAgICB0YWJsZS5hbGwgdGQgewogICAgICAgICAgICAgICAgYm9yZGVyLXN0eWxlOiBzb2xp ZDsgYm9yZGVyLWNvbG9yOiAjMzMzOwogICAgICAgICAgICAgICAgYm9yZGVyLXdpZHRoOiAxcHgg MnB4OwogICAgICAgIH0KICAgICAgICB0YWJsZS5mdWxsIHRkLCB0YWJsZS5oZWFkZXJzIHRkLCB0 YWJsZS5ub25lIHRkIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9CgogICAgICAgIGhyIHsgaGVpZ2h0 OiAxcHg7IH0KICAgICAgICBoci5pbnNlcnQgewogICAgICAgICAgICAgICAgd2lkdGg6IDgwJTsg Ym9yZGVyLXN0eWxlOiBub25lOyBib3JkZXItd2lkdGg6IDA7CiAgICAgICAgICAgICAgICBjb2xv cjogI0NDQzsgYmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9Ci0tPjwvc3R5bGU+Cjwv aGVhZD4KPGJvZHk+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgd2lkdGg9IjY2JSIgYm9yZGVyPSIwIiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPjx0cj48dGQ+PHRhYmxlIHN1bW1hcnk9ImxheW91dCIg d2lkdGg9IjEwMCUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjIiIGNlbGxzcGFjaW5nPSIxIj4K PHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5ESVNQQVRDSDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPlIu IEF2YXNhcmFsYSwgRWQuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPkludGVybmV0 LURyYWZ0PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+TW90b3JvbGEgSW5jPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbDwvdGQ+PHRk IGNsYXNzPSJoZWFkZXIiPkouIEJha2tlcjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVy Ij5FeHBpcmVzOiBTZXB0ZW1iZXIgMTIsIDIwMTA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5SZXNl YXJjaCBpbiBNb3Rpb24gQ29ycG9yYXRpb248L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRl ciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Uy4gU2FoYTwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5SSVQgU29sdXRp b25zPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNsYXNz PSJoZWFkZXIiPk1hcmNoIDExLCAyMDEwPC90ZD48L3RyPgo8L3RhYmxlPjwvdGQ+PC90cj48L3Rh YmxlPgo8aDE+PGJyIC8+PGJyIC8+QSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkg RXZlbnQgUGFja2FnZSBmb3IgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24gaW4g c3VwcG9ydCBvZiB0aGUgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIE5vdGlmaWNhdGlv biAoQ0RJVk4pIENESVYgc2VydmljZQogZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2 LW5vdGlmaWNhdGlvbi0wNC50eHQ8L2gxPgoKPGgzPkFic3RyYWN0PC9oMz4KCjxwPiAzR1BQIGFu ZCBUSVNQQU4gYXJlIGRlZmluaW5nIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGZvciB0aGUg Q29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIHNlcnZpY2UgdXNpbmcgSVAgTXVsdGltZWRp YSAoSU0pCiAgICAgICBDb3JlIE5ldHdvcmsgKENOKSBzdWJzeXN0ZW0gc3VwcGxlbWVudGFyeSBz ZXJ2aWNlLiBBcyBwYXJ0IG9mIENESVYsIGEgU0lQIGJhc2VkIEV2ZW50IHBhY2thZ2UgZnJhbWV3 b3JrIGlzIHVzZWQgZm9yIG5vdGlmeWluZwogICAgICAgdXNlcnMgYWJvdXQgZGl2ZXJzaW9ucyAo cmUtZGlyZWN0aW9ucyBvciBmb3J3YXJkaW5nKSBvZiB0aGVpciBpbmNvbWluZyBjb21tdW5pY2F0 aW9uIHNlc3Npb25zLiBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgbmV3IFNJUAogICAgICAgZXZl bnQgcGFja2FnZSBmb3IgYWxsb3dpbmcgdXNlcnMgdG8gc3Vic2NyaWJlIHRvIGFuZCByZWNlaXZl IHN1Y2ggbm90aWZpY2F0aW9ucy4gVXNlcnMgY2FuIGZ1cnRoZXIgZGVmaW5lIGZpbHRlcnMgdG8g Y29udHJvbCB0aGUKICAgICAgIHJhdGUgYW5kIGNvbnRlbnQgb2Ygc3VjaCBub3RpZmljYXRpb25z LiBUaGUgcHJvcG9zZWQgZXZlbnQgcGFja2FnZSBpcyBhcHBsaWNhYmxlIHRvIHRoZSBDRElWIHN1 cHBsZW1lbnRhcnkgc2VydmljZSBpbiBJTVMgYW5kIG1heQogICAgICAgbm90IGJlIGFwcGxpY2Fi bGUgdG8gdGhlIGdlbmVyYWwgaW50ZXJuZXQuCiAgIAo8L3A+CjxoMz5TdGF0dXMgb2YgdGhpcyBN ZW1vPC9oMz4KPHA+ClRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4g ZnVsbApjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCZuYnNwOzc4IGFuZCBC Q1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLgpOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNv IGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMKSW50ZXJuZXQtRHJhZnRzLjwvcD4KPHA+ CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBv dGhlciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJl Zj0naHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Jz5odHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQ8L2E+LjwvcD4KPHA+ClRoZSBsaXN0IG9m IEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEg aHJlZj0naHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCc+aHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbDwvYT4uPC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBTZXB0ZW1iZXIgMTIsIDIwMTAuPC9wPgoKPGgzPkNvcHlyaWdodCBOb3RpY2U8L2gzPgo8 cD4KQ29weXJpZ2h0IChjKSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlCmRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4KPHA+ ClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWwKUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyBpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YKcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCAoaHR0cDovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKS4KUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2Fy ZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIKcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0 aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuPC9wPgo8YSBuYW1lPSJ0b2MiPjwvYT48YnIgLz48 aHIgLz4KPGgzPlRhYmxlIG9mIENvbnRlbnRzPC9oMz4KPHAgY2xhc3M9InRvYyI+CjxhIGhyZWY9 IiNhbmNob3IxIj4xLjwvYT4mbmJzcDsKSW50cm9kdWN0aW9uPGJyIC8+CjxhIGhyZWY9IiNhbmNo b3IyIj4yLjwvYT4mbmJzcDsKVGVybWlub2xvZ3k8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjMiPjMu PC9hPiZuYnNwOwpBcHBsaWNhYmlsaXR5IFN0YXRlbWVudDxiciAvPgo8YSBocmVmPSIjYW5jaG9y NCI+NC48L2E+Jm5ic3A7CkFiYnJldmlhdGlvbnMgYW5kIERlZmluaXRpb25zPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1Ij40LjEuPC9hPiZuYnNwOwpBYmJy ZXZpYXRpb25zPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2 Ij40LjIuPC9hPiZuYnNwOwpEZWZpbml0aW9uczxiciAvPgo8YSBocmVmPSIjYW5jaG9yNyI+NS48 L2E+Jm5ic3A7ClJlcXVpcmVtZW50czxiciAvPgo8YSBocmVmPSIjYW5jaG9yOCI+Ni48L2E+Jm5i c3A7ClBhY2thZ2UgRGVmaW5pdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yOSI+Ni4xLjwvYT4mbmJzcDsKRXZlbnQgUGFja2FnZSBOYW1lPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMCI+Ni4yLjwvYT4mbmJzcDsK RXZlbnQgUGFja2FnZSBQYXJhbWV0ZXJzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3IxMSI+Ni4zLjwvYT4mbmJzcDsKU1VCU0NSSUJFIGJvZGllczxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTIiPjYuNC48L2E+Jm5ic3A7 ClN1YnNjcmlwdGlvbiBEdXJhdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yMTMiPjYuNS48L2E+Jm5ic3A7Ck5vdGlmeSBib2RpZXM8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI05vdGlmaWVyUCI+Ni42LjwvYT4mbmJzcDsKTm90 aWZpZXIgUHJvY2Vzc2luZyBvZiBTVUJTQ1JJQkUgcmVxdWVzdHM8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI0F1dGgiPjYuNi4x LjwvYT4mbmJzcDsKQXV0aGVudGljYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI0F1dGhvIj42LjYuMi48L2E+Jm5ic3A7 CkF1dGhvcml6YXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI05v dGlmaWVyRyI+Ni43LjwvYT4mbmJzcDsKTm90aWZpZXIgR2VuZXJhdGlvbiBvZiBOT1RJRlkgcmVx dWVzdHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE0Ij42 LjguPC9hPiZuYnNwOwpTdWJzY3JpYmVyIFByb2Nlc3Npbmcgb2YgTk9USUZZIFJlcXVlc3RzPGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxNSI+Ni45LjwvYT4m bmJzcDsKSGFuZGxpbmcgb2YgRm9ya2VkIFJlcXVlc3RzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxNiI+Ni4xMC48L2E+Jm5ic3A7ClJhdGUgb2YgTm90aWZp Y2F0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTci PjYuMTEuPC9hPiZuYnNwOwpTdGF0ZSBBZ2VudHM8YnIgLz4KPGEgaHJlZj0iI0NvbW0tZGl2LWlu Zm8iPjcuPC9hPiZuYnNwOwpDb21tLWRpdi1pbmZvIERvY3VtZW50PGJyIC8+CjxhIGhyZWY9IiNj b21tLWRpdi1pbmZvLWRvYyI+OC48L2E+Jm5ic3A7ClN0cnVjdHVyZSBvZiBDb21tLWRpdi1pbmZv IEZvcm1hdDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY29tbS1kaXYt aW5mby1lbGUiPjguMS48L2E+Jm5ic3A7CkNvbW0tZGl2LWluZm8gRWxlbWVudDxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY29t bS1kaXYtc3Vicy1pbmZvIj44LjEuMS48L2E+Jm5ic3A7CmNvbW0tZGl2LXN1YnMtaW5mbyBFbGVt ZW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNjb21tLWRpdi1udGZ5LWluZm8iPjguMS4yLjwvYT4mbmJzcDsKQ29tbS1kaXYt bnRmeS1pbmZvIEVsZW1lbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NvbW0tZGl2LWluZm8tc2VsIj44LjEuMy48L2E+Jm5i c3A7CkNvbW0tZGl2LWluZm8tc2VsZWN0aW9uLWNyaXRlcmlhPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNzYW1ub3QiPjguMi48L2E+Jm5ic3A7ClNhbXBsZSBOb3RpZmlj YXRpb24gYm9keTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTkiPjguMi4xLjwvYT4mbmJzcDsKSW5zdGFuY2Ugb2Yg Y29tbXVuaWNhdGlvbiBkaXZlcnNpb24gc3Vic2NyaXB0aW9uIGZpbHRlciBkb2N1bWVudDxiciAv PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yMjAiPjguMi4yLjwvYT4mbmJzcDsKSW5zdGFuY2Ugb2YgY29tbXVuaWNhdGlvbiBk aXZlcnNpb24gbm90aWZpY2F0aW9uIGRvY3VtZW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNzY2hlbWEiPjguMy48L2E+Jm5ic3A7ClNjaGVtYTxiciAvPgo8YSBocmVm PSIjc2VjLWNvbmQiPjkuPC9hPiZuYnNwOwpTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciAvPgo8 YSBocmVmPSIjYW5jaG9yMjEiPjEwLjwvYT4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczxiciAv PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjIiPjEwLjEuPC9hPiZu YnNwOwpDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBJbmZvcm1hdGlvbiBFdmVudCBQYWNrYWdlIFJl Z2lzdHJhdGlvbjxiciAvPgo8YSBocmVmPSIjYW5jaG9yMjMiPjExLjwvYT4mbmJzcDsKQWNrbm93 bGVkZ2VtZW50czxiciAvPgo8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4xMi48L2E+Jm5ic3A7 ClJlZmVyZW5jZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5y ZWZlcmVuY2VzMSI+MTIuMS48L2E+Jm5ic3A7Ck5vcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczIiPjEyLjIuPC9h PiZuYnNwOwpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CjxhIGhyZWY9IiNhbmNob3IyNiI+ QXBwZW5kaXgmbmJzcDtBLjwvYT4mbmJzcDsKQ2hhbmdlIGxvZzxiciAvPgo8YSBocmVmPSIjcmZj LmF1dGhvcnMiPiYjMTY3OzwvYT4mbmJzcDsKQXV0aG9ycycgQWRkcmVzc2VzPGJyIC8+CjwvcD4K PGJyIGNsZWFyPSJhbGwiIC8+Cgo8YSBuYW1lPSJhbmNob3IxIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uMSI+PC9hPjxoMz4xLiZuYnNwOwpJbnRyb2R1Y3Rpb248L2gzPgoKPHA+IDNHUFAg aXMgY3VycmVudGx5IG1haW50YWluaW5nIGFuZCBzcGVjaWZ5aW5nIGNvbW11bmljYXRpb24gZGl2 ZXJzaW9uIG1lY2hhbmlzbXMgd2hpY2ggYWxsb3cgdXNlcnMgdG8gZm9yd2FyZCBhbmQvb3IgcmVk aXJlY3QKaW5jb21pbmcgY29tbXVuaWNhdGlvbnMgdG8gb3RoZXIgZGVzdGluYXRpb25zLiBUaGUg aW50ZW50aW9uIG9mIHN1Y2ggbWVjaGFuaXNtcyBpcyB0byBwcm92aWRlIHVzZXJzIHdpdGggc3Vm ZmljaWVudCBmbGV4aWJpbGl0eSB0byAKbWFuYWdlIHRoZWlyIGluY29taW5nIGNvbW11bmljYXRp b25zIGluIGEgYmV0dGVyIHdheS4gVGhlIG1vc3QgY29tbW9uIGV4YW1wbGUgaXMgQ29tbXVuaWNh dGlvbiBGb3J3YXJkIE9uIEJ1c3kgKENGQikgd2hlcmUgaW4gdXNlcnMKY2FuIGZvcndhcmQgYW55 IGluY29taW5nIGNhbGxzLCB3aGlsc3QgdGhleSBhcmUgYnVzeSBvbiBzb21lIG90aGVyIGNhbGws IHRvIHRoZWlyIHZvaWNlIG1haWwgb3IgYSBzdWl0YWJsZSBhbHRlcm5hdGl2ZSAoZS5nLiBzb21l IApvdGhlciB1c2VyKS4gU2ltaWxhcmx5IG90aGVyIHZhcmlhbnRzIG9mIGNvbW11bmljYXRpb24g ZGl2ZXJzaW9uIGFyZSB3ZWxsIGRlZmluZWQgYW5kIHVzZWQgaW4gcHJhY3RpY2Ugc3VjaCBhcyBD b21tdW5pY2F0aW9uIEZvcndhcmQKb24gTm8gQW5zd2VyIChDRk5BKSwgQ29tbXVuaWNhdGlvbiBG b3J3YXJkIFVuY29uZGl0aW9uYWwgKENGVSkuIFNpbWlsYXJseSAzR1BQIGlzIGN1cnJlbnRseSBt YWludGFpbmluZyBhbmQgc3BlY2lmeWluZyBhIG1lY2hhbmlzbSAKZm9yIFVzZXJzIHRvIGNvbmZp Z3VyZSBDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBTZXJ2aWNlcyAoPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyMzR1BQLjI0LjYwNCc+WzFdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPjNH UFAsICZsZHF1bztDb21tdW5pY2F0aW9uIERpdmVyc2lvbiAoQ0RJVikgdXNpbmcgSVAgTXVsdGlt ZWRpYSAoSU0pQ29yZSBOZXR3b3JrIChDTikgc3Vic3lzdGVtOyAgUHJvdG9jb2wgc3BlY2lmaWNh dGlvbiwmcmRxdW87IERlY2VtYmVyJm5ic3A7MjAwOS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ IGFuZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nIzNHUFAuMjQuNDA0Jz5bMl08c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+M0dQUCwgJmxkcXVvO1RJU1BBTjsgUFNUTi9JU0ROIHNpbXVs YXRpb24gc2VydmljZXM6IENvbW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKTsgUHJvdG9jb2wg c3BlY2lmaWNhdGlvbiwmcmRxdW87IEp1bmUmbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4pIApmb3IgdGhlaXIgaW5jb21pbmcgY29tbXVuaWNhdGlvbnMuICBUaGUgaW50ZW50aW9u IG9mIHN1Y2ggbWVjaGFuaXNtcyBpcyB0byBwcm92aWRlIFVzZXJzIHdpdGggc3VmZmljaWVudCBm bGV4aWJpbGl0eSB0byBtYW5hZ2UgCnRoZWlyIGluY29taW5nIGNvbW11bmljYXRpb25zIGluIGEg YmV0dGVyIHdheS4KPGJyIC8+CjxiciAvPgoKSG93ZXZlciwgd2l0aCB0aGUgaW5jcmVhc2luZyB1 c2FnZSBvZiBDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBzZXJ2aWNlcywgdXNlcnMgbWF5IGhhdmUg bWFueSBkaWZmZXJlbnQgdmFyaWFudHMgYW5kIGNvbmZpZ3VyYXRpb25zCmFjdGl2ZSBhdCB0aGUg c2FtZSB0aW1lLiAgRm9yIGluc3RhbmNlLCBhIHVzZXIgbWF5IGhhdmUgdmFyaW91cyBDRlUgc2Vy dmljZXMgY29uZmlndXJlZCBkaWZmZXJlbnRseSBiYXNlZCBvbiB0aGUgdGltZS1vZi10aGUtZGF5 IGFuZCAKdGhlIENhbGxpbmcgcGFydHkncyBpZGVudGl0eSwgb3IgQ0ZCIGJhc2VkIG9uIHRoZSB0 aW1lLW9mLXRoZS1kYXkuICBUaGlzIGlzIHBvc3NpYmxlIGJ5IGhhdmluZyB2YXJpb3VzIHN1Y2gg Y29uZmlndXJlZCBkaXZlcnNpb25zIGJ5IApzdWJzY3JpYmluZyB0byBkaWZmZXJlbnQgQ29tbXVu aWNhdGlvbiBEaXZlcnNpb24gKENESVYpIHNlcnZpY2VzIGFzIHNwZWNpZmllZCBieSAzR1BQLiAg VGhvdWdoLCB0aGVyZSBoYXMgYmVlbiBxdWl0ZSBhY3RpdmUgd29yayBpbiAKdGhlIGFyZWEgb2Yg YmV0dGVyIGN1c3RvbWl6YXRpb24gYW5kIGNvbmZpZ3VyYXRpb24gb2Ygc3VjaCBDb21tdW5pY2F0 aW9uIERpdmVyc2lvbiBtZWNoYW5pc21zLCBub3QgbXVjaCBhdHRlbnRpb24gaGFzIGJlZW4gcGFp ZCB0byBob3cKdGhlIFVzZXJzIGNhbiBtYW5hZ2UgdGhlc2Ugc2VydmljZXMgaW4gYW4gZWZmZWN0 aXZlIG1hbm5lci4gIFdpdGggdGhlIHZhcmlvdXMgYWR2YW5jZWQgb3B0aW9ucyBhbmQgaGlnaCBm bGV4aWJpbGl0eSBwcm92aWRlZCwgaXQgaXMgCnBvc3NpYmxlIHRoYXQgdGhlIHVzZXIgbG9zZXMg dHJhY2sgb2YgdGhlIHZhcmlvdXMgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gY29uZmlndXJhdGlv bnMgb3Igc2VydmljZXMgdGhleSBoYXZlIHJlZ2lzdGVyZWQgZm9yLgo8YnIgLz4KPGJyIC8+CgpP bmUgb2YgdGhlIGJhc2ljIHdheXMsIGJ5IHdoaWNoIGEgdXNlciBjYW4gbWFuYWdlIGEgQ0RJViBz ZXJ2aWNlIGlzIHRvIGJlIGluZm9ybWVkIG9mIHdoaWNoIHNlcnZpY2VzIHRoZXkgaGF2ZSByZWdp c3RlcmVkIGZvci4gRm9yIGV4YW1wbGUsIAo8YSBjbGFzcz0naW5mbycgaHJlZj0nIzNHUFAuMjQu NjA0Jz5bMV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+M0dQUCwgJmxkcXVvO0Nv bW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKSB1c2luZyBJUCBNdWx0aW1lZGlhIChJTSlDb3Jl IE5ldHdvcmsgKENOKSBzdWJzeXN0ZW07ICBQcm90b2NvbCBzcGVjaWZpY2F0aW9uLCZyZHF1bzsg RGVjZW1iZXImbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gYW5kIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjM0dQUC4yNC40MDQnPlsyXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz4zR1BQLCAmbGRxdW87VElTUEFOOyBQU1ROL0lTRE4gc2ltdWxhdGlvbiBzZXJ2aWNl czogQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpOyBQcm90b2NvbCBzcGVjaWZpY2F0aW9u LCZyZHF1bzsgSnVuZSZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBhbGxvdyBm b3Igc3VjaCBpbmRpY2F0aW9ucyB0byBiZSByZWNlaXZlZCBieQp0aGUgc3Vic2NyaWJlciwgYXQg dGhlIHRpbWUgb2YgaW5pdGlhdGluZyBhbiBvdXRnb2luZyBjYWxsLiAgSG93ZXZlciwgc2ltcGx5 IHNob3dpbmcgdGhlIHJlZ2lzdGVyZWQgc2VydmljZXMgaXMgbm90IHN1ZmZpY2llbnQsIApzaW5j ZSBlYWNoIHNlcnZpY2UgbWF5IGJlIGN1c3RvbWl6ZWQgaW4gbnVtZXJvdXMgYW5kIGRpZmZlcmVu dCB3YXlzIGZvciBkaWZmZXJlbnQgY3JpdGVyaWEuIEZvciBleGFtcGxlIHZhcmlvdXMgaW5zdGFu dGlhdGlvbnMgb2YgQ0ZCCm1heSBiZSBjb25maWd1cmVkIGZvciBkaWZmZXJlbnQgdGltZXMtb2Yt dGhlLWRheSBhbmQgZGlmZmVyZW50IGNhbGxpbmcgcGFydHkgaWRlbnRpdGllcy4gRXZlbiBpZiBz dWJzY3JpYmVycyBhcmUgc2hvd24gaW5mb3JtYXRpb24gYWJvdXQKYWxsIHRoZSBDb21tdW5pY2F0 aW9uIERpdmVyc2lvbiBzZXJ2aWNlcyBhbmQgdGhlaXIgdmFyaWFudHMgdGhhdCB0aGV5IGFyZSBy ZWdpc3RlcmVkIGZvciwgdGhleSBtYXkgbm90IGJlIGFibGUgdG8gbWFrZSBzZW5zZSBvciB2ZXJp ZnkgCnRoYXQgZWFjaCBvZiB0aGVtIGlzIGNvcnJlY3QgYXMgcGVyIHRoZWlyIGV4cGVjdGF0aW9u LiAgU3VjaCBhIG1pc21hdGNoIGluIHRlcm1zIG9mIHNlcnZpY2UgYmVoYXZpb3IgZXhwZWN0YXRp b24gYW5kIGFjdHVhbCBleGVjdXRpb24sCm1heSBoYXBwZW4gZHVlIHRvIGluY29ycmVjdCBjb25m aWd1cmF0aW9uIG9uIGJlaGFsZiBvZiB0aGUgVXNlciwgd2hpY2ggY2Fubm90IGJlIGVhc2lseSBk ZXRlY3RlZCBpZiB0aGVyZSBhcmUgdmFyaW91cyBjb21tdW5pY2F0aW9uIApkaXZlcnNpb24gc2Vy dmljZXMgYW5kIHRoZWlyIGRpZmZlcmVudCBjb25maWd1cmF0aW9ucyBmb3IgaGFuZGxpbmcgaW5j b21pbmcgY29tbXVuaWNhdGlvbnMuCjxiciAvPgo8YnIgLz4KCkEgcHJvYmFibGUgYW5kIHN1aXRh YmxlIGluc3RhbmNlLCB3aGVuIHRoZSBzdWJzY3JpYmVyIG1heSBlYXNpbHkganVkZ2Ugd2hldGhl ciBhIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGlzIGNvcnJlY3QsIGlzIHdoZW4gaXQgYWN0dWFs bHkKdGFrZXMgcGxhY2UuICBUaGUgc3Vic2NyaWJlciBpcyBhbHJlYWR5IGF3YXJlIG9mIHRoZSBj dXJyZW50IGNvbmRpdGlvbnMgKHRpbWUtb2YtZGF5LCBjdXJyZW50IHByZXNlbmNlIGFuZCBhdmFp bGFiaWxpdHkgZXRjKSBhbmQgaGVuY2UKaXMgaW4gYSBwb3NpdGlvbiB0byBkZWNpZGUsIHdoZXRo ZXIgdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIHdoaWNoIGp1c3Qgb2NjdXJyZWQsIHdhcyBp bmRlZWQgYXMgcGVyIHRoZWlyIGV4cGVjdGF0aW9uLiAKRm9yIGUuZy4gdGhlIHN1YnNjcmliZXIg d2FudGVkIHRvIGRpdmVydCBhbGwgaW5jb21pbmcgY2FsbHMgdG8gdm9pY2UtbWFpbCwgYmV0d2Vl biAzLjAwIHAubS4gdG8gNC4wMCBwLm0uICBZZXQsIGJ5IG1pc3Rha2Ugc2hlIApjb25maWd1cmVz IHRoZSB0aW1lLWR1cmF0aW9uIGFzIDMuMDAgdG8gNC4wMCBwLm0uICBJdCB3b3VsZCBiZSB2ZXJ5 IGRpZmZpY3VsdCBmb3IgaGVyIHRvIHNwb3QgdGhpcyBlcnJvciB3aGlsZSBtYW51YWxseSByZXZp ZXdpbmcgaGVyIApjb21wbGV0ZSBzZXQgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24gc2Vydmlj ZXMsIHdpdGggdGhlaXIgdmFyaW91cyBjb25maWd1cmF0aW9ucy4gIEluc3RlYWQsIGlmIHRoZSBz dWJzY3JpYmVyIHJlY2VpdmVzIGEgcmVhbC10aW1lIApub3RpZmljYXRpb24gb2YgYW55IGNvbW11 bmljYXRpb24gZGl2ZXJzaW9uIG9jY3VycmluZyBhZnRlciA0IHAubS4sIHNoZSB3b3VsZCBiZSBh YmxlIHRvIGltbWVkaWF0ZWx5IGd1ZXNzIHRoYXQgc29tZXRoaW5nIGlzICd3cm9uZycgCm9yIG5v dCBhcyBwZXIgaGVyIGludGVudGlvbiBhbmQgdGFrZSBjb3JyZWN0aXZlIGFjdGlvbi4gIFN1Y2gg Y29ycmVjdGl2ZSBhY3Rpb24gY291bGQgYmUgbWFudWFsIHZlcmlmaWNhdGlvbiBvZiB0aGUgc3Bl Y2lmaWMgcnVsZSB3aGljaAp0cmlnZ2VyZWQgdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uLCB3 aGVyZWluIHNoZSB3aWxsIGJlIGFibGUgdG8gc3BvdCB0aGUgKm1pc3Rha2UqIG1vcmUgZWFzaWx5 Lgo8YnIgLz4KPGJyIC8+CgpUaHVzLCBmb3IgZWZmZWN0aXZlIHN1YnNjcmliZXIgc2VydmljZXMg bWFuYWdlbWVudCBvZiBtdWx0aXBsZSBjb25maWd1cmF0aW9ucyBvZiB2YXJpb3VzIENvbW11bmlj YXRpb24gRGl2ZXJzaW9uIHNlcnZpY2VzLCAKYSBub3RpZmljYXRpb24tYmFzZWQgbWVjaGFuaXNt IG1heSB3b3JrIHdlbGwuICBTdWNoIGEgbWVjaGFuaXNtIHdvdWxkIGludm9sdmUgbm90aWZ5aW5n IHN1YnNjcmliZXJzIGFib3V0IGRpdmVyc2lvbnMgb2YgdGhlaXIgaW5jb21pbmcKY29tbXVuaWNh dGlvbnMsIGFzIGFuZCB3aGVuIHRoZSBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBoYXBwZW5zIG9y IHdpdGggYSBzbGlnaHQgZGVsYXkgKGFzIHBlciBzdWJzY3JpYmVyIHNlcnZpY2UgY29uZmlndXJh dGlvbikuICAKQXMgc3VjaCBkaXZlcnNpb24tcmVsYXRlZCBpbmZvcm1hdGlvbiBpcyBjb252ZXll ZCBhbG1vc3QgaW5zdGFudGx5IG9yIHdpdGhpbiBhIHNtYWxsIHRpbWUtZnJhbWUsIHRoZSBzdWJz Y3JpYmVycyBjYW4gdmVyaWZ5IHdoZXRoZXIKdGhlIHBhcnRpY3VsYXIgY29tbXVuaWNhdGlvbiBk aXZlcnNpb24gaXMgaW5kZWVkIGNvcnJlY3QgYXQgdGhhdCBpbnN0YW50IG9mIHRpbWUuCjxiciAv Pgo8YnIgLz4KClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFNJUCBldmVudCBwYWNrYWdlIHRoYXQg YWxsb3dzIGEgU0lQIFVzZXIgQWdlbnRzIHRvIHN1YnNjcmliZSB0byBhbmQgYmUgbm90aWZpZWQg b2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb25zIAplbmFjdGVkIG9uIHRoZWlyIGJlaGFsZi4gIC4g CjxiciAvPgo8YnIgLz4KCgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4yIj48L2E+PGgzPjIuJm5ic3A7ClRlcm1pbm9sb2d5PC9oMz4KCjxwPiBJbiB0 aGlzIGRvY3VtZW50LCB0aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwKICAgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJNQVkiLAogICBhbmQgIk9QVElPTkFMIiBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjExOSc+ WzNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJyYWRuZXIsIFMuLCAmbGRxdW87 S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMs JnJkcXVvOyBNYXJjaCZuYnNwOzE5OTcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPgogICBhbmQg aW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzIGZvciBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25z LiAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMi PjwvYT48aDM+My4mbmJzcDsKQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQ8L2gzPgoKPHA+IEl0IGlz IGJlbGlldmVkIHRoYXQgdGhlIFNJUCBldmVudCBwYWNrYWdlIGRlZmluZWQgaGVyZSBpcyBub3Qg YXBwbGljYWJsZSB0byB0aGUgZ2VuZXJhbCBJbnRlcm5ldCBhbmQgaGFzIGJlZW4gZGVzaWduZWQg dG8gc2VydmUgdGhlCmFyY2hpdGVjdHVyZSBvZiB0aGUgQ0RJViBzZXJ2aWNlIGluIElNUyBjb3Jl IG5ldHdvcmtzLiBUaGUgYWltIG9mIHRoaXMgbWVtbyBpcyB0byBmb2xsb3cgdGhlIHByb2NlZHVy ZSBpbmRpY2F0ZWQgaW4gUkZDIDM0MjcgCjxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzQyNyc+ WzRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk1hbmtpbiwgQS4sIEJyYWRuZXIs IFMuLCBNYWh5LCBSLiwgV2lsbGlzLCBELiwgT3R0LCBKLiwgYW5kIEIuIFJvc2VuLCAmbGRxdW87 Q2hhbmdlIFByb2Nlc3MgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCks JnJkcXVvOyBEZWNlbWJlciZuYnNwOzIwMDIuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBhbmQg dG8gcmVnaXN0ZXIgYSBuZXcgZXZlbnQgcGFja2FnZSB3aXRoIGV2ZW50IG5hbWUgImNvbW0tZGl2 LWluZm8iIHdpdGggSUFOQS4KIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi40Ij48L2E+PGgzPjQuJm5ic3A7CkFiYnJldmlhdGlvbnMgYW5kIERlZmlu aXRpb25zPC9oMz4KCjxhIG5hbWU9ImFuY2hvcjUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi40LjEiPjwvYT48aDM+NC4xLiZuYnNwOwpBYmJyZXZpYXRpb25zPC9oMz4KCjxwPgo8L3A+Cjxi bG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij4KPHA+IENESVY6IENvbW11bmljYXRpb24gRGl2ZXJzaW9u LiAKPC9wPgo8cD4gQ0RJVk46IENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbi4g CjwvcD4KPHA+IFRJU1BBTjogVGVsZWNvbW11bmljYXRpb25zIGFuZCBJbnRlcm5ldCBDb252ZXJn ZWQgU2VydmljZXMgYW5kIFByb3RvY29scyBmb3IgQWR2YW5jZWQgTmV0d29ya2luZy4gCjwvcD4K PC9ibG9ja3F1b3RlPjxwPgoKPC9wPgo8YSBuYW1lPSJhbmNob3I2Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNC4yIj48L2E+PGgzPjQuMi4mbmJzcDsKRGVmaW5pdGlvbnM8L2gzPgoKPHA+ CjwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPgo8cD4gU3Vic2NyaWJlciAtIFRoZSBVc2Vy IEFnZW50IHdobyBoYXMgc3Vic2NyaWJlZCB0byB0aGUgQ29tbXVuaWNhdGlvbiBkaXZlcnNpb24g bm90aWZpY2F0aW9uIHNlcnZpY2UuIAo8L3A+CjxwPiBVc2VyIC0gQW5vdGhlciB0ZXJtIGZvciB0 aGUgc3Vic2NyaWJlci4gCjwvcD4KPHA+IERpdmVydGluZyBVc2VyIC0gVGhlIFVzZXIgQWdlbnQg d2hvIGhhcyBjb25maWd1cmVkIGEgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24uIFRoaXMgY291bGQg YmUgdGhlIFVzZXIgQWdlbnQgd2hvIGhhcyBjb25maWd1cmVkCiAgICB0aGUgQ29tbXVuaWNhdGlv biBESXZlcnNpb24gc2VydmljZSBydWxlcyBpbiB0aGUgbmV0d29yay4gCjwvcD4KPHA+IERpdmVy dGVkLVRvIEVudGl0eS9Vc2VyIC0gVGhlIFVzZXIgQWdlbnQgd2hvIGlzIHRoZSBuZXcgdGFyZ2V0 CiAgICBvZiB0aGUgaW5jb21pbmcgY29tbXVuaWNhdGlvbiwgcG9zdCBleGVjdXRpb24gb2YgYW55 IGNvbmZpZ3VyZWQgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gc2VydmljZS4KPC9wPgo8cD4gT3Jp Z2luYXRpbmcgVXNlciAtIFRoZSBVc2VyIEFnZW50IHdobyBpcyB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgaW5jb21pbmcgY29tbXVuaWNhdGlvbiwgd2hpY2ggd2FzIGluaXRpYWxseSAKICAgIHRhcmdl dGVkIHRvd2FyZHMgdGhlIERpdmVydGluZyBVc2VyLCBidXQgZmluYWxseSBzZW50IHRvIHRoZSBE aXZlcnRlZC1UbyBVc2VyLiAgVGhlIE9yaWdpbmF0aW5nCiAgICAgIFVzZXIgaXMgYWxzbyByZWZl cnJlZCB0byBhcyB0aGUgQ2FsbGVyLiAKPC9wPgo8cD4gSU1TIENvcmUgTmV0d29yayAtIFRoaXMg cmVmZXJzIHRvIHRoZSBJTVMgYmFzZWQgU0lQIGJhc2VkIG5ldHdvcmsgdGhhdCBjb25mb3JtcyB0 byB0aGUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyMzR1BQLjI0LjIyOSc+WzddPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPjNHUFAsICZsZHF1bztJbnRlcm5ldCBQcm90b2NvbCAoSVAp IG11bHRpbWVkaWEgY2FsbCBjb250cm9sIHByb3RvY29sIGJhc2VkIG9uIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKSBhbmQgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQ KTsgU3RhZ2UgMywmcmRxdW87IFNlcHRlbWJlciZuYnNwOzIwMDkuPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiAKICAgIGFuZCBub3QgdGhlIGdlbmVyYWwgU0lQIG5ldHdvcmsgYXMgZGVmaW5lZCBp biA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzMyNjEnPls1XTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5Sb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywg Ry4sIEpvaG5zdG9uLCBBLiwgUGV0ZXJzb24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiwg YW5kIEUuIFNjaG9vbGVyLCAmbGRxdW87U0lQOiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2ws JnJkcXVvOyBKdW5lJm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgo8L3A+Cjwv YmxvY2txdW90ZT48cD4KCjwvcD4KPGEgbmFtZT0iYW5jaG9yNyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjUiPjwvYT48aDM+NS4mbmJzcDsKUmVxdWlyZW1lbnRzPC9oMz4KCjxwPkEgY29t cHJlaGVuc2l2ZSBkZXNjcmlwdGlvbiBvZiBhbGwgdGhlIHJlcXVpcmVtZW50cyB0aGF0IGFmZmVj dCB0aGUgQ0RJViBzZXJ2aWNlIGRldmVsb3BlZCBieSAzR1BQIGNhbiBiZSBmb3VuZCBpbiB0aGUg M0dQUAogICB3ZWIgcGFnZSBhdCBodHRwOi8vd3d3LjNncHAub3JnIGFuZCBodHRwOi8vd3d3LmV0 c2kub3JnLiAKPGJyIC8+CjxiciAvPgoKIEZvciB0aGUgc2FrZSBvZiBzaW1wbGljaXR5LCB3ZSBi cmllZmx5IGRpc2N1c3MgaGVyZSB0aG9zZSByZXF1aXJlbWVudHMgdGhhdCBhZmZlY3QgdGhlIHNv bHV0aW9uIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgogVGhlc2UgcmVxdWlyZW1lbnRzIGNh biBiZSBzdW1tYXJpemVkIGFzIGZvbGxvd3M6IAogPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+ VGhlcmUgbXVzdCBiZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBzdWJzY3JpYmVyLWNvbnRyb2xs ZWQgbm90aWZpY2F0aW9uIG9mIGNvbW11bmljYXRpb24gZGl2ZXJzaW9ucyB0byB0aGUgZGl2ZXJ0 aW5nIHVzZXIsCiAgICBpbmNsdWRpbmcgdGhlIG9wdGlvbiB0byBjb250cm9sIHdoaWNoIG5vdGlm aWNhdGlvbnMgdGhlIHVzZXIgd2FudHMgdG8gcmVjZWl2ZSBhbmQgdG8gY29udHJvbCB0aGUgcmF0 ZSBhdCB3aGljaCBub3RpZmljYXRpb25zIGFyZSByZWNlaXZlZC4KPC9saT4KPGxpPlRoZXJlIG11 c3QgYmUgYSBtZWNoYW5pc20gdGhhdCBlbmFibGVzIGZpbHRlcmluZyBvZiBub3RpZmljYXRpb25z IG9mIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uLiAKPC9saT4KPGxpPlRoZXJlIG11c3QgYmUgYSBt ZWNoYW5pc20gdGhhdCBlbmFibGVzIHRyaWdnZXJpbmcgb2Ygbm90aWZpY2F0aW9ucyBvZiBjb21t dW5pY2F0aW9uIGRpdmVyc2lvbi4gCjwvbGk+CjxsaT5UaGVyZSBtdXN0IGJlIGEgbWVjaGFuaXNt IHRoYXQgZW5hYmxlcyBzZWxlY3RpbmcgaW5mb3JtYXRpb24gdG8gYmUgaW5jbHVkZWQgaW4gbm90 aWZpY2F0aW9ucyBvZiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbi4gCjwvbGk+CjwvdWw+PHA+Cjxi ciAvPgo8YnIgLz4KClRoZXNlIHJlcXVpcmVtZW50cyBsZWFkIHRvIGEgc29sdXRpb24gd2hlcmVi eSB0aGUgdXNlciBjYW4gaW5kaWNhdGUgdG8gYSBuZXR3b3JrIG5vZGUgaGlzIGludGVyZXN0IGlu IHJlY2VpdmluZyBjZXJ0YWluIHR5cGUgb2YgCiAgbm90aWZpY2F0aW9ucyBvZiBjb21tdW5pY2F0 aW9uIGRpdmVyc2lvbi4gIFB1c2hpbmcgdGhlc2Ugc2V0dGluZ3MgdG8gYSBuZXR3b3JrIG5vZGUg YWxsb3dzIHRoZSBuZXR3b3JrIG5vZGUgdG8gY29uc2VydmUgc2NhcmNlIAogIHJlc291cmNlcyB3 aGlsZSBzdGlsbCBub3RpZnlpbmcgdGhlIHVzZXIgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb25z IGVuYWN0aW5nIG9uIHRoZSB1c2VyJ3MgYmVoYWxmLgoKPC9wPgo8YSBuYW1lPSJhbmNob3I4Ij48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNiI+PC9hPjxoMz42LiZuYnNwOwpQYWNrYWdlIERl ZmluaXRpb248L2gzPgoKPHA+IFRoaXMgc2VjdGlvbiBmaWxscyBpbiB0aGUgZGV0YWlscyBuZWVk ZWQgZm9yIGFuIGV2ZW50IHBhY2thZ2UgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuNCBvZiA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzMyNjUnPls2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5Sb2FjaCwgQS4sICZsZHF1bztTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJ UCktU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDIuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KPC9wPgo8YSBuYW1lPSJhbmNob3I5Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uNi4xIj48L2E+PGgzPjYuMS4mbmJzcDsKRXZlbnQgUGFja2FnZSBO YW1lPC9oMz4KCjxwPiBUaGUgU0lQIEV2ZW50cyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHBhY2th Z2UgZGVmaW5pdGlvbnMgdG8gc3BlY2lmeSB0aGUgbmFtZSBvZiB0aGVpciBwYWNrYWdlIG9yIHRl bXBsYXRlLXBhY2thZ2UuCjxiciAvPgo8YnIgLz4KClRoZSBuYW1lIG9mIHRoaXMgcGFja2FnZSBp cyAiY29tbS1kaXYtaW5mbyIuIEFzIHNwZWNpZmllZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzMyNjUnPls2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Sb2FjaCwgQS4s ICZsZHF1bztTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCktU3BlY2lmaWMgRXZlbnQg Tm90aWZpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDIuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwgdGhpcyB2YWx1ZSBhcHBlYXJzIGluIHRoZSBFdmVudApoZWFkZXIgcHJlc2VudCBpbiBT VUJTQ1JJQkUgYW5kIE5PVElGWSByZXF1ZXN0cy4gCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTAiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjIiPjwvYT48aDM+Ni4yLiZuYnNwOwpFdmVudCBQ YWNrYWdlIFBhcmFtZXRlcnM8L2gzPgoKPHA+IFRoZSBTSVAgRXZlbnRzIHNwZWNpZmljYXRpb24g PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMjY1Jz5bNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+Um9hY2gsIEEuLCAmbGRxdW87U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IChTSVApLVNwZWNpZmljIEV2ZW50IE5vdGlmaWNhdGlvbiwmcmRxdW87IEp1bmUmbmJzcDsyMDAy Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gYWxsb3dzIHBhY2thZ2VzIHRvIGRlZmluZSBhZGRp dGlvbmFsIHBhcmFtZXRlcnMuIFRoaXMgZXZlbnQgcGFja2FnZSAKICJjb21tLWRpdi1pbmZvIiBk b2VzIG5vdCBkZWZpbmUgYWRkaXRpb25hbCBwYXJhbWV0ZXJzLgouIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjExIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4zIj48L2E+PGgzPjYuMy4mbmJz cDsKU1VCU0NSSUJFIGJvZGllczwvaDM+Cgo8cD4gVGhlIFNJUCBFdmVudHMgc3BlY2lmaWNhdGlv biByZXF1aXJlcyBwYWNrYWdlIG9yIHRlbXBsYXRlLXBhY2thZ2UgZGVmaW5pdGlvbnMgdG8gZGVm aW5lIHRoZSB1c2FnZSwgaWYgYW55LCBvZiBib2RpZXMgaW4gU1VCU0NSSUJFIHJlcXVlc3RzLgo8 YnIgLz4KPGJyIC8+CgpBIFNVQlNDUklCRSBmb3IgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gZXZl bnQgTUFZIGNvbnRhaW4gYSBib2R5LiBUaGUgcHVycG9zZSBvZiB0aGUgYm9keSBkZXBlbmRzIG9u IGl0cyB0eXBlLiBTdWJzY3JpcHRpb25zIHRvCnRoZSBDb21tLWRpdi1pbmZvIGV2ZW50IHBhY2th Z2UgU0hBTEwgb25seSBpbmNsdWRlIGEgYm9keSBvZiBNSU1FIHR5cGUgImFwcGxpY2F0aW9uL2Nv bW0tZGl2LWluZm8reG1sIi4gCjxiciAvPgo8YnIgLz4KCkEgYm9keSBvZiB0aGUgU1VCU0NSSUJF IHJlcXVlc3Qgd2l0aCBjb250ZW50IHR5cGUgc2V0IHRvIE1JTUUgdHlwZSAiYXBwbGljYXRpb24v Y29tbS1kaXYtaW5mbyt4bWwiIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21tdW5p Y2F0aW9uCmRpdmVyc2lvbiBub3RpZmljYXRpb24gaW5mb3JtYXRpb24gZmlsdGVyIGNyaXRlcmlh IGFuZCBub3RpZmljYXRpb24gdHJpZ2dlciBjcml0ZXJpYS4gVGhpcyBpbmZvcm1hdGlvbiBpcyBj b252ZXllZCB1c2luZyB0aGUgWE1MIGVsZW1lbnRzIGRlZmluZWQKaW4gPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNzZWwnPlNlY3Rpb24mbmJzcDs4LjEuMS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPmNvbW0tZGl2LXNlbGVjdGlvbi1jcml0ZXJpYTwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi42LjQiPjwvYT48aDM+Ni40LiZuYnNwOwpTdWJzY3JpcHRpb24gRHVyYXRpb248L2gzPgoKPHA+ IFRoZSBkZWZhdWx0IGV4cGlyYXRpb24gdGltZSBmb3Igc3Vic2NyaXB0aW9ucyB3aXRoaW4gdGhp cyBwYWNrYWdlIGlzIDM2MDAgc2Vjb25kcy4gIEFzIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzMyNjUnPls2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Sb2FjaCwgQS4s ICZsZHF1bztTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCktU3BlY2lmaWMgRXZlbnQg Tm90aWZpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDIuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwgdGhlIHN1YnNjcmliZXIKICAgIE1BWSBzcGVjaWZ5IGFuIGFsdGVybmF0ZSBleHBpcmF0 aW9uIGluIHRoZSBFeHBpcmVzIGhlYWRlciBmaWVsZC4KCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTMi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjUiPjwvYT48aDM+Ni41LiZuYnNwOwpOb3Rp ZnkgYm9kaWVzPC9oMz4KCjxwPlRoZSBTSVAgRXZlbnRzIHNwZWNpZmljYXRpb24gcmVxdWlyZXMg cGFja2FnZSBkZWZpbml0aW9ucyB0byBkZWZpbmUgYSBkZWZhdWx0IHZhbHVlIGZvciBzdWJzY3Jp cHRpb24gZHVyYXRpb25zLCBhbmQgdG8gZGlzY3VzcyAKcmVhc29uYWJsZSBjaG9pY2VzIGZvciBk dXJhdGlvbnMgd2hlbiB0aGV5IGFyZSBleHBsaWNpdGx5IHNwZWNpZmllZC4KPGJyIC8+CjxiciAv PgoKVGhlIE5PVElGWSBtZXNzYWdlIGNvbnRhaW5zIGJvZGllcy4gVGhpcyBib2R5IGlzIGEgZm9y bWF0IGxpc3RlZCBpbiB0aGUgQWNjZXB0IGhlYWRlciBmaWVsZCBvZiB0aGUgU1VCU0NSSUJFIHJl cXVlc3Qgb3IgYSBwYWNrYWdlIApzcGVjaWZpYyBkZWZhdWx0IGZvcm1hdCBpZiB0aGUgQWNjZXB0 IGhlYWRlciBmaWVsZCB3YXMgb21pdHRlZCBmcm9tIHRoZSBTVUJTQ1JJQkUgcmVxdWVzdC4KPGJy IC8+CjxiciAvPgoKSW4gdGhpcyBldmVudCBwYWNrYWdlLCB0aGUgYm9keSBvZiB0aGUgbm90aWZp Y2F0aW9uIGNvbnRhaW5zIHRoZSBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBpbmZvcm1hdGlvbiBw ZXJ0YWluaW5nIHRvIHRoZSBkaXZlcnNpb24KdGhhdCBvY2N1cmVkIGluIHRoZSBuZXR3b3JrIG9u IGJlaGFsZiBvZiB0aGUgc3Vic2NyaWJlci4gVGhlIGZvcm1hdCBvZiB0aGUgY29tbXVuaWNhdGlv biBkaXZlcnNpb24gaW5mb3JtYXRpb24gaXMgYW4gWE1MIGRvY3VtZW50CmFzIHBlciBlbGVtZW50 cyBkZWZpbmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29tbS1kaXYtbnRmeS1pbmZvJz5T ZWN0aW9uJm5ic3A7OC4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q29tbS1k aXYtbnRmeS1pbmZvIEVsZW1lbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgpTZWUgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNjb21tLWRpdi1pbmZvLWRvYyc+U2VjdGlvbiZuYnNwOzg8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3RydWN0dXJlIG9mIENvbW0tZGl2LWluZm8gRm9y bWF0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KPGJyIC8+CjxiciAvPgoKQWxsIHN1YnNjcmli ZXJzIGFuZCBub3RpZmllcnMgb2YgdGhlICJjb21tLWRpdi1pbmZvIiBldmVudCBwYWNrYWdlIE1V U1Qgc3VwcG9ydCB0aGUgImFwcGxpY2F0aW9uL2NvbW0tZGl2LWluZm8reG1sIiBkYXRhIGZvcm1h dApkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb21tLWRpdi1pbmZvLWRvYyc+ U2VjdGlvbiZuYnNwOzg8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3RydWN0dXJl IG9mIENvbW0tZGl2LWluZm8gRm9ybWF0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gVGhlIFNV QlNDUklCRSByZXF1ZXN0IE1BWSBjb250YWluIGFuIEFjY2VwdCBoZWFkZXIgZmllbGQuIElmIG5v IHN1Y2ggaGVhZGVyIApmaWVsZCBpcyBwcmVzZW50LCBpdCBoYXMgYSBkZWZhdWx0IHZhbHVlIG9m ICJhcHBsaWNhdGlvbi9jb21tLWRpdi1pbmZvK3htbCIgKGFzc3VtaW5nIEV2ZW50IGhlYWRlciBo YXMgYSB2YWx1ZSBvZiAiY29tbS1kaXYtaW5mbyIpLiAKSWYgdGhlIEFjY2VwdCBoZWFkZXIgZmll bGQgaXMgcHJlc2VudCwgaXQgTVVTVCBjb250YWluIHRoZSB2YWx1ZSAiYXBwbGljYXRpb24vY29t bS1kaXYtaW5mbyt4bWwiLiAgIAo8L3A+CjxhIG5hbWU9Ik5vdGlmaWVyUCI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjYuNiI+PC9hPjxoMz42LjYuJm5ic3A7Ck5vdGlmaWVyIFByb2Nlc3Np bmcgb2YgU1VCU0NSSUJFIHJlcXVlc3RzPC9oMz4KCjxwPgpUaGUgY29udGVudHMgb2YgYSBkb2N1 bWVudCBjb250YWluaW5nIGNvbW0tZGl2LWluZm8gaW5mb3JtYXRpb24gY2FuIGNvbnRhaW4gc2Vu c2l0aXZlIGluZm9ybWF0aW9uIHRoYXQgY2FuIHJldmVhbCBzb21lIHByaXZhY3kgCmluZm9ybWF0 aW9uLiAgVGhlcmVmb3JlLCBzdWNoIGNvbW0tZGl2LWluZm8gZG9jdW1lbnRzIE1VU1Qgb25seSBi ZSBzZW50IHRvIGF1dGhvcml6ZWQgc3Vic2NyaWJlcnMuIEluIG9yZGVyIHRvIGRldGVybWluZSBp ZiBhIApzdWJzY3JpcHRpb24gb3JpZ2luYXRlcyBpbiBhbiBhdXRob3JpemVkIHVzZXIsIHRoZSBz dWJzY3JpYmVyIE1VU1QgYmUgYXV0aGVudGljYXRlZCBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNBdXRoJz5TZWN0aW9uJm5ic3A7Ni42LjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QXV0aGVudGljYXRpb248L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CmFu ZCB0aGVuIHRoZSB1c2VyIE1VU1QgYmUgYXV0aG9yaXplZCB0byBiZSBhIHN1YnNjcmliZXIgYXMg ZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjQXV0aG8nPlNlY3Rpb24mbmJzcDs2 LjYuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPi4KCjwvcD4KPGEgbmFtZT0iQXV0aCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjYuNi4xIj48L2E+PGgzPjYuNi4xLiZuYnNwOwpBdXRoZW50aWNhdGlvbjwv aDM+Cgo8cD5Ob3RpZmllcnMgTVVTVCBhdXRoZW50aWNhdGUgYWxsIHN1YnNjcmlwdGlvbiByZXF1 ZXN0cy4gIFRoaXMgYXV0aGVudGljYXRpb24gY2FuIGJlIGRvbmUgdXNpbmcgYW55IG9mIHRoZSBt ZWNoYW5pc21zIGRlZmluZWQgaW4KPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMjYxJz5bNV08 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Um9zZW5iZXJnLCBKLiwgU2NodWx6cmlu bmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2huc3RvbiwgQS4sIFBldGVyc29uLCBKLiwgU3Bhcmtz LCBSLiwgSGFuZGxleSwgTS4sIGFuZCBFLiBTY2hvb2xlciwgJmxkcXVvO1NJUDogU2Vzc2lvbiBJ bml0aWF0aW9uIFByb3RvY29sLCZyZHF1bzsgSnVuZSZuYnNwOzIwMDIuPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiBhbmQgb3RoZXIgYXV0aGVudGljYXRpb24gZXh0ZW5zaW9ucy4KCjwvcD4KPGEg bmFtZT0iQXV0aG8iPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42LjYuMiI+PC9hPjxoMz42 LjYuMi4mbmJzcDsKQXV0aG9yaXphdGlvbjwvaDM+Cgo8cD4gT25jZSBhdXRoZW50aWNhdGVkLCB0 aGUgbm90aWZpZXIgbWFrZXMgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbi4gIEEgbm90aWZpZXIg TVVTVCBOT1QgYWNjZXB0IGEgc3Vic2NyaXB0aW9uIHVubGVzcyAKYXV0aG9yaXphdGlvbiBoYXMg YmVlbiBwcm92aWRlZCBieSB0aGUgdXNlci4gIFRoZSBtZWFucyBieSB3aGljaCBhdXRob3JpemF0 aW9uIGFyZSBwcm92aWRlZCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4g CkF1dGhvcml6YXRpb24gbWF5IGhhdmUgYmVlbiBwcm92aWRlZCBhaGVhZCBvZiB0aW1lIHRocm91 Z2ggYWNjZXNzIGxpc3RzLCBwZXJoYXBzIHNwZWNpZmllZCBpbiBhIHdlYiBwYWdlLiAgQXV0aG9y aXphdGlvbiBtYXkgaGF2ZSAKYmVlbiBwcm92aWRlZCBieSBtZWFucyBvZiB1cGxvYWRpbmcgc29t ZSBraW5kIG9mIHN0YW5kYXJkaXplZCBhY2Nlc3MgY29udHJvbCBsaXN0IGRvY3VtZW50Cgo8L3A+ CjxhIG5hbWU9Ik5vdGlmaWVyRyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuNyI+PC9h PjxoMz42LjcuJm5ic3A7Ck5vdGlmaWVyIEdlbmVyYXRpb24gb2YgTk9USUZZIHJlcXVlc3RzPC9o Mz4KCjxwPiBUaGUgU0lQIEV2ZW50cyBzcGVjaWZpY2F0aW9uIGRldGFpbHMgdGhlIGZvcm1hdHRp bmcgYW5kIHN0cnVjdHVyZSBvZiBOT1RJRlkgbWVzc2FnZXMuIEhvd2V2ZXIsIHBhY2thZ2VzIGFy ZSBtYW5kYXRlZCB0byBwcm92aWRlIApkZXRhaWxlZCBpbmZvcm1hdGlvbiBvbiB3aGVuIHRvIHNl bmQgYSBOT1RJRlksIGhvdyB0byBjb21wdXRlIHRoZSBzdGF0ZSBvZiB0aGUgcmVzb3VyY2UsIGhv dyB0byBnZW5lcmF0ZSBuZXV0cmFsIG9yIGZha2Ugc3RhdGUgaW5mb3JtYXRpb24sCmFuZCB3aGV0 aGVyIHN0YXRlIGluZm9ybWF0aW9uIGlzIGNvbXBsZXRlIG9yIHBhcnRpYWwuICBUaGlzIHNlY3Rp b24gZGVzY3JpYmVzIHRob3NlIGRldGFpbHMgZm9yIHRoZSAiY29tbS1kaXYtaW5mbyIgZXZlbnQg cGFja2FnZS4KPGJyIC8+CjxiciAvPgoKQSBub3RpZmllciBNQVkgc2VuZCBhIE5PVElGWSBhdCBh bnkgdGltZS4gIFR5cGljYWxseSwgaXQgd2lsbCBzZW5kIG9uZSB3aGVuIGEgY29tbXVuaWNhdGlv biBkaXZlcnNpb24gaXMgZW5hY3RlZCBvbiBiZWhhbGYgb2YgdGhlIHVzZXIuICAKVGhlIE5PVElG WSByZXF1ZXN0IE1BWSBjb250YWluIGEgYm9keSBjb250YWluaW5nIGEgY29tbS1kaXYtaW5mbyBk b2N1bWVudC4gIFRoZSB0aW1lcyBhdCB3aGljaCB0aGUgTk9USUZZIGlzIHNlbnQgZm9yIGEgcGFy dGljdWxhciAKc3Vic2NyaWJlciwgYW5kIHRoZSBjb250ZW50cyBvZiB0aGUgYm9keSB3aXRoaW4g dGhhdCBub3RpZmljYXRpb24sIGFyZSBzdWJqZWN0IHRvIGFueSBydWxlcyBzcGVjaWZpZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gcG9saWN5IAp0aGF0IGdvdmVybnMgdGhlIHN1YnNjcmlwdGlvbiBh bmQgdG8gcHJlZmVyZW5jZXMgaW5kaWNhdGVkIGF0IHRoZSB0aW1lIG9mIHN1YnNjcmlwdGlvbi4K PGJyIC8+CjxiciAvPgoKVGhlIGJvZHkgb2YgdGhlIE5PVElGWSBNVVNUIGJlIHNlbnQgdXNpbmcg dGhlIHR5cGUgImFwcGxpY2F0aW9uL2NvbW0tZGl2LWluZm8reG1sIi4KPGJyIC8+CjxiciAvPgoK Tm90aWZpZXJzIGNvdWxkIGRldGVjdCB0aGF0IGEgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24gd2Fz IGVuYWN0ZWQgb24gYmVoYWxmIG9mIHRoZSBzdWJzY3JpYmVyIHZpYSBhICJIaXN0b3J5LUluZm8i IGhlYWRlciBmaWVsZCAKdmFsdWUsIHBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nIzNHUFAuMjQu NDA0Jz5bMl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+M0dQUCwgJmxkcXVvO1RJ U1BBTjsgUFNUTi9JU0ROIHNpbXVsYXRpb24gc2VydmljZXM6IENvbW11bmljYXRpb24gRGl2ZXJz aW9uIChDRElWKTsgUHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwmcmRxdW87IEp1bmUmbmJzcDsyMDA5 Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gb3IgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyMzR1BQ LjI0LjYwNCc+WzFdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPjNHUFAsICZsZHF1 bztDb21tdW5pY2F0aW9uIERpdmVyc2lvbiAoQ0RJVikgdXNpbmcgSVAgTXVsdGltZWRpYSAoSU0p Q29yZSBOZXR3b3JrIChDTikgc3Vic3lzdGVtOyAgUHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwmcmRx dW87IERlY2VtYmVyJm5ic3A7MjAwOS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBzZW50IGZy b20gYW4gYXBwbGljYXRpb24gc2VydmVyIGhvc3RpbmcgCnRoZSBDRElWIGFwcGxpY2F0aW9uLiAK PGJyIC8+CjxiciAvPgoKSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgbm90aWZpZXJzIGRvIG1h aW50YWluIHRoZSBoaXN0b3J5IG9mIGxhc3QgTiBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbnMgdGhh dCBvY2N1cnJlZCwgd2hlcmUgdGhlIHZhbHVlIE4gPj0xIGFzCnBhcnQgb2Ygc3RhdGUgaW5mb3Jt YXRpb24gZm9yIHRoYXQgc2VydmVyLiBUaGUgdmFsdWUgb2YgTiBjb3VsZCBiZSBjb25maWd1cmVk IGFuZCBpcyBsZWZ0IHRvIHNlcnZlciBwb2xpY3kgdG8gZGV0ZXJtaW5lIGFwcHJvcHJpYXRlIHZh bHVlLiAKPGJyIC8+CjxiciAvPgoKVGhlIHN0YXRlIGluZm9ybWF0aW9uIGlzIHJldGFpbmVkIGV2 ZW4gYWZ0ZXIgdGhlIG5vdGlmaWNhdGlvbiBmb3IgdGhvc2UgZGl2ZXJzaW9ucyBhcmUgc2VudCB0 byB0aGUgc3Vic2NyaWJlciBhbmQgY2hhbmdlcyB3aGVuIG5ldyBkaXZlcnNpb24gCm9jY3Vycy4g U28gZXZlcnkgdGltZSBhIG5ldyBkaXZlcnNpb24gb2NjdXJzLCB0aGUgc3RhdGUgaW5mb3JtYXRp b24gY2hhbmdlcyB0byByZWZsZWN0IHRoZSBsYXRlc3QgZGl2ZXJzaW9uIHJlbW92aW5nIHRoZSBv bGRlc3QgZGl2ZXJzaW9uIAppbmZvcm1hdGlvbi4KIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjE0Ij48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi44Ij48L2E+PGgzPjYuOC4mbmJzcDsKU3Vic2Ny aWJlciBQcm9jZXNzaW5nIG9mIE5PVElGWSBSZXF1ZXN0czwvaDM+Cgo8cD4gVGhlIFNJUCBFdmVu dHMgc3BlY2lmaWNhdGlvbiBleHBlY3RzIGV2ZW50IHBhY2thZ2VzIHRvIGRlc2NyaWJlIHRoZSBw cm9jZXNzIGZvbGxvd2VkIGJ5IHRoZSBzdWJzY3JpYmVyIHVwb24gcmVjZWlwdCBvZiBhIApOT1RJ RlkgcmVxdWVzdC4gSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCBlYWNoIE5PVElGWSByZXF1ZXN0IGNv bnRhaW5zIGEgY29tbS1kaXYtaW5mbyBkb2N1bWVudAoKPC9wPgo8YSBuYW1lPSJhbmNob3IxNSI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuOSI+PC9hPjxoMz42LjkuJm5ic3A7CkhhbmRs aW5nIG9mIEZvcmtlZCBSZXF1ZXN0czwvaDM+Cgo8cD4gVGhlIFNJUCBFdmVudHMgc3BlY2lmaWNh dGlvbiByZXF1aXJlcyBlYWNoIHBhY2thZ2UgdG8gZGVzY3JpYmUgaGFuZGxpbmcgb2YgZm9ya2Vk IFJlcXVlc3RzLiAKPGJyIC8+CjxiciAvPgoKVGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgYWxsb3dz IGEgc2luZ2xlIGRpYWxvZyB0byBiZSBjb25zdHJ1Y3RlZCBhcyBhIHJlc3VsdCBvZiBlbWl0dGlu ZyBhbiBpbml0aWFsIFNVQlNDUklCRSByZXF1ZXN0LiAgClRoaXMgZ3VhcmFudGVlcyB0aGF0IG9u bHkgYSBzaW5nbGUgbm90aWZpZXIgaXMgZ2VuZXJhdGluZyBub3RpZmljYXRpb25zIGZvciBhIHBh cnRpY3VsYXIgc3Vic2NyaXB0aW9uIHRvIGEgcGFydGljdWxhciB1c2VyLgoKPC9wPgo8YSBuYW1l PSJhbmNob3IxNiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjYuMTAiPjwvYT48aDM+Ni4x MC4mbmJzcDsKUmF0ZSBvZiBOb3RpZmljYXRpb25zPC9oMz4KCjxwPgpUaGUgU0lQIEV2ZW50cyBz cGVjaWZpY2F0aW9uIHJlcXVpcmVzIGVhY2ggcGFja2FnZSB0byBzcGVjaWZ5IG1heGltdW0gcmF0 ZSBhdCB3aGljaCBub3RpZmljYXRpb25zIGNhbiBiZSBzZW50IC4gCjxiciAvPgo8YnIgLz4KCkNv bW0tZGl2LWluZm8gbm90aWZpZXJzIFNIT1VMRCBOT1QgZ2VuZXJhdGUgbm90aWZpY2F0aW9ucyBm b3IgYQogIHNpbmdsZSBzdWJzY3JpcHRpb24gYXQgYSByYXRlIG9mIG1vcmUgdGhhbiBvbmNlIGV2 ZXJ5IGZpdmUgc2Vjb25kcy4KCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTciPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi42LjExIj48L2E+PGgzPjYuMTEuJm5ic3A7ClN0YXRlIEFnZW50czwvaDM+ Cgo8cD4KVGhlIG5vdGlpZmVycyBtYWludGFpbiB0aGUgc3RhdGUgb2YgbGFzdCBOIGNvbW11bmlj YXRpb24gZGl2ZXJzaW9ucywgd2hlcmUgTj49MSB0aGF0IG9jY3VycmVkIGluIHRoZSBuZXR3b3Jr IG9uIGJlaGFsZiBvZiB0aGUKc3Vic2NyaWJlciBldmVuIGFmdGVyIHRoZSBub3RpZmljYXRpb25z IGZvciB0aG9zZSBOIGNvbW11bmljYXRpb25zIGRpdmVyc2lvbnMgYXJlIHNlbnQgb3IgdW5zZW50 LiBUaGlzIHN0YXRlIGluZm9ybWF0aW9uIGdldHMKdXBkYXRlZCB3aXRoIHRoZSBsYXRlc3QgY29t bXVuaWNhdGlvbiBkaXZlcnNpb24gdGhhdCBvY2N1cnMgYnkgcmVtb3ZpbmcgdGhlIG9sZGVzdCBj b21tdW5pY2F0aW9uIGRpdmVyc2lvbiBhbmQgYWRkaW5nIHRoZSBsYXRlc3QKZGl2ZXJzaW9uIHdo aWxlIG1haW50YWluaW5nIHRoZSBudW1iZXIgb2YgZGl2ZXJzaW9ucyBhdCBOLgo8YnIgLz4KPGJy IC8+CgpUaHVzIGF0IGFueSBwb2ludCBvZiB0aW1lIGEgc3Vic2NyaWJlciBNQVkga25vdyB0aGUg c3RhdGUgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb25zIGVuYWN0ZWQgb24gaGlzIG9yIGhlciBi ZWhhbGYgYnkgdGhlIHNlcnZlci4KCjwvcD4KPGEgbmFtZT0iQ29tbS1kaXYtaW5mbyI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjciPjwvYT48aDM+Ny4mbmJzcDsKQ29tbS1kaXYtaW5mbyBE b2N1bWVudDwvaDM+Cgo8cD4gQ29tbS1kaXYtaW5mbyBkb2N1bWVudCBpcyBhbiBYTUwgZG9jdW1l bnQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNXM0MuUkVDLXhtbC0yMDAwMTAwNic+WzhdPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJyYXksIFQuLCBTcGVyYmVyZy1NY1F1ZWVuLCBD LiwgTWFsZXIsIEUuLCBhbmQgSi4gUGFvbGksICZsZHF1bztFeHRlbnNpYmxlIE1hcmt1cCBMYW5n dWFnZSAoWE1MKSAxLjAgKFNlY29uZCBFZGl0aW9uKSwmcmRxdW87IE9jdG9iZXImbmJzcDsyMDAw Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gdGhhdCBNVVNUIGJlIHdlbGwtZm9ybWVkCmFuZCBT SE9VTEQgYmUgdmFsaWQuIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIEluZm9ybWF0aW9uIGRvY3Vt ZW50cyBNVVNUIGJlIGJhc2VkIG9uIFhNTCAxLjAgYW5kIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBV VEYtOCAKPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NzQ1Jz5bOV08c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+U2NodWx6cmlubmUsIEguLCBUc2Nob2ZlbmlnLCBILiwgTW9ycmlz LCBKLiwgQ3VlbGxhciwgSi4sIFBvbGssIEouLCBhbmQgSi4gUm9zZW5iZXJnLCAmbGRxdW87Q29t bW9uIFBvbGljeTogQSBEb2N1bWVudCBGb3JtYXQgZm9yIEV4cHJlc3NpbmcgUHJpdmFjeSBQcmVm ZXJlbmNlcywmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAwNy48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LiAgIAo8L3A+CjxhIG5hbWU9ImNvbW0tZGl2LWluZm8tZG9jIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uOCI+PC9hPjxoMz44LiZuYnNwOwpTdHJ1Y3R1cmUgb2YgQ29tbS1kaXYtaW5m byBGb3JtYXQ8L2gzPgoKPHA+QSBDb21tdW5pY2F0aW9ucyBEaXZlcnNpb24gSW5mb3JtYXRpb24g ZG9jdW1lbnQgc3RhcnRzIHdpdGggYSAiY29tbS1kaXYtaW5mbyIgZWxlbWVudC4gCiBUaGUgY29t bS1kaXYtaW5mbyBlbGVtZW50IGhhcyBhIHNlcmllcyBvZiBlbGVtZW50cyBkZXNjcmliaW5nIHRo ZSBwYXJ0aWN1bGFyIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIG9yIHRoZSBmaWx0ZXIgY3JpdGVy aWEgZm9yCiByZWNlaXZpbmcgdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGluZm9ybWF0aW9u LiAgCjwvcD4KPGEgbmFtZT0iY29tbS1kaXYtaW5mby1lbGUiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi44LjEiPjwvYT48aDM+OC4xLiZuYnNwOwpDb21tLWRpdi1pbmZvIEVsZW1lbnQ8L2gz PgoKPHA+IFRoZSBjb21tLWRpdi1pbmZvIGVsZW1lbnQgZ2l2ZXMgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHNwZWNpZmljIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIG9yIGl0IGNvdWxkIGdpdmUgaW5m b3JtYXRpb24gCiAgICBhYm91dCBhIHBhcnRpY3VsYXIgc2VsZWN0aW9uIGNyaXRlcmlhIGZvciB0 aGUgdXNlciByZWNlaXZpbmcgdGhlIGNvbW11bmljYXRpb24gZGl2ZXJzaW9uIGluZm9ybWF0aW9u LiAgIAo8L3A+CjxhIG5hbWU9ImNvbW0tZGl2LXN1YnMtaW5mbyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjguMS4xIj48L2E+PGgzPjguMS4xLiZuYnNwOwpjb21tLWRpdi1zdWJzLWluZm8g RWxlbWVudDwvaDM+Cgo8cD5UaGUgY29tbS1kaXYtc3Vicy1pbmZvIGVsZW1lbnQgaXMgdXNlZCBi eSB0aGUgc3Vic2NyaWJpbmcgdXNlciB0byBzcGVjaWZ5IHRoZSBjb21tdW5pY2F0aW9uIGRpdmVy c2lvbiBpbmZvcm1hdGlvbgogICAgICAgICAgIHNlbGVjdGlvbiBjcml0ZXJpYSBhbmQgdGhlIGNv bW11bmljYXRpb24gZGl2ZXJzaW9uIG5vdGlmaWNhdGlvbiB0cmlnZ2VyIGNyaXRlcmlhLiBJdCBj b250YWlucyB0aGUgZm9sbG93aW5nIGVsZW1lbnRzOgogICAgICAgIAo8L3A+CjxhIG5hbWU9InNl bCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMS4xLjEiPjwvYT48aDM+OC4xLjEuMS4m bmJzcDsKY29tbS1kaXYtc2VsZWN0aW9uLWNyaXRlcmlhPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQg Y29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24gaW5mb3Jt YXRpb24gc2VsZWN0aW9uIGNyaXRlcmlhLiBJdCBjb250YWlucwogICAgICAgICAgICAgIGZvbGxv d2luZyBzdWItZWxlbWVudHMgZm9yIHNwZWNpZnlpbmcgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYS4g CjwvcD4KPGEgbmFtZT0ib3JpZyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMS4xLjEu MSI+PC9hPjxoMz44LjEuMS4xLjEuJm5ic3A7Cm9yaWdpbmF0aW5nLXVzZXItc2VsZWN0aW9uLWNy aXRlcmlhPC9oMz4KCjxwPlRoaXMgZWxlbWVudCBzcGVjaWZpZXMgdGhlIG9yaWdpbmF0aW5nIHVz ZXIgaW5mb3JtYXRpb24gZm9yIHRoZSBjb21tdW5pY2F0aW9uIGkuZS4gdGhlIGNhbGxlci4gVGhp cyBpcyBzcGVjaWZpZWQKICAgICAgICAgICAgICAgICAgIGluIHRoZSBmb3JtIG9mICJ1c2VyLW5h bWUiIGFuZCAidXNlci11cmkiLiBFLmcuIHNpcDpBbGljZUBkb21haW4uY29tLiBUaGUgVXNlcm5h bWUgYXMgd2VsbCBhcyBVc2VyLVVSSSBzcGVjaWZpZWQKICAgICAgICAgICAgICAgICAgIHdpbGwg YmUgY29tcGFyZWQgd2l0aCB0aGUgb3JpZ2luYXRpbmcgdXNlciBpbmZvcm1hdGlvbiBvZiB0aGUg Y3VycmVudCB1c2VyIGFuZCBpZiB0aGVyZSBpcyBhIG1hdGNoLCB0aGVuCiAgICAgICAgICAgICAg ICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGl2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWMgY29t bXVuaWNhdGlvbiB3b3VsZCBiZSBzZWxlY3RlZCBmb3Igbm90aWZpY2F0aW9uIHRvIHRoZQogICAg ICAgICAgICAgICAgICAgRGl2ZXJ0aW5nIHVzZXIuIEl0IGNvbnNpc3RzIG9mIHRoZSBmb2xsb3dp bmcgc3ViLWVsZW1lbnRzLiAKPC9wPgo8YSBuYW1lPSJ1aS1pbmZvIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uOC4xLjEuMS4xLjEiPjwvYT48aDM+OC4xLjEuMS4xLjEuJm5ic3A7CnVzZXIt aW5mbzwvaDM+Cgo8cD5UaGlzIGVsZW1lbnQgZ2l2ZXMgdXNlciBkZXRhaWxzIGxpa2UgdXNlcm5h bWUgYW5kIFVSSS4gVGhpcyBlbGVtZW50IGhhcyBmdXJ0aGVyIHN1Yi1lbGVtZW50cyBmb3IKICAg ICAgICAgICAgICAgICAgICAgZGVzY3JpYmluZyB1c2VybmFtZSBhbmQgdXNlciBVUkkKPC9wPgo8 YSBuYW1lPSJ1dSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMS4xLjEuMS4xLjEiPjwv YT48aDM+OC4xLjEuMS4xLjEuMS4mbmJzcDsKVXNlci1uYW1lPC9oMz4KCjxwPiBUaGlzIGVsZW1l bnQgZ2l2ZXMgVXNlcm5hbWUuICJBbGljZSIuIAo8L3A+CjxhIG5hbWU9InVpIj48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uOC4xLjEuMS4xLjEuMiI+PC9hPjxoMz44LjEuMS4xLjEuMS4yLiZu YnNwOwpVc2VyLVVSSTwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIFVzZXIgVVJJLiBFLmcg InNpcDpBbGljZUBkb21haW4uY29tIi4gSXQgdGFrZXMgdGhlIGZvcm0gb2YgYW55IFVSSSBzY2hl bWUgbGlrZSBzaXAuCiAgICAgICAgICAgICAgICAgICAgICAgIHNpcHMsIHRlbCBvciBhbnkgb3Ro ZXIgVVJJIHNjaGVtZQo8L3A+CjxhIG5hbWU9ImRpdi10aW1lLXNlbCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjguMS4xLjEuMiI+PC9hPjxoMz44LjEuMS4xLjIuJm5ic3A7CmRpdmVyc2lv bi10aW1lLXNlbGVjdGlvbi1jcml0ZXJpYTwvaDM+Cgo8cD5UaGlzIGVsZW1lbnQgc3BlY2lmaWVz IHRoZSB0aW1lIHJhbmdlIGZvciByZWNlaXZpbmcgbm90aWZpY2F0aW9ucy4gSXQgY29udGFpbnMg Zm9sbG93aW5nIGFkZGl0aW9uYWwgZWxlbWVudHMKICAgICAgICAgICAgICAgICAgICAuCjwvcD4K PGEgbmFtZT0idGltZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMS4xLjEuMi4xIj48 L2E+PGgzPjguMS4xLjEuMi4xLiZuYnNwOwp0aW1lLXJhbmdlPC9oMz4KCjxwPiBUaGlzIGVsZW1l bnQgc3BlY2lmaWVzIHRoZSB0aW1lIHJhbmdlIGF0IHdoaWNoIG5vdGlmaWNhdGlvbnMgZm9yIGNv bW11bmljYXRpb24gZGl2ZXJzaW9ucyBjYW4gYmUgc2VudAogICAgICAgICAgICAgICAgICAgICAg ICB0byB0aGUgc3Vic2NyaWJlci4gVGhpcyBjb3VsZCBiZSBzcGVjaWZpZWQgaW4gdGhlIGZvcm0g b2YgYSB0aW1lLWludGVydmFsIHRvIGVuYWJsZSBwZXJpb2RpYyB0cmlnZ2VyaW5nCiAgICAgICAg ICAgICAgICAgICAgICAgIG9mIG5vdGlmaWNhdGlvbnMgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNp b25zIHdoaWNoIHRvb2sgcGxhY2UgaW4gdGhhdCB0aW1lLWludGVydmFsLiAKICAgICAgICAgICAg ICAgICAgICAgICAgPGJyIC8+CjxiciAvPgoKICAgICAgICAgICAgICAgICAgICAgICAgTk9URTog SWYgdGhlIHRpbWUtcmFuZ2UgZWxlbWVudCBpcyBub3Qgc3BlY2lmaWVkLCB0aGVuIG5vdGlmaWNh dGlvbnMgYWJvdXQgZXZlcnkgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24KICAgICAgICAgICAgICAg ICAgICAgICAgdGhhdCBvY2N1cnMgaXMgc2VudCB0byB0aGUgc3Vic2NyaWJlci4KICAgICAgICAg ICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJzdGFydCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjguMS4xLjEuMi4xLjEiPjwvYT48aDM+OC4xLjEuMS4yLjEuMS4mbmJzcDsKc3RhcnQtdGlt ZTwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IHNwZWNpZmllcyB0aGUgc3RhcnQgdGltZSBmb3IgcmVj ZWl2aW5nIG5vdGlmaWNhdGlvbnMuIEl0cyB2YWx1ZSBpcyBleHByZXNzZWQgaW4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFlZWVk6TU06RERUSEg6TU06U1NaIGZvcm1hdC4KPC9wPgo8YSBu YW1lPSJlbmQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMS4xLjIuMS4yIj48L2E+ PGgzPjguMS4xLjEuMi4xLjIuJm5ic3A7CmVuZC10aW1lPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQg c3BlY2lmaWVzIHRoZSBlbmQgdGltZSBmb3IgcmVjZWl2aW5nIG5vdGlmaWNhdGlvbnMuIEl0cyB2 YWx1ZSBpcyBleHByZXNzZWQgaW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZWVlZOk1N OkREVEhIOk1NOlNTWiBmb3JtYXQuICAKPC9wPgo8YSBuYW1lPSJkaXZpbmctdXNlci1zZWwiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMS4xLjMiPjwvYT48aDM+OC4xLjEuMS4zLiZu YnNwOwpkaXZlcnRpbmctdXNlci1zZWxlY3Rpb24tY3JpdGVyaWE8L2gzPgoKPHA+IFRoaXMgZWxl bWVudCBnaXZlcyBkZXRhaWxzIG9mIGRpdmVydGluZyB1c2VyLiBUaGlzIGVsZW1lbnQgY291bGQg Y29udGFpbiB0aGUgdmFsdWUgcHJlc2VudCBpbiBQLUNhbGxlZC1QYXJ0eS1JRAogICAgICAgICAg ICAgICAgICAgICBoZWFkZXIgZmllbGQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMiBvZiA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzM0NTUnPlsxMF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+R2FyY2lhLU1hcnRpbiwgTS4sIEhlbnJpa3NvbiwgRS4sIGFuZCBELiBNaWxscywg JmxkcXVvO1ByaXZhdGUgSGVhZGVyIChQLUhlYWRlcikgRXh0ZW5zaW9ucyB0byB0aGUgU2Vzc2lv biBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIGZvciB0aGUgM3JkLUdlbmVyYXRpb24gUGFydG5l cnNoaXAgUHJvamVjdCAoM0dQUCksJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAwMy48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+IGFuZCBieSBpbmNsdWRpbmcgdGhlIGlkZW50aXR5IGluIHRoZSAiZGl2 ZXJ0aW5nLXVzZXItaW5mbyIsIAogICAgICAgICAgICAgICAgICAgICBUaGUgVUEgaWRlbnRpZmll cyB3aGljaCBhZGRyZXNzLW9mLXJlY29yZCwgb3V0IG9mIHNldmVyYWwgcmVnaXN0ZXJlZCBhZGRy ZXNzLW9mLXJlY29yZHMsIHRoZSBpbnZpdGF0aW9uIHdhcyBzZW50IHRvCiAgICAgICAgICAgICAg ICAgICAgIHdoZW4gaXQgd2FzIGRpdmVydGVkIChmb3IgZXhhbXBsZSwgdGhlIHVzZXIgbWF5IGJl IHNpbXVsdGFuZW91c2x5IHVzaW5nIGEgcGVyc29uYWwgYW5kIGEgYnVzaW5lc3MgU0lQIFVSSXMg dG8gCiAgICAgICAgICAgICAgICAgICAgIHJlY2VpdmUgaW52aXRhdGlvbiB0byBzZXNzaW9ucyku ICBUaGUgVVJJIHNwZWNpZmllZCBvdmVyIGhlcmUgd2lsbCBiZSBjb21wYXJlZCB3aXRoIHRoZSBS ZXF1ZXN0IFVSSSBvZiB0aGUgZGl2ZXJ0aW5nIAogICAgICAgICAgICAgICAgICAgICB1c2VyIGZv ciB3aG9tIGEgY29tbXVuaWNhdGlvbiBoYXMgYmVlbiBkaXZlcnRlZC4gIE9ubHkgaWYgdGhlcmUg aXMgYSBtYXRjaCwgdGhlbiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGl2ZXJzaW9uIG9mIAogICAg ICAgICAgICAgICAgICAgICB0aGlzIHNwZWNpZmljIGNvbW11bmljYXRpb24gd291bGQgYmUgc2Vs ZWN0ZWQgZm9yIG5vdGlmaWNhdGlvbiB0byB0aGUgZGl2ZXJ0aW5nIHVzZXIuICBUaGlzIGlzIGFu IG9wdGlvbmFsIHBhcmFtZXRlci4gCiAgICAgICAgICAgICAgICAgICAgIElmIGFic2VudCwgdGhl biBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbnMgdG93YXJkcyBhbGwgcmVnaXN0ZXJlZCBjb250YWN0 cyBvZiB0aGUgc3Vic2NyaWJpbmcgdXNlciB3b3VsZCBiZSBjb25zaWRlcmVkIAogICAgICAgICAg ICAgICAgICAgICBmb3Igbm90aWZpY2F0aW9uLCBzdWJqZWN0IHRvIG90aGVyIGZpbHRlciBjcml0 ZXJpYS4gVGhpcyBlbGVtZW50IGNvbnNpc3RzIG9mIHN1Yi1lbGVtZW50cyBkZWZpbmVkIGZvciAi dXNlci1pbmZvIiAKICAgICAgICAgICAgICAgICAgICAgZWxlbWVudCA8YSBjbGFzcz0naW5mbycg aHJlZj0nI3V1Jz5TZWN0aW9uJm5ic3A7OC4xLjEuMS4xLjEuMTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5Vc2VyLW5hbWU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CiAgICAgICAg ICAgICAgICAgCjwvcD4KPGEgbmFtZT0iZGl2ZWQtdXNlci1zZWwiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi44LjEuMS4xLjQiPjwvYT48aDM+OC4xLjEuMS40LiZuYnNwOwpkaXZlcnRlZC10 by11c2VyLXNlbGVjdGlvbi1jcml0ZXJpYTwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIGRl dGFpbHMgb2YgdGhlIGZpbmFsIHRhcmdldCBvZiB0aGUgY29tbXVuaWNhdGlvbiwgdGhlIGRpdmVy ZWQtdG8gdXNlci4gIFRoZSBVUkkKICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWVkIGluIHRo ZSBSZXF1ZXN0IFVSSSBvZiB0aGUgbmV3IHJlcXVlc3QgaXMgY29tcGFyZWQgd2l0aCB0aGUgc3Bl Y2lmaWVkIGRpdmVydGVkLXRvIFVSSS4gT25seSBpZgogICAgICAgICAgICAgICAgICAgICB0aGVy ZSBpcyBhIG1hdGNoLCB0aGVuIGluZm9ybWF0aW9uIGFib3V0IHRoZSBkaXZlcnNpb24gb2YgdGhp cyBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIHdvdWxkIGJlIHNlbGVjdGVkIAogICAgICAgICAgICAg ICAgICAgICBmb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBEaXZlcnRpbmcgdXNlci4gVGhpcyBlbGVt ZW50IGNvbnNpc3RzIG9mIHN1Yi1lbGVtZW50cyBkZWZpbmVkIGZvciAidXNlci1pbmZvIiBlbGVt ZW50CiAgICAgICAgICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdXUnPlNlY3Rp b24mbmJzcDs4LjEuMS4xLjEuMS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlVz ZXItbmFtZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgICAgCjwvcD4K PGEgbmFtZT0iZGl2LXJlYS1zZWwiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMS4x LjUiPjwvYT48aDM+OC4xLjEuMS41LiZuYnNwOwpkaXZlcnNpb24tcmVhc29uLXNlbGVjdGlvbi1j cml0ZXJpYTwvaDM+Cgo8cD5UaGlzIGVsZW1lbnQgY29udGFpbnMgdGhlIHJlYXNvbiBmb3IgY29t bXVuaWNhdGlvbiBkaXZlcnNpb24uIEl0IGNvbnRhaW5zIGZvbGxvd2luZyBzdWItZWxlbWVudDog CjwvcD4KPGEgbmFtZT0iZGl2LXJlYXNvbiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjgu MS4xLjEuNS4xIj48L2E+PGgzPjguMS4xLjEuNS4xLiZuYnNwOwpkaXZlcnNpb24tcmVhc29uLWlu Zm88L2gzPgoKPHA+IFRoaXMgZWxlbWVudCBnaXZlcyB0aGUgYWN0dWFsIHJlYXNvbiBmb3IgdGhl IGNvbW11bmljYXRpb24gZGl2ZXJzaW9uLiBFLmcuICJDYWxsIEZvcndhcmQgb24gQnVzeSIuCjwv cD4KPGEgbmFtZT0iY29tbS1kaXYtbnRmeS10cmkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi44LjEuMS4yIj48L2E+PGgzPjguMS4xLjIuJm5ic3A7CmNvbW0tZGl2LW50ZnktdHJpZ2dlci1j cml0ZXJpYTwvaDM+Cgo8YSBuYW1lPSJudGZ5LXRpbWUtc2VsIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uOC4xLjEuMi4xIj48L2E+PGgzPjguMS4xLjIuMS4mbmJzcDsKbm90aWZpY2F0aW9u LXRpbWUtc2VsZWN0aW9uLWNyaXRlcmlhPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQgaW5mb3JtcyB0 aGUgc2VydmVyIGFib3V0IHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBub3RpZmljYXRpb24gc2hvdWxk IGJlIHRyaWdnZXJlZC4gCjwvcD4KPGEgbmFtZT0icHJlcy1zZWwiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi44LjEuMS4yLjIiPjwvYT48aDM+OC4xLjEuMi4yLiZuYnNwOwpwcmVzZW5jZS1z dGF0dXMtc2VsZWN0aW9uLWNyaXRlcmlhPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQgZ2l2ZXMgdGhl IHByZXNlbmNlIHN0YXR1cyBvZiB0aGUgc3Vic2NyaWJlciwgYmFzZWQgb24gd2hpY2ggdGhlIGRl Y2lzaW9uIGNhbiBiZSBtYWRlLCB3aGV0aGVyIHRoZQogICAgICAgICAgICAgICAgIHN1YnNjcmli ZXIgd2lzaGVzIHRvIHJlY2VpdmUgbm90aWZpY2F0aW9uIGluZm9ybWF0aW9uIG9yIG5vdC4gCjwv cD4KPGEgbmFtZT0icHJlcy1pbmZvIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4xLjEu Mi4yLjEiPjwvYT48aDM+OC4xLjEuMi4yLjEuJm5ic3A7CnByZXNlbmNlLXNlbGVjdGlvbi1pbmZv PC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQgc3BlY2lmaWVzIHRoZSBwcmVzZW5jZSBzdGF0dXMgb2Yg dGhlIHN1YnNjcmliZXIgd2l0aGluIHdoaWNoIHRoZSBzdWJzY3JpYmVyIGV4cGVjdHMgdG8gcmVj ZWl2ZSAKICAgICAgICAgICAgICAgICAgIG5vdGlmaWNhdGlvbnMgYWJvdXQgY29tbXVuaWNhdGlv biBkaXZlcnNpb25zLgogICAgICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJub3QtYnUiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMS4yLjMiPjwvYT48aDM+OC4xLjEuMi4zLiZuYnNw Owpub3RpZmljYXRpb24tYnVmZmVyLWludGVydmFsPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQgc3Bl Y2lmaWVzIGFuIG9wdGlvbmFsIGVsZW1lbnQgKGluIHNlY29uZHMpIHRvIG92ZXJ3cml0ZSB0aGUg Q0RJVk4gQnVmZmVyIFRpbWVyIGZvciB3aGljaCB0aGUgQ0RJVk4KICAgICAgICAgICAgICAgQXBw bGljYXRpb24gU2VydmVyIHNob3VsZCBzdG9yZSB0aGUgQ0RJViBOb3RpZmljYXRpb24sIGlmIGl0 IGNhbm5vdCBiZSBkZWxpdmVyZWQgdG8gdGhlIHN1YnNjcmliZXIsIEZvciBleGFtcGxlIAogICAg ICAgICAgICAgICB0aGlzIHdvdWxkIGJlIHJlcXVpcmVkIGZvciBidWZmZXJpbmcgdGhlCiAgICAg ICAgICAgICAgIG5vdGlmaWNhdGlvbnMsIGlmIHRoZSB1c2VyIGlzIGxvZ2dlZCBvdXQgYW5kIHRo ZSBkaXZlcnNpb24gaXMgdHJpZ2dlcmVkIGR1ZSB0byBDRk5ML0NGTlJjLCByZXN1bHRpbmcgaW4g Q0RJVk4gZm9yCiAgICAgICAgICAgICAgIHRoYXQgZGl2ZXJzaW9uLiBUaGUgdXNlciBtYXkgc2V0 IE5vdGlmaWNhdGlvbiBCdWZmZXIgSW50ZXJ2YWwgdmFsdWUgaW4gc2Vjb25kcyB0byBhIG1heGlt dW0gdmFsdWUgb2YgMSBkYXkuIEFsc28sIGlmCiAgICAgICAgICAgICAgIG5vdCBjb25maWd1cmVk IGJ5IHRoZSB1c2VyLCB0aGUgZGVmYXVsdCB2YWx1ZSBvZiAxIGRheSAoYXMgY29uZmlndXJlZCBi eSB0aGUgbmV0d29yayBwcm92aWRlcikgaXMgYXBwbGljYWJsZS4gIAogICAgICAgICAgIAo8L3A+ CjxhIG5hbWU9ImNvbW0tZGl2LW50ZnktaW5mbyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjguMS4yIj48L2E+PGgzPjguMS4yLiZuYnNwOwpDb21tLWRpdi1udGZ5LWluZm8gRWxlbWVudDwv aDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBub3RpZmljYXRpb24gaW5mb3JtYXRpb24u IFRoaXMgZWxlbWVudCBoYXMgZm9sbG93aW5nIHN1Yi1lbGVtZW50czogCjwvcD4KPGEgbmFtZT0i YW5jaG9yMTgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMi4xIj48L2E+PGgzPjgu MS4yLjEuJm5ic3A7Cm9yaWdpbmF0aW5nLXVzZXItaW5mbzwvaDM+Cgo8cD4gUmVmZXIgdG8gPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNvcmlnJz5TZWN0aW9uJm5ic3A7OC4xLjEuMS4xPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPm9yaWdpbmF0aW5nLXVzZXItc2VsZWN0aW9uLWNyaXRl cmlhPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBmb3IgZGV0YWlscyBvZiB0aGlzIGVsZW1lbnQu IAo8L3A+CjxhIG5hbWU9ImRpdmluZy11c2VyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u OC4xLjIuMiI+PC9hPjxoMz44LjEuMi4yLiZuYnNwOwpkaXZlcnRpbmctdXNlci1pbmZvPC9oMz4K CjxwPiBUaGlzIGVsZW1lbnQgZ2l2ZXMgZGV0YWlscyBvZiB0aGUgZGl2ZXJ0aW5nIHVzZXIuICBU aGlzIGlzIGFuIG9wdGlvbmFsIGVsZW1lbnQgYW5kIHdvdWxkIGJlIHByZXNlbnQgb25seSBpZiB0 aGUKICAgICAgICAgICAgICAgc3Vic2NyaWJlciBoYXMgcmVxdWVzdGVkIGl0LiBpZiBhYnNlbnQs IGl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgZGl2ZXJzaW9uIG9jY3VycmVkIGF0IG9uZSBvZiB0aGUg cmVnaXN0ZXJlZCBjb250YWN0cy4KICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJkaXZlZC11c2Vy Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4xLjIuMyI+PC9hPjxoMz44LjEuMi4zLiZu YnNwOwpkaXZlcnRlZC10by11c2VyLWluZm88L2gzPgoKPHA+IFRoaXMgZWxlbWVudCBnaXZlcyBk ZXRhaWxzIG9mIHRoZSBmaW5hbCB0YXJnZXQgb2YgdGhlIGNvbW11bmljYXRpb24gaS5lIHRoZSBk aXZlcmVkLXRvIHVzZXIuICBUaGlzIGVsZW1lbnQgY29uc2lzdHMKICAgICAgICAgICAgICAgb2Yg c3ViLWVsZW1lbnRzIGRlZmluZWQgZm9yICJ1c2VyLWluZm8iIGVsZW1lbnQuIAo8L3A+CjxhIG5h bWU9ImRpdi10aW1lIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4xLjIuNCI+PC9hPjxo Mz44LjEuMi40LiZuYnNwOwpkaXZlcnNpb24tdGltZS1pbmZvPC9oMz4KCjxwPiBUaGlzIGVsZW1l bnQgZ2l2ZXMgdGhlIHRpbWUgb2YgY29tbXVuaWNhdGlvbiBkaXZlcnNpb24uIEl0cyB2YWx1ZSBp cyBleHByZXNzZWQgaW4gCiAgICAgICAgICAgICAgIFlZWVk6TU06RERUSEg6TU06U1MgZm9ybWF0 LiAgCjwvcD4KPGEgbmFtZT0iZGl2LXJlYXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44 LjEuMi41Ij48L2E+PGgzPjguMS4yLjUuJm5ic3A7CmRpdmVyc2lvbi1yZWFzb24taW5mbzwvaDM+ Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBhY3R1YWwgcmVhc29uIGZvciB0aGUgY29tbXVu aWNhdGlvbiBkaXZlcnNpb24uCjwvcD4KPGEgbmFtZT0iY29tbS1kaXYtaW5mby1zZWwiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMyI+PC9hPjxoMz44LjEuMy4mbmJzcDsKQ29tbS1k aXYtaW5mby1zZWxlY3Rpb24tY3JpdGVyaWE8L2gzPgoKPHA+IFRoaXMgZWxlbWVudCBnaXZlcyB0 aGUgc3Vic2NyaWJlciB2YXJpb3VzIHRvIHNlbGVjdCBjb21tdW5pY2F0aW9uIGRpdmVyc2lvbiBp bmZvcm1hdGlvbi4gVGhpcyBlbGVtZW50IGhhcyBmb2xsb3dpbmcKICAgICAgICAgICBzdWItZWxl bWVudHMuIAo8L3A+CjxhIG5hbWU9ImRpcy1vcmlnIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uOC4xLjMuMSI+PC9hPjxoMz44LjEuMy4xLiZuYnNwOwpkaXNhYmxlLW9yaWdpbmF0aW5nLXVz ZXItaW5mbzwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBzdWJzY3JpYmVyIG9wdGlv biBvZiBhZGRpbmcgb3JpZ2luYXRpbmcgdXNlciBpbmZvcm1hdGlvbiB0byB0aGUgbm90aWZpY2F0 aW9uIGluZm9ybWF0aW9uLiBUaGUKICAgICAgICAgICAgZGVmYXVsdCB2YWx1ZSBpcyBmYWxzZSB3 aGljaCBtZWFucyB0aGUgc3Vic2NyaWJlciB3YW50cyB0aGUgb3JpZ2luYXRpbmctdXNlci1pbmZv IGVsZW1lbnQgdG8gYmUgcHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgbm90aWZpY2F0aW9uIGlu Zm9ybWF0aW9uLgogICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImRpcy1kaXZpLXUiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMy4yIj48L2E+PGgzPjguMS4zLjIuJm5ic3A7CmRpc2Fi bGUtZGl2ZXJ0aW5nLXVzZXItaW5mbzwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBz dWJzY3JpYmVyIG9wdGlvbiBvZiBhZGRpbmcgZGl2ZXJ0aW5nLXVzZXIgaW5mb3JtYXRpb24gdG8g dGhlIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4gIFRoZQogICAgICAgICAgICBkZWZhdWx0IHZh bHVlIGlzIGZhbHNlIHdoaWNoIG1lYW5zIHRoZSBzdWJzY3JpYmVyIHdhbnRzIHRoZSBkaXZlcnRp bmctdXNlci1pbmZvIGVsZW1lbnQgdG8gYmUgcHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgbm90 aWZpY2F0aW9uIGluZm9ybWF0aW9uLgogICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImRpcy1kaXZ0 LXUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjEuMy4zIj48L2E+PGgzPjguMS4zLjMu Jm5ic3A7CmRpc2FibGUtZGl2ZXJ0ZWQtdG8tdXNlci1pbmZvPC9oMz4KCjxwPiBUaGlzIGVsZW1l bnQgZ2l2ZXMgdGhlIHN1YnNjcmliZXIgb3B0aW9uIG9mIGFkZGluZyBkaXZlcnRpbmctdG8tdXNl ciBpbmZvcm1hdGlvbiB0byB0aGUgbm90aWZpY2F0aW9uIGluZm9ybWF0aW9uLgogICAgICAgICAg ICAgIFRoZSBkZWZhdWx0IHZhbHVlIGlzIGZhbHNlIHdoaWNoIG1lYW5zIHRoZSBzdWJzY3JpYmVy IHdhbnRzIHRoZSBkaXZlcnRlZC10by11c2VyLWluZm8gZWxlbWVudCB0byBiZSBwcmVzZW50IGlu IHRoZQogICAgICAgICAgICAgIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4KICAgICAgICAgICAK PC9wPgo8YSBuYW1lPSJkaXMtZGl2LXRpbWUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44 LjEuMy40Ij48L2E+PGgzPjguMS4zLjQuJm5ic3A7CmRpc2FibGUtZGl2ZXJzaW9uLXRpbWUtaW5m bzwvaDM+Cgo8cD4gVGhpcyBlbGVtZW50IGdpdmVzIHRoZSBzdWJzY3JpYmVyIG9wdGlvbiBvZiBh ZGRpbmcgZGl2ZXJzaW9uLXRpbWUgaW5mb3JtYXRpb24gdG8gdGhlIG5vdGlmaWNhdGlvbiBpbmZv cm1hdGlvbi4gIFRoZQogICAgICAgICAgICBkZWZhdWx0IHZhbHVlIGlzIGZhbHNlIHdoaWNoIG1l YW5zIHRoZSBzdWJzY3JpYmVyIHdhbnRzIHRoZSBkaXZlcnNpb24tdGltZS1pbmZvIHRvIGJlIHBy ZXNlbnQgaW4gdGhlIG5vdGlmaWNhdGlvbgogICAgICAgICAgICBpbmZvcm1hdGlvbi4KICAgICAg ICAgICAKPC9wPgo8YSBuYW1lPSJkaXMtZGl2LXJlYSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjguMS4zLjUiPjwvYT48aDM+OC4xLjMuNS4mbmJzcDsKZGlzYWJsZS1kaXZlcnNpb24tcmVh c29uPC9oMz4KCjxwPiBUaGlzIGVsZW1lbnQgZ2l2ZXMgdGhlIHN1YnNjcmliZXIgb3B0aW9uIG9m IGFkZGluZyBkaXZlcnNpb24tdGltZSBpbmZvcm1hdGlvbiB0byB0aGUgbm90aWZpY2F0aW9uIGlu Zm9ybWF0aW9uLiAgIFRoZQogICAgICAgICAgICBkZWZhdWx0IHZhbHVlIGlzIGZhbHNlIHdoaWNo IG1lYW5zIHRoZSBzdWJzY3JpYmVyIHdhbnRzIHRoZSBkaXZlcnNpb24tcmVhc29uIGluZm9ybWF0 aW9uIHRvIGJlIHByZXNlbnQgaW4gdGhlCiAgICAgICAgICAgIG5vdGlmaWNhdGlvbiBpbmZvcm1h dGlvbi4KICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJkaXMtZGl2LXJ1bGUiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi44LjEuMy42Ij48L2E+PGgzPjguMS4zLjYuJm5ic3A7CmRpc2FibGUt ZGl2ZXJzaW9uLXJ1bGU8L2gzPgoKPHA+IFRoaXMgZWxlbWVudCBnaXZlcyB0aGUgc3Vic2NyaWJl ciBvcHRpb24gb2YgYWRkaW5nIGRpdmVyc2lvbi1ydWxlIGluZm9ybWF0aW9uIHRvIHRoZSBub3Rp ZmljYXRpb24gaW5mb3JtYXRpb24uIFRoZQogICAgICAgICAgICAgICBkZWZhdWx0IHZhbHVlIGlz IGZhbHNlIHdoaWNoIG1lYW5zIHRoZSBzdWJzY3JpYmVyIHdhbnRzIHRoZSBkaXZlcnNpb24tcnVs ZSBpbmZvcm1hdGlvbiB0byBiZSBwcmVzZW50IGluIHRoZQogICAgICAgICAgICAgICBub3RpZmlj YXRpb24gaW5mb3JtYXRpb24uCiAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0ic2Ftbm90Ij48L2E+ PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4yIj48L2E+PGgzPjguMi4mbmJzcDsKU2FtcGxlIE5v dGlmaWNhdGlvbiBib2R5PC9oMz4KCjxhIG5hbWU9ImFuY2hvcjE5Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uOC4yLjEiPjwvYT48aDM+OC4yLjEuJm5ic3A7Ckluc3RhbmNlIG9mIGNvbW11 bmljYXRpb24gZGl2ZXJzaW9uIHN1YnNjcmlwdGlvbiBmaWx0ZXIgZG9jdW1lbnQ8L2gzPgo8ZGl2 IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdp bi1yaWdodDogYXV0byc+PHByZT4KCiZsdDtjb21tLWRpdi1pbmZvJmd0OwogICZsdDtjb21tLWRp di1zdWJzLWluZm8mZ3Q7CiAgICAgICZsdDtjb21tLWRpdi1zZWxlY3Rpb24tY3JpdGVyaWEmZ3Q7 CiAgICAgICAgICZsdDtvcmlnaW5hdGluZy11c2VyLXNlbGVjdGlvbi1jcml0ZXJpYSZndDsKICAg ICAgICAgICAmbHQ7dXNlci1pbmZvJmd0OwogICAgICAgICAgICAgJmx0O3VzZXItbmFtZSZndDtC b3NzJmx0Oy91c2VyLW5hbWUmZ3Q7CiAgICAgICAgICAgICAmbHQ7dXNlci1VUkkmZ3Q7CiAgICAg ICAgICAgICAgIHNpcDpib3NzQG9mZmljZS5jb20KICAgICAgICAgICAgICZsdDsvdXNlci1VUkkm Z3Q7CiAgICAgICAgICAgJmx0Oy91c2VyLWluZm8mZ3Q7CiAgICAgICAgICZsdDsvb3JpZ2luYXRp bmctdXNlci1zZWxlY3Rpb24tY3JpdGVyaWEmZ3Q7CiAgICAgICAgICZsdDtkaXZlcnNpb24tdGlt ZS1zZWxlY3Rpb24tY3JpdGVyaWEmZ3Q7CiAgICAgICAgICAgJmx0O3RpbWUtcmFuZ2UmZ3Q7CiAg ICAgICAgICAgICZsdDtzdGFydC10aW1lJmd0OzE5OTktMDUtMzFUMTM6MjA6MDAtMDU6MDBaJmx0 Oy9zdGFydC10aW1lJmd0OwogICAgICAgICAgICAmbHQ7ZW5kLXRpbWUmZ3Q7MjAwNi0wNS0wNlQx MzoyMDowMC0wNTowMFombHQ7L2VuZC10aW1lJmd0OwogICAgICAgICAgICZsdDsvdGltZS1yYW5n ZSZndDsKICAgICAgICAgJmx0Oy9kaXZlcnNpb24tdGltZS1zZWxlY3Rpb24tY3JpdGVyaWEmZ3Q7 CiAgICAgICAgICZsdDtkaXZlcnNpb24tcmVhc29uLXNlbGVjdGlvbi1jcml0ZXJpYSZndDsKICAg ICAgICAgICAmbHQ7ZGl2ZXJzaW9uLXJlYXNvbi1pbmZvJmd0OzQwNCAzMDImbHQ7L2RpdmVyc2lv bi1yZWFzb24taW5mbyZndDsKICAgICAgICAgJmx0Oy9kaXZlcnNpb24tcmVhc29uLXNlbGVjdGlv bi1jcml0ZXJpYSZndDsKICAgICAgICZsdDsvY29tbS1kaXYtc2VsZWN0aW9uLWNyaXRlcmlhJmd0 OwogICAgICAgJmx0O2NvbW0tZGl2LW50ZnktdHJpZ2dlci1jcml0ZXJpYSZndDsKICAgICAgICAg Jmx0O25vdGlmaWNhdGlvbi10aW1lLXNlbGVjdGlvbi1jcml0ZXJpYSZndDsKICAgICAgICAgICAm bHQ7dGltZS1yYW5nZSZndDsKICAgICAgICAgICAgJmx0O3N0YXJ0LXRpbWUmZ3Q7MTk5OS0wNS0z MVQxMzoyMDowMC0wNTowMFombHQ7L3N0YXJ0LXRpbWUmZ3Q7CiAgICAgICAgICAgICZsdDtlbmQt dGltZSZndDsyMDA2LTA1LTA2VDEzOjIwOjAwLTA1OjAwWiZsdDsvZW5kLXRpbWUmZ3Q7CiAgICAg ICAgICAgJmx0Oy90aW1lLXJhbmdlJmd0OwogICAgICAgICAmbHQ7L25vdGlmaWNhdGlvbi10aW1l LXNlbGVjdGlvbi1jcml0ZXJpYSZndDsKICAgICAgICZsdDsvY29tbS1kaXYtbnRmeS10cmlnZ2Vy LWNyaXRlcmlhJmd0OwogICAmbHQ7L2NvbW0tZGl2LXN1YnMtaW5mbyZndDsKJmx0Oy9jb21tLWRp di1pbmZvJmd0OwoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjIwIj48L2E+PGJyIC8+PGhy IC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxh IGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFt ZT0icmZjLnNlY3Rpb24uOC4yLjIiPjwvYT48aDM+OC4yLjIuJm5ic3A7Ckluc3RhbmNlIG9mIGNv bW11bmljYXRpb24gZGl2ZXJzaW9uIG5vdGlmaWNhdGlvbiBkb2N1bWVudDwvaDM+CjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgoKJmx0O2NvbW0tZGl2LWluZm8mZ3Q7CiAgJmx0O2NvbW0tZGl2LW50 ZnktaW5mbyZndDsKICAgICZsdDtvcmlnaW5hdGluZy11c2VyLWluZm8mZ3Q7CiAgICAgICZsdDt1 c2VyLW5hbWUmZ3Q7Qm9zcyZsdDsvdXNlci1uYW1lJmd0OwogICAgICAmbHQ7dXNlci1VUkkmZ3Q7 c2lwOmJvc3NAb2ZmaWNlLmNvbSZsdDsvdXNlci1VUkkmZ3Q7CiAgICAmbHQ7L29yaWdpbmF0aW5n LXVzZXItaW5mbyZndDsKICAgICZsdDtkaXZlcnRpbmctdXNlci1pbmZvJmd0OwogICAgICBzaXA6 YWxpY2VAb2ZmaWNlLmNvbQogICAgJmx0Oy9kaXZlcnRpbmctdXNlci1pbmZvJmd0OwogICAgJmx0 O2RpdmVydGVkLXRvLXVzZXItaW5mbyZndDsKICAgICAgc2lwOmJvYkBvZmZpY2UuY29tCiAgICAm bHQ7L2RpdmVydGVkLXRvLXVzZXItaW5mbyZndDsKICAgICZsdDtkaXZlcnNpb24tdGltZS1pbmZv Jmd0OzE5OTktMDYtMDFUMTM6MjA6MDAtMDU6MDBaCiAgICAmbHQ7L2RpdmVyc2lvbi10aW1lLWlu Zm8mZ3Q7CiAgICAmbHQ7ZGl2ZXJzaW9uLXJlYXNvbi1pbmZvJmd0OzQwNAogICZsdDsvY29tbS1k aXYtbnRmeS1pbmZvJmd0OwombHQ7L2NvbW0tZGl2LWluZm8mZ3Q7Cgo8L3ByZT48L2Rpdj4KPGEg bmFtZT0ic2NoZW1hIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4zIj48L2E+PGgzPjgu My4mbmJzcDsKU2NoZW1hPC9oMz4KPGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgombHQ7P3htbCB2 ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgPyZndDsKJmx0O3hzOnNjaGVtYQogIHRhcmdl dE5hbWVzcGFjZT0iaHR0cDovL3VyaS5ldHNpLm9yZy9uZ24vcGFyYW1zL3htbC9jb21tLWRpdi1p bmZvIgogIHhtbG5zOnRucz0iaHR0cDovL3VyaS5ldHNpLm9yZy9uZ24vcGFyYW1zL3htbC9jb21t LWRpdi1pbmZvIgogIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIK ICB4bWxucz0iaHR0cDovL3VyaS5ldHNpLm9yZy9uZ24vcGFyYW1zL3htbC9jb21tLWRpdi1pbmZv IgogIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogIGF0dHJpYnV0ZUZvcm1EZWZhdWx0 PSJ1bnF1YWxpZmllZCImZ3Q7CiAgJmx0OyEtLQogIFRoaXMgaW1wb3J0IGJyaW5ncyBpbiB0aGUg WE1MIGxhbmd1YWdlIGRlZmluaXRpb24KICAtLSZndDsKICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFj ZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgc2NoZW1hTG9jYXRp b249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDMveG1sLnhzZCIvJmd0OwogICZsdDshLS0KICBD b21tdW5pY2F0aW9uIERpdmVyc2lvbiBJbmZvcm1hdGlvbi4gVGhpcyBpcyB0aGUgdG9wLWxldmVs IFhNTCBlbGVtZW50CiAgLS0mZ3Q7CiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY29tbS1kaXYtaW5m byIKICAgIHR5cGU9ImNvbW0tZGl2LWluZm8tdHlwZSIgLyZndDsKICAmbHQ7IS0tCiAgQ29tbXVu aWNhdGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24gVHlwZS4KICBUaGlzIGlzIHRoZSB0b3AtbGV2 ZWwgWE1MIGVsZW1lbnQKICAtLSZndDsKICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY29tbS1k aXYtaW5mby10eXBlIiZndDsKICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJjb21tLWRpdi1zdWJzLWluZm8iCiAgICAgICAgdHlwZT0iY29tbS1kaXYtc3Vicy1p bmZvLXR5cGUiIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0i Y29tbS1kaXYtbnRmeS1pbmZvIgogICAgICAgIHR5cGU9ImNvbW0tZGl2LW50ZnktaW5mby10eXBl IiBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czphbnkgbmFtZXNwYWNlPSIjI290aGVy IiBwcm9jZXNzQ29udGVudHM9ImxheCIKICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0i dW5ib3VuZGVkIi8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0O3hzOmF0dHJp YnV0ZSBuYW1lPSJlbnRpdHkiIHR5cGU9InhzOmFueVVSSSIKICAgICAgdXNlPSJyZXF1aXJlZCIv Jmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0OyEtLS0KICBDb21tdW5pY2F0aW9u IERpdmVyc2lvbiBTdWJzY3JpcHRpb24gVHlwZS4KICBVc2VkIGF0IFN1YnNjcmlwdGlvbiB0aW1l IHRvCiAgICAgICAgc2VsZWN0IENvbW11bmljYXRpb24gRGl2ZXJzaW9ucyBmb3Igbm90aWZpY2F0 aW9uLAogICAgICAgIHdoZW4gdG8gbm90aWZ5IHRoZW0gYW5kCiAgICAgICAgd2hhdCB0byBub3Rp ZnkuCiAgLS0mZ3Q7CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9ImNvbW0tZGl2LXN1YnMtaW5m by10eXBlIiZndDsKICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQg bmFtZT0iY29tbS1kaXYtc2VsZWN0aW9uLWNyaXRlcmlhIgogICAgICAgIHR5cGU9ImNvbW0tZGl2 LXNlbGVjdGlvbi1jcml0ZXJpYS10eXBlIgogICAgICAgIG1pbk9jY3Vycz0iMCIgLyZndDsKICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY29tbS1kaXYtbnRmeS10cmlnZ2VyLWNyaXRlcmlhIgog ICAgICAgIHR5cGU9ImNvbW0tZGl2LW50ZnktdHJpZ2dlci1jcml0ZXJpYS10eXBlIgogICAgICAg IG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY29tbS1kaXYt aW5mby1zZWxlY3Rpb24tY3JpdGVyaWEiCiAgICAgICAgdHlwZT0iY29tbS1kaXYtaW5mby1zZWxl Y3Rpb24tY3JpdGVyaWEtdHlwZSIKICAgICAgICBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZs dDt4czphbnkgbmFtZXNwYWNlPSIjI290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCIKICAgICAg ICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8mZ3Q7CiAgICAmbHQ7L3hzOnNl cXVlbmNlJmd0OwogICAgJmx0O3hzOmFueUF0dHJpYnV0ZSBuYW1lc3BhY2U9IiMjb3RoZXIiIHBy b2Nlc3NDb250ZW50cz0ibGF4Ii8mZ3Q7CiAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7 IS0tLQogIENvbW11bmljYXRpb24gRGl2ZXJzaW9uIE5vdGlmaWNhdGlvbiBJbmZvcm1hdGlvbiBU eXBlCiAgVXNlZCB3aGlsZSBub3RpZnlpbmcgdGhlIFVzZXIgYWJvdXQgdGhlIENvbW11bmljYXRp b24gRGl2ZXJzaW9uCiAgLS0mZ3Q7CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9ImNvbW0tZGl2 LW50ZnktaW5mby10eXBlIiZndDsKICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hz OmVsZW1lbnQgbmFtZT0ib3JpZ2luYXRpbmctdXNlci1pbmZvIgogICAgICAgIHR5cGU9InVzZXIt aW5mby10eXBlIiBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9 ImRpdmVydGluZy11c2VyLWluZm8iIHVzZT0ib3B0aW9uYWwiCiAgICAgICAgdHlwZT0ieHM6YW55 VVJJIiBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImRpdmVy dGVkLXRvLXVzZXItaW5mbyIKICAgICAgICB0eXBlPSJ4czphbnlVUkkiIG1pbk9jY3Vycz0iMCIg LyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZGl2ZXJzaW9uLXRpbWUtaW5mbyIKICAg ICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiAvJmd0OwogICAgICAmbHQ7eHM6 ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tcmVhc29uLWluZm8iCiAgICAgICAgdHlwZT0iZGl2ZXJz aW9uLXJlYXNvbi1pbmZvLXR5cGUiIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVs ZW1lbnQgbmFtZT0iZGl2ZXJzaW9uLXJ1bGUtaW5mbyIKICAgICAgICB0eXBlPSJkaXZlcnNpb24t cnVsZS1pbmZvLXR5cGUiIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmFueSBuYW1l c3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4IgogICAgICAgIG1pbk9jY3Vycz0i MCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAg Jmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7IS0tCiAgQ09NTVVOSUNBVElPTiBESVZFUlNJ T04gU0VMRUNUSU9OIENSSVRFUklBCiAgLS0mZ3Q7CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9 ImNvbW0tZGl2LXNlbGVjdGlvbi1jcml0ZXJpYS10eXBlIiZndDsKICAgICZsdDt4czpzZXF1ZW5j ZSZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ib3JpZ2luYXRpbmctdXNlci1zZWxlY3Rp b24tY3JpdGVyaWEiCiAgICAgICAgdHlwZT0idXNlci1zZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSIg bWluT2NjdXJzPSIwIiAvJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnRpbmct dXNlci1zZWxlY3Rpb24tY3JpdGVyaWEiCiAgICAgICAgdHlwZT0ieHM6YW55VVJJIiBtaW5PY2N1 cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImRpdmVydGVkLXRvLXVzZXIt c2VsZWN0aW9uLWNyaXRlcmlhIgogICAgICAgIHR5cGU9InhzOmFueVVSSSIgbWluT2NjdXJzPSIw IiAvJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJkaXZlcnNpb24tdGltZS1zZWxlY3Rp b24tY3JpdGVyaWEiCiAgICAgICAgdHlwZT0idGltZS1yYW5nZS1zZWxlY3Rpb24tY3JpdGVyaWEt dHlwZSIKICAgICAgICBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5h bWU9ImRpdmVyc2lvbi1yZWFzb24tc2VsZWN0aW9uLWNyaXRlcmlhIgogICAgICAgIHR5cGU9ImRp dmVyc2lvbi1yZWFzb24tc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUiCiAgICAgICAgbWluT2NjdXJz PSIwIiAvJmd0OwogICAgICAmbHQ7eHM6YW55IG5hbWVzcGFjZT0iIyNvdGhlciIgcHJvY2Vzc0Nv bnRlbnRzPSJsYXgiCiAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIv Jmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0Owog ICZsdDshLS0KICBDT01NVU5JQ0FUSU9OIERJVkVSU0lPTiBOT1RJRklDQVRJT04gVFJJR0dFUiBD UklURVJJQQogIC0tJmd0OwogICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJjb21tLWRpdi1udGZ5 LXRyaWdnZXItY3JpdGVyaWEtdHlwZSImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAg ICZsdDt4czplbGVtZW50IG5hbWU9Im5vdGlmaWNhdGlvbi10aW1lLXNlbGVjdGlvbi1jcml0ZXJp YSIKICAgICAgICB0eXBlPSJ0aW1lLXJhbmdlLXNlbGVjdGlvbi1jcml0ZXJpYS10eXBlIgogICAg ICAgIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0icHJlc2Vu Y2Utc3RhdHVzLXNlbGVjdGlvbi1jcml0ZXJpYSIKICAgICAgICB0eXBlPSJwcmVzZW5jZS1zdGF0 dXMtc2VsZWN0aW9uLWNyaXRlcmlhLXR5cGUiCiAgICAgICAgbWluT2NjdXJzPSIwIiAvJmd0Owog ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJub3RpZmljYXRpb24tYnVmZmVyLWludGVydmFsIgog ICAgICBtaW5PY2N1cnM9IjAiIGRlZmF1bHQ9Ijg2NDAwIiZndDsKICAgICAgICAmbHQ7eHM6c2lt cGxlVHlwZSZndDsKICAgICAgICAgICZsdDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czppbnRlZ2Vy IiZndDsKICAgICAgJmx0O3hzOm1heEluY2x1c2l2ZSB2YWx1ZT0iODY0MDAiLyZndDsKICAgICAg ICAgICZsdDsveHM6cmVzdHJpY3Rpb24mZ3Q7CiAgICAgICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0 OwogICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAgICZsdDt4czphbnkgbmFtZXNwYWNlPSIj I290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCIKICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0idW5ib3VuZGVkIi8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAmbHQ7L3hz OmNvbXBsZXhUeXBlJmd0OwogICZsdDshLS0KICBDT01NVU5JQ0FUSU9OIERJVkVSU0lPTiBJTkZP Uk1BVElPTiBTRUxFQ1RJT04gQ1JJVEVSSUEKICAtLSZndDsKICAmbHQ7eHM6Y29tcGxleFR5cGUg bmFtZT0iY29tbS1kaXYtaW5mby1zZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSImZ3Q7CiAgICAmbHQ7 eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImRpc2FibGUtb3JpZ2lu YXRpbmctdXNlci1pbmZvIgogICAgICAgIHR5cGU9InhzOmJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNl IiBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImRpc2FibGUt ZGl2ZXJ0aW5nLXVzZXItaW5mbyIKICAgICAgICB0eXBlPSJ4czpib29sZWFuIiBkZWZhdWx0PSJm YWxzZSIgbWluT2NjdXJzPSIwIiAvJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJkaXNh YmxlLWRpdmVydGVkLXRvLXVzZXItaW5mbyIKICAgICAgICB0eXBlPSJ4czpib29sZWFuIiBkZWZh dWx0PSJmYWxzZSIgbWluT2NjdXJzPSIwIiAvJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1l PSJkaXNhYmxlLWRpdmVyc2lvbi10aW1lLWluZm8iCiAgICAgICAgdHlwZT0ieHM6Ym9vbGVhbiIg ZGVmYXVsdD0iZmFsc2UiIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQg bmFtZT0iZGlzYWJsZS1kaXZlcnNpb24tcmVhc29uLWluZm8iCiAgICAgICAgdHlwZT0ieHM6Ym9v bGVhbiIgZGVmYXVsdD0iZmFsc2UiIG1pbk9jY3Vycz0iMCIgLyZndDsKICAgICAgJmx0O3hzOmVs ZW1lbnQgbmFtZT0iZGlzYWJsZS1kaXZlcnNpb24tcnVsZS1pbmZvIgogICAgICAgIHR5cGU9Inhz OmJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNlIiBtaW5PY2N1cnM9IjAiIC8mZ3Q7CiAgICAgICZsdDt4 czphbnkgbmFtZXNwYWNlPSIjI290aGVyIiBwcm9jZXNzQ29udGVudHM9ImxheCIKICAgICAgICBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVl bmNlJmd0OwogICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAmbHQ7IS0tIFVzZXIgSW5mbyBU eXBlIC0tJmd0OwogICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJ1c2VyLWluZm8tdHlwZSImZ3Q7 CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9InVzZXIt bmFtZSIgdHlwZT0ieHM6c3RyaW5nIgogICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIv Jmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJ1c2VyLVVSSSIgdHlwZT0ieHM6YW55VVJJ Ii8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7 CgogICZsdDshLS0KICBESVZFUlNJT04gUkVBU09OIElORk8KICAtLSZndDsKCiAgICAmbHQ7eHM6 c2ltcGxlVHlwZSBuYW1lPSJkaXZlcnNpb24tcmVhc29uLWluZm8tdHlwZXMiJmd0OwogICAgICAg ICZsdDt4czpsaXN0IGl0ZW1UeXBlPSJkaXZlcnNpb24tcmVhc29uLWluZm8tdHlwZSIvJmd0Owog ICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0OwogICZsdDt4czpzaW1wbGVUeXBlIG5hbWU9ImRpdmVy c2lvbi1yZWFzb24taW5mby10eXBlIiZndDsKICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFz ZT0ieHM6aW50ZWdlciImZ3Q7CiAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0i NDA0Ii8mZ3Q7CiAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iNDg2Ii8mZ3Q7 CiAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iNDA4Ii8mZ3Q7CiAgICAgICAg ICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iMzAyIi8mZ3Q7CiAgICAgICAgICAgICZsdDt4 czplbnVtZXJhdGlvbiB2YWx1ZT0iNDg3Ii8mZ3Q7CiAgICAgICAgICAgICZsdDt4czplbnVtZXJh dGlvbiB2YWx1ZT0iNDgwIi8mZ3Q7CiAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1 ZT0iNTAzIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpyZXN0cmljdGlvbiZndDsKICAmbHQ7L3hzOnNp bXBsZVR5cGUmZ3Q7CiAgJmx0OyEtLQogIERJVkVSU0lPTiBSVUxFIElORk8KICAtLSZndDsKICAm bHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iZGl2ZXJzaW9uLXJ1bGUtaW5mby10eXBlIiZndDsKICAg ICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZGl2ZXJzaW9u LXJ1bGUiIHR5cGU9InhzOnN0cmluZyIvJmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAm bHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDshLS0KICBPUklHSU5BVElORyBVU0VSIFNFTEVD VElPTiBDUklURVJJQQogIC0tJmd0OwogICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJ1c2VyLXNl bGVjdGlvbi1jcml0ZXJpYS10eXBlIiZndDsKICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0idXNlci1pbmZvIgogICAgICAgIHR5cGU9InVzZXItaW5mby10 eXBlIiBtaW5PY2N1cnM9IjAiCiAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiIC8mZ3Q7CiAg ICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0OyEt LQogIERJVkVSU0lPTiBSRUFTT04gU0VMRUNUSU9OIENSSVRFUklBCiAgLS0mZ3Q7CiAgJmx0O3hz OmNvbXBsZXhUeXBlIG5hbWU9ImRpdmVyc2lvbi1yZWFzb24tc2VsZWN0aW9uLWNyaXRlcmlhLXR5 cGUiJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1l PSJkaXZlcnNpb24tcmVhc29uLWluZm8iCiAgICAgICAgdHlwZT0iZGl2ZXJzaW9uLXJlYXNvbi1p bmZvLXR5cGVzIi8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICZsdDsveHM6Y29tcGxl eFR5cGUmZ3Q7CiAgJmx0OyEtLQogIFRJTUUgUkFOR0UgU0VMRUNUSU9OIENSSVRFUklBCiAgLS0m Z3Q7CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9InRpbWUtcmFuZ2Utc2VsZWN0aW9uLWNyaXRl cmlhLXR5cGUiJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJ0aW1lLXJhbmdlIgogICAgdHlwZT0idGltZS1yYW5nZS10eXBlIiBtaW5PY2N1cnM9 IjAiCiAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiIC8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVl bmNlJmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0OyEtLQogIFRJTUUgUkFOR0Ug SU5GTwogIC0tJmd0OwogICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJ0aW1lLXJhbmdlLXR5cGUi Jmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJz dGFydC10aW1lIiB0eXBlPSJ4czpkYXRlVGltZSIgLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQg bmFtZT0iZW5kLXRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIiAvJmd0OwogICAgJmx0Oy94czpzZXF1 ZW5jZSZndDsKICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDshLS0KICBQUkVTRU5DRSBT VEFUVVMgU0VMRUNUSU9OIENSSVRFUklBCiAgLS0mZ3Q7CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5h bWU9InByZXNlbmNlLXN0YXR1cy1zZWxlY3Rpb24tY3JpdGVyaWEtdHlwZSImZ3Q7CiAgICAmbHQ7 eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czplbGVtZW50IG5hbWU9InByZXNlbmNlLXN0YXR1 cy1pbmZvIgogICAgICAgIHR5cGU9InByZXNlbmNlLXN0YXR1cy1pbmZvLXR5cGUiIG1pbk9jY3Vy cz0iMCIKICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIgLyZndDsKICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7IS0tCiAgUFJFU0VOQ0Ug U1RBVFVTIElORk8KICAtLSZndDsKICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0icHJlc2VuY2Ut c3RhdHVzLWluZm8tdHlwZSImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4 czplbGVtZW50IG5hbWU9InByZXNlbmNlLXN0YXR1cyIgdHlwZT0ieHM6c3RyaW5nIiAvJmd0Owog ICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwombHQ7L3hz OnNjaGVtYSZndDsKCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJzZWMtY29uZCI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjkiPjwvYT48aDM+OS4mbmJzcDsKU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnM8L2gzPgoKPHA+CkF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9mIHN1YnNjcmlw dGlvbnMgaGF2ZSBiZWVuIGRpc2N1c3NlZAppbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI05vdGlm aWVyUCc+U2VjdGlvbiZuYnNwOzYuNjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5O b3RpZmllciBQcm9jZXNzaW5nIG9mIFNVQlNDUklCRSByZXF1ZXN0czwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uICBMYWNrIG9mIGF1dGhlbnRpY2F0aW9uIG9yIGF1dGhvcml6YXRpb24gbWF5IHBy b3ZpZGUKY29tbS1kaXYtaW5mbyBpbmZvcm1hdGlvbiB0byB1bmF1dGhvcml6ZWQgcGFydGllcyBh bmQgY2FuIHJldmVhbApzZW5zaXRpdmUgaW5mb3JtYXRpb24gd2l0aCByZWdhcmRzIHRvIHRoZSB1 c2VyJ3MgY2FsbCByZWNlaXZpbmcKcGF0dGVybnMuICBGb3IgZXhhbXBsZSwgd2hvIGNhbGxzIHRo ZSB1c2VyIGFuZCBhdCB3aGF0IHRpbWUsIGV0Yy4gIAo8YnIgLz4KPGJyIC8+CgpJbnRlZ3JpdHkg cHJvdGVjdGlvbiBhbmQgY29uZmlkZW50aWFsaXR5IG9mIG5vdGlmaWNhdGlvbnMgYXJlIGFsc28K ZGlzY3Vzc2VkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjTm90aWZpZXJHJz5TZWN0aW9uJm5i c3A7Ni43PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5vdGlmaWVyIEdlbmVyYXRp b24gb2YgTk9USUZZIHJlcXVlc3RzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gIElmIGEgbm90 aWZpZXIgZG9lcyBub3QgZW5jcnlwdCBib2RpZXMgb2YKTk9USUZZIHJlcXVlc3RzLCBhbiBlYXZl c2Ryb3BwZXIgY291bGQgbGVhcm4gdGhlIHN0YXR1cyBvZiBhIFNJUCB1c2VyCmFnZW50IGFuZCB1 c2UgaXQgdG8gY3JlYXRlIG1hbGljaW91cyBzZXNzaW9ucy4gIElmIHRoZSBub3RpZmllcgpkb2Vz IG5vdCBpbnRlZ3JpdHkgcHJvdGVjdCB0aGUgYm9kaWVzIG9mIE5PVElGWSByZXF1ZXN0cywgYSBt YW4taW4tCnRoZS1taWRkbGUgYXR0YWNrZXIgb3IgbWFsaWNpb3VzIFNJUCBwcm94eSBjb3VsZCBt b2RpZnkgdGhlIGNvbnRlbnRzCm9mIHRoZSBjb21tLWRpdi1pbmZvIGV2ZW50IHBhY2thZ2Ugbm90 aWZpY2F0aW9uLiAgQWx0aG91Z2ggdGhpcyBkb2VzCm5vdCBjYXVzZSBoYXJtLCBpdCBjYW4gY3Jl YXRlIGFubm95YW5jZXMuIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIxIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uMTAiPjwvYT48aDM+MTAuJm5ic3A7CklBTkEgQ29uc2lkZXJhdGlvbnM8L2gz PgoKPHA+IFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIHRoZSBuZXcgU0lQIEV2ZW50IFBhY2thZ2Uu IAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAu MSI+PC9hPjxoMz4xMC4xLiZuYnNwOwpDb21tdW5pY2F0aW9uIERpdmVyc2lvbiBJbmZvcm1hdGlv biBFdmVudCBQYWNrYWdlIFJlZ2lzdHJhdGlvbjwvaDM+CjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgoKUGFja2FnZSBOYW1lOiBDb21tLWRpdi1pbmZvCgpUeXBlOiBQYWNrYWdlCgpDb250YWN0OiAg Sm9uIE1lcmRpdGgsICZsdDtKb2huLm1lcmVkaXRoQDNncHAub3JnJmd0OwoKUHVibGlzaGVkIFNw ZWNpZmljYXRpb246IFJGQyBYWFhYIChOb3RlIHRvIFJGQyBFZGl0b3IpCgo8L3ByZT48L2Rpdj4K PGEgbmFtZT0iYW5jaG9yMjMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMSI+PC9hPjxo Mz4xMS4mbmJzcDsKQWNrbm93bGVkZ2VtZW50czwvaDM+Cgo8cD4gVGhlIGF1dGhvcnMgd291bGQg bGlrZSB0byB0aGFuayBTYW1pciBTYWtsaWthciBmb3IgZWRpdGluZyBhbmQgYmVpbmcgcGFydCBv ZiB0aGUgaW5pdGlhbCB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQgYW5kIEJhbiBBbC1CYWtyaSwKICAg ICAgUm9sYW5kIEplc3NrZSwgSm9zZSBNaWd1ZWwgVG9ycmVzLCBQYXVsIEt5eml2YXQsIEpvaG4g RWx3ZWxsICwgS2VpdGggRHJhZ2UgLCBHb256YWxvIENhbWFyaWxsbyBhbmQgRGVhbiBXaWxsaXMg Zm9yIHRoZWlyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gCjwvcD4KPGEgbmFt ZT0icmZjLnJlZmVyZW5jZXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMiI+PC9hPjxo Mz4xMi4mbmJzcDsKUmVmZXJlbmNlczwvaDM+Cgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlczEiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8aDM+MTIuMS4mbmJzcDtOb3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0 aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0 b3AiPjxhIG5hbWU9IjNHUFAuMjQuNjA0Ij5bMV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+M0dQUCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNz L2h0bWwtaW5mby8yNDYwNC5odG0iPkNvbW11bmljYXRpb24gRGl2ZXJzaW9uIChDRElWKSB1c2lu ZyBJUCBNdWx0aW1lZGlhIChJTSlDb3JlIE5ldHdvcmsgKENOKSBzdWJzeXN0ZW07ICBQcm90b2Nv bCBzcGVjaWZpY2F0aW9uPC9hPiwmcmRxdW87IDNHUFAgVFMmbmJzcDsyNC42MDQgOC42LjAsIERl Y2VtYmVyJm5ic3A7MjAwOS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iM0dQUC4yNC40MDQiPlsyXTwvYT48L3RkPgo8dGQgY2xhc3M9 ImF1dGhvci10ZXh0Ij4zR1BQLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3d3dy4zZ3BwLm9yZy9m dHAvU3BlY3MvaHRtbC1pbmZvLzI0NDA0Lmh0bSI+VElTUEFOOyBQU1ROL0lTRE4gc2ltdWxhdGlv biBzZXJ2aWNlczogQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpOyBQcm90b2NvbCBzcGVj aWZpY2F0aW9uPC9hPiwmcmRxdW87IDNHUFAgVFMmbmJzcDsyNC40MDQgNy41LjAsIEp1bmUmbmJz cDsyMDA5LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w Ij48YSBuYW1lPSJSRkMyMTE5Ij5bM108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ PGEgaHJlZj0ibWFpbHRvOnNvYkBoYXJ2YXJkLmVkdSI+QnJhZG5lciwgUy48L2E+LCAmbGRxdW87 PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjExOSI+S2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHM8L2E+LCZyZHF1bzsg QkNQJm5ic3A7MTQsIFJGQyZuYnNwOzIxMTksIE1hcmNoJm5ic3A7MTk5NyAoPGEgaHJlZj0iZnRw Oi8vZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjMjExOS50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMyMTE5Lmh0bWwiPkhUTUw8 L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMy MTE5LnhtbCI+WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIg dmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzM0MjciPls0XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5NYW5raW4sIEEuLCBCcmFkbmVyLCBTLiwgTWFoeSwgUi4sIFdpbGxpcywgRC4s IE90dCwgSi4sIGFuZCBCLiBSb3NlbiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzM0MjciPkNoYW5nZSBQcm9jZXNzIGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0 aW9uIFByb3RvY29sIChTSVApPC9hPiwmcmRxdW87IFJGQyZuYnNwOzM0MjcsIERlY2VtYmVyJm5i c3A7MjAwMiAoPGEgaHJlZj0iZnRwOi8vZnRwLnJmYy1lZGl0b3Iub3JnL2luLW5vdGVzL3JmYzM0 MjcudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzI2MSI+WzVdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPlJvc2VuYmVyZywgSi4sIFNjaHVsenJpbm5lLCBILiwgQ2FtYXJpbGxvLCBHLiwg Sm9obnN0b24sIEEuLCBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4sIEhhbmRsZXksIE0uLCBhbmQg RS4gU2Nob29sZXIsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzMjYxIj5TSVA6IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbDwvYT4sJnJkcXVvOyBSRkMm bmJzcDszMjYxLCBKdW5lJm5ic3A7MjAwMiAoPGEgaHJlZj0iZnRwOi8vZnRwLnJmYy1lZGl0b3Iu b3JnL2luLW5vdGVzL3JmYzMyNjEudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzI2NSI+WzZdPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlJvYWNoLCBBLiwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyNjUiPlNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbCAoU0lQKS1TcGVjaWZpYyBFdmVudCBOb3RpZmljYXRpb248L2E+LCZyZHF1bzsgUkZDJm5i c3A7MzI2NSwgSnVuZSZuYnNwOzIwMDIgKDxhIGhyZWY9ImZ0cDovL2Z0cC5yZmMtZWRpdG9yLm9y Zy9pbi1ub3Rlcy9yZmMzMjY1LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8L3RhYmxlPgoKPGEg bmFtZT0icmZjLnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjEyLjIuJm5ic3A7SW5mb3JtYXRpdmUg UmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IjNHUFAuMjQuMjI5Ij5bN108 L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+M0dQUCwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNzL2h0bWwtaW5mby8yNDIyOS5odG0iPkludGVybmV0 IFByb3RvY29sIChJUCkgbXVsdGltZWRpYSBjYWxsIGNvbnRyb2wgcHJvdG9jb2wgYmFzZWQgb24g U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIGFuZCBTZXNzaW9uIERlc2NyaXB0aW9u IFByb3RvY29sIChTRFApOyBTdGFnZSAzPC9hPiwmcmRxdW87IDNHUFAgVFMmbmJzcDsyNC4yMjkg NS4yMy4wLCBTZXB0ZW1iZXImbmJzcDsyMDA5LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJXM0MuUkVDLXhtbC0yMDAwMTAwNiI+Wzhd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkJyYXksIFQuLCBTcGVyYmVyZy1NY1F1 ZWVuLCBDLiwgTWFsZXIsIEUuLCBhbmQgSi4gUGFvbGksICZsZHF1bzs8YSBocmVmPSJodHRwOi8v d3d3LnczLm9yZy9UUi8yMDAwL1JFQy14bWwtMjAwMDEwMDYiPkV4dGVuc2libGUgTWFya3VwIExh bmd1YWdlIChYTUwpIDEuMCAoU2Vjb25kIEVkaXRpb24pPC9hPiwmcmRxdW87IFdvcmxkIFdpZGUg V2ViIENvbnNvcnRpdW0gRmlyc3RFZGl0aW9uJm5ic3A7UkVDLXhtbC0yMDAwMTAwNiwgT2N0b2Jl ciZuYnNwOzIwMDAgKDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDAvUkVDLXhtbC0y MDAwMTAwNiI+SFRNTDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi IHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0NzQ1Ij5bOV08L2E+PC90ZD4KPHRkIGNsYXNzPSJh dXRob3ItdGV4dCI+U2NodWx6cmlubmUsIEguLCBUc2Nob2ZlbmlnLCBILiwgTW9ycmlzLCBKLiwg Q3VlbGxhciwgSi4sIFBvbGssIEouLCBhbmQgSi4gUm9zZW5iZXJnLCAmbGRxdW87PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDc0NSI+Q29tbW9uIFBvbGljeTogQSBEb2N1 bWVudCBGb3JtYXQgZm9yIEV4cHJlc3NpbmcgUHJpdmFjeSBQcmVmZXJlbmNlczwvYT4sJnJkcXVv OyBSRkMmbmJzcDs0NzQ1LCBGZWJydWFyeSZuYnNwOzIwMDcgKDxhIGhyZWY9ImZ0cDovL2Z0cC5y ZmMtZWRpdG9yLm9yZy9pbi1ub3Rlcy9yZmM0NzQ1LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8 dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzM0NTUi PlsxMF08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+R2FyY2lhLU1hcnRpbiwgTS4s IEhlbnJpa3NvbiwgRS4sIGFuZCBELiBNaWxscywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzM0NTUiPlByaXZhdGUgSGVhZGVyIChQLUhlYWRlcikgRXh0ZW5z aW9ucyB0byB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIGZvciB0aGUgM3Jk LUdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCk8L2E+LCZyZHF1bzsgUkZDJm5i c3A7MzQ1NSwgSmFudWFyeSZuYnNwOzIwMDMgKDxhIGhyZWY9ImZ0cDovL2Z0cC5yZmMtZWRpdG9y Lm9yZy9pbi1ub3Rlcy9yZmMzNDU1LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8L3RhYmxlPgoK PGEgbmFtZT0iYW5jaG9yMjYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BIj48L2E+PGgz PkFwcGVuZGl4IEEuJm5ic3A7CkNoYW5nZSBsb2c8L2gzPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KCltSRkMgRURJVE9SIE5PVEU6IFBsZWFzZSByZW1vdmUgdGhpcyBzZWN0aW9uIHdoZW4gcHVi bGlzaGluZ10KCjwvcHJlPjwvZGl2Pgo8cD5DaGFuZ2VzIGZyb20gZHJhZnQtYXZhc2FyYWxhLWRp c3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0wMwo8L3A+Cjx1bCBjbGFzcz0idGV4dCI+Cjxs aT5BZGRlZCBTdGF0ZSBpbmZvcm1hdGlvbiB0byBOb3RpZmllcnMuIAo8L2xpPgo8bGk+RW5oYW5j ZWQgZGl2ZXJ0aW5nLXVzZXItaW5mbyBlbGVtZW50IGRlZmluaXRpb24uIAo8L2xpPgo8L3VsPjxw PgoKPC9wPgo8cD5DaGFuZ2VzIGZyb20gZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2 LW5vdGlmaWNhdGlvbi0wMgo8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT5Nb2RpZmllZCB0aHcg YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgdG8gbWFrZSBpdCBtb3JlIElNUyBzcGVjaWZpYy4gCjwv bGk+CjxsaT5BZGRlZCBhIGRlZmluaXRpb24gZm9yIElNUyBDb3JlIG5ldHdvcmsuIAo8L2xpPgo8 bGk+VXBkYXRlZCBhdXRob3JzIGxpc3QgYW5kIEFja25vd2xlZGdlbWVudCBzZWN0aW9ucy4gCjwv bGk+CjwvdWw+PHA+Cgo8L3A+CjxwPkNoYW5nZXMgZnJvbSBkcmFmdC1hdmFzYXJhbGEtZGlzcGF0 Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTAxCjwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPklu Y29ycG9yYXRlZCByZXZpZXcgY29tbWVudHMuIAo8L2xpPgo8bGk+TW9kaWZpZWQgY29udGFjdCBk ZXRhaWxzIGZvciBjbyBhdXRob3IgU3ViaXIgU2FoYS4gCjwvbGk+CjwvdWw+PHA+Cgo8L3A+Cjxw PkNoYW5nZXMgZnJvbSBkcmFmdC1hdmFzYXJhbGEtc2lwcGluZy1jb21tLWRpdi1ub3RpZmljYXRp b24tMDAKPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+IENoYW5nZWQgY29udGFjdCBkZXRhaWxz IG9mIGNvIGF1dGhvciBTdWJpciBTYWhhLiAKPC9saT4KPGxpPiBNb3ZlZCBmcm9tIFNJUFBJTkcg dG8gRElTUEFUQ0ggV0cuIAo8L2xpPgo8L3VsPjxwPgoKPC9wPgo8cD5DaGFuZ2VzIGZyb20gZHJh ZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0wMAo8L3A+Cjx1bCBj bGFzcz0idGV4dCI+CjxsaT4gQWRkZWQgY29tbS1kaXYtaW5mbyBkb2N1bWVudCBzdHJ1Y3R1cmUg aW5mb3JtYXRpb24gYW5kIHNjaGVtYSBmb3IgdGhlIAogICAgZXZlbnQgcGFja2FnZS4KCjwvbGk+ CjxsaT4gQWRkZWQgbW9yZSBlbGFib3JhdGUgZGVzY3JpcHRpb24gZm9yIHZhcmlvdXMgc2VjdGlv bnMgaW4gY29tbS1kaXYtaW5mbwogICAgZG9jdW1lbnQKCjwvbGk+CjwvdWw+PHA+Cgo8L3A+Cjxh IG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPkF1dGhvcnMnIEFkZHJlc3NlczwvaDM+Cjx0 YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5SYW5qaXQgQXZhc2FyYWxhIChlZGl0b3IpPC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TW90 b3JvbGEgSW5kaWEgUHZ0IEx0ZDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkJhZ2FtYW5lIFRlY2ggUGFyaywg QyBWIFJhbWFuIE5hZ2FyPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5i c3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+QmFuZ2Fsb3JlICA1NjAwOTM8L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5JbmRpYTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0i cmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9 Im1haWx0bzpyYW5qaXRAbW90b3JvbGEuY29tIj5yYW5qaXRAbW90b3JvbGEuY29tPC9hPjwvdGQ+ PC90cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJh dXRob3ItdGV4dCI+Sm9obiBMdWMgQmFra2VyPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+UmVzZWFyY2ggaW4g TW90aW9uIENvcnBvcmF0aW9uPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+NTAwMCBSaXZlcnNpZGUgRHJpdmUs IEJ1aWxkaW5nIDYsIFN1aXRlIDEwMDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPklydmluZywgVGV4YXMgIDc1 MDM5PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRk IGNsYXNzPSJhdXRob3ItdGV4dCI+VVNBPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3Ii IGFsaWduPSJyaWdodCI+RW1haWw6Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ PGEgaHJlZj0ibWFpbHRvOmpiYWtrZXJAcmltLmNvbSI+amJha2tlckByaW0uY29tPC9hPjwvdGQ+ PC90cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJh dXRob3ItdGV4dCI+U3ViaXIgU2FoYTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNFTyBSSVQgU29sdXRpb25z PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+Qi02MDIsIFNhbGFycHVyaWEgU2lsdmVyd29vZCwgQyBWIFJhbWFu IE5hZ2FyPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+QmFuZ2Fsb3JlICA1NjAwOTM8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0 Ij5JbmRpYTwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVt YWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpk cnN1Ymlyc2FoYUB5YWhvby5jb20iPmRyc3ViaXJzYWhhQHlhaG9vLmNvbTwvYT48L3RkPjwvdHI+ CjwvdGFibGU+CjwvYm9keT48L2h0bWw+Cgo= ------_=_NextPart_001_01CAC146.2C9B8DFB-- From emcho@sip-communicator.org Thu Mar 11 12:09:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881A43A6BD5 for ; Thu, 11 Mar 2010 12:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_SORBS_WEB=0.619] 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 XKDDHsi3nwAu for ; Thu, 11 Mar 2010 12:09:01 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 2C0923A6C3F for ; Thu, 11 Mar 2010 11:58:53 -0800 (PST) Received: by bwz3 with SMTP id 3so445686bwz.29 for ; Thu, 11 Mar 2010 11:58:56 -0800 (PST) Received: by 10.204.156.213 with SMTP id y21mr1684836bkw.195.1268337536304; Thu, 11 Mar 2010 11:58:56 -0800 (PST) Received: from [10.210.62.210] ([80.10.46.82]) by mx.google.com with ESMTPS id 24sm1289358bkr.12.2010.03.11.11.58.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Mar 2010 11:58:54 -0800 (PST) References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> Message-Id: <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> From: Emil Ivov To: Peter Saint-Andre In-Reply-To: <4B99295D.9090008@stpeter.im> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Thu, 11 Mar 2010 20:59:18 +0100 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 20:09:03 -0000 Hey Peter, On 11 mars 2010, at 18:33, Peter Saint-Andre wrote: > On 3/10/10 8:08 AM, Emil Ivov wrote: > > Regarding section 2, I have a few questions: > > 1. What kind of URI are you talking about? The the stpeter@stpeter.im kind. > 2. Is this a URI that the SIP+XMPP service provides to the client? Not the service itself but rather the provider. > If so, how? Out of scope (but basically via a web registration or any other means that people are using for mail and IM registration) > 3. How exactly can a URI and a password be used for authentication > in XMPP (i.e., using which SASL mechanism)? Below. > 4. Does the client derive a username from the URI so that it can use > an > authentication mechanism that experts a username and password? Yes, exactly. The way most clients would do for SIP and XMPP already. This is just about making sure that they would be able to bring the assumption over to a SIP+XMPP service. Cheers, Emil > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > From stpeter@stpeter.im Thu Mar 11 12:32:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEE73A6899 for ; Thu, 11 Mar 2010 12:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgi7FZk2wX1f for ; Thu, 11 Mar 2010 12:32:24 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EDE173A68AF for ; Thu, 11 Mar 2010 12:20:13 -0800 (PST) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA68D40D3A; Thu, 11 Mar 2010 13:20:18 -0700 (MST) Message-ID: <4B995081.4090201@stpeter.im> Date: Thu, 11 Mar 2010 13:20:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Emil Ivov References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> In-Reply-To: <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000205070607040801030104" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 20:32:26 -0000 This is a cryptographically signed message in MIME format. --------------ms000205070607040801030104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/11/10 12:59 PM, Emil Ivov wrote: > Hey Peter, >=20 > On 11 mars 2010, at 18:33, Peter Saint-Andre wrote= : >=20 >> On 3/10/10 8:08 AM, Emil Ivov wrote: >> >> Regarding section 2, I have a few questions: >> >> 1. What kind of URI are you talking about? >=20 > The the stpeter@stpeter.im kind. Since it lacks a scheme, stpeter@stpeter.im is not a URI. >> 2. Is this a URI that the SIP+XMPP service provides to the client? >=20 > Not the service itself but rather the provider. >=20 >> If so, how? >=20 > Out of scope (but basically via a web registration or any other means > that people are using for mail and IM registration) >=20 >> 3. How exactly can a URI and a password be used for authentication in >> XMPP (i.e., using which SASL mechanism)? >=20 > Below. >=20 >> 4. Does the client derive a username from the URI so that it can use a= n >> authentication mechanism that experts a username and password? >=20 > Yes, exactly. The way most clients would do for SIP and XMPP already. > This is just about making sure that they would be able to bring the > assumption over to a SIP+XMPP service. That is unclear to me. Do I visit a website, receive an email with a URI, click that to authorize, and receive credentials for my combined SIP+XMPP account? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000205070607040801030104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMTIwMjAxN1owIwYJKoZIhvcNAQkEMRYEFPu9lL+6ssq90g4aw35+ a+gwterfMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAe6f6ED9H3gzgSdEn8eQU4oZ4OK6L8HuYDk5UgpCS 0lnkFIbF17XxAeSVrN+LZ8/NeDLmt56+scD1Eajq979mcOeOKgYVkzxt0jBABO3CpX4NTKFi q+Sx5cMdip6D7D/ReLoIXgarCMxrNd4JTn31Df5AHaAxFm6fC7DKJEqnJ4FCIaUaWsYgCQER N7ObMCMAVeP6zDlLEBu4dy8LdOFBIfO4XfEHIHgWx1Y3xPbR+A/oxOhKpsZ6DaLufUeWf/Hm aZXxfbadFYEYiG/TH14T0zaEhdueufBrK8o40K6WbmneX4vgR54k4uSWUhbWGBekTQvJv4Sh hcYTBUq3Epz8sAAAAAAAAA== --------------ms000205070607040801030104-- From pkyzivat@cisco.com Thu Mar 11 13:05:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135303A683E for ; Thu, 11 Mar 2010 13:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.954 X-Spam-Level: X-Spam-Status: No, score=-9.954 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfMfyeTAZt5o for ; Thu, 11 Mar 2010 13:05:37 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B03AB3A68C7 for ; Thu, 11 Mar 2010 13:04:41 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI7pmEtAZnwM/2dsb2JhbACDDJdXc6QviC+QQYEyg0kEgxc X-IronPort-AV: E=Sophos;i="4.49,622,1262563200"; d="scan'208";a="98941998" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2010 20:56:16 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2BKuFfr023545; Thu, 11 Mar 2010 20:56:15 GMT Message-ID: <4B9958EF.1060105@cisco.com> Date: Thu, 11 Mar 2010 15:56:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> In-Reply-To: <4B995081.4090201@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:05:38 -0000 Peter Saint-Andre wrote: >>> 1. What kind of URI are you talking about? >> The the stpeter@stpeter.im kind. > > Since it lacks a scheme, stpeter@stpeter.im is not a URI. That was unclear to me too. I was *guessing* that the intent is that pkyzivat@ietf.org would imply support for a variety of url schemes that can have that as their body: sip:pkyzivat@ietf.org xmpp:pkyzivat@ietf.org mailto:pkyzivat@ietf.org whatever protocols the domain cares to support. IOW its just a convention for linking things based on similar name. And then using the same, or related, credentials for all. Thanks, Paul From emcho@sip-communicator.org Thu Mar 11 14:07:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D188E3A684E for ; Thu, 11 Mar 2010 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWP-UdyPLbBN for ; Thu, 11 Mar 2010 14:07:43 -0800 (PST) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 263793A6894 for ; Thu, 11 Mar 2010 14:07:42 -0800 (PST) Received: by fxm27 with SMTP id 27so684808fxm.28 for ; Thu, 11 Mar 2010 14:07:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.147.11 with SMTP id y11mr408693hba.78.1268345264197; Thu, 11 Mar 2010 14:07:44 -0800 (PST) In-Reply-To: <4B995081.4090201@stpeter.im> References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> From: Emil Ivov Date: Thu, 11 Mar 2010 23:07:24 +0100 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 22:07:44 -0000 On Thu, Mar 11, 2010 at 9:20 PM, Peter Saint-Andre wrote: >>> 1. What kind of URI are you talking about? >> >> The the stpeter@stpeter.im kind. > > Since it lacks a scheme, stpeter@stpeter.im is not a URI. True. I guess ID would have been a better choice. Is this a problem for any other reason than the misuse of the term? >>> 4. Does the client derive a username from the URI so that it can use an >>> authentication mechanism that experts a username and password? >> >> Yes, exactly. The way most clients would do for SIP and XMPP already. >> This is just about making sure that they would be able to bring the >> assumption over to a SIP+XMPP service. > > That is unclear to me. Do I visit a website, receive an email with a > URI, click that to authorize, and receive credentials for my combined > SIP+XMPP account? Yes, for example. Pretty much the same way you would get them at register.jabber.org (while it worked ;) ). Cheers, Emil From lendl@nic.at Thu Mar 11 14:23:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879033A6906 for ; Thu, 11 Mar 2010 14:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN40i9SpGkvG for ; Thu, 11 Mar 2010 14:23:43 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 7CE973A6960 for ; Thu, 11 Mar 2010 14:23:38 -0800 (PST) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 7DCE04CDC4; Thu, 11 Mar 2010 23:23:41 +0100 (CET) Message-ID: <4B996D6E.9030008@nic.at> Date: Thu, 11 Mar 2010 23:23:42 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "PFAUTZ, PENN L (ATTCORP)" References: <404BBC8D-04BD-4E1F-87F2-C8707EB1AE98@softarmor.com><114DAD31379DFA438C0A2E39B3B8AF5D01213F66D0@srvxchg><37B4C540-0C8C-4A3D-9493-80B9416E8815@softarmor.com><22008_1267774700_4B90B4EC_22008_38058_1_94C682931C08B048B7A8645303FDC9F30EFBC79EAA@PUEXCB1B.nanterre.francetelecom.fr> <22008_1268058768_4B950A90_22008_213649_1_94C682931C08B048B7A8645303FDC9F30EFC0180AB@PUEXCB1B.nanterre.francetelecom.fr> <35FE871E2B085542A35726420E29DA6B037B0E21@gaalpa1msgusr7a.ugd.att.com> <4B97BE44.2060302@nic.at> <35FE871E2B085542A35726420E29DA6B0384131D@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0384131D@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] is this TRIP necessary? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 22:23:44 -0000 Penn, On 10.03.2010 17:23, PFAUTZ, PENN L (ATTCORP) wrote: > > But I'd really like to raise what I think is a larger issue - just what > are we trying to accomplish? > Good question: what kind of interconnection model is the right one? That is the 1 M $ question. > All the LRF and TRIP stuff seems to be tending toward a kind of > link-by-link call routing model that to me seems redolent of the kind > of trunk group by trunk group routing in the PSTN. I thought that that > was what we were trying to get away from in moving to IP! The original > promise of ENUM was that it would identify the target and basic Internet > connectivity would then get you there. As you've pointed out elsewhere, (For those who have not followed the discussions in speermint, my arguments are laid out in draft-lendl-speermint-background-02 ) > that original vision didn't really work for most carriers, but carriers > have tried to replicate parts of it with approaches like the GSMA IPX to > provide a secure IP fabric for connecting. That allows connectivity > management via selective advertising in BGP so that the SIP INVITES > based on same ENUM query response is appropriately routed from different > originating networks. The same techniques support direct bilateral > interconnection which is how much of the traffic will flow anyway. That the carriers seem to be falling for this blatant monopoly play by the IPX advocates is something that never fails to amaze me. I just don't see how bilateral peerings outside the IPX can be visible in the Layer 3 routing map of the IPX and thus be eligible to be used as transit links. All this fancy BGP trickery only works if *all* players in the VoIP routing space are IPX members (will the IPX admit corporate PBxs into their net?) and all transit-capable links between them are within the IPX framework. > So, when would you want something TRIP like? To me the remaining case > seems to be when you're searching for the best intermediary when you're > neither directly connected nor linked to some kind of IPX like fabric > that can get to the target. I expect intermediaries to compete and > scale to matter. When I need an intermediary I'll generally prefer that > they handle the whole job. Some pricing tables will let me choose and > I'm not sure I need/want those coming across the NNI as reachability > advertisements. If the main problem is that you can't fully mesh all SSPs (which includes PBXs), then shifting the interconnection duty to "intermediaries" does simplify the problem a bit, but it does not solve it. That step only works if all the intermediaries are members of the IPX. This is not realistic. There will be competing peering infrastructures. Starting from other commercial undertakings in the western world (Xconnect & co) to perhaps a Chinese peering platform and an Arabic one. Now, will all intermediaries join all those platforms? Will any two of them share at least one? Or will there be a hierarchy of intermediaries (just like the tiers in the PSTN and the Internet world)? How will routing information be passed between the tiers? Across multiple fabrics? Maybe the IPX proponents have a plan for that. I haven't seen it. > Add to this the downward pressure on rates that is only going > accelerate and I wonder how much need there really is. I may be biased > from my vantage point though and perhaps someone can provide the > compelling use case. >From my point of view, the pressure on rates will continue, and in the long term they will be replaced by the cost the destination places on his attention. A hardcore end to end interconnection model will run into the same problems email faces these days. The price I pay to my voice operator will shift from paying for the transmission capacity to what additional trust and accountability he can confer the called party. What I can imagine for the future is a scenario where PBXs/carriers will allow calls from trusted parties (however that is defined) to reach their ingress points without settlement. But I doubt that I will allow my phone to ring just because some punk in Indonesia sends my PBX a few IP packets. That will be one of the jobs of a carrier: I will want to get the call either directly from someone who falls under my criteria of a trusted communication partner or from some carrier that either pays me to let the phone ring, guarantees that he polices his users, or simply charges his users for calling me. We're entering a phase where attention is more valuable than the 64kbit/s transmission capacity of a traditional voice channel. The business model of carriers might need to adjust to that, and I definitely think there is a role for them here. If not, voice will move from being a service to being a product that I buy at my local electronics discounter just as I buy a wlan AP there. (And no, Skype / Google Talk / won't cut it. Not for replacing a word-wide, ubiquitous medium that can act as a global default communication path.) But we're getting slightly off tangent here ... Anyway, I few years ago I proposed a scheme that tried to integrate both RFC 3263-style end-2-end routing, controlled opportunistic peering, and old-style PSTN-like transit routing into one overall scheme. This would have allowed SSPs full control over their peering/interconnection strategies and would have allow mixed mode arrangements and thus gradual changes in policy to allow for an evolution of the interconnection ecosystem. Speermint wasn't interested. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From stpeter@stpeter.im Thu Mar 11 18:38:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C783A68A2 for ; Thu, 11 Mar 2010 18:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRr4Ky7sCoIM for ; Thu, 11 Mar 2010 18:38:36 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8D8D43A67D1 for ; Thu, 11 Mar 2010 18:38:32 -0800 (PST) Received: from squire.local (dsl-175-55.dynamic-dsl.frii.net [216.17.175.55]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AAE9A40E14; Thu, 11 Mar 2010 19:38:37 -0700 (MST) Message-ID: <4B99A92C.9010802@stpeter.im> Date: Thu, 11 Mar 2010 19:38:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Emil Ivov References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050101070501050509060502" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 02:38:37 -0000 This is a cryptographically signed message in MIME format. --------------ms050101070501050509060502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/11/10 3:07 PM, Emil Ivov wrote: > On Thu, Mar 11, 2010 at 9:20 PM, Peter Saint-Andre = wrote: >>>> 1. What kind of URI are you talking about? >>> >>> The the stpeter@stpeter.im kind. >> >> Since it lacks a scheme, stpeter@stpeter.im is not a URI. >=20 > True. I guess ID would have been a better choice. Is this a problem > for any other reason than the misuse of the term? Life certainly is simpler if your chat ID and your voice ID are the same -- and *really* simple if the same as your email ID. This is how service providers such as Google do things. Naturally, not every provider wants to offer a combined email+chat+voice service because it's a lot more work= =2E >>>> 4. Does the client derive a username from the URI so that it can use= an >>>> authentication mechanism that expects a username and password? >>> >>> Yes, exactly. The way most clients would do for SIP and XMPP already.= >>> This is just about making sure that they would be able to bring the >>> assumption over to a SIP+XMPP service. >> >> That is unclear to me. Do I visit a website, receive an email with a >> URI, click that to authorize, and receive credentials for my combined >> SIP+XMPP account? >=20 > Yes, for example.=20 OK. But it's still now clear what engineering work is required here. In the flow you describe, there is some social communication with the end user ("your chat+voice account has been created!"), but no automated way of informing the user's software that the account supports XMPP for chat and SIP for voice. How exactly does the provider communicate that fact to the application, given that the user's SIP+XMPP application is not involved in the account provisioning process (as far as I can tell)? Are you thinking that the end user will employ their SIP+XMPP application to complete account provisioning, or that the application will communicate with a web-based registration system somehow? Is there discovery involved on the part of the SIP+XMPP application? > Pretty much the same way you would get them at > register.jabber.org (while it worked ;) ). Yeah yeah yeah. :P We're working on it. Running code isn't always a lot of fun for those who run the service... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050101070501050509060502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMjAyMzgzNlowIwYJKoZIhvcNAQkEMRYEFGteiurm8gzKdaWsgRjA wuTusDofMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAN2MOYh40gB4IgVgwi+GPNr8f55L7bo7EuV9BXI+4 b+Y8o2uEkS1muWFLERACf+0GLP7Yl5rJHx1LYFGyWjaHxr5TjWb2mz3/Th61K8f7xMeHtr6O XpJyKWNlZrwR1jB3j9lmzQYS7bz8TH4fEwMihTfMpI5vX6858aHXNCtdirR9LH2jvCrGILjG UUuw8IUCdDjz7LWalolKUJxbAzW3BTxuw4+pxHhfoVExwOmvZURJEURPERV43INtCceA1gp0 8NFq0s+hwZhvykoHVV6oOke45jGyWVfx+8AAEMewNXdIDeaJUDO0imKX5ut+WLPuARimvchN 4ra6lPxUq1w4mwAAAAAAAA== --------------ms050101070501050509060502-- From gregert@teigre.com Thu Mar 11 23:18:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DBB3A68B2 for ; Thu, 11 Mar 2010 23:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPawZFgMAJk0 for ; Thu, 11 Mar 2010 23:18:58 -0800 (PST) Received: from pontius.teigre.com (pontius.teigre.com [213.225.78.155]) by core3.amsl.com (Postfix) with ESMTP id 9C2A03A6BB3 for ; Thu, 11 Mar 2010 23:18:45 -0800 (PST) X-ClientAddr: 217.14.5.61 Received: from [192.168.5.192] (217-14-5-61-dhcp-osl.bbse.no [217.14.5.61]) (authenticated bits=0) by pontius.teigre.com (8.13.8/8.13.8) with ESMTP id o2C7IlUO029458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Mar 2010 08:18:47 +0100 Message-ID: <4B99EAD7.9090407@teigre.com> Date: Fri, 12 Mar 2010 08:18:47 +0100 From: Greger Viken Teigre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigre.com-MailScanner-Information: Please contact the ISP for more information X-teigre.com-MailScanner: Found to be clean X-teigre.com-MailScanner-From: gregert@teigre.com Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 07:18:59 -0000 On 11.03.2010 00:48, Dean Willis wrote: > > On Mar 10, 2010, at 5:16 PM, Daryl Malas wrote: > >> Dean, >> >> Based on your assessment below, let me try and summarize: >> >> Two IETF efforts: >> 1) Egress Route Method for SIP (Intra-domain) >> 2) Dynamic Routing Method for SIP (Inter-domain) > > It's possible both could be done by one protocol, possibly with two > modes of operation. > I think you're onto something here. A few observations from the context of business-quality video conferencing/telepresence (some may be on a tangent, but as a different perspective on related problems): Even within an enterprise network, there may be different administrative domains. E.164 numbers are starting to become really difficult to manage as geography is less relevant when the clients roam. Due to this and because of an increasing number of SIP-based non-PSTN services that connect into the voice-fabric of the enterprise (presence federation, hunt groups across voice, video, PC client), more and more a domain-based routing model are mixed with the traditional e.164 dial plan. If you do a 4Mb/s video call, choosing the right egress point from one administrative domain to another or towards a peering partner/service provider becomes critical due to the bandwidth requirements and need for a capable client at the other end. Choosing the right egress can actually influence whether the call goes through at all (or end up as voice only, when yuo could have had video). We see more and more mixed environments where SIP clients either register to or send SIP messages over other vendors' SIP servers. If the call is routed (or forked) to multiple destinations, you can never be sure that you actually get the "best" result (as in get to the callee client with the most compatible functionality), and in fact, often the call will fail because you may get a quicker response from a less-capable network/device, it attempts to take the call with a 200 OK (or maybe Not supported here) and then something fails due to incompatibilities in SDP. There is not only a question of choosing the right egress, but when you move outside your domain, you don't have any control, so the problem becomes bigger. As a service provider offering connectivity to the enterprise, there is no good way to plan the egress together with the enterprise. A 4 Mb/s video call may be attempted over a SIP trunk not capable of a video call (e.g. local branch office in one country), while the same call could have been successfully forwarded through the main office in another country. Well, you tell the user: you used the wrong URI or number. Or the hunt group was configured with wrong priorities. Why should the user care? Then once in the service provider's network, the calls have a tendency to use e.164 numbers (because that's what the service provider "likes") with a domain that sometimes seems to be accidental. If the call is a PSTN call, it's much cheaper to route the call over the old interconnects, but if it's a 4Mb/s video call, you may want to route over another peering fabric for video. You can solve that by separating voice and video (which is mostly done as video often is over the data network) and the address space so that the routing decision is really left to the user. Some of these examples have multiple problems in them, but following the discussion, I have been a bit worried that the focus on fixing a problem for service providers doing regular voice calls and solving it with ENUM will make us forget that there are some other related problems that are looming in the not so distant future. I am therefore happy that the focus has shifted a bit towards solving the generic problem. And BTW, the problems are not really only video-focused. If you want to peer HD voice traffic, you need a way to filter out the e.164 numbers you can route over an HD-capable peering network, while the remaining calls go the cheap route. The typical resolution I have seen is to set up an ENUM service. I haven't really seen how this can scale to using URIs, and to a complex set of capabilities (IM, presence, video of different flavors...) g-) > -- > Dean > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From enrico.marocco@telecomitalia.it Fri Mar 12 01:58:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215033A6B0D for ; Fri, 12 Mar 2010 01:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.05 X-Spam-Level: ** X-Spam-Status: No, score=2.05 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25A5FJet1JNR for ; Fri, 12 Mar 2010 01:58:55 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id B41783A6A42 for ; Fri, 12 Mar 2010 01:58:54 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Mar 2010 10:58:55 +0100 Received: from [163.162.173.9] (163.162.173.9) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Mar 2010 10:58:54 +0100 Message-ID: <4B9A1074.6080706@telecomitalia.it> Date: Fri, 12 Mar 2010 10:59:16 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Peter Saint-Andre References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> <4B99A92C.9010802@stpeter.im> In-Reply-To: <4B99A92C.9010802@stpeter.im> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060207080200030706040801" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 09:58:56 -0000 --------------ms060207080200030706040801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Peter Saint-Andre wrote: >>>>> 1. What kind of URI are you talking about? >>>> The the stpeter@stpeter.im kind. >>> Since it lacks a scheme, stpeter@stpeter.im is not a URI. >> True. I guess ID would have been a better choice. Is this a problem >> for any other reason than the misuse of the term? > > Life certainly is simpler if your chat ID and your voice ID are the same > -- and *really* simple if the same as your email ID. This is how service > providers such as Google do things. Naturally, not every provider wants > to offer a combined email+chat+voice service because it's a lot more work. The discussion is getting very close to the point. If you are a multi-service provider with a user base of millions, you can expect developers to offer custom integration of your services in their platforms in order to make life easier to the users. That's basically why iPhone and Android devices offer a shortcut for configuring email+IM+calendar+whatever Google services altogether, simply entering your credentials once. Of course things work like that for Google and maybe for a few others, but certainly not for small providers. The goal of the draft is to stimulate discussion on the topic and to explore how existing mechanisms (like, e.g., the domain parameter used in DIGEST authentication) can be used to achieve seamless integration of SIP and XMPP accounts in a standard way. We certainly do not want to mandate service providers to offer both services, nor to standardize some exotic multi-purpose configuration framework that will take years to define and will never see the light. -- Ciao, Enrico --------------ms060207080200030706040801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMzEy MDk1OTE2WjAjBgkqhkiG9w0BCQQxFgQUF8s+OE3cZ2zPL2LsqrEGvDdwde0wXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAJ+luv4Mwkyb2+0oiqx2 zCgPkaMymWU6HcigMT1fBdyh/XE50VWiTp6pB+38iEddtAJ3rBIJDfV+5Eau/EUv05s33xJY CP6AXbqY3SKClszGqLjQ0z8xiN73P4Qn0VW+EwtsBvMiMO5bL7G/PSp1Nlzxl6rpJ00PWpdh QKr3K2lVs2qYplOWcqTZkwlA3aAr1U6dBdnVAh1jyOKr/7YUxAiCTnR0Yu3L8SYBsqdQxEXh +dUyqH3XobMatsagbRY05MTST5c998B+k5KtHew5zLBDQi3inK329tyWdvLH+/3O6SLtaN2h 6JhPtqXvo/RgGN9mree8xfryoQBmxx5JcMsAAAAAAAA= --------------ms060207080200030706040801-- From emcho@sip-communicator.org Fri Mar 12 04:54:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DC53A6905 for ; Fri, 12 Mar 2010 04:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.44 X-Spam-Level: X-Spam-Status: No, score=0.44 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnwZWTJ5qx-X for ; Fri, 12 Mar 2010 04:54:12 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id B0C093A68D3 for ; Fri, 12 Mar 2010 04:54:11 -0800 (PST) Received: by bwz3 with SMTP id 3so1106681bwz.29 for ; Fri, 12 Mar 2010 04:54:14 -0800 (PST) Received: by 10.204.161.197 with SMTP id s5mr2336843bkx.90.1268398454178; Fri, 12 Mar 2010 04:54:14 -0800 (PST) Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id g18sm5099292bkw.7.2010.03.12.04.54.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Mar 2010 04:54:13 -0800 (PST) Message-ID: <4B9A3973.40501@sip-communicator.org> Date: Fri, 12 Mar 2010 13:54:11 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> <4B99A92C.9010802@stpeter.im> In-Reply-To: <4B99A92C.9010802@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 12:54:12 -0000 Adding to what Enrico said, Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > OK. But it's still now clear what engineering work is required here. In= > the flow you describe, there is some social communication with the end > user ("your chat+voice account has been created!"), but no automated wa= y > of informing the user's software that the account supports XMPP for cha= t > and SIP for voice. How exactly does the provider communicate that fact > to the application, given that the user's SIP+XMPP application is not > involved in the account provisioning process (as far as I can tell)?=20 The provider doesn't need to communicate that fact to the application. The user does this by choosing to create a SIP+XMPP account. Again, it's pretty much what what already happens with multi protocol clients for SIP and XMPP only accounts. Cheers, Emil From stpeter@stpeter.im Fri Mar 12 07:23:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB01F3A6D08 for ; Fri, 12 Mar 2010 07:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAnkqb6vJIJq for ; Fri, 12 Mar 2010 07:23:46 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 44CE53A684A for ; Fri, 12 Mar 2010 07:06:49 -0800 (PST) Received: from squire.local (dsl-179-231.dynamic-dsl.frii.net [216.17.179.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 67E9340E14; Fri, 12 Mar 2010 08:06:54 -0700 (MST) Message-ID: <4B9A588D.5080307@stpeter.im> Date: Fri, 12 Mar 2010 08:06:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Emil Ivov References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> <4B99A92C.9010802@stpeter.im> <4B9A3973.40501@sip-communicator.org> In-Reply-To: <4B9A3973.40501@sip-communicator.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050509090707050301050003" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:23:48 -0000 This is a cryptographically signed message in MIME format. --------------ms050509090707050301050003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/12/10 5:54 AM, Emil Ivov wrote: > Adding to what Enrico said, >=20 > Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: >> OK. But it's still now clear what engineering work is required here. I= n >> the flow you describe, there is some social communication with the end= >> user ("your chat+voice account has been created!"), but no automated w= ay >> of informing the user's software that the account supports XMPP for ch= at >> and SIP for voice. How exactly does the provider communicate that fact= >> to the application, given that the user's SIP+XMPP application is not >> involved in the account provisioning process (as far as I can tell)?=20 >=20 > The provider doesn't need to communicate that fact to the application. > The user does this by choosing to create a SIP+XMPP account. Again, it'= s > pretty much what what already happens with multi protocol clients for > SIP and XMPP only accounts. Yes, this is all quite beautiful. But I still don't see what engineering work is required within the IETF to make this happen. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050509090707050301050003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMjE1MDY1M1owIwYJKoZIhvcNAQkEMRYEFHHlKx9NOj+4ZiXSkVfS WgrM38a7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAD9ZXIfwjEK08ilLAMKvIfiorc7J55YClAlyCeHR4 kTUwlfZjXWGmHAQUIKM493cEFvCt6SR6sKSoLcKlEgCwKx/zNyiSfhOgHyrPs6elmbAq5iVg 6F4dUtj45yT/YsxfyA5nH9OEorL8Ui4x0dlYwjC1FZGCB7DfbqPzgsThFvR0spcKMpaEq9fG 1pGYZPr9Mp6hiCX6pHYNr/dhb43kHpNQTi9TjKjkxCk4SSnIdAiCRsNlGAP6vIMXhxNNJAL9 e+t1CUv+1MkcdFHmpvflkwPoliuQDQ1ISu95rKVRw+wHRqETZst8IcY0aoWU1fQAExUva0t0 pLyzReK95gHXNwAAAAAAAA== --------------ms050509090707050301050003-- From stpeter@stpeter.im Fri Mar 12 07:27:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E3E3A6886 for ; Fri, 12 Mar 2010 07:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KJJpF2D3KLi for ; Fri, 12 Mar 2010 07:26:59 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4616D3A6911 for ; Fri, 12 Mar 2010 07:08:36 -0800 (PST) Received: from squire.local (dsl-179-231.dynamic-dsl.frii.net [216.17.179.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A880440E14; Fri, 12 Mar 2010 08:08:41 -0700 (MST) Message-ID: <4B9A58F8.7020205@stpeter.im> Date: Fri, 12 Mar 2010 08:08:40 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Enrico Marocco References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> <4B99A92C.9010802@stpeter.im> <4B9A1074.6080706@telecomitalia.it> In-Reply-To: <4B9A1074.6080706@telecomitalia.it> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000400060506020603060205" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:27:00 -0000 This is a cryptographically signed message in MIME format. --------------ms000400060506020603060205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/12/10 2:59 AM, Enrico Marocco wrote: > Peter Saint-Andre wrote: >>>>>> 1. What kind of URI are you talking about? >>>>> The the stpeter@stpeter.im kind. >>>> Since it lacks a scheme, stpeter@stpeter.im is not a URI. >>> True. I guess ID would have been a better choice. Is this a problem >>> for any other reason than the misuse of the term? >> >> Life certainly is simpler if your chat ID and your voice ID are the sa= me >> -- and *really* simple if the same as your email ID. This is how servi= ce >> providers such as Google do things. Naturally, not every provider want= s >> to offer a combined email+chat+voice service because it's a lot more w= ork. >=20 > The discussion is getting very close to the point. If you are a > multi-service provider with a user base of millions, you can expect > developers to offer custom integration of your services in their > platforms in order to make life easier to the users. That's basically > why iPhone and Android devices offer a shortcut for configuring > email+IM+calendar+whatever Google services altogether, simply entering > your credentials once. >=20 > Of course things work like that for Google and maybe for a few others, > but certainly not for small providers.=20 Indeed. > The goal of the draft is to > stimulate discussion on the topic and to explore how existing mechanism= s > (like, e.g., the domain parameter used in DIGEST authentication) can be= > used to achieve seamless integration of SIP and XMPP accounts in a > standard way.=20 OK, I do think that's worth exploring. > We certainly do not want to mandate service providers to > offer both services, nor to standardize some exotic multi-purpose > configuration framework that will take years to define and will never > see the light. +1 to that! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000400060506020603060205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMjE1MDg0MFowIwYJKoZIhvcNAQkEMRYEFBbmhc1/yg2FXs9u58Ya VkTrfvLsMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAenzsOO998FgB104vuFbs0seRgeHeTcOHZemwQ+63 jcmj7EP/MPw6VxHddbi+7JwfZwa+RqcLU/Vuqx/YNSuLvngASfk8QCHQ8b3c2l7Fl1+mYVnw XegziFSaltEy4E0CdklgAJ3hkZ4KaEB9mk4PZBLF1xUk4iN8jWWtSA42xduAs/4DtX3e1zJ0 OMZlJQ94IzYKB3XJ240105czKvOtdXi3nLwYK+LOnMiS0ivj1FNxTapPNl15CixySk6xA6+f +8RqDvCiyrbGgpclI4RBdFyZLowoIaDnaq9ETu9oTcU8vE6cUHMdmIlkSK9Ph5OPYOxn51BA QthEFVTGaFfKagAAAAAAAA== --------------ms000400060506020603060205-- From emcho@sip-communicator.org Fri Mar 12 07:50:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFA53A6B24 for ; Fri, 12 Mar 2010 07:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4rYq0B4Sim6 for ; Fri, 12 Mar 2010 07:50:58 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 811D93A6A5C for ; Fri, 12 Mar 2010 07:35:36 -0800 (PST) Received: by bwz3 with SMTP id 3so1266907bwz.29 for ; Fri, 12 Mar 2010 07:35:39 -0800 (PST) Received: by 10.204.137.1 with SMTP id u1mr1654860bkt.151.1268408135506; Fri, 12 Mar 2010 07:35:35 -0800 (PST) Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id g18sm5675352bkw.19.2010.03.12.07.35.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Mar 2010 07:35:34 -0800 (PST) Message-ID: <4B9A5F45.2090002@sip-communicator.org> Date: Fri, 12 Mar 2010 16:35:33 +0100 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <4B97B5F0.3030905@sip-communicator.org> <4B99295D.9090008@stpeter.im> <598FE5D9-781D-44A4-B465-C843FB231E9E@sip-communicator.org> <4B995081.4090201@stpeter.im> <4B99A92C.9010802@stpeter.im> <4B9A3973.40501@sip-communicator.org> <4B9A588D.5080307@stpeter.im> In-Reply-To: <4B9A588D.5080307@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Authentication for SIP+XMPP clients X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:50:59 -0000 Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > On 3/12/10 5:54 AM, Emil Ivov wrote: >> Adding to what Enrico said, >> >> Peter Saint-Andre =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: >>> OK. But it's still now clear what engineering work is required here. = In >>> the flow you describe, there is some social communication with the en= d >>> user ("your chat+voice account has been created!"), but no automated = way >>> of informing the user's software that the account supports XMPP for c= hat >>> and SIP for voice. How exactly does the provider communicate that fac= t >>> to the application, given that the user's SIP+XMPP application is not= >>> involved in the account provisioning process (as far as I can tell)? = >> The provider doesn't need to communicate that fact to the application.= >> The user does this by choosing to create a SIP+XMPP account. Again, it= 's >> pretty much what what already happens with multi protocol clients for >> SIP and XMPP only accounts. >=20 > Yes, this is all quite beautiful. But I still don't see what engineerin= g > work is required within the IETF to make this happen. Ideally - none. If we can agree that SIP+XMPP clients can assume they can SRV query the SIP and XMPP counterparts of a SIP+XMPP using the usual records, and that they can also assume they would be using the same credentials to log against both of these protocols and people feel that this fits the charter (and doesn't violate the the no-modifications-on-the-server-side requirement), then all we need is a paragraph in the sip+xmpp document that describes this. At worst we can put it in a BCP doc. Otherwise, people may think that the subject is more complicated than that and that it needs to be explored further for some reason and in this case there maybe something else to do, and of course I have no idea what it may be. Cheers, Emil From rjsparks@nostrum.com Fri Mar 12 07:57:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1CC3A6CDC; Fri, 12 Mar 2010 07:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrFHdFbCiPb7; Fri, 12 Mar 2010 07:57:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 582AF3A6A2B; Fri, 12 Mar 2010 07:42:54 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2CFgwJw013316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Mar 2010 09:42:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Fri, 12 Mar 2010 09:42:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <204C0846-1479-4795-88F2-903A4BDD5837@cisco.com> To: siprec@ietf.org, SIPCORE , codec@ietf.org, DISPATCH list , ecrit@ietf.org, XMPP , rai@ietf.org X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [dispatch] RAI WG chair changes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rai@ietf.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:57:04 -0000 WIth the upcoming IESG and IAB changes, we need to make=20 a bunch of chair changes. After the end of the IETF 77 the chairs=20 for the following WGs will be: SIPREC=20 Brian Rosen John Elwell SIPCORE Adam Roach Paul Kyzivat CODEC Michael Knappe Jonathan Rosenberg Cullen Jennings DISPATCH Mary Barnes Cullen Jennings ECRIT=20 Richard Barnes Marc Linsner XMPP Joe Hildebrand Ben Campbell To help with continuity of the IETF77 meeting, we are going to add the = new chairs now,=20 and not remove any existing chairs until after the meeting.=20 We would like to express many thinks for all the work all these chairs = have done and continue to do.=20 Thanks,=20 Cullen, Gonzalo, & Robert From fluffy@cisco.com Fri Mar 12 08:01:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382273A6C48; Fri, 12 Mar 2010 08:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj9E+cnc4-Ge; Fri, 12 Mar 2010 08:01:03 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 90C5C3A6CC4; Fri, 12 Mar 2010 07:49:02 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADrxmUurR7Ht/2dsb2JhbACaanOifphRhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,626,1262563200"; d="scan'208";a="99270463" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Mar 2010 15:49:08 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2CFn85G006554; Fri, 12 Mar 2010 15:49:08 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Fri, 12 Mar 2010 08:49:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: To: siprec@ietf.org X-Mailer: Apple Mail (2.1077) Cc: DISPATCH , rai@ietf.org Subject: [dispatch] NEW SIPREC Working Group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: siprec@ietf.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 16:01:04 -0000 The SIPREC working group has been approved and you will see the = announcements soon. I'd like to encourage everyone to go subscribe to = the siprec mailing list at: ( https://www.ietf.org/mailman/listinfo/siprec ) I'd very much like to thank Brian Rosen and John Elwell for agreeing to = chair this ship.=20 The tentative plan is to take an hour of time from the sipcore meeting = and run a SIPREC working group meeting meeting from 10:30 to 11:30 = Tuesday March 23 in the California B room. Please note this is a = tentative plan, I'm trying to get this to work but it not finalized yet.=20= Cullen From jmpolk@cisco.com Fri Mar 12 11:31:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829463A690A; Fri, 12 Mar 2010 11:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5SNQ0dqvhyM; Fri, 12 Mar 2010 11:31:22 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 32DFC3A68B5; Fri, 12 Mar 2010 11:31:22 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEIlmkurRN+J/2dsb2JhbACaanOjRphXhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,627,1262563200"; d="scan'208";a="165205802" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2010 19:31:28 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2CJVRSc029217; Fri, 12 Mar 2010 19:31:28 GMT Message-Id: <201003121931.o2CJVRSc029217@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Mar 2010 13:31:27 -0600 To: siprec@ietf.org, siprec@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: DISPATCH , rai@ietf.org Subject: Re: [dispatch] [RAI] NEW SIPREC Working Group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:31:23 -0000 At 09:49 AM 3/12/2010, Cullen Jennings wrote: >The SIPREC working group has been approved and you will see the >announcements soon. I'd like to encourage everyone to go subscribe >to the siprec mailing list at: > >( https://www.ietf.org/mailman/listinfo/siprec ) > >I'd very much like to thank Brian Rosen and John Elwell for agreeing >to chair this ship. hence the mangled name of "shipwreck" for the wg... like Dean suggested... lol (it's Friday) > > >The tentative plan is to take an hour of time from the sipcore >meeting and run a SIPREC working group meeting meeting from 10:30 to >11:30 Tuesday March 23 in the California B room. Please note this is >a tentative plan, I'm trying to get this to work but it not finalized yet. > >Cullen > > > > >_______________________________________________ >RAI mailing list >RAI@ietf.org >https://www.ietf.org/mailman/listinfo/rai From ranjit@motorola.com Fri Mar 12 21:27:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6BF3A6834; Fri, 12 Mar 2010 21:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KIAXcvxl03v; Fri, 12 Mar 2010 21:27:26 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 21B5C3A694A; Fri, 12 Mar 2010 21:27:18 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1268458043!40364755!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29324 invoked from network); 13 Mar 2010 05:27:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2010 05:27:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o2D5RN12026589; Fri, 12 Mar 2010 22:27:23 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o2D5RNrE003499; Fri, 12 Mar 2010 23:27:23 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o2D5RLZX003496; Fri, 12 Mar 2010 23:27:22 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC26D.CE17FB13" Date: Sat, 13 Mar 2010 13:26:58 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Query on draft-ietf-sipcore-info-events-07 thread-index: AcrCbc1fOC+kPgM7SvG/qQEEcug40Q== From: "Avasarala Ranjit-A20990" To: X-CFilter-Loop: Reflected Cc: sipcore@ietf.org Subject: [dispatch] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 05:27:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC26D.CE17FB13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Are there any registered INFO packages and can the regular SIP event packages based on RFC 3265 be used with INFO mechanism? Thanks Regards Ranjit ------_=_NextPart_001_01CAC26D.CE17FB13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Query on draft-ietf-sipcore-info-events-07

Hi all

Are there any registered INFO packages = and can the regular SIP event packages based on RFC 3265 be used with = INFO mechanism?

Thanks

Regards
Ranjit

------_=_NextPart_001_01CAC26D.CE17FB13-- From adam@nostrum.com Mon Mar 15 08:48:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEE23A68F2 for ; Mon, 15 Mar 2010 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo8Wta197+n2 for ; Mon, 15 Mar 2010 08:48:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E9E283A6805 for ; Mon, 15 Mar 2010 08:48:02 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FFm7Z6035136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 10:48:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E56B7.6070009@nostrum.com> Date: Mon, 15 Mar 2010 10:48:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Greger Viken Teigre References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> In-Reply-To: <4B99EAD7.9090407@teigre.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:48:04 -0000 Greger: For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) provide about 80% of what you're asking for. /a On 3/12/10 01:18, Mar 12, Greger Viken Teigre wrote: > Even within an enterprise network, there may be different > administrative domains. E.164 numbers are starting to become really > difficult to manage as geography is less relevant when the clients > roam. Due to this and because of an increasing number of SIP-based > non-PSTN services that connect into the voice-fabric of the enterprise > (presence federation, hunt groups across voice, video, PC client), > more and more a domain-based routing model are mixed with the > traditional e.164 dial plan. If you do a 4Mb/s video call, choosing > the right egress point from one administrative domain to another or > towards a peering partner/service provider becomes critical due to the > bandwidth requirements and need for a capable client at the other end. > Choosing the right egress can actually influence whether the call goes > through at all (or end up as voice only, when yuo could have had video). > > We see more and more mixed environments where SIP clients either > register to or send SIP messages over other vendors' SIP servers. If > the call is routed (or forked) to multiple destinations, you can never > be sure that you actually get the "best" result (as in get to the > callee client with the most compatible functionality), and in fact, > often the call will fail because you may get a quicker response from a > less-capable network/device, it attempts to take the call with a 200 > OK (or maybe Not supported here) and then something fails due to > incompatibilities in SDP. There is not only a question of choosing the > right egress, but when you move outside your domain, you don't have > any control, so the problem becomes bigger. > > As a service provider offering connectivity to the enterprise, there > is no good way to plan the egress together with the enterprise. A 4 > Mb/s video call may be attempted over a SIP trunk not capable of a > video call (e.g. local branch office in one country), while the same > call could have been successfully forwarded through the main office in > another country. Well, you tell the user: you used the wrong URI or > number. Or the hunt group was configured with wrong priorities. Why > should the user care? > > Then once in the service provider's network, the calls have a tendency > to use e.164 numbers (because that's what the service provider > "likes") with a domain that sometimes seems to be accidental. If the > call is a PSTN call, it's much cheaper to route the call over the old > interconnects, but if it's a 4Mb/s video call, you may want to route > over another peering fabric for video. You can solve that by > separating voice and video (which is mostly done as video often is > over the data network) and the address space so that the routing > decision is really left to the user. > > Some of these examples have multiple problems in them, but following > the discussion, I have been a bit worried that the focus on fixing a > problem for service providers doing regular voice calls and solving it > with ENUM will make us forget that there are some other related > problems that are looming in the not so distant future. I am therefore > happy that the focus has shifted a bit towards solving the generic > problem. > > And BTW, the problems are not really only video-focused. If you want > to peer HD voice traffic, you need a way to filter out the e.164 > numbers you can route over an HD-capable peering network, while the > remaining calls go the cheap route. The typical resolution I have seen > is to set up an ENUM service. I haven't really seen how this can scale > to using URIs, and to a complex set of capabilities (IM, presence, > video of different flavors...) > g-) > From pkyzivat@cisco.com Mon Mar 15 09:09:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09BE3A6B93 for ; Mon, 15 Mar 2010 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.271 X-Spam-Level: X-Spam-Status: No, score=-10.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGW8r+avt+aS for ; Mon, 15 Mar 2010 09:08:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 171AB3A6939 for ; Mon, 15 Mar 2010 09:08:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALf4nUtAZnwM/2dsb2JhbACacXOhYZdsglWCJgQ X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="92791292" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2010 16:09:05 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FG94qV007769; Mon, 15 Mar 2010 16:09:05 GMT Message-ID: <4B9E5B9E.7030907@cisco.com> Date: Mon, 15 Mar 2010 12:09:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> In-Reply-To: <4B9E56B7.6070009@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:09:01 -0000 Adam Roach wrote: > Greger: > > For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) > provide about 80% of what you're asking for. Selecting a *UAS* that has the capabilities the caller envisions using (such as video) were certainly among the things that were among the intended use cases. I'm dubious about their suitability for selecting a route to reach the UAS, assuming its the same UAS you are seeking. Also callerprefs are no guarantee (not even a superset) of the capabilities that will be used on a call. It is an entirely reasonable use case for a UAC to invite with no offer, and then negotiate the use of voice and video because the UAS offers that. Its also entirely reasonable for a call to start out as audio only, for the caller and callee to learn as a result of discussion that both are video capable, and then add video to the call. As non-voice media become more mainstream, and as e2e sip sessions become more feasible, we should be investigating how the infrastructure can avoid breaking these kinds of use cases. Nailing down the route in a way that precludes use of media not announced at call establishment time isn't going in a very helpful direction. Thanks, Paul > /a > > On 3/12/10 01:18, Mar 12, Greger Viken Teigre wrote: >> Even within an enterprise network, there may be different >> administrative domains. E.164 numbers are starting to become really >> difficult to manage as geography is less relevant when the clients >> roam. Due to this and because of an increasing number of SIP-based >> non-PSTN services that connect into the voice-fabric of the enterprise >> (presence federation, hunt groups across voice, video, PC client), >> more and more a domain-based routing model are mixed with the >> traditional e.164 dial plan. If you do a 4Mb/s video call, choosing >> the right egress point from one administrative domain to another or >> towards a peering partner/service provider becomes critical due to the >> bandwidth requirements and need for a capable client at the other end. >> Choosing the right egress can actually influence whether the call goes >> through at all (or end up as voice only, when yuo could have had video). >> >> We see more and more mixed environments where SIP clients either >> register to or send SIP messages over other vendors' SIP servers. If >> the call is routed (or forked) to multiple destinations, you can never >> be sure that you actually get the "best" result (as in get to the >> callee client with the most compatible functionality), and in fact, >> often the call will fail because you may get a quicker response from a >> less-capable network/device, it attempts to take the call with a 200 >> OK (or maybe Not supported here) and then something fails due to >> incompatibilities in SDP. There is not only a question of choosing the >> right egress, but when you move outside your domain, you don't have >> any control, so the problem becomes bigger. >> >> As a service provider offering connectivity to the enterprise, there >> is no good way to plan the egress together with the enterprise. A 4 >> Mb/s video call may be attempted over a SIP trunk not capable of a >> video call (e.g. local branch office in one country), while the same >> call could have been successfully forwarded through the main office in >> another country. Well, you tell the user: you used the wrong URI or >> number. Or the hunt group was configured with wrong priorities. Why >> should the user care? >> >> Then once in the service provider's network, the calls have a tendency >> to use e.164 numbers (because that's what the service provider >> "likes") with a domain that sometimes seems to be accidental. If the >> call is a PSTN call, it's much cheaper to route the call over the old >> interconnects, but if it's a 4Mb/s video call, you may want to route >> over another peering fabric for video. You can solve that by >> separating voice and video (which is mostly done as video often is >> over the data network) and the address space so that the routing >> decision is really left to the user. >> >> Some of these examples have multiple problems in them, but following >> the discussion, I have been a bit worried that the focus on fixing a >> problem for service providers doing regular voice calls and solving it >> with ENUM will make us forget that there are some other related >> problems that are looming in the not so distant future. I am therefore >> happy that the focus has shifted a bit towards solving the generic >> problem. >> >> And BTW, the problems are not really only video-focused. If you want >> to peer HD voice traffic, you need a way to filter out the e.164 >> numbers you can route over an HD-capable peering network, while the >> remaining calls go the cheap route. The typical resolution I have seen >> is to set up an ENUM service. I haven't really seen how this can scale >> to using URIs, and to a complex set of capabilities (IM, presence, >> video of different flavors...) >> g-) >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From adam@nostrum.com Mon Mar 15 09:24:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98AD3A677D for ; Mon, 15 Mar 2010 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUSQBVXj6pqU for ; Mon, 15 Mar 2010 09:24:35 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 556BD3A68C2 for ; Mon, 15 Mar 2010 09:24:35 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FGOdKF037910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 11:24:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E5F47.2040604@nostrum.com> Date: Mon, 15 Mar 2010 11:24:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> In-Reply-To: <4B9E5B9E.7030907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:24:36 -0000 On 3/15/10 11:09, Mar 15, Paul Kyzivat wrote: > > > Adam Roach wrote: >> Greger: >> >> For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) >> provide about 80% of what you're asking for. > > Selecting a *UAS* that has the capabilities the caller envisions using > (such as video) were certainly among the things that were among the > intended use cases. > > I'm dubious about their suitability for selecting a route to reach the > UAS, assuming its the same UAS you are seeking. That's the other 20%. :) > Also callerprefs are no guarantee (not even a superset) of the > capabilities that will be used on a call. It is an entirely reasonable > use case for a UAC to invite with no offer, and then negotiate the use > of voice and video because the UAS offers that. Its also entirely > reasonable for a call to start out as audio only, for the caller and > callee to learn as a result of discussion that both are video capable, > and then add video to the call. > > As non-voice media become more mainstream, and as e2e sip sessions > become more feasible, we should be investigating how the > infrastructure can avoid breaking these kinds of use cases. Nailing > down the route in a way that precludes use of media not announced at > call establishment time isn't going in a very helpful direction. Nailing down a route... for signaling? I'm a bit confused about how that is going to preclude certain media types. Now, if we want to talk about media steering, that's a completely different issue. I don't think SIP routing plays into that. /a From pkyzivat@cisco.com Mon Mar 15 09:33:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2943A6ABC for ; Mon, 15 Mar 2010 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C15i5xqUpiSS for ; Mon, 15 Mar 2010 09:33:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CE8A53A6C34 for ; Mon, 15 Mar 2010 09:33:43 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANn+nUtAZnwM/2dsb2JhbACacHOiBJdshHsE X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="92932799" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2010 16:33:50 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2FGXoaP015394; Mon, 15 Mar 2010 16:33:50 GMT Message-ID: <4B9E616C.1000208@cisco.com> Date: Mon, 15 Mar 2010 12:33:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> In-Reply-To: <4B9E5F47.2040604@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:33:54 -0000 Adam Roach wrote: > On 3/15/10 11:09, Mar 15, Paul Kyzivat wrote: >> >> >> Adam Roach wrote: >>> Greger: >>> >>> For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) >>> provide about 80% of what you're asking for. >> >> Selecting a *UAS* that has the capabilities the caller envisions using >> (such as video) were certainly among the things that were among the >> intended use cases. >> >> I'm dubious about their suitability for selecting a route to reach the >> UAS, assuming its the same UAS you are seeking. > > That's the other 20%. :) I think we're following the 80/80 rule here. :-) >> Also callerprefs are no guarantee (not even a superset) of the >> capabilities that will be used on a call. It is an entirely reasonable >> use case for a UAC to invite with no offer, and then negotiate the use >> of voice and video because the UAS offers that. Its also entirely >> reasonable for a call to start out as audio only, for the caller and >> callee to learn as a result of discussion that both are video capable, >> and then add video to the call. >> >> As non-voice media become more mainstream, and as e2e sip sessions >> become more feasible, we should be investigating how the >> infrastructure can avoid breaking these kinds of use cases. Nailing >> down the route in a way that precludes use of media not announced at >> call establishment time isn't going in a very helpful direction. > > Nailing down a route... for signaling? I'm a bit confused about how that > is going to preclude certain media types. > > Now, if we want to talk about media steering, that's a completely > different issue. I don't think SIP routing plays into that. Perhaps I misinterpreted the draft, but I got the distinct impression that media steering, following the signaling path, was presumed, and the primary issue being raised. Hence my concern. Paul From adam@nostrum.com Mon Mar 15 10:34:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8CB3A6A9E for ; Mon, 15 Mar 2010 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWHQC5a+1UKV for ; Mon, 15 Mar 2010 10:34:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C4C6E3A69C2 for ; Mon, 15 Mar 2010 10:33:15 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FHXKTs043178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 12:33:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E6F60.1040703@nostrum.com> Date: Mon, 15 Mar 2010 12:33:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> In-Reply-To: <4B9E616C.1000208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:34:32 -0000 On 3/15/10 11:33, Mar 15, Paul Kyzivat wrote: > > Adam Roach wrote: >> Nailing down a route... for signaling? I'm a bit confused about how >> that is going to preclude certain media types. >> >> Now, if we want to talk about media steering, that's a completely >> different issue. I don't think SIP routing plays into that. > > Perhaps I misinterpreted the draft, but I got the distinct impression > that media steering, following the signaling path, was presumed, and > the primary issue being raised. And, to be clear, that's probably what Daryl has in mind. But it doesn't sound like what Greger is trying to do. Daryl is working within the strictures of reproducing the business relationships of the PSTN in a SIP network. And the path that has been taken, for better or worse, involves the heavy use of SBCs and other devices that impose a rather strict control on the way things are done. These devices largely ensure that the media path follows the signaling path, even when that's not the optimal thing to do. The chances of such networks deploying video, hi-def voice, or any of the other really neat things that Greger mentions are slim to none. This, of course, is NOT Daryl's fault. But it's where the egress-route work comes from. Greger is speaking more towards the network you seem to have in mind -- one in which end-to-end SIP calls are possible, without SBCs or similar control boxes clobbering new services and mangling the ability to convey novel media from one endpoint to another. Networks where we don't need to define alternate connection models for protocols simply to accommodate network elements that do things that are explicitly disallowed by protocol specification. Don't get me wrong -- the business concerns driving SBC deployment are legitimate. But that doesn't change the fact that they destroy innovation. In many ways, these approaches represent an unfortunate bifurcation in the SIP road. One path leads to a rather stagnant network that manages to reproduce what we've been doing for the past century, possibly with some minor operational cost savings. The other leads to vibrant new services, end-to-end multimedia, and innovative applications. But that fork has already been taken, and I don't think we're going to join the paths back again any time soon. So, for the time being, we find ourselves doing work in the stagnant world (SPEERMINT, MARTINI, DRINKS) as well as the vibrant world (P2PSIP, SIP Certs, CODEC). And, while there can be some commonality between solutions, the increasing difficulty that people in the two different worlds have acknowledging the other makes it nearly impossible to come up with solutions that make everyone happy. The constituents of the stagnant world will find any vibrant solutions to be too complicated, too general, and subject to being broken by their intermediaries. The constituents of the vibrant world will find any stagnant solutions to be too brittle, too special-purpose, and too constrained. Getting back to the problem at hand. In the stagnant world, steering the signaling effectively steers the media. And if you can combine that steering with E.164-number lookup (because the stagnant world uses phone numbers), then the problem is solved. Anything more general is going to be too complicated, too general, and subject to be broken by SBCs. In the vibrant world, signaling and media follow different paths. Steering the signaling is unlikely to change the media path. If you want to steer media, you would need to do so explicitly. We already have some mechanisms defined in the RAI area to do this -- TURN comes to mind -- and there are probably others at layer 3 that I'm not familiar with. This is where we may need some new work. Anything that requires E.164 numbers as identifiers or that assumes media follows the signaling path is going to be too brittle, too special purpose, and too constrained. Which is to say that I don't think there is a solution that satisfies both groups. The divergence from the fork between the stagnant world and the vibrant world is great enough that there is no common ground left for these kinds of issues. As odious as it is, I'm afraid we're stuck with solving this problem twice. The real challenge is ensuring that stagnant solutions don't do lasting damage to the core protocols -- we need to make sure they don't destroy the vibrant world with collateral damage. Which is why I support a simple, non-normative, informational draft about the form of URLs that one might want to put in ENUM. It satisfies the requirements of the stagnant world, and doesn't even have any normative impacts on any protocol anywhere. It's harmless, and lets the people in the vibrant world concentrate on solving the problem in a more general way without having to accommodate the peculiarities of network elements living in the stagnant world. /a From gonzalo.camarillo@ericsson.com Tue Mar 16 03:58:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACD13A69F1 for ; Tue, 16 Mar 2010 03:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omGwAcexUIxR for ; Tue, 16 Mar 2010 03:58:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D958A3A683A for ; Tue, 16 Mar 2010 03:58:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-31-4b9f64761701 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CC.C5.23532.6746F9B4; Tue, 16 Mar 2010 11:59:03 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 11:59:02 +0100 Received: from [131.160.126.193] ([131.160.126.193]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 11:59:02 +0100 Message-ID: <4B9F6475.2030002@ericsson.com> Date: Tue, 16 Mar 2010 12:59:01 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2010 10:59:02.0296 (UTC) FILETIME=[B00B0980:01CAC4F7] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:58:57 -0000 Hi Ranjit, there is a blackout period before IETF meetings in which one cannot submit drafts. Please, submit this version as soon as the blackout period is over and have Paul have a look at it so that he can confirm he is happy with it. Thanks, Gonzalo On 11/03/2010 8:10 PM, Avasarala Ranjit-A20990 wrote: > Hi All > > I am not able to upload the updated version (-04) of the I-D due to some > issue with the I-D submission tool - (Says I can submit I-D only on > 2010-03-22). > Until then I am attaching a copy of the updated version (txt and html > formats). > > Please review and comment. > > Thanks > > Note: Let me know if there is any other way to upload the I-D document > and will be happy to do it. > > > > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 7:19 PM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > I think this all sounds good now. > > Thanks, > Paul > > Avasarala Ranjit-A20990 wrote: >> Inline >> >> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, March 02, 2010 2:16 AM >> To: Avasarala Ranjit-A20990 >> Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org >> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review >> ofdraft-avasarala-dispatch-comm-div-notification-03] >> >> inline... >> >> Avasarala Ranjit-A20990 wrote: >> >>> I'm still a little confused here. >>> If phone is on and subscription is active, then in general >>> notification should be possible, regardless of registration. I >>> realize >> >>> IMS doesn't permit that, but from a general standard perspective we >>> shouldn't assume it. The manifestation in this case is that the >>> NOTIFY >> >>> would fail and the subscription would eventually be torn down. >>> >>> So I think the cases are: >>> - there is a subscription and notification works >>> - there is a subscription but notification fails >>> - there is no subscription. >>> >>> Agreed. Actually instead of calling it as >>> Notification fails, we can say - not sending notification due to (1) >>> no match of filter criteria (2) phone not registered or outside >>> coverage area due to which there is no connectivity and hence >>> notification cannot be sent Anyway if no subscription, no >> notification. >> >> Are you suggesting that you might have a subscription, and have the >> filter criteria met, and yet not attempt to send a NOTIFY because the >> phone is not registered or has no network connectivity??? >> >> That seems wrong. ISTM that either you would remove the subscription, >> or else you would try to send the NOTIFY and then discover that it > fails. >> >> yes the subscription could be removed when the device is > >> not reachable. >> >> OTOH, this probably ought not to be within scope of what is discussed >> in this draft. >> >> yes true not within the scope of this draft. >> >>>> [3] in the example u suggested where sip:alice@atlanta.org with two >>>> contacts: sip:line1@alice.office.atlanta.com and >>>> sip:line2@alice.home.atlanta.com and >>>> both the phones ring, then it would be a case of parallel >> forking. >>>> Now say one or both the phones have set diversion rules, to divert >>>> the >>> In this case, what does it mean for "one or both phones have set >>> diversion rules"? Does that somehow imply distinct rules for each >> phone? >>> I don't see how that could work. Aren't the diversion rules for the >>> *AOR*? >>> >>> Yes the diversion rules are for AoR. So when there >>> is >> >>> a diversion rule set for the AoR and when diversions occur, the >>> notifications are Sent to the AoR. >> >> Not sent to the AoR - sent to the remote contact of the dialog for >> each subscription to the AoR. Same point as below that you agreed > with. >> >> Yes agree with u. >> >>> I see they could be set/changed from either phone. But its a single >>> set of rules isn't it? So I might set the rules from the office, and >>> then cancel them from home. >>> >>> yes single set and could be set from either of the >>> phones. True. >>> >>>> call to say >>>> sip:voicemail@alice.atlanta.com, then the notifications would >>>> get >> >>>> generated with respect to both the contacts. >>> Again I'm confused by the terminology you use, and how it relates >>> operationally. The diversion happens on the AOR, and the >>> subscriptions >> >>> are on the AOR, and the notifications are sent to the subscribers. I >>> don't see where the registered contacts enter into the picture at > all. >>> >>> Ya agree with you on this. Sorry for the confusion. >>> >>> If you have something else in mind, I hope you can explain it better >>> in the draft. >>> >>>> [4] Yes the value of N is configurable and depends on how many >>>> diversions the subscribe wants to keep or could be dependent on >>>> server policy (some maximum >>>> number). If the server policy is to send notifications as and >>>> when they occur and not keep any divsersions information, then the >>>> value of last N >>>> diversions will be zero. But if the server chooses to retain the > >>>> last diversion always, then the value of N will be 1 and so on. >>> All is straightforward for N>=1. >>> >>> For N=0 things are messy. If we are modeling this as state, and >>> notifications are about state changes, then the new diversion is >>> added >> >>> to the (previously empty) state and that triggers notifications to >>> all >> >>> current subscriptions. Then if you don't want to retain even this >>> much >> >>> state (because N=0) you immediately remove that version from the >> state. >>> But that is again a state change, so you end up with another >>> notification of that state change. >>> >>> True. Actually the notifications are for informing >>> the subscriber of the call diversions that happen. The notifications >>> are not for informing the subscriber of state changes in the notifier > >>> or the number of diversions that occurred. As I mentioned in the >>> abstract as well as 24.604, the main intent of CDIVN service is to >>> inform the subscribers of communication diversions that occur on >>> their >> >>> behalf in the network and this information will help them manage >>> their >> >>> rules better. >> >> I am not certain, but think we may still be talking past one another >> to some extent. >> >> The state can be considered just a formalism for defining the service >> clearly, regardless of whether it has intrinsic value to the CDIV >> service. But it *is* a formalism. So if it is introduced, then its >> behavior can't be ignored when inconvenient. Defining the state with >> N=0 leads to some undesired behavior. The simplest way around that is >> to insist that N be >=1. >> >> Ok in that case we can say that value of N >=1 and the >> notifier has always maintains history of last diversion at a minimu. >> It can maintain more than 1 too depending on the policy. >> >> If its important to you that no state be retained once a notification >> has been sent about the most recent diversion, then you will have to >> find some other way to specify the service, that still meets the >> expectations of 3265. I don't know if there is anything there that >> Adam would consider valid. We will have to get his opinion on that. >> >> In that case I am OK maintaining the hostory of >> diversions that occurred as part of state information and retaining >> that state even after the notification for that diversion is sent - so > >> that in case I do not get a confirmation, I would be able to re-send > the notification. >> Also maintaining state of diversions would help when the notifications > >> need to sent only at a particular time (if fikter criteria mentions > it). >> >> >> Thanks, >> Paul >> >>> But if we want to include the information related to > >>> how many diversions have happened till time (say from 12 AM ) till >>> the >> >>> time the notification is being sent, then as you say we can store the > >>> diversions. This would be useful when the subscriber specifies in the > >>> filter criteria to send notifications only during certain time like >>> between 5 and 6 PM and not whenever a diversion occurs. Then N is >>> grater than 1. >> >>> I presume you don't want that behavior. If you can live with N>=1 >>> then >> >>> we don't have the problem at all. If you need to support N=0 and >>> don't >> >>> want the extra notify, then we have to figure out if there is some >>> trick to how things are modeled to get the desired effect. I've >>> suggested something previously, but Adam didn't like it. >>> >>> This needs sorting out. >>> >>> Thanks, >>> Paul >> From dean.willis@softarmor.com Tue Mar 16 14:15:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C4F3A6A7D for ; Tue, 16 Mar 2010 14:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjaSIM8R1-TT for ; Tue, 16 Mar 2010 14:15:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 351393A6AD8 for ; Tue, 16 Mar 2010 14:15:49 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GLFtOC007280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 16:15:56 -0500 Message-Id: <6F61671C-4BCA-444C-80B2-A6ADCE78C5A6@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B9E5F47.2040604@nostrum.com> Content-Type: multipart/alternative; boundary=Apple-Mail-13-556657270 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 16:15:49 -0500 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:15:54 -0000 --Apple-Mail-13-556657270 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 15, 2010, at 11:24 AM, Adam Roach wrote: >> > Nailing down a route... for signaling? I'm a bit confused about how > that is going to preclude certain media types. > > Now, if we want to talk about media steering, that's a completely > different issue. I don't think SIP routing plays into that. Ah, but it does. Given the "evil peering architecture" (we really need a better dictionary for this) under discussion, the signaling route selected affects the media route, perhaps even limiting the media changes available once the call has been established. We're really talking about application-driven IP routing as an end-goal. The A-IMS model of using SIP to set up one's permission for using an HTTP proxy for web browsing is just the tip of this iceberg. Imagine, if you will, an IP network where each router takes into consideration not just the destination address of a packet but all sorts of other information (aka "metadata") including packet source, application, billing relationships, current contractual quotas, censorship rules, and all sorts of other stuff before it chooses the route by which it is going to send that packet towards its next hop. Making these routing decisions at SIP proxies is an interim step. It breaks the Internet up into myriad islands, each connected only by application gateways. IP routing as we know it is still used inside each island (although perhaps only on a transitional basis). But routing between islands is driven by more business-like (or even political) factors; simple route efficiency is inadequate for expressing the complex and shifting policy framework of the net. The logical outgrowth of the model is that every router become both a policy decision and policy enforcement point, provisioned with and taking into account the operational and political rules that govern utilization. Only a tiny fraction of these rules have anything to do with efficient delivery of a packet from Alice to Bob. Rather, they include things like seeing that the application is SOX compliant, making sure that the appropriate watchers-and-listeners have access to the content, diverting widget-orders from the intended recipient towards an ally of the router operator's and so on. Of course, efficient delivery and bandwidth management is still crucial, so perhaps something like RSVP will be used within "islands" to separate the policy decisions made by the application gateways from the policy enforcement of packet delivery, so perhaps it won't diverge totally from the Internet as we know it. Certainly this sort of system is the end-goal of very few people who are working on the technology today, but it is the (or at least "a") logical outgrowth of application-specific routing. It's what happens when we abandon the end-to-end principle and its related concepts of address-based application-independent routing, etc. Most people aren't trying to "change the Internet". People are just asking for ways to solve today's problems. Problems like "How do I tell my SIP nodes which SBC to use for calls to area code 212" or "Which NAT router should I use to reach Google most efficiently"? have as their basis an understanding that we've moved somewhat away from the Internet and towards something very different -- a route is not just a route, an application is not just an IP Address and a port number, and no node can be trusted to handle ALL of an important task, because everything eventually gets hacked. So, do we take this understanding of the difference between the common "real" network and the theoretical Internet and attempt to solve people's problems as they see them today, or do we step back and ask "What is the Internet way to solve this problem, why isn't it working, and what do we have to do to make it work right?" My guess is the former; it's easier, and there's more money to be made on it today. In the long run it destroys our world, but we just aren't geared towards understanding those kinds of things and would much rather just have today's problem fixed today. -- Dean --Apple-Mail-13-556657270 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 15, 2010, = at 11:24 AM, Adam Roach wrote:

Nailing down a route... for = signaling? I'm a bit confused about how that is going to preclude = certain media types.

Now, if we want to talk about media = steering, that's a completely different issue. I don't think SIP routing = plays into that.

Ah, but it = does.

Given the "evil peering architecture" (we = really need a better dictionary for this) under discussion, the = signaling route selected affects the media route, perhaps even limiting = the media changes available once the call has been established. We're = really talking about application-driven IP routing as an end-goal. The = A-IMS model of using SIP to set up one's permission for using an HTTP = proxy for web browsing is just the tip of this = iceberg.

Imagine, if you will, an IP network = where each router takes into consideration not just the destination = address of a packet but all sorts of other information (aka "metadata") = including packet source, application, billing relationships, current = contractual quotas, censorship rules, and all sorts of other stuff = before it chooses the route by which it is going to send that packet = towards its next hop.

Making these routing = decisions at SIP proxies is an interim step. It breaks the Internet up = into myriad islands, each connected only by application gateways. IP = routing as we know it is still used inside each island (although perhaps = only on a transitional basis). But routing between islands is driven by = more business-like (or even political) factors; simple route efficiency = is inadequate for expressing the complex and shifting policy framework = of the net.

The logical outgrowth of the model = is that every router become both a policy decision and policy = enforcement point, provisioned with and taking into account the = operational and political rules that govern utilization. Only a tiny = fraction of these rules have anything to do with efficient delivery of a = packet from Alice to Bob. Rather, they include things like seeing that = the application is SOX compliant, making sure that the appropriate = watchers-and-listeners have access to the content, diverting = widget-orders from the intended recipient towards an ally of the router = operator's and so on. Of course, efficient delivery and bandwidth = management is still crucial, so perhaps something like RSVP will be used = within "islands" to separate the policy decisions made by the = application gateways from the policy enforcement of packet delivery, so = perhaps it won't diverge totally from the Internet as we know = it.


Certainly this sort of = system is the end-goal of very few people who are working on the = technology today, but it is the (or at least "a") logical outgrowth of = application-specific routing. It's what happens when we abandon the = end-to-end principle and its related concepts of address-based = application-independent routing, = etc. 

Most people aren't trying to "change = the Internet".  People are just asking for ways to solve today's = problems. Problems like "How do I tell my SIP nodes which SBC to use for = calls to area code 212" or "Which NAT router should I use to reach = Google most efficiently"? have as their basis an understanding that = we've moved somewhat away from the Internet and towards something very = different -- a route is not just a route, an application is not just an = IP Address and a port number,  and no node can be trusted to handle = ALL of an important task, because everything eventually gets = hacked.

So, do we take this understanding of = the difference between the common "real" network and the theoretical = Internet and attempt to solve people's problems as they see them today, = or do we step back and ask "What is the Internet way to solve this = problem, why isn't it working, and what do we have to do to make it work = right?" My guess is the former; it's easier, and there's more money to = be made on it today. In the long run it destroys our world, but we just = aren't geared towards understanding those kinds of things and would much = rather just have today's problem fixed = today.

--
Dean
= --Apple-Mail-13-556657270-- From dean.willis@softarmor.com Tue Mar 16 14:21:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF7C3A69CC for ; Tue, 16 Mar 2010 14:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 7Qlne7o1FpfI for ; Tue, 16 Mar 2010 14:21:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A66453A696B for ; Tue, 16 Mar 2010 14:21:16 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GLLNS1007351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 16:21:24 -0500 Message-Id: <181C6F5E-60C4-4DC9-847E-639CAEFB79F1@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B9E6F60.1040703@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 16:21:17 -0500 References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:21:32 -0000 On Mar 15, 2010, at 12:33 PM, Adam Roach wrote: > ... > Which is to say that I don't think there is a solution that > satisfies both groups. The divergence from the fork between the > stagnant world and the vibrant world is great enough that there is > no common ground left for these kinds of issues. As odious as it is, > I'm afraid we're stuck with solving this problem twice. The real > challenge is ensuring that stagnant solutions don't do lasting > damage to the core protocols -- we need to make sure they don't > destroy the vibrant world with collateral damage. Beautifully said! I read it just after my similar but less-elegant rant, which presumes that the stagnant world is likely to be selected over the vibrant through the simple processes of expediency, apathy, corruption, greed, and fear. But then, I'm an optimist. -- Dean From D.Malas@cablelabs.com Tue Mar 16 14:59:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609013A67F7 for ; Tue, 16 Mar 2010 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 9XgWrV83Sgv3 for ; Tue, 16 Mar 2010 14:59:29 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7F14C3A67AC for ; Tue, 16 Mar 2010 14:59:29 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2GLxaaC027200; Tue, 16 Mar 2010 15:59:37 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 16 Mar 2010 15:59:37 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 16 Mar 2010 15:59:37 -0600 From: Daryl Malas To: "'Dean Willis'" , Adam Roach Date: Tue, 16 Mar 2010 15:59:37 -0600 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrFTreW7UTQXyTMSfO8iA7L750+xgAA+Ogg Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6774@srvxchg> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <181C6F5E-60C4-4DC9-847E-639CAEFB79F1@softarmor.com> In-Reply-To: <181C6F5E-60C4-4DC9-847E-639CAEFB79F1@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:59:30 -0000 I believe this issue was summarized well during the 73rd IETF meeting at th= e RAI open meeting, and captured in Jonathan's draft: http://tools.ietf.org= /html/draft-rosenberg-rai-modest-proposal-00 I believe we MUST solve this problem twice. Let's be realistic. Understan= ding the problem fully, defining the requirements, establishing the group a= nd hammering through the varying solutions will take 5 - 10 years to comple= te. The telecommunications industry will develop their own proprietary mec= hanisms for doing this, creating greater fragmentation and interoperability= issues; or the IETF can step up and as an interim solution say, since, you= are going to solve this, do it this way. At least in this case, we will k= now where the industry is at in their resolution rather than guessing at th= e plethora of "potentials" down the road. Regards, Daryl -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dean Willis Sent: Tuesday, March 16, 2010 3:21 PM To: Adam Roach Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-0= 0 On Mar 15, 2010, at 12:33 PM, Adam Roach wrote: > ... > Which is to say that I don't think there is a solution that satisfies=20 > both groups. The divergence from the fork between the stagnant world=20 > and the vibrant world is great enough that there is no common ground=20 > left for these kinds of issues. As odious as it is, I'm afraid we're=20 > stuck with solving this problem twice. The real challenge is ensuring=20 > that stagnant solutions don't do lasting damage to the core protocols=20 > -- we need to make sure they don't destroy the vibrant world with=20 > collateral damage. Beautifully said! I read it just after my similar but less-elegant rant, wh= ich presumes that the stagnant world is likely to be selected over the vibr= ant through the simple processes of expediency, apathy, corruption, greed, = and fear. But then, I'm an optimist. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Tue Mar 16 15:24:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2413E3A6A4D for ; Tue, 16 Mar 2010 15:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esGgSsJkzkri for ; Tue, 16 Mar 2010 15:24:51 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 843303A6A30 for ; Tue, 16 Mar 2010 15:24:50 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2GMOq0e076099 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 16 Mar 2010 17:24:56 -0500 (CDT) (envelope-from adam@nostrum.com) User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 16 Mar 2010 17:24:52 -0600 From: Adam Roach To: Daryl Malas , Dean Willis Message-ID: Thread-Topic: War of the Worlds (was Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFTreW7UTQXyTMSfO8iA7L750+xgAA+OggAAE4/Tg= In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6774@srvxchg> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 22:24:55 -0000 On 3/16/10 3:59 PM, "Daryl Malas" wrote: > I believe this issue was summarized well during the 73rd IETF meeting at the > RAI open meeting, and captured in Jonathan's draft: > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 I think Jonathan Rosenberg correctly identified that there was a problem here. And then, just like Jonathan Swift's original "Modest Proposal," he goes on to propose that the solution to our problem is best found in eating our own children. I disagree profoundly with characterizing Rosenberg's Modest Proposal as an appropriate summary of the issues, as it gets the analysis precisely wrong. It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just allowing collateral damage to the vibrant world for the sake of expediency in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant solutions. I'll admit that it's easier to see the stagnant world, since the telcos have quite a bit of money to throw around driving its deployment. But there are people in the vibrant world working on new services. Go back and re-read Greger's description of what he's seeing deployed. Check out the stuff that AG Projects (http://ag-projects.com/) has been working on, selling, and actually deploying. I don't recall whether you would have been at the meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring it to Anaheim. /a From dean.willis@softarmor.com Tue Mar 16 15:53:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1763A6BAD for ; Tue, 16 Mar 2010 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYotuPSTSqBY for ; Tue, 16 Mar 2010 15:53:33 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7D2953A6B54 for ; Tue, 16 Mar 2010 15:49:48 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GMnpBC008132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 17:49:53 -0500 Message-Id: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-14-562293434 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 17:49:45 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" , Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 22:53:37 -0000 --Apple-Mail-14-562293434 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 16, 2010, at 6:24 PM, Adam Roach wrote: > > I disagree profoundly with characterizing Rosenberg's Modest > Proposal as an > appropriate summary of the issues, as it gets the analysis precisely > wrong. > It proposes completely abandoning the vibrant world as a lost cause, > and > embracing the stagnant world as the only path forward. This isn't just > allowing collateral damage to the vibrant world for the sake of > expediency > in stagnant world solutions -- it's a suggestion that we nuke the > vibrant > world so it doesn't keep annoying people trying to develop stagnant > solutions. > I have long speculated that perhaps the best thing we can do is punt the "stagnant world" stuff to a different forum. I seem to recall many times suggesting that SIP should just be moved to the ITU so we can get on with building the Internet. I'd happily add ENUM to the same bucket. The problem is that we might wake up one day and realize that the Internet has been turned off, and all we have left is a stagnant backwater of telecommunications boundaries established by fat-and- happy politicos eager to preserve their own domains. The alternative, perhaps, is to embrace stagnation. Then add chlorine. -- Dean --Apple-Mail-14-562293434 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 16, 2010, = at 6:24 PM, Adam Roach wrote:

I disagree = profoundly with characterizing Rosenberg's Modest Proposal as = an
appropriate summary of the issues, as it gets the analysis = precisely wrong.
It proposes completely abandoning the vibrant world = as a lost cause, and
embracing the stagnant world as the only path = forward. This isn't just
allowing collateral damage to the vibrant = world for the sake of expediency
in stagnant world solutions -- it's = a suggestion that we nuke the vibrant
world so it doesn't keep = annoying people trying to develop = stagnant
solutions.


I = have long speculated that perhaps the best thing we can do is punt the = "stagnant world" stuff to a different forum. I seem to recall many times = suggesting that SIP should just be moved to the ITU so we can get on = with building the Internet. I'd happily add ENUM to the same = bucket.

The problem is that we might wake up = one day and realize that the Internet has been turned off, and all we = have left is a stagnant backwater of telecommunications boundaries = established by fat-and-happy politicos eager to preserve their own = domains.

The alternative, perhaps, is to = embrace stagnation. Then add = chlorine.

--
Dean
= --Apple-Mail-14-562293434-- From adam@nostrum.com Tue Mar 16 16:01:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5623A6824 for ; Tue, 16 Mar 2010 16:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of5WRwzsyQwi for ; Tue, 16 Mar 2010 16:01:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 81DCE3A6973 for ; Tue, 16 Mar 2010 16:01:01 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2GN15Lp078776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 18:01:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BA00DB1.7070702@nostrum.com> Date: Tue, 16 Mar 2010 18:01:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dean Willis References: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> In-Reply-To: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" , Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 23:01:06 -0000 On 3/16/10 5:49 PM, Dean Willis wrote: > I have long speculated that perhaps the best thing we can do is punt > the "stagnant world" stuff to a different forum. I seem to recall many > times suggesting that SIP should just be moved to the ITU so we can > get on with building the Internet. I'd happily add ENUM to the same > bucket. > > The problem is that we might wake up one day and realize that the > Internet has been turned off, and all we have left is a stagnant > backwater of telecommunications boundaries established by > fat-and-happy politicos eager to preserve their own domains. Surely you've seen what I'm trying to do here. I've spent a disproportionate amount of my IETF time making sure MARTINI doesn't do something profoundly stupid to SIP registration (which, as you point out, already has some broken baked into it). I'm actually agitating for acceptance and publication of Daryl's draft, since it's harmless and will hopefully prevent some other SDO from coming up with something that's actually dangerous. I think doing the stagnant world things in the IETF is still the right answer, as painful as it is to have to continually deal with solutions that willfully destroy the end-to-end principle. Because doing the work here at least allows us to steer things into directions that cause the least amount of harm. From that perspective, Daryl's draft is perfect[1]: it doesn't actually create any new protocol at all. > The alternative, perhaps, is to embrace stagnation. Then add chlorine. The problem, of course, is not the muck. It's the fact that it's not moving forward. Chlorine won't make it go. /a [1] Assuming we don't define new DNS record types From jon.peterson@neustar.biz Tue Mar 16 16:30:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3440D3A6824 for ; Tue, 16 Mar 2010 16:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HOi9rqZzDOA for ; Tue, 16 Mar 2010 16:30:04 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id F41DB3A68E4 for ; Tue, 16 Mar 2010 16:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=neustar.biz; s=neustarbiz; t=1268782208; x=1584132062; q=dns/txt; h=From:Date: Subject:Message-ID:Content-Language:Content-Type; bh=Movnqn7Df9m NFe+e4pGHKUNCNmUcbk0KmPkBIs5K8xk=; b=A2BHdFNqSbuFzkyqPHDPb8eoMDt gtTVMt/VzV1GHOTEpQB1gocyEnDfBzzsTMvUCx5ZAux8axokCmCZ9jtCqRw== Received: from ([10.31.13.31]) by chihiron2.nc.neustar.com with ESMTP id 5202415.23592112; Tue, 16 Mar 2010 19:30:07 -0400 Received: from STNTEXCHHT03.cis.neustar.com ([10.31.13.242]) by stntexch12.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 19:29:31 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 16 Mar 2010 19:29:30 -0400 From: "Peterson, Jon" To: Adam Roach , Daryl Malas , Dean Willis Date: Tue, 16 Mar 2010 19:29:30 -0400 Thread-Topic: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFTreW7UTQXyTMSfO8iA7L750+xgAA+OggAAE4/TgAAkGSNw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3QfRm5HcMFT/kYJU2llTUw== Content-Type: multipart/alternative; boundary="_000_C7C562683B15Cjonpetersonneustarbiz_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2010 23:29:31.0197 (UTC) FILETIME=[875C0ED0:01CAC560] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 23:30:11 -0000 --_000_C7C562683B15Cjonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not sure that dispatching malas-dispatch-sip-egress-route requires us t= o untwist this particular Gordian knot, nor to resurrect TRIP, nor to decl= are some kind of interplanetary Armageddon. I think Otmar Lendl has been right on the mark in this discussion. He point= s out that global directories like ENUM serve well as an LUF and poorly as = an LRF, to speak in the SPEERMINT idiom - I don't think this is an especial= ly controversial point. I read malas-dispatch-sip-egress as a document that= argues that knowing the results of the LUF doesn't necessarily help you to= find a next hop to route your call through. Again, I'd say not especially = controversial. malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxe= s that could contain a sort of joint LUF/LRF routing information. The only = conceptual problem I have with this approach is that the entity that typica= lly provisions the LUF doesn't know the local topology of the originating n= etwork well enough to say useful things about the LRF - that is indeed the = entire motivation for considering the LUF and LRF as separate lookups. The = draft sort of glosses this over with a lot of passive voice when describing= how the ENUM provisioning gets done. Is it done by the terminating side, o= r the originating side, or somehow both? In any event, from a DISPATCH perspective, I'd propose the problem seems to= lie comfortable within the parameters of SPEERMINT. Surely one of the SPEE= RMINT chairs must think this is a worthwhile effort... Jon Peterson NeuStar, Inc. On 3/16/10 3:24 PM, "Adam Roach" wrote: On 3/16/10 3:59 PM, "Daryl Malas" wrote: > I believe this issue was summarized well during the 73rd IETF meeting at = the > RAI open meeting, and captured in Jonathan's draft: > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 I think Jonathan Rosenberg correctly identified that there was a problem here. And then, just like Jonathan Swift's original "Modest Proposal," he goes on to propose that the solution to our problem is best found in eating our own children. I disagree profoundly with characterizing Rosenberg's Modest Proposal as an appropriate summary of the issues, as it gets the analysis precisely wrong. It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just allowing collateral damage to the vibrant world for the sake of expediency in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant solutions. I'll admit that it's easier to see the stagnant world, since the telcos hav= e quite a bit of money to throw around driving its deployment. But there are people in the vibrant world working on new services. Go back and re-read Greger's description of what he's seeing deployed. Check out the stuff that AG Projects (http://ag-projects.com/) has been working on, selling, and actually deploying. I don't recall whether you would have been at the meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring it to Anaheim. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C7C562683B15Cjonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-di= spatch-sip-egress-route-00)
I’m not sure that dispatching malas-dispatch-sip-egress-route require= s us to untwist this particular Gordian knot, nor to resurrect TRIP,  = nor to declare some kind of interplanetary Armageddon.

I think Otmar Lendl has been right on the mark in this discussion. He point= s out that global directories like ENUM serve well as an LUF and poorly as = an LRF, to speak in the SPEERMINT idiom - I don’t think this is an es= pecially controversial point. I read malas-dispatch-sip-egress as a documen= t that argues that knowing the results of the LUF doesn’t necessarily= help you to find a next hop to route your call through. Again, I’d s= ay not especially controversial.

malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxe= s that could contain a sort of joint LUF/LRF routing information. The only = conceptual problem I have with this approach is that the entity that typica= lly provisions the LUF doesn’t know the local topology of the origina= ting network well enough to say useful things about the LRF – that is= indeed the entire motivation for considering the LUF and LRF as separate l= ookups. The draft sort of glosses this over with a lot of passive voice whe= n describing how the ENUM provisioning gets done. Is it done by the termina= ting side, or the originating side, or somehow both?

In any event, from a DISPATCH perspective, I’d propose the problem se= ems to lie comfortable within the parameters of SPEERMINT. Surely one of th= e SPEERMINT chairs must think this is a worthwhile effort...

Jon Peterson
NeuStar, Inc.

On 3/16/10 3:24 PM, "Adam Roach" <adam@nostrum.com> wrote:

On 3/16/10 3:59 PM, "Daryl Malas"= <D.Malas@cablelabs.com> wrote:=

> I believe this issue was summarized well during the 73rd IETF meeting = at the
> RAI open meeting, and captured in Jonathan's draft:
> http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00

I think Jonathan Rosenberg correctly identified that there was a problem here. And then, just like Jonathan Swift's original "Modest Proposal,&= quot; he
goes on to propose that the solution to our problem is best found in eating=
our own children.

I disagree profoundly with characterizing Rosenberg's Modest Proposal as an=
appropriate summary of the issues, as it gets the analysis precisely wrong.=
It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency<= BR> in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant
solutions.

I'll admit that it's easier to see the stagnant world, since the telcos hav= e
quite a bit of money to throw around driving its deployment. But there are<= BR> people in the vibrant world working on new services. Go back and re-read Greger's description of what he's seeing deployed. Check out the stuff that=
AG Projects (http://ag-projects.com/) has been working on, selling, and
actually deploying. I don't recall whether you would have been at the
meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring=
it to Anaheim.

/a


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

--_000_C7C562683B15Cjonpetersonneustarbiz_-- From D.Malas@cablelabs.com Tue Mar 16 16:49:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA643A689A for ; Tue, 16 Mar 2010 16:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 mKz47MbY5Vnf for ; Tue, 16 Mar 2010 16:49:54 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B262B3A6818 for ; Tue, 16 Mar 2010 16:49:54 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2GNo3cu001981; Tue, 16 Mar 2010 17:50:03 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 16 Mar 2010 17:50:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 16 Mar 2010 17:50:03 -0600 From: Daryl Malas To: "'Adam Roach'" , Dean Willis Date: Tue, 16 Mar 2010 17:50:02 -0600 Thread-Topic: War of the Worlds (was Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFXJAXIlbU0S5OS0SMcPIppZgsSwABan1A Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6776@srvxchg> References: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> <4BA00DB1.7070702@nostrum.com> In-Reply-To: <4BA00DB1.7070702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 23:49:55 -0000 Adam and Dean, Perhaps you have misunderstood my comments. My comment is, simply, it is b= etter to know and control the "ugly" truths rather than simply sweep them u= nder the rug and blindly believe they do not exist. In this way, you know = what evil you will need to face, rather than being surprised by the unknown= proprietary solutions vendors have created based on monetary rather than t= echnology gains. Regards, Daryl -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, March 16, 2010 5:01 PM To: Dean Willis Cc: Daryl Malas; dispatch@ietf.org Subject: Re: War of the Worlds (was Re: [dispatch] I-D Action: draft-malas-= dispatch-sip-egress-route-00) On 3/16/10 5:49 PM, Dean Willis wrote: > I have long speculated that perhaps the best thing we can do is punt=20 > the "stagnant world" stuff to a different forum. I seem to recall many=20 > times suggesting that SIP should just be moved to the ITU so we can=20 > get on with building the Internet. I'd happily add ENUM to the same=20 > bucket. > > The problem is that we might wake up one day and realize that the=20 > Internet has been turned off, and all we have left is a stagnant=20 > backwater of telecommunications boundaries established by=20 > fat-and-happy politicos eager to preserve their own domains. Surely you've seen what I'm trying to do here. I've spent a disproportionat= e amount of my IETF time making sure MARTINI doesn't do something profoundl= y stupid to SIP registration (which, as you point out, already has some bro= ken baked into it). I'm actually agitating for acceptance and publication o= f Daryl's draft, since it's harmless and will hopefully prevent some other = SDO from coming up with something that's actually dangerous. I think doing the stagnant world things in the IETF is still the right answ= er, as painful as it is to have to continually deal with solutions that wil= lfully destroy the end-to-end principle. Because doing the work here at lea= st allows us to steer things into directions that cause the least amount of= harm. From that perspective, Daryl's draft is perfect[1]: it doesn't actually cr= eate any new protocol at all. > The alternative, perhaps, is to embrace stagnation. Then add chlorine. The problem, of course, is not the muck. It's the fact that it's not moving= forward. Chlorine won't make it go. /a [1] Assuming we don't define new DNS record types From D.Malas@cablelabs.com Tue Mar 16 17:05:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDB43A6AAD for ; Tue, 16 Mar 2010 17:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28BySuxJHvua for ; Tue, 16 Mar 2010 17:04:03 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 43E223A6818 for ; Tue, 16 Mar 2010 17:04:03 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2H04BNC002823; Tue, 16 Mar 2010 18:04:11 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 16 Mar 2010 18:04:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 16 Mar 2010 18:04:11 -0600 From: Daryl Malas To: "'Peterson, Jon'" , Adam Roach , Dean Willis Date: Tue, 16 Mar 2010 18:04:10 -0600 Thread-Topic: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFTreW7UTQXyTMSfO8iA7L750+xgAA+OggAAE4/TgAAkGSNwAAuP0w Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6777@srvxchg> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6777srvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 00:05:11 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6777srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, The provisioning of the "egress route" information is done by the originati= ng side. The terminating side provisions their ingress routing information= into an ENUM server, and the originating party evalutes the routes and ass= ociates egress routes to them. In this way, they append the information pr= ovided by the terminating side (provisioning side). If the terminating sid= e changes the route (domain's) associated with the TNs, which an egress rou= te was appended, then the egress route information is no longer valid and i= s removed. The originating side would have to append a new egress route. = Yes, this may seem inefficient, but there are two industry assumptions: 1) = routes do not change very often; 2) the efficiency gained by associating an= egress route is greater than the inefficiency in updating egress routes. This draft does not consider the "business" reasons for doing this, but sim= ply says...since, we know you are already doing this, then we should make t= he method consistent using (a) well defined mechanism(s) approved by a body= of experts. I do not think this goes against what Otmar was asserting in his Speermint = draft. I believe Otmar was trying to address a bigger picture issue, which= was not ignored in Speermint. On the contrary, we decided early to addres= s the short-term issue of basic telephony peering using SIP, and then move = on to the bigger more complex issue. It just took us longer to get there t= han we expected. We are still listening. Regards, Daryl ________________________________ From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, March 16, 2010 5:30 PM To: Adam Roach; Daryl Malas; Dean Willis Cc: dispatch@ietf.org Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-= dispatch-sip-egress-route-00) I'm not sure that dispatching malas-dispatch-sip-egress-route requires us t= o untwist this particular Gordian knot, nor to resurrect TRIP, nor to decl= are some kind of interplanetary Armageddon. I think Otmar Lendl has been right on the mark in this discussion. He point= s out that global directories like ENUM serve well as an LUF and poorly as = an LRF, to speak in the SPEERMINT idiom - I don't think this is an especial= ly controversial point. I read malas-dispatch-sip-egress as a document that= argues that knowing the results of the LUF doesn't necessarily help you to= find a next hop to route your call through. Again, I'd say not especially = controversial. malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxe= s that could contain a sort of joint LUF/LRF routing information. The only = conceptual problem I have with this approach is that the entity that typica= lly provisions the LUF doesn't know the local topology of the originating n= etwork well enough to say useful things about the LRF - that is indeed the = entire motivation for considering the LUF and LRF as separate lookups. The = draft sort of glosses this over with a lot of passive voice when describing= how the ENUM provisioning gets done. Is it done by the terminating side, o= r the originating side, or somehow both? In any event, from a DISPATCH perspective, I'd propose the problem seems to= lie comfortable within the parameters of SPEERMINT. Surely one of the SPEE= RMINT chairs must think this is a worthwhile effort... Jon Peterson NeuStar, Inc. On 3/16/10 3:24 PM, "Adam Roach" wrote: On 3/16/10 3:59 PM, "Daryl Malas" wrote: > I believe this issue was summarized well during the 73rd IETF meeting at = the > RAI open meeting, and captured in Jonathan's draft: > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 I think Jonathan Rosenberg correctly identified that there was a problem here. And then, just like Jonathan Swift's original "Modest Proposal," he goes on to propose that the solution to our problem is best found in eating our own children. I disagree profoundly with characterizing Rosenberg's Modest Proposal as an appropriate summary of the issues, as it gets the analysis precisely wrong. It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just allowing collateral damage to the vibrant world for the sake of expediency in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant solutions. I'll admit that it's easier to see the stagnant world, since the telcos hav= e quite a bit of money to throw around driving its deployment. But there are people in the vibrant world working on new services. Go back and re-read Greger's description of what he's seeing deployed. Check out the stuff that AG Projects (http://ag-projects.com/) has been working on, selling, and actually deploying. I don't recall whether you would have been at the meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring it to Anaheim. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6777srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] War of the Worlds (was Re: I-D Action: dr= aft-malas-dispatch-sip-egress-route-00)
Jon,
 
The provisioning of the "egress route" information is= done by=20 the originating side.  The terminating side provisions their ingress=20 routing information into an ENUM server, and the originating party evalutes= the=20 routes and associates egress routes to them.  In this way, they append= the=20 information provided by the terminating side (provisioning side).  If = the=20 terminating side changes the route (domain's) associated with the TNs, whic= h an=20 egress route was appended, then the egress route information is no longer v= alid=20 and is removed.  The originating side would have to append a new egres= s=20 route.  Yes, this may seem inefficient, but there are two industry=20 assumptions: 1) routes do not change very often; 2) the efficiency gained b= y=20 associating an egress route is greater than the inefficiency in updating eg= ress=20 routes.
 
This draft does not consider the "business" reasons f= or doing=20 this, but simply says...since, we know you are already doing this, then we= =20 should make the method consistent using (a) well defined mechanism(s)= =20 approved by a body of experts.
 
I do not think this goes against what Otmar was asser= ting in=20 his Speermint draft.  I believe Otmar was trying to address a bigger=20 picture issue, which was not ignored in Speermint.  On the contrary, w= e=20 decided early to address the short-term issue of basic telephony peering us= ing=20 SIP, and then move on to the bigger more complex issue.  It just took = us=20 longer to get there than we expected.  We are still=20 listening.
 
Regards,
 <= /DIV>
Daryl 

From: Peterson, Jon=20 [mailto:jon.peterson@neustar.biz]
Sent: Tuesday, March 16, 2010 = 5:30=20 PM
To: Adam Roach; Daryl Malas; Dean Willis
Cc:=20 dispatch@ietf.org
Subject: Re: [dispatch] War of the Worlds (was = Re:=20 I-D Action: draft-malas-dispatch-sip-egress-route-00)


I’m not sure that dispatching=20 malas-dispatch-sip-egress-route requires us to untwist this particular Gord= ian=20 knot, nor to resurrect TRIP,  nor to declare some kind of interplaneta= ry=20 Armageddon.

I think Otmar Lendl has been right on the mark in this=20 discussion. He points out that global directories like ENUM serve well as a= n LUF=20 and poorly as an LRF, to speak in the SPEERMINT idiom - I don’t think= this is an=20 especially controversial point. I read malas-dispatch-sip-egress as a docum= ent=20 that argues that knowing the results of the LUF doesn’t necessarily h= elp you to=20 find a next hop to route your call through. Again, I’d say not especi= ally=20 controversial.

malas-dispatch-sip-egress-route then goes on to speci= fy a=20 few NAPTR syntaxes that could contain a sort of joint LUF/LRF routing=20 information. The only conceptual problem I have with this approach is that = the=20 entity that typically provisions the LUF doesn’t know the local topol= ogy of the=20 originating network well enough to say useful things about the LRF – = that is=20 indeed the entire motivation for considering the LUF and LRF as separate=20 lookups. The draft sort of glosses this over with a lot of passive voice wh= en=20 describing how the ENUM provisioning gets done. Is it done by the terminati= ng=20 side, or the originating side, or somehow both?

In any event, from a= =20 DISPATCH perspective, I’d propose the problem seems to lie comfortabl= e within=20 the parameters of SPEERMINT. Surely one of the SPEERMINT chairs must think = this=20 is a worthwhile effort...

Jon Peterson
NeuStar, Inc.

On 3/= 16/10=20 3:24 PM, "Adam Roach" <adam@nostrum.com= >=20 wrote:
On 3/16/10 3:59 PM, "Daryl Malas" <D.Malas@cablelabs.com> wrote:
>=20 I believe this issue was summarized well during the 73rd IETF meeting at= =20 the
> RAI open meeting, and captured in Jonathan's draft:
> <= A=20 href=3D"http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00= ">http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00
=
I=20 think Jonathan Rosenberg correctly identified that there was a=20 problem
here. And then, just like Jonathan Swift's original "Modest=20 Proposal," he
goes on to propose that the solution to our problem is b= est=20 found in eating
our own children.

I disagree profoundly with=20 characterizing Rosenberg's Modest Proposal as an
appropriate summary o= f the=20 issues, as it gets the analysis precisely wrong.
It proposes completel= y=20 abandoning the vibrant world as a lost cause, and
embracing the stagna= nt=20 world as the only path forward. This isn't just
allowing collateral da= mage=20 to the vibrant world for the sake of expediency
in stagnant world solu= tions=20 -- it's a suggestion that we nuke the vibrant
world so it doesn't keep= =20 annoying people trying to develop stagnant
solutions.

I'll admi= t=20 that it's easier to see the stagnant world, since the telcos have
quit= e a=20 bit of money to throw around driving its deployment. But there are
peo= ple=20 in the vibrant world working on new services. Go back and re-read
Greg= er's=20 description of what he's seeing deployed. Check out the stuff that
AG= =20 Projects (http://ag-projects.com/= ) has=20 been working on, selling, and
actually deploying. I don't recall wheth= er=20 you would have been at the
meeting where I wore a t-shirt showing some= =20 novel SIP devices -- I'll bring
it to=20 Anaheim.

/a


___________________________________________= ____
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

= --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6777srvxchg_-- From adam@nostrum.com Tue Mar 16 17:47:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39DD3A6AAA for ; Tue, 16 Mar 2010 17:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOn9DWKOQb2t for ; Tue, 16 Mar 2010 17:47:21 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 456F63A6A14 for ; Tue, 16 Mar 2010 17:47:19 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2H0lNxv086418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 19:47:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BA02699.8080805@nostrum.com> Date: Tue, 16 Mar 2010 19:47:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Daryl Malas References: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> <4BA00DB1.7070702@nostrum.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F6776@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6776@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 00:47:21 -0000 On 3/16/10 18:50, Mar 16, Daryl Malas wrote: > Adam and Dean, > > Perhaps you have misunderstood my comments. My comment is, simply, it is better to know and control the "ugly" truths rather than simply sweep them under the rug and blindly believe they do not exist. In this way, you know what evil you will need to face, rather than being surprised by the unknown proprietary solutions vendors have created based on monetary rather than technology gains. > That's exactly what I say below. /a > Regards, > > Daryl > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, March 16, 2010 5:01 PM > To: Dean Willis > Cc: Daryl Malas; dispatch@ietf.org > Subject: Re: War of the Worlds (was Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00) > > On 3/16/10 5:49 PM, Dean Willis wrote: > >> I have long speculated that perhaps the best thing we can do is punt >> the "stagnant world" stuff to a different forum. I seem to recall many >> times suggesting that SIP should just be moved to the ITU so we can >> get on with building the Internet. I'd happily add ENUM to the same >> bucket. >> >> The problem is that we might wake up one day and realize that the >> Internet has been turned off, and all we have left is a stagnant >> backwater of telecommunications boundaries established by >> fat-and-happy politicos eager to preserve their own domains. >> > Surely you've seen what I'm trying to do here. I've spent a disproportionate amount of my IETF time making sure MARTINI doesn't do something profoundly stupid to SIP registration (which, as you point out, already has some broken baked into it). I'm actually agitating for acceptance and publication of Daryl's draft, since it's harmless and will hopefully prevent some other SDO from coming up with something that's actually dangerous. > > I think doing the stagnant world things in the IETF is still the right answer, as painful as it is to have to continually deal with solutions that willfully destroy the end-to-end principle. Because doing the work here at least allows us to steer things into directions that cause the least amount of harm. > > From that perspective, Daryl's draft is perfect[1]: it doesn't actually create any new protocol at all. > > >> The alternative, perhaps, is to embrace stagnation. Then add chlorine. >> > The problem, of course, is not the muck. It's the fact that it's not moving forward. Chlorine won't make it go. > > /a > > > [1] Assuming we don't define new DNS record types > From henry.sinnreich@gmail.com Tue Mar 16 21:19:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FD83A686E for ; Tue, 16 Mar 2010 21:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+Dmd1bgTLM9 for ; Tue, 16 Mar 2010 21:19:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1B3663A687E for ; Tue, 16 Mar 2010 21:19:38 -0700 (PDT) Received: by gyh4 with SMTP id 4so309320gyh.31 for ; Tue, 16 Mar 2010 21:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=nm4lzvlbGrsi6992iiujo8TVyMaY7Ts+o5nCiE08+bs=; b=gPPtmCzseRE8fEdd8UM+ZkKQvCdpdT8IUIZ/D2s2yMfYOt/ATKxF9PAEPFH8e3EP0I 9+AiAjxLK4RtKw1E6YsdKqINTbJT4mk4kH+7I+r2upE4a04TwWrYhG/1W/kAtI+SnBWu qjUG/pFE0akgS3IxwLZJT1yy3P6Dvd6FC3Qsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=Idxg8dbLWGy7fgcteVjRQEWc+RINIGvzWIpEVQTvjPOmzzoj8uFYgN4CBVMjKrLwE1 f2MfbLsz67TpvQRTUAJHv4hlkgd4mnt7lCKvupSEzaOH+P8Po/OP+saQ/uiPKkvhaY8H Ow/YN4RY7pbTZ7nP3DA/93tc30JmQdPcSPLE0= Received: by 10.101.187.3 with SMTP id o3mr411196anp.49.1268799571777; Tue, 16 Mar 2010 21:19:31 -0700 (PDT) Received: from [192.168.0.34] (cpe-76-184-253-10.tx.res.rr.com [76.184.253.10]) by mx.google.com with ESMTPS id 5sm2245188ywd.59.2010.03.16.21.19.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 21:19:30 -0700 (PDT) User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 16 Mar 2010 23:19:27 -0500 From: Henry Sinnreich To: Dean Willis , Adam Roach Message-ID: Thread-Topic: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFiQgQw1kkq8FSS0OSa8heIJGjwA== In-Reply-To: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3351626370_950792" Cc: "dispatch@ietf.org" , Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 04:19:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351626370_950792 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This really sums up the enigma why the IETF should do work that contradicts every principle of the Internet architecture and its engineering. It may be useful to remember the _solid_ track record of the "stagnant world" * OSI * X4.00 mail * IN * AIN * ISDN * SONET/SDH * ATM * BISDN * H.323 * current re-incarnations such as PSTN/SIP and other (avoiding flames here)... How many companies have disappeared building this stuff? Layoffs. Capital destruction. The other enigma is the tolerance to associate the IETF with the reincarnations of these failures. >I have long speculated that perhaps the best thing we can do is punt the "stagnant world" stuff to a different forum. >I seem to recall many times suggesting that SIP should just be moved to the ITU so we can get on with building the Internet. >I'd happily add ENUM to the same bucket. Well said. Thanks, Henry On 3/16/10 5:49 PM, "Dean Willis" wrote: > > On Mar 16, 2010, at 6:24 PM, Adam Roach wrote: >> >> I disagree profoundly with characterizing Rosenberg's Modest Proposal as an >> appropriate summary of the issues, as it gets the analysis precisely wrong. >> It proposes completely abandoning the vibrant world as a lost cause, and >> embracing the stagnant world as the only path forward. This isn't just >> allowing collateral damage to the vibrant world for the sake of expediency >> in stagnant world solutions -- it's a suggestion that we nuke the vibrant >> world so it doesn't keep annoying people trying to develop stagnant >> solutions. >> > > I have long speculated that perhaps the best thing we can do is punt the > "stagnant world" stuff to a different forum. I seem to recall many times > suggesting that SIP should just be moved to the ITU so we can get on with > building the Internet. I'd happily add ENUM to the same bucket. > > The problem is that we might wake up one day and realize that the Internet has > been turned off, and all we have left is a stagnant backwater of > telecommunications boundaries established by fat-and-happy politicos eager to > preserve their own domains. > > The alternative, perhaps, is to embrace stagnation. Then add chlorine. > > -- > Dean > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --B_3351626370_950792 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-di= spatch-sip-egress-route-00) This really sums up the enigma why the IETF should do work that contradict= s every principle of the Internet architecture and its engineering.

It may be useful to remember the  _solid_   track record of = the  "stagnant world"
  • OSI
  • X4.00 mail
  • IN
  • AIN
  • ISDN
  • SONET/SDH
  • ATM
  • BISDN
  • H.323
  • current re-incarnations such as PSTN/SIP and other (avoi= ding flames here)...
How many companies have disappeared building this stuff= ? Layoffs. Capital destruction.

The other enigma is the tolerance to associate the IETF with the reincarnat= ions of these failures.

>I have long speculated that perhaps the best thing we can do is punt th= e "stagnant world" stuff to a different forum.
>I seem to recall many times suggesting that SIP should just be moved to= the ITU so we can get on with building the Internet.
>I'd happily add ENUM to the same bucket.

Well said.

Thanks, Henry


On 3/16/10 5:49 PM, "Dean Willis" <dean.willis@softarmor.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
On Mar 16, 2010, at 6:24 PM, Adam Roach wrote:
<= SPAN STYLE=3D'font-size:13pt'>
I disagree profoundly with characterizing Rosenberg's Modest Proposal as an=
appropriate summary of the issues, as it gets the analysis precisely wrong.=
It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency<= BR> in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant
solutions.

=
I have long speculated that perhaps the best thing we can do is punt the &q= uot;stagnant world" stuff to a different forum. I seem to recall many t= imes suggesting that SIP should just be moved to the ITU so we can get on wi= th building the Internet. I'd happily add ENUM to the same bucket.

The problem is that we might wake up one day and realize that the Internet = has been turned off, and all we have left is a stagnant backwater of telecom= munications boundaries established by fat-and-happy politicos eager to prese= rve their own domains.

The alternative, perhaps, is to embrace stagnation. Then add chlorine.

--
Dean

__________________________= _____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch
--B_3351626370_950792-- From dean.willis@softarmor.com Tue Mar 16 22:34:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291AA3A6806 for ; Tue, 16 Mar 2010 22:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 7ETA8tiGWNcx for ; Tue, 16 Mar 2010 22:34:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 274913A67B5 for ; Tue, 16 Mar 2010 22:34:02 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2H5Y7iv010616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Mar 2010 00:34:09 -0500 Message-Id: <9F12997C-4956-4ADA-9459-94B6C2723B0C@softarmor.com> From: Dean Willis To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6776@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Mar 2010 00:34:02 -0500 References: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> <4BA00DB1.7070702@nostrum.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F6776@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 05:34:03 -0000 On Mar 16, 2010, at 6:50 PM, Daryl Malas wrote: > Adam and Dean, > > Perhaps you have misunderstood my comments. My comment is, simply, > it is better to know and control the "ugly" truths rather than > simply sweep them under the rug and blindly believe they do not > exist. In this way, you know what evil you will need to face, > rather than being surprised by the unknown proprietary solutions > vendors have created based on monetary rather than technology gains. You are right. It is indeed better to know about the ugly than to ignore it. I have perhaps forecast its development all to clearly and proven unable to do anything about it, which tends to make one crotchety at best. And I'd rather have a real routing protocol to handle the "LRF evil" within an administrative domain than hack the DNS to convey the same information. It is, I think, the lesser of two evils. -- Dean From dean.willis@softarmor.com Tue Mar 16 22:37:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B093A67B5 for ; Tue, 16 Mar 2010 22:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxxcsO6gdF3M for ; Tue, 16 Mar 2010 22:37:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C04E93A6914 for ; Tue, 16 Mar 2010 22:37:19 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2H5bOjg010645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Mar 2010 00:37:26 -0500 Message-Id: <39982AB3-DBC1-4A35-8B8E-7427A3032679@softarmor.com> From: Dean Willis To: Henry Sinnreich In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-21-586746706 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Mar 2010 00:37:19 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org" , Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 05:37:21 -0000 --Apple-Mail-21-586746706 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 16, 2010, at 11:19 PM, Henry Sinnreich wrote: > This really sums up the enigma why the IETF should do work that > contradicts every principle of the Internet architecture and its > engineering. > > It may be useful to remember the _solid_ track record of the > "stagnant world" Not to mention that I still can't reliably make a SIP call. Bernie and I had to hack on things together for thirty minutes before we could make a call work to talk about E2MD earlier this week. But at least we didn't break down and use Skype... until today, when we needed to talk in a hurry. -- Dean --Apple-Mail-21-586746706 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
On Mar 16, 2010, at 11:19 PM, Henry Sinnreich wrote:

This really sums up the enigma why the IETF should do work that contradicts every principle of the Internet architecture and its engineering.

It may be useful to remember the  _solid_   track record of the  "stagnant world"

Not to mention that I still can't reliably make a SIP call. Bernie and I had to hack on things together for thirty minutes before we could make a call work to talk about E2MD earlier this week. But at least we didn't break down and use Skype... until today, when we needed to talk in a hurry.

--
Dean
--Apple-Mail-21-586746706-- From Milan.Patel@InterDigital.com Wed Mar 17 02:04:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338F63A6820 for ; Wed, 17 Mar 2010 02:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.473 X-Spam-Level: X-Spam-Status: No, score=0.473 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 4Fn67c+UIzgn for ; Wed, 17 Mar 2010 02:04:58 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id BC4973A67E3 for ; Wed, 17 Mar 2010 02:04:57 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 05:05:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2010 05:04:43 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> In-Reply-To: <4B97B3CC.4070400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: AcrAYkveNkY20HbnT8mLPtLmob//NAFTXtUQ From: "Patel, Milan" To: "Paul Kyzivat" , "Jon Peterson" X-OriginalArrivalTime: 17 Mar 2010 09:05:06.0902 (UTC) FILETIME=[F03E6F60:01CAC5B0] Cc: DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:04:59 -0000 Hi Paul, Thanks for pointing out the NIT. I will address that in the next revision.=20 Your other comments seem to be specific to the semantics of certain OLI values. That is out of scope of both the internet draft and IETF, since they were defined elsewhere (ITU-T).=20 After receiving Jon's comments, I had extensive discussions with operators and vendors about the use of CPC and OLI currently in the field. The current version of the draft reflects such usage and the syntax of the CPC and OLI as defined in version -02 of the draft has been scrutinized by operators and vendors attending 3GPP and has receiving unanimous support.=20 The draft defines the CPC and OLI as tel URI parameters. For usage with SIP URIs, further syntax would need to be defined extending the SIP URI parameter as defined in RFC 3261. Currently, we see no requirements to include CPC or OLI for SIP URIs. If this is needed in the future, a further Internet-Draft can be proposed.=20 Regards, Milan -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, March 10, 2010 2:59 PM To: Jon Peterson Cc: Milan Patel; DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 I just got around to reading this draft. I have all of the concerns that Jon does, plus some others: Many of these properties are in fact properties of the *call*, not=20 properties of the *caller*. That is especially true of the oli values: - some are a function of the called number rather than the caller: * 30 Intercept (blank) - for calls to unassigned directory number (DN) * 31 Intercept (trouble) - for calls to directory numbers (DN) that have been manually placed in trouble-busy state by Telco personnel * 32 Intercept (regular) - for calls to recently changed or disconnected numbers - the value can be assigned mid-call, as a result of call handling: * 34 Telco Operator Handled Call - after the Telco Operator Services System has handled a call for an IC, it may change the standard ANI digits to "34", before outpulsing the sequence to the IC, when the Telco performs all call handling functions, e.g., billing. The code tells the IC that the BOC has performed billing on the call and the IC only has to complete the call. * 52 Outward Wide Area Telecommunications Service (OUTWATS) - this service allows customers to make calls to a certain zone(s) or band(s) on a direct dialed basis for a flat monthly charge or for a charge based on accumulated usage. OUTWATS lines can dial station-to-station calls directly to points within the selected band(s) or zone(s). The LEC performs a screening function to determine the correct charging and routing for OUTWATS calls based on the customer's class of service and the service area of the call party. When these calls are routed to the interexchange carrier via a combined WATS-POTS trunk group, it is necessary to identify the WATS calls with the ANI code "52". - (this is not an exhaustive list.) Putting the value in From is problematic if it is a function of=20 something other than the caller. Its even more problematic if it can=20 change mid-call, since changing it breaks Identity. Even when the information is a property of the caller, it seems likely=20 that it will often be added by something other than the UAC, since the=20 UAC is unlikely to be trusted to provide it. If this is information that is a property of the call rather than=20 caller, and it can change along the signaling path, then IMO it belongs=20 in some other header, in a field that may be changed along the path. Also a NIT: The "oli" parameter with value 29 indicates that the device that the call is initiated from is located within a prison. An "oli" with value "prison" is equally valid. The ABNF doesn't permit a value of "prison" for the oli parameter - only digits. Jon Peterson wrote: >=20 > In evaluating proposals to add capabilities to SIP via a tel URI, the=20 > first question we ask is, "Would this be useful in SIP requests that do=20 > NOT use telephone numbers?" If the answer is "yes," then probably the=20 > capability should be added to SIP in a way that works with and without > the tel URI. (The draft is very slightly unclear about whether or not > you can include this parameter in SIP URIs that do not contain embedded=20 > tel URIs but do contain non-tel-URI representations of telephone numbers=20 > - but I'm speaking here to the overall intention to couple the use of=20 > OLI/CPC information to telephone numbers exclusively.) >=20 > While the draft focuses on the use case where SIP is gatewaying to ISUP,=20 > and thus where telephone numbers are likely to be used, I would be=20 > hesitant to rule out uses that do not involve telephone numbers -=20 > especially when the motivating use case given is REGISTER in an=20 > emergency context. Encapsulating the opaque numeric values of OLI into a=20 > SIP parameter also more or less restricts the use of this to entities=20 > that understand ISUP. This begs the obvious question: should there be a=20 > way in SIP (outside of gatewaying) to express these same concepts?=20 > Since you already translate the CPC values into human-readable=20 > equivalents ("operator", "payphone", "test"), is there some reason why > OLI can't receive the same treatment? The only example of the semantics=20 > of OLI that you give ("oli=3D29" meaning "prison") indeed seems it = could > admit of that translation. If there is some good reason why CPC should > be translated and OLI should be encapsulated, the draft should=20 > explicitly motivate it. >=20 > By the by, since the Acks mention that I submitted a version of this=20 > proposal prior to Rohan's, just as an historical aside I in fact split > that out from the original draft-ietf-sip-privacy-04 by Flemming and=20 > Bill Marshall, which for some reason had it tacked into an appendix. The=20 > parameter proposed in that document (which can still be found via=20 > Google), the Nature of Party ("np") parameter, maps to a set of=20 > human-readable literals like "ordinary", "police", "payphone",=20 > "emergency", and so on. The document then proposes a mapping to the ANI=20 > II digits; one could just as easily be provided for OLI or CPC in the=20 > ISUP variants of interest. The example given in that appendix shows this=20 > being used in a URI that doesn't contain a telephone number. In any=20 > event, if you want to have a pedigree of the idea in your Acks, you=20 > shouldn't leave out that document. >=20 > Jon Peterson > NeuStar, Inc. >=20 > Milan Patel wrote: >> Hi, >> >> A new version of the Internet Draft for the Calling Party's Category and >> Originating Line Identity URI Parameters is now available.=20 >> http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt >> >> This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 >> >> Best regards, >> Milan >> >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 08=20 >> October 2009 18:40 >> To: Patel, Milan (MOP:EP10) >> Cc: r.jesske@telekom.de; mdolly@att.com >> Subject: New Version Notification for >> draft-patel-dispatch-cpc-oli-parameter-00 >> >> A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt has >> been successfuly submitted by Milan Patel and posted to the IETF >> repository. >> >> Filename: draft-patel-dispatch-cpc-oli-parameter >> Revision: 00 >> Title: Uniform Resource Identifier (URI) Parameters for >> indicating the Calling Party's Catagory and Originating Line Identity >> Creation_date: 2009-10-08 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document defines two new URI parameters to describe the calling >> party's category and toll class of service originating line >> information which are parameters also used in SS7 ISUP and other >> telephony signalling protocols. The intended use of these URI >> parameters is for the "tel" URI or equivalent SIP URI representation. >> =20 >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> =20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Wed Mar 17 07:58:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102F13A6A62 for ; Wed, 17 Mar 2010 07:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.482 X-Spam-Level: X-Spam-Status: No, score=-8.482 tagged_above=-999 required=5 tests=[AWL=-1.613, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as69+qxwJNwk for ; Wed, 17 Mar 2010 07:58:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 80B733A6C50 for ; Wed, 17 Mar 2010 07:51:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOJoEtAZnwN/2dsb2JhbACbBHOhPphigkkBBgSCIgSOPkM X-IronPort-AV: E=Sophos;i="4.49,657,1262563200"; d="scan'208";a="93575797" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Mar 2010 14:51:42 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2HEpgrW018892; Wed, 17 Mar 2010 14:51:42 GMT Message-ID: <4BA0EC7D.6060900@cisco.com> Date: Wed, 17 Mar 2010 10:51:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Patel, Milan" References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 14:58:12 -0000 Patel, Milan wrote: > Hi Paul, > > Thanks for pointing out the NIT. I will address that in the next > revision. > > Your other comments seem to be specific to the semantics of certain OLI > values. That is out of scope of both the internet draft and IETF, since > they were defined elsewhere (ITU-T). You miss my point. I am not suggesting there is anything wrong with the semantics of the values. My point is that values with these semantics do not belong in a URI that is being used to describe the originator of a call, or in the URI used to describe the destination of the call. They are properties of the *call*. So, these really don't belong in a URI at all. They belong in some other header or headers. > After receiving Jon's comments, I had extensive discussions with > operators and vendors about the use of CPC and OLI currently in the > field. The current version of the draft reflects such usage and the > syntax of the CPC and OLI as defined in version -02 of the draft has > been scrutinized by operators and vendors attending 3GPP and has > receiving unanimous support. > > The draft defines the CPC and OLI as tel URI parameters. For usage with > SIP URIs, further syntax would need to be defined extending the SIP URI > parameter as defined in RFC 3261. Currently, we see no requirements to > include CPC or OLI for SIP URIs. If this is needed in the future, a > further Internet-Draft can be proposed. For those that truly describe properties of a URI (if there are any of those), you may be right. For those that describe properties of a call, if they were carried as part of the call rather than as properties of the URI, then it wouldn't matter if the URI is sip or tel. But in reality, even the properties that describe the caller aren't properly properties of the caller's URI. For instance, in principle the same originating "number" might be used by one phone in a prison and another in a police station. ISTM that piggybacking these on the TEL uri is simply a convenient "ploy", because both phone numbers and these properties are managed by the ITU. Thanks, Paul > Regards, > Milan > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, March 10, 2010 2:59 PM > To: Jon Peterson > Cc: Milan Patel; DISPATCH > Subject: Re: [dispatch] FW: New VersionNotification for > draft-patel-dispatch-cpc-oli-parameter-00 > > I just got around to reading this draft. > I have all of the concerns that Jon does, plus some others: > > Many of these properties are in fact properties of the *call*, not > properties of the *caller*. That is especially true of the oli values: > > - some are a function of the called number rather than the caller: > * 30 Intercept (blank) - for calls to unassigned directory number > (DN) > * 31 Intercept (trouble) - for calls to directory numbers (DN) that > have been manually placed in trouble-busy state by Telco > personnel > * 32 Intercept (regular) - for calls to recently changed or > disconnected numbers > > - the value can be assigned mid-call, as a result of call handling: > * 34 Telco Operator Handled Call - after the Telco Operator Services > System has handled a call for an IC, it may change the standard > ANI digits to "34", before outpulsing the sequence to the IC, > when the Telco performs all call handling functions, e.g., > billing. The code tells the IC that the BOC has performed > billing > on the call and the IC only has to complete the call. > * 52 Outward Wide Area Telecommunications Service (OUTWATS) - this > service allows customers to make calls to a certain zone(s) or > band(s) on a direct dialed basis for a flat monthly charge or > for > a charge based on accumulated usage. OUTWATS lines can dial > station-to-station calls directly to points within the selected > band(s) or zone(s). The LEC performs a screening function to > determine the correct charging and routing for OUTWATS calls > based on the customer's class of service and the service area of > the call party. When these calls are routed to the interexchange > carrier via a combined WATS-POTS trunk group, it is necessary to > identify the WATS calls with the ANI code "52". > > - (this is not an exhaustive list.) > > Putting the value in From is problematic if it is a function of > something other than the caller. Its even more problematic if it can > change mid-call, since changing it breaks Identity. > > Even when the information is a property of the caller, it seems likely > that it will often be added by something other than the UAC, since the > UAC is unlikely to be trusted to provide it. > > If this is information that is a property of the call rather than > caller, and it can change along the signaling path, then IMO it belongs > in some other header, in a field that may be changed along the path. > > Also a NIT: > > The "oli" parameter with value 29 indicates that the device that the > call is initiated from is located within a prison. An "oli" with > value "prison" is equally valid. > > The ABNF doesn't permit a value of "prison" for the oli parameter - only > > digits. > > > Jon Peterson wrote: >> In evaluating proposals to add capabilities to SIP via a tel URI, the >> first question we ask is, "Would this be useful in SIP requests that > do >> NOT use telephone numbers?" If the answer is "yes," then probably the >> capability should be added to SIP in a way that works with and without > >> the tel URI. (The draft is very slightly unclear about whether or not > >> you can include this parameter in SIP URIs that do not contain > embedded >> tel URIs but do contain non-tel-URI representations of telephone > numbers >> - but I'm speaking here to the overall intention to couple the use of >> OLI/CPC information to telephone numbers exclusively.) >> >> While the draft focuses on the use case where SIP is gatewaying to > ISUP, >> and thus where telephone numbers are likely to be used, I would be >> hesitant to rule out uses that do not involve telephone numbers - >> especially when the motivating use case given is REGISTER in an >> emergency context. Encapsulating the opaque numeric values of OLI into > a >> SIP parameter also more or less restricts the use of this to entities >> that understand ISUP. This begs the obvious question: should there be > a >> way in SIP (outside of gatewaying) to express these same concepts? >> Since you already translate the CPC values into human-readable >> equivalents ("operator", "payphone", "test"), is there some reason why > >> OLI can't receive the same treatment? The only example of the > semantics >> of OLI that you give ("oli=29" meaning "prison") indeed seems it could > >> admit of that translation. If there is some good reason why CPC should > >> be translated and OLI should be encapsulated, the draft should >> explicitly motivate it. >> >> By the by, since the Acks mention that I submitted a version of this >> proposal prior to Rohan's, just as an historical aside I in fact split > >> that out from the original draft-ietf-sip-privacy-04 by Flemming and >> Bill Marshall, which for some reason had it tacked into an appendix. > The >> parameter proposed in that document (which can still be found via >> Google), the Nature of Party ("np") parameter, maps to a set of >> human-readable literals like "ordinary", "police", "payphone", >> "emergency", and so on. The document then proposes a mapping to the > ANI >> II digits; one could just as easily be provided for OLI or CPC in the >> ISUP variants of interest. The example given in that appendix shows > this >> being used in a URI that doesn't contain a telephone number. In any >> event, if you want to have a pedigree of the idea in your Acks, you >> shouldn't leave out that document. >> >> Jon Peterson >> NeuStar, Inc. >> >> Milan Patel wrote: >>> Hi, >>> >>> A new version of the Internet Draft for the Calling Party's Category > and >>> Originating Line Identity URI Parameters is now available. >>> http://www.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-00.txt >>> >>> This is based on Rohan Mahy's draft-mahy-iptel-cpc-06 >>> >>> Best regards, >>> Milan >>> >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: > 08 >>> October 2009 18:40 >>> To: Patel, Milan (MOP:EP10) >>> Cc: r.jesske@telekom.de; mdolly@att.com >>> Subject: New Version Notification for >>> draft-patel-dispatch-cpc-oli-parameter-00 >>> >>> A new version of I-D, draft-patel-dispatch-cpc-oli-parameter-00.txt > has >>> been successfuly submitted by Milan Patel and posted to the IETF >>> repository. >>> >>> Filename: draft-patel-dispatch-cpc-oli-parameter >>> Revision: 00 >>> Title: Uniform Resource Identifier (URI) Parameters for >>> indicating the Calling Party's Catagory and Originating Line Identity >>> Creation_date: 2009-10-08 >>> WG ID: Independent Submission >>> Number_of_pages: 10 >>> >>> Abstract: >>> This document defines two new URI parameters to describe the calling >>> party's category and toll class of service originating line >>> information which are parameters also used in SS7 ISUP and other >>> telephony signalling protocols. The intended use of these URI >>> parameters is for the "tel" URI or equivalent SIP URI representation. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gregert@teigre.com Wed Mar 17 12:57:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DA83A67CC for ; Wed, 17 Mar 2010 12:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3lnzA34qOG7 for ; Wed, 17 Mar 2010 12:57:51 -0700 (PDT) Received: from pontius.teigre.com (pontius.teigre.com [213.225.78.155]) by core3.amsl.com (Postfix) with ESMTP id F0C923A6952 for ; Wed, 17 Mar 2010 12:57:50 -0700 (PDT) X-ClientAddr: 217.14.5.61 Received: from [192.168.5.192] (217-14-5-61-dhcp-osl.bbse.no [217.14.5.61]) (authenticated bits=0) by pontius.teigre.com (8.13.8/8.13.8) with ESMTP id o2HJw6t1028451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2010 20:58:07 +0100 Message-ID: <4BA13444.6010709@teigre.com> Date: Wed, 17 Mar 2010 20:57:56 +0100 From: Greger Viken Teigre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Adam Roach References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> In-Reply-To: <4B9E5F47.2040604@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigre.com-MailScanner-Information: Please contact the ISP for more information X-teigre.com-MailScanner: Found to be clean X-teigre.com-MailScanner-From: gregert@teigre.com Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 19:57:52 -0000 On 15.03.2010 17:24, Adam Roach wrote: > On 3/15/10 11:09, Mar 15, Paul Kyzivat wrote: >> >> >> Adam Roach wrote: >>> Greger: >>> >>> For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) >>> provide about 80% of what you're asking for. >> >> Selecting a *UAS* that has the capabilities the caller envisions >> using (such as video) were certainly among the things that were among >> the intended use cases. >> >> I'm dubious about their suitability for selecting a route to reach >> the UAS, assuming its the same UAS you are seeking. > > That's the other 20%. :) Yes, the toolset is there. Making it work in a multi-vendor, multi-party, multi-capability UA environment is far away. > > >> Also callerprefs are no guarantee (not even a superset) of the >> capabilities that will be used on a call. It is an entirely >> reasonable use case for a UAC to invite with no offer, and then >> negotiate the use of voice and video because the UAS offers that. Its >> also entirely reasonable for a call to start out as audio only, for >> the caller and callee to learn as a result of discussion that both >> are video capable, and then add video to the call. >> >> As non-voice media become more mainstream, and as e2e sip sessions >> become more feasible, we should be investigating how the >> infrastructure can avoid breaking these kinds of use cases. Nailing >> down the route in a way that precludes use of media not announced at >> call establishment time isn't going in a very helpful direction. > > Nailing down a route... for signaling? I'm a bit confused about how > that is going to preclude certain media types. I'm not sure I'm following this, but a video phone will for example be able to make PSTN calls over one peering relationship, high-def voice/AAC-LD over another, and video over a third. If the original call was to a URI with hunt functionality forking across all three, it's pretty random where the call will end up and any attempt with no offer or renegotiate to video afterwards is not likely to work very well from a user perspective. g-) > > Now, if we want to talk about media steering, that's a completely > different issue. I don't think SIP routing plays into that. > > /a From gregert@teigre.com Wed Mar 17 13:32:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D0B3A6944 for ; Wed, 17 Mar 2010 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIr3SMWsv3Be for ; Wed, 17 Mar 2010 13:32:31 -0700 (PDT) Received: from pontius.teigre.com (pontius.teigre.com [213.225.78.155]) by core3.amsl.com (Postfix) with ESMTP id 9BF073A69BE for ; Wed, 17 Mar 2010 13:32:30 -0700 (PDT) X-ClientAddr: 217.14.5.61 Received: from [192.168.5.192] (217-14-5-61-dhcp-osl.bbse.no [217.14.5.61]) (authenticated bits=0) by pontius.teigre.com (8.13.8/8.13.8) with ESMTP id o2HKWlJI030273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Mar 2010 21:32:47 +0100 Message-ID: <4BA13C64.80908@teigre.com> Date: Wed, 17 Mar 2010 21:32:36 +0100 From: Greger Viken Teigre User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090908030307080005050804" X-teigre.com-MailScanner-Information: Please contact the ISP for more information X-teigre.com-MailScanner: Found to be clean X-teigre.com-MailScanner-From: gregert@teigre.com Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 20:32:38 -0000 This is a multi-part message in MIME format. --------------090908030307080005050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Jon here (even though I feel partially responsible for starting a war of the worlds thread...) SPEERMINT seems to be the right place. I have trying to get through all the current drafts there, and I see that some of the issues I raised here as a response to egress-route is really something that should be raised in SPEERMINT context. g-) On 17.03.2010 00:29, Peterson, Jon wrote: > > I'm not sure that dispatching malas-dispatch-sip-egress-route requires > us to untwist this particular Gordian knot, nor to resurrect TRIP, > nor to declare some kind of interplanetary Armageddon. > > I think Otmar Lendl has been right on the mark in this discussion. He > points out that global directories like ENUM serve well as an LUF and > poorly as an LRF, to speak in the SPEERMINT idiom - I don't think this > is an especially controversial point. I read malas-dispatch-sip-egress > as a document that argues that knowing the results of the LUF doesn't > necessarily help you to find a next hop to route your call through. > Again, I'd say not especially controversial. > > malas-dispatch-sip-egress-route then goes on to specify a few NAPTR > syntaxes that could contain a sort of joint LUF/LRF routing > information. The only conceptual problem I have with this approach is > that the entity that typically provisions the LUF doesn't know the > local topology of the originating network well enough to say useful > things about the LRF -- that is indeed the entire motivation for > considering the LUF and LRF as separate lookups. The draft sort of > glosses this over with a lot of passive voice when describing how the > ENUM provisioning gets done. Is it done by the terminating side, or > the originating side, or somehow both? > > In any event, from a DISPATCH perspective, I'd propose the problem > seems to lie comfortable within the parameters of SPEERMINT. Surely > one of the SPEERMINT chairs must think this is a worthwhile effort... > > Jon Peterson > NeuStar, Inc. > > On 3/16/10 3:24 PM, "Adam Roach" wrote: > > On 3/16/10 3:59 PM, "Daryl Malas" wrote: > > > I believe this issue was summarized well during the 73rd IETF > meeting at the > > RAI open meeting, and captured in Jonathan's draft: > > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 > > I think Jonathan Rosenberg correctly identified that there was a > problem > here. And then, just like Jonathan Swift's original "Modest > Proposal," he > goes on to propose that the solution to our problem is best found > in eating > our own children. > > I disagree profoundly with characterizing Rosenberg's Modest > Proposal as an > appropriate summary of the issues, as it gets the analysis > precisely wrong. > It proposes completely abandoning the vibrant world as a lost > cause, and > embracing the stagnant world as the only path forward. This isn't just > allowing collateral damage to the vibrant world for the sake of > expediency > in stagnant world solutions -- it's a suggestion that we nuke the > vibrant > world so it doesn't keep annoying people trying to develop stagnant > solutions. > > I'll admit that it's easier to see the stagnant world, since the > telcos have > quite a bit of money to throw around driving its deployment. But > there are > people in the vibrant world working on new services. Go back and > re-read > Greger's description of what he's seeing deployed. Check out the > stuff that > AG Projects (http://ag-projects.com/) has been working on, > selling, and > actually deploying. I don't recall whether you would have been at the > meeting where I wore a t-shirt showing some novel SIP devices -- > I'll bring > it to Anaheim. > > /a > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------090908030307080005050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Jon here (even though I feel partially responsible for starting a war of the worlds thread...)
SPEERMINT seems to be the right place. I have trying to get through all the current drafts there, and I see that some of the issues I raised here as a response to egress-route is really something that should be raised in SPEERMINT context.
g-)

On 17.03.2010 00:29, Peterson, Jon wrote:
Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)
I’m not sure that dispatching malas-dispatch-sip-egress-route requires us to untwist this particular Gordian knot, nor to resurrect TRIP,  nor to declare some kind of interplanetary Armageddon.

I think Otmar Lendl has been right on the mark in this discussion. He points out that global directories like ENUM serve well as an LUF and poorly as an LRF, to speak in the SPEERMINT idiom - I don’t think this is an especially controversial point. I read malas-dispatch-sip-egress as a document that argues that knowing the results of the LUF doesn’t necessarily help you to find a next hop to route your call through. Again, I’d say not especially controversial.

malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxes that could contain a sort of joint LUF/LRF routing information. The only conceptual problem I have with this approach is that the entity that typically provisions the LUF doesn’t know the local topology of the originating network well enough to say useful things about the LRF – that is indeed the entire motivation for considering the LUF and LRF as separate lookups. The draft sort of glosses this over with a lot of passive voice when describing how the ENUM provisioning gets done. Is it done by the terminating side, or the originating side, or somehow both?

In any event, from a DISPATCH perspective, I’d propose the problem seems to lie comfortable within the parameters of SPEERMINT. Surely one of the SPEERMINT chairs must think this is a worthwhile effort...

Jon Peterson
NeuStar, Inc.

On 3/16/10 3:24 PM, "Adam Roach" <adam@nostrum.com> wrote:
On 3/16/10 3:59 PM, "Daryl Malas" <D.Malas@cablelabs.com> wrote:

> I believe this issue was summarized well during the 73rd IETF meeting at the
> RAI open meeting, and captured in Jonathan's draft:
> http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00

I think Jonathan Rosenberg correctly identified that there was a problem
here. And then, just like Jonathan Swift's original "Modest Proposal," he
goes on to propose that the solution to our problem is best found in eating
our own children.

I disagree profoundly with characterizing Rosenberg's Modest Proposal as an
appropriate summary of the issues, as it gets the analysis precisely wrong.
It proposes completely abandoning the vibrant world as a lost cause, and
embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency
in stagnant world solutions -- it's a suggestion that we nuke the vibrant
world so it doesn't keep annoying people trying to develop stagnant
solutions.

I'll admit that it's easier to see the stagnant world, since the telcos have
quite a bit of money to throw around driving its deployment. But there are
people in the vibrant world working on new services. Go back and re-read
Greger's description of what he's seeing deployed. Check out the stuff that
AG Projects (http://ag-projects.com/) has been working on, selling, and
actually deploying. I don't recall whether you would have been at the
meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring
it to Anaheim.

/a


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------090908030307080005050804-- From richard@shockey.us Wed Mar 17 14:01:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E97D3A67DA for ; Wed, 17 Mar 2010 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2] 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 aDzB7oQq7KsV for ; Wed, 17 Mar 2010 14:01:23 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id EE0EE3A6855 for ; Wed, 17 Mar 2010 14:01:22 -0700 (PDT) Received: (qmail 8337 invoked by uid 0); 17 Mar 2010 21:01:33 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 17 Mar 2010 21:01:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=BUMwdkwC8WVb9AdcBdW49bD4ITNKXSzKat4nHIfdo2AyjVXwy/v9xoU1+ZpOAi25uACfs+GfGVJrEGfYJWAEpTp3dSkcmKWyLMSmL/nturtRv4UcOhUWQF3cn4QkUj4m; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ns0Mv-00024a-98; Wed, 17 Mar 2010 15:01:33 -0600 From: "Richard Shockey" To: "'Daryl Malas'" , "'Dean Willis'" , "'Adam Roach'" References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <181C6F5E-60C4-4DC9-847E-639CAEFB79F1@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F6774@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6774@srvxchg> Date: Wed, 17 Mar 2010 17:01:29 -0400 Message-ID: <010001cac615$04ca2550$0e5e6ff0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFTreW7UTQXyTMSfO8iA7L750+xgAA+OggADBOG7A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 21:01:24 -0000 +1 Daryl is right here. Can we let people try and solve their problems? At least in the intermediate term vs seeing chaos rule? I'm getting this same thread in the E2MD discussions. I though the IETF was about trying to make the internet work better. The meta issue here is there are ..yes classic telecommunications carriers have substantive technical problems interoperating or transitioning from classic analog POTS to SIP centric solutions. GEE "what am I going to do with my DMS 250 and 500's .. hummmm what do I do when I get a EOL letter for my hundreds of 5ESS switches." Part of the solution MAY assume a transitional mechanism that generally accepts that some form of the classic intercarrier interconnection model may exist and that policy MAY exist at each intermediate hop. This assumes that you may need to crawl before you walk and that nirvana may be a while off in the future. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Tuesday, March 16, 2010 6:00 PM To: 'Dean Willis'; Adam Roach Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 I believe this issue was summarized well during the 73rd IETF meeting at the RAI open meeting, and captured in Jonathan's draft: http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 I believe we MUST solve this problem twice. Let's be realistic. Understanding the problem fully, defining the requirements, establishing the group and hammering through the varying solutions will take 5 - 10 years to complete. The telecommunications industry will develop their own proprietary mechanisms for doing this, creating greater fragmentation and interoperability issues; or the IETF can step up and as an interim solution say, since, you are going to solve this, do it this way. At least in this case, we will know where the industry is at in their resolution rather than guessing at the plethora of "potentials" down the road. Regards, Daryl -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, March 16, 2010 3:21 PM To: Adam Roach Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 On Mar 15, 2010, at 12:33 PM, Adam Roach wrote: > ... > Which is to say that I don't think there is a solution that satisfies > both groups. The divergence from the fork between the stagnant world > and the vibrant world is great enough that there is no common ground > left for these kinds of issues. As odious as it is, I'm afraid we're > stuck with solving this problem twice. The real challenge is ensuring > that stagnant solutions don't do lasting damage to the core protocols > -- we need to make sure they don't destroy the vibrant world with > collateral damage. Beautifully said! I read it just after my similar but less-elegant rant, which presumes that the stagnant world is likely to be selected over the vibrant through the simple processes of expediency, apathy, corruption, greed, and fear. But then, I'm an optimist. -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Wed Mar 17 14:04:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5ED3A6944 for ; Wed, 17 Mar 2010 14:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uk12d1iZcUJ for ; Wed, 17 Mar 2010 14:04:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 437F13A6952 for ; Wed, 17 Mar 2010 14:04:50 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2HL4tWQ082818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Mar 2010 16:04:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BA143F6.7070409@nostrum.com> Date: Wed, 17 Mar 2010 16:04:54 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Shockey References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <181C6F5E-60C4-4DC9-847E-639CAEFB79F1@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F6774@srvxchg> <010001cac615$04ca2550$0e5e6ff0$@us> In-Reply-To: <010001cac615$04ca2550$0e5e6ff0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, 'Daryl Malas' Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 21:04:58 -0000 Let me make sure I understand this correctly. I'm pushing for adoption and publication of Daryl's draft, and you're trying to disagree with me by pushing for adoption and publication of Daryl's draft. Is that where we stand? /a On 3/17/10 4:01 PM, Richard Shockey wrote: > +1 Daryl is right here. > > Can we let people try and solve their problems? At least in the intermediate > term vs seeing chaos rule? I'm getting this same thread in the E2MD > discussions. I though the IETF was about trying to make the internet work > better. > > The meta issue here is there are ..yes classic telecommunications carriers > have substantive technical problems interoperating or transitioning from > classic analog POTS to SIP centric solutions. GEE "what am I going to do > with my DMS 250 and 500's .. hummmm what do I do when I get a EOL letter for > my hundreds of 5ESS switches." > > Part of the solution MAY assume a transitional mechanism that generally > accepts that some form of the classic intercarrier interconnection model may > exist and that policy MAY exist at each intermediate hop. > > This assumes that you may need to crawl before you walk and that nirvana may > be a while off in the future. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Daryl Malas > Sent: Tuesday, March 16, 2010 6:00 PM > To: 'Dean Willis'; Adam Roach > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 > > I believe this issue was summarized well during the 73rd IETF meeting at the > RAI open meeting, and captured in Jonathan's draft: > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 > > I believe we MUST solve this problem twice. Let's be realistic. > Understanding the problem fully, defining the requirements, establishing the > group and hammering through the varying solutions will take 5 - 10 years to > complete. The telecommunications industry will develop their own > proprietary mechanisms for doing this, creating greater fragmentation and > interoperability issues; or the IETF can step up and as an interim solution > say, since, you are going to solve this, do it this way. At least in this > case, we will know where the industry is at in their resolution rather than > guessing at the plethora of "potentials" down the road. > > Regards, > > Daryl > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Tuesday, March 16, 2010 3:21 PM > To: Adam Roach > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 > > > On Mar 15, 2010, at 12:33 PM, Adam Roach wrote: > > >> ... >> > >> Which is to say that I don't think there is a solution that satisfies >> both groups. The divergence from the fork between the stagnant world >> and the vibrant world is great enough that there is no common ground >> left for these kinds of issues. As odious as it is, I'm afraid we're >> stuck with solving this problem twice. The real challenge is ensuring >> that stagnant solutions don't do lasting damage to the core protocols >> -- we need to make sure they don't destroy the vibrant world with >> collateral damage. >> > Beautifully said! I read it just after my similar but less-elegant rant, > which presumes that the stagnant world is likely to be selected over the > vibrant through the simple processes of expediency, apathy, corruption, > greed, and fear. But then, I'm an optimist. > > -- > Dean > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From dean.willis@softarmor.com Wed Mar 17 17:26:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33693A683B for ; Wed, 17 Mar 2010 17:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 j2z408vqhT-g for ; Wed, 17 Mar 2010 17:26:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 149C93A6917 for ; Wed, 17 Mar 2010 17:26:16 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2I0QOUn019132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Mar 2010 19:26:25 -0500 Message-Id: <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4BA0EC7D.6060900@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Mar 2010 19:26:18 -0500 References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> <4BA0EC7D.6060900@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 00:26:17 -0000 On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote: >> > > For those that truly describe properties of a URI (if there are any > of those), you may be right. > > For those that describe properties of a call, if they were carried > as part of the call rather than as properties of the URI, then it > wouldn't matter if the URI is sip or tel. > > But in reality, even the properties that describe the caller aren't > properly properties of the caller's URI. For instance, in principle > the same originating "number" might be used by one phone in a prison > and another in a police station. > > ISTM that piggybacking these on the TEL uri is simply a convenient > "ploy", because both phone numbers and these properties are managed > by the ITU. Let's run through them: ordinary: the caller has been identified and has no special features. At least not on this call; they might have some on another call, or might re-INVITE midstream if they change their mind, so don't count in it. Property of "call", not "caller". Test: This is a test call. If the same guy calls you in 5 minutes, it might not be a test. Property of "call", not "caller". operator: This call was generated by an operator position. Ostensibly, the caller is an operator? Probably a property of the "caller". One could envision putting this info in RFC 4474. payphone: The calling station is a payphone. Again, a property of the caller. unknown: I don't know what this means. It's probably got nothing to do with the caller. mobile-hplmn/vplmn: The call was generated by a mobile device (property of the calling device, anyhow) in it's home/visited plmn (property of this call; doesn't persist if you call it back). Some of the ANI II digits are things that are properties of a caller. Some, like Code 25, are attributes of call and caller. Many seem to specify specifc route-handling FOR THIS CALL, like not stripping off a leading "63". So I'm not sure this is a useful categorization. I'm pretty sure I don't want a "Type 67" modifier attached to A SIP URI. I'm also sure that most of these parameters make no sense on a TEL URI when that URI is used as a Request-URI; they don't route a call. They kindof make sense in a From: URI (or an RFC 4474 Identity header field), but they lack reversibility: one couldn't store this From: in a phone book, then turn around and call it back 5 minutes later. Consequently, the called party MUST understand them, or bad things will happen. This calls for an option tag, which is messy. But I'm at a loss for proposing a better mechanism. Perhaps we could follow the SIP-T method and define another extension header field carried in the request? -- Dean From richard@shockey.us Wed Mar 17 18:06:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC373A68DD for ; Wed, 17 Mar 2010 18:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94arHfYb3oQQ for ; Wed, 17 Mar 2010 18:06:16 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 138203A67E6 for ; Wed, 17 Mar 2010 18:06:16 -0700 (PDT) Received: (qmail 16486 invoked by uid 0); 18 Mar 2010 01:06:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Mar 2010 01:06:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=FUg0ERYPNPtRtIN2JBdEDxFDfX/3yr4SjzYJr5PppNhI6VNa2znSmf8TtOL6Dr8fQ9NE+Id8KKSPn9OUVVyWgjc0mgnjEPkCX5HXke7G4y3Th9TsEEs7xWMs91cgmqQU; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ns4Bu-00023X-81; Wed, 17 Mar 2010 19:06:26 -0600 From: "Richard Shockey" To: , Date: Wed, 17 Mar 2010 21:06:22 -0400 Message-ID: <013801cac637$3a7668e0$af633aa0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01CAC615.B364C8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/uZOrLwXMolSnQeyPKU4g86oIkg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: rai@ietf.org Subject: [dispatch] Reminder Last Message: SIP Forum Luncheon at IETF 77 Monday 11:30 13:00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 01:06:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0139_01CAC615.B364C8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SIP Forum is going to hold a open meeting for the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical issues that relate to IETF WG's. The agenda for this luncheon will be to review current activities in the SIP Forum and seek additional technical input from the RAI community on mutual concerns. As many of you know the SIP Forum is the principal sponsor of the SIPit interoperability events and currently has 4 Task groups operating. BTW registration for SIPit 26 will be open soon. Our principal technical initiatives are: 1. SIP Connect 1.1 which is developing an enhanced profile of IETF Standards for PBX to SSP interoperability. As part of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP. 2. FAX over SIP is investigating the interoperability of SIP in T.38 networks with a goal of possible recommendations to the relevant SDO's on how fax can work better. 3. Client User Agent Configuration which has a pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP User Agents 4. SIP in the SmartGrid. This is a Special Interest Group that is evaluating the appropriateness of using SIP as a protocol for a number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) deployments. Information on the SIP Forum is available at http//www.sipforum.org If you are interested in attending this event we have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( 150 Maximum) lunch will be provided. Location .. Monday 11:30 13:00 the Laguna room and its located on the 4th floor of the Anaheim Hilton The link to the poll is: http://www.doodle.com/hde57nbpcdykzqfz Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ------=_NextPart_000_0139_01CAC615.B364C8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The SIP Forum is going to hold a open meeting for = the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical = issues that relate to IETF WG’s. The agenda for this luncheon will be to = review current activities in the SIP Forum and seek additional technical input = from the RAI community on mutual concerns.

 

As many of you know the SIP Forum is the principal = sponsor of the SIPit interoperability events and currently has 4 Task groups = operating.

 

BTW registration for SIPit 26 will be open = soon.

 

Our principal technical initiatives = are:

 

1.      SIP Connect 1.1 which is developing an enhanced  profile of IETF Standards for PBX to SSP interoperability. As part = of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP.

2.      FAX over SIP is investigating the = interoperability of SIP in T.38 networks with a goal of possible recommendations to the = relevant SDO’s on how fax can work better.

3.      Client User Agent Configuration which has a = pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP = User Agents

4.      SIP in the SmartGrid. This is a Special Interest = Group that is evaluating the appropriateness of using SIP as a protocol for a = number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) = deployments.

 

Information on the SIP Forum is available at =

 

http//www.sipforum.org

 

If you are interested in attending this event we = have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( = 150 Maximum) lunch will be provided.

 

Location .. Monday 11:30 13:00 the Laguna room and its = located on the 4th floor of the Anaheim Hilton

The link to the poll = is:

http://www.doodle.com/hde57nbpcdykzqfz

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype: rshockey101
LinkedIn : http://www.linkedin.com/i= n/rshockey101

 

------=_NextPart_000_0139_01CAC615.B364C8E0-- From Milan.Patel@InterDigital.com Thu Mar 18 03:08:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C762E3A6B60 for ; Thu, 18 Mar 2010 03:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 vWshK091yHQ7 for ; Thu, 18 Mar 2010 03:08:58 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 407AB3A6B58 for ; Thu, 18 Mar 2010 03:08:56 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 06:09:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 05:59:34 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000D763893@SABRE.InterDigital.com> In-Reply-To: <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: AcrGMad4NJHjCNzkQu2Op0L1SvpHJwAT2/yg From: "Patel, Milan" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 18 Mar 2010 10:09:06.0381 (UTC) FILETIME=[0B2A2FD0:01CAC683] Cc: DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 10:09:00 -0000 Hi Dean, Paul, I now understand your comments about some OLI values characterizing the call vs caller. The recommended use of the URI parameter is in the P-Asserted-Identity. If this is not supported, the OLI can be added in the From header. From a 3GPP point of view, the OLI would be added to the P-Asserted-Identity header. The CPC and OLI values are subject to trust domain rules, so they will not be sent to the called party. It is important they get interworked at the Media Gateway Control Function to ISUP information elements. Regards, Milan -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, March 18, 2010 12:26 AM To: Paul Kyzivat Cc: Patel, Milan; DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote: >> > > For those that truly describe properties of a URI (if there are any =20 > of those), you may be right. > > For those that describe properties of a call, if they were carried =20 > as part of the call rather than as properties of the URI, then it =20 > wouldn't matter if the URI is sip or tel. > > But in reality, even the properties that describe the caller aren't =20 > properly properties of the caller's URI. For instance, in principle =20 > the same originating "number" might be used by one phone in a prison =20 > and another in a police station. > > ISTM that piggybacking these on the TEL uri is simply a convenient =20 > "ploy", because both phone numbers and these properties are managed =20 > by the ITU. Let's run through them: ordinary: the caller has been identified and has no special features. =20 At least not on this call; they might have some on another call, or =20 might re-INVITE midstream if they change their mind, so don't count in =20 it. Property of "call", not "caller". Test: This is a test call. If the same guy calls you in 5 minutes, it =20 might not be a test. Property of "call", not "caller". operator: This call was generated by an operator position. Ostensibly, =20 the caller is an operator? Probably a property of the "caller". One =20 could envision putting this info in RFC 4474. payphone: The calling station is a payphone. Again, a property of the =20 caller. unknown: I don't know what this means. It's probably got nothing to do =20 with the caller. mobile-hplmn/vplmn: The call was generated by a mobile device =20 (property of the calling device, anyhow) in it's home/visited plmn =20 (property of this call; doesn't persist if you call it back). Some of the ANI II digits are things that are properties of a caller. =20 Some, like Code 25, are attributes of call and caller. Many seem to =20 specify specifc route-handling FOR THIS CALL, like not stripping off a =20 leading "63". So I'm not sure this is a useful categorization. I'm pretty sure I don't want a "Type 67" modifier attached to A SIP =20 URI. I'm also sure that most of these parameters make no sense on a =20 TEL URI when that URI is used as a Request-URI; they don't route a =20 call. They kindof make sense in a From: URI (or an RFC 4474 Identity =20 header field), but they lack reversibility: one couldn't store this =20 From: in a phone book, then turn around and call it back 5 minutes =20 later. Consequently, the called party MUST understand them, or bad =20 things will happen. This calls for an option tag, which is messy. But I'm at a loss for proposing a better mechanism. Perhaps we could =20 follow the SIP-T method and define another extension header field =20 carried in the request? -- Dean From pkyzivat@cisco.com Thu Mar 18 05:49:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543CE3A69C6 for ; Thu, 18 Mar 2010 05:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.43 X-Spam-Level: X-Spam-Status: No, score=-8.43 tagged_above=-999 required=5 tests=[AWL=-1.561, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubjd6-95Yqb3 for ; Thu, 18 Mar 2010 05:49:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EE6A63A6927 for ; Thu, 18 Mar 2010 05:49:32 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJy+oUtAZnwN/2dsb2JhbACbLXOgGph6gksBBoInBI8J X-IronPort-AV: E=Sophos;i="4.51,267,1267401600"; d="scan'208";a="94038281" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2010 12:49:43 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2ICnhLt026269; Thu, 18 Mar 2010 12:49:43 GMT Message-ID: <4BA2216E.5090102@cisco.com> Date: Thu, 18 Mar 2010 08:49:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <61CAF342FE1EE34EAC8FB19B765914000D763886@SABRE.InterDigital.com> <4BA0EC7D.6060900@cisco.com> <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> In-Reply-To: <6DC49EE7-B148-4EE5-B004-5763EEE42B05@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 12:49:34 -0000 inline Dean Willis wrote: > > On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote: >>> >> >> For those that truly describe properties of a URI (if there are any of >> those), you may be right. >> >> For those that describe properties of a call, if they were carried as >> part of the call rather than as properties of the URI, then it >> wouldn't matter if the URI is sip or tel. >> >> But in reality, even the properties that describe the caller aren't >> properly properties of the caller's URI. For instance, in principle >> the same originating "number" might be used by one phone in a prison >> and another in a police station. >> >> ISTM that piggybacking these on the TEL uri is simply a convenient >> "ploy", because both phone numbers and these properties are managed by >> the ITU. > > > Let's run through them: > > ordinary: the caller has been identified and has no special features. At > least not on this call; they might have some on another call, or might > re-INVITE midstream if they change their mind, so don't count in it. > Property of "call", not "caller". > > Test: This is a test call. If the same guy calls you in 5 minutes, it > might not be a test. Property of "call", not "caller". > > operator: This call was generated by an operator position. Ostensibly, > the caller is an operator? Probably a property of the "caller". One > could envision putting this info in RFC 4474. > payphone: The calling station is a payphone. Again, a property of the > caller. > > unknown: I don't know what this means. It's probably got nothing to do > with the caller. > > mobile-hplmn/vplmn: The call was generated by a mobile device (property > of the calling device, anyhow) in it's home/visited plmn (property of > this call; doesn't persist if you call it back). > > Some of the ANI II digits are things that are properties of a caller. > Some, like Code 25, are attributes of call and caller. Many seem to > specify specifc route-handling FOR THIS CALL, like not stripping off a > leading "63". I included several others in my earlier post: Properties of the callee: * 30 Intercept (blank) - for calls to unassigned directory number (DN) * 31 Intercept (trouble) - for calls to directory numbers (DN) that have been manually placed in trouble-busy state by Telco personnel * 32 Intercept (regular) - for calls to recently changed or disconnected numbers The following can be assigned mid-call, as a result of call handling, and so are properties of neither the caller nor the callee. I gather 34 is what Dean is calling "operator". But from the description, the "From" will probably still be as supplied by the caller, rather than identifying the operator. So again its a (dynamic) property of the call, not the caller. * 34 Telco Operator Handled Call - after the Telco Operator Services System has handled a call for an IC, it may change the standard ANI digits to "34", before outpulsing the sequence to the IC, when the Telco performs all call handling functions, e.g., billing. The code tells the IC that the BOC has performed billing on the call and the IC only has to complete the call. * 52 Outward Wide Area Telecommunications Service (OUTWATS) - this service allows customers to make calls to a certain zone(s) or band(s) on a direct dialed basis for a flat monthly charge or for a charge based on accumulated usage. OUTWATS lines can dial station-to-station calls directly to points within the selected band(s) or zone(s). The LEC performs a screening function to determine the correct charging and routing for OUTWATS calls based on the customer's class of service and the service area of the call party. When these calls are routed to the interexchange carrier via a combined WATS-POTS trunk group, it is necessary to identify the WATS calls with the ANI code "52". > So I'm not sure this is a useful categorization. > > I'm pretty sure I don't want a "Type 67" modifier attached to A SIP URI. > I'm also sure that most of these parameters make no sense on a TEL URI > when that URI is used as a Request-URI; they don't route a call. They > kindof make sense in a From: URI (or an RFC 4474 Identity header field), > but they lack reversibility: one couldn't store this From: in a phone > book, then turn around and call it back 5 minutes later. Consequently, > the called party MUST understand them, or bad things will happen. This > calls for an option tag, which is messy. > > But I'm at a loss for proposing a better mechanism. Perhaps we could > follow the SIP-T method and define another extension header field > carried in the request? Since at least some of this stuff apparently has to change mid-call, I think it calls for a new header to carry it. Thanks, Paul From pkyzivat@cisco.com Thu Mar 18 06:19:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2C03A69C6 for ; Thu, 18 Mar 2010 06:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.682 X-Spam-Level: X-Spam-Status: No, score=-9.682 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i99Grcv9SjHT for ; Thu, 18 Mar 2010 06:18:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 02B903A6AC6 for ; Thu, 18 Mar 2010 06:18:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvFoUtAZnwM/2dsb2JhbACbLXOgTJh5gkyCLQQ X-IronPort-AV: E=Sophos;i="4.51,267,1267401600"; d="scan'208";a="93913160" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Mar 2010 13:19:06 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IDJ6Iw000658; Thu, 18 Mar 2010 13:19:06 GMT Message-ID: <4BA22855.2020407@cisco.com> Date: Thu, 18 Mar 2010 09:19:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Patel, Milan" References: <61CAF342FE1EE34EAC8FB19B765914000D763893@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000D763893@SABRE.InterDigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 13:19:01 -0000 Patel, Milan wrote: > Hi Dean, Paul, > > I now understand your comments about some OLI values characterizing the > call vs caller. > > The recommended use of the URI parameter is in the P-Asserted-Identity. > If this is not supported, the OLI can be added in the From header. From > a 3GPP point of view, the OLI would be added to the P-Asserted-Identity > header. The CPC and OLI values are subject to trust domain rules, so > they will not be sent to the called party. It is important they get > interworked at the Media Gateway Control Function to ISUP information > elements. Using this in the PAI header does provide a vehicle for mid-call changes. But it doesn't alter the reality that the PAI also is intended to make an assertion about the *caller* while some of this other information is about the *call* rather than the caller. For example, how does it make any sense to include * 31 Intercept (trouble) - for calls to directory numbers (DN) that have been manually placed in trouble-busy state by Telco personnel into the PAI header??? Thanks, Paul > Regards, > Milan > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, March 18, 2010 12:26 AM > To: Paul Kyzivat > Cc: Patel, Milan; DISPATCH > Subject: Re: [dispatch] FW: New VersionNotification for > draft-patel-dispatch-cpc-oli-parameter-00 > > > On Mar 17, 2010, at 9:51 AM, Paul Kyzivat wrote: >> For those that truly describe properties of a URI (if there are any >> of those), you may be right. >> >> For those that describe properties of a call, if they were carried >> as part of the call rather than as properties of the URI, then it >> wouldn't matter if the URI is sip or tel. >> >> But in reality, even the properties that describe the caller aren't >> properly properties of the caller's URI. For instance, in principle >> the same originating "number" might be used by one phone in a prison >> and another in a police station. >> >> ISTM that piggybacking these on the TEL uri is simply a convenient >> "ploy", because both phone numbers and these properties are managed >> by the ITU. > > > Let's run through them: > > ordinary: the caller has been identified and has no special features. > At least not on this call; they might have some on another call, or > might re-INVITE midstream if they change their mind, so don't count in > it. Property of "call", not "caller". > > Test: This is a test call. If the same guy calls you in 5 minutes, it > might not be a test. Property of "call", not "caller". > > operator: This call was generated by an operator position. Ostensibly, > the caller is an operator? Probably a property of the "caller". One > could envision putting this info in RFC 4474. > > payphone: The calling station is a payphone. Again, a property of the > caller. > > unknown: I don't know what this means. It's probably got nothing to do > with the caller. > > mobile-hplmn/vplmn: The call was generated by a mobile device > (property of the calling device, anyhow) in it's home/visited plmn > (property of this call; doesn't persist if you call it back). > > Some of the ANI II digits are things that are properties of a caller. > Some, like Code 25, are attributes of call and caller. Many seem to > specify specifc route-handling FOR THIS CALL, like not stripping off a > leading "63". > > So I'm not sure this is a useful categorization. > > I'm pretty sure I don't want a "Type 67" modifier attached to A SIP > URI. I'm also sure that most of these parameters make no sense on a > TEL URI when that URI is used as a Request-URI; they don't route a > call. They kindof make sense in a From: URI (or an RFC 4474 Identity > header field), but they lack reversibility: one couldn't store this > From: in a phone book, then turn around and call it back 5 minutes > later. Consequently, the called party MUST understand them, or bad > things will happen. This calls for an option tag, which is messy. > > But I'm at a loss for proposing a better mechanism. Perhaps we could > follow the SIP-T method and define another extension header field > carried in the request? > > > -- > Dean > > > From D.Malas@cablelabs.com Thu Mar 18 07:58:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDEA3A6C3D for ; Thu, 18 Mar 2010 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjvcJM2xU8I4 for ; Thu, 18 Mar 2010 07:58:38 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 169CD3A6C05 for ; Thu, 18 Mar 2010 07:58:38 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2IEwnnH012871; Thu, 18 Mar 2010 08:58:49 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 18 Mar 2010 08:58:48 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 18 Mar 2010 08:58:49 -0600 From: Daryl Malas To: "'Greger Viken Teigre'" , "dispatch@ietf.org" Date: Thu, 18 Mar 2010 08:58:48 -0600 Thread-Topic: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrGEQR/c6fQRaxlTyu7yXqqMbcZMAAmnCJQ Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6787@srvxchg> References: <4BA13C64.80908@teigre.com> In-Reply-To: <4BA13C64.80908@teigre.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6787srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:58:46 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6787srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there any other thoughts on "Speermint-izing" this work? --Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Greger Viken Teigre Sent: Wednesday, March 17, 2010 2:33 PM To: dispatch@ietf.org Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-= dispatch-sip-egress-route-00) I agree with Jon here (even though I feel partially responsible for startin= g a war of the worlds thread...) SPEERMINT seems to be the right place. I have trying to get through all the= current drafts there, and I see that some of the issues I raised here as a= response to egress-route is really something that should be raised in SPEE= RMINT context. g-) On 17.03.2010 00:29, Peterson, Jon wrote: I'm not sure that dispatching malas-dispatch-sip-egress-route requires us t= o untwist this particular Gordian knot, nor to resurrect TRIP, nor to decl= are some kind of interplanetary Armageddon. I think Otmar Lendl has been right on the mark in this discussion. He point= s out that global directories like ENUM serve well as an LUF and poorly as = an LRF, to speak in the SPEERMINT idiom - I don't think this is an especial= ly controversial point. I read malas-dispatch-sip-egress as a document that= argues that knowing the results of the LUF doesn't necessarily help you to= find a next hop to route your call through. Again, I'd say not especially = controversial. malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxe= s that could contain a sort of joint LUF/LRF routing information. The only = conceptual problem I have with this approach is that the entity that typica= lly provisions the LUF doesn't know the local topology of the originating n= etwork well enough to say useful things about the LRF - that is indeed the = entire motivation for considering the LUF and LRF as separate lookups. The = draft sort of glosses this over with a lot of passive voice when describing= how the ENUM provisioning gets done. Is it done by the terminating side, o= r the originating side, or somehow both? In any event, from a DISPATCH perspective, I'd propose the problem seems to= lie comfortable within the parameters of SPEERMINT. Surely one of the SPEE= RMINT chairs must think this is a worthwhile effort... Jon Peterson NeuStar, Inc. On 3/16/10 3:24 PM, "Adam Roach" wrote: On 3/16/10 3:59 PM, "Daryl Malas" wrote: > I believe this issue was summarized well during the 73rd IETF meeting at = the > RAI open meeting, and captured in Jonathan's draft: > http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00 I think Jonathan Rosenberg correctly identified that there was a problem here. And then, just like Jonathan Swift's original "Modest Proposal," he goes on to propose that the solution to our problem is best found in eating our own children. I disagree profoundly with characterizing Rosenberg's Modest Proposal as an appropriate summary of the issues, as it gets the analysis precisely wrong. It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just allowing collateral damage to the vibrant world for the sake of expediency in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant solutions. I'll admit that it's easier to see the stagnant world, since the telcos hav= e quite a bit of money to throw around driving its deployment. But there are people in the vibrant world working on new services. Go back and re-read Greger's description of what he's seeing deployed. Check out the stuff that AG Projects (http://ag-projects.com/) has been working on, selling, and actually deploying. I don't recall whether you would have been at the meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring it to Anaheim. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6787srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] War of the Worlds (was Re: I-D Action: dr= aft-malas-dispatch-sip-egress-route-00)
Are there any other thoughts on "Speermint-izing" thi= s=20 work?  --Daryl

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Greger Viken=20 Teigre
Sent: Wednesday, March 17, 2010 2:33 PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] War of the Worlds (was = Re:=20 I-D Action: draft-malas-dispatch-sip-egress-route-00)

I agree with Jon here (even though I feel partially responsible = for=20 starting a war of the worlds thread...)
SPEERMINT seems to be the right= =20 place. I have trying to get through all the current drafts there, and I see= that=20 some of the issues I raised here as a response to egress-route is really=20 something that should be raised in SPEERMINT context.
g-)

On=20 17.03.2010 00:29, Peterson, Jon wrote:=20

I’m not sure that dispatching=20 malas-dispatch-sip-egress-route requires us to untwist this particular Go= rdian=20 knot, nor to resurrect TRIP,  nor to declare some kind of interplane= tary=20 Armageddon.

I think Otmar Lendl has been right on the mark in this= =20 discussion. He points out that global directories like ENUM serve well as= an=20 LUF and poorly as an LRF, to speak in the SPEERMINT idiom - I don’t= think this=20 is an especially controversial point. I read malas-dispatch-sip-egress as= a=20 document that argues that knowing the results of the LUF doesn’t ne= cessarily=20 help you to find a next hop to route your call through. Again, I’d = say not=20 especially controversial.

malas-dispatch-sip-egress-route then goe= s on=20 to specify a few NAPTR syntaxes that could contain a sort of joint LUF/LR= F=20 routing information. The only conceptual problem I have with this approac= h is=20 that the entity that typically provisions the LUF doesn’t know the = local=20 topology of the originating network well enough to say useful things abou= t the=20 LRF – that is indeed the entire motivation for considering the LUF = and LRF as=20 separate lookups. The draft sort of glosses this over with a lot of passi= ve=20 voice when describing how the ENUM provisioning gets done. Is it done by = the=20 terminating side, or the originating side, or somehow both?

In any= =20 event, from a DISPATCH perspective, I’d propose the problem seems t= o lie=20 comfortable within the parameters of SPEERMINT. Surely one of the SPEERMI= NT=20 chairs must think this is a worthwhile effort...

Jon=20 Peterson
NeuStar, Inc.

On 3/16/10 3:24 PM, "Adam Roach" <adam@nostrum.com&g= t;=20 wrote:
On 3/16/10 3:59 PM, "Daryl Malas" <D.Malas@cablelabs.com> wrote:

&g= t; I=20 believe this issue was summarized well during the 73rd IETF meeting at= =20 the
> RAI open meeting, and captured in Jonathan's draft:
>= http://tools.ietf.org/html/draft-rosenberg-rai= -modest-proposal-00

I=20 think Jonathan Rosenberg correctly identified that there was a=20 problem
here. And then, just like Jonathan Swift's original "Modest= =20 Proposal," he
goes on to propose that the solution to our problem is= best=20 found in eating
our own children.

I disagree profoundly with= =20 characterizing Rosenberg's Modest Proposal as an
appropriate summary= of=20 the issues, as it gets the analysis precisely wrong.
It proposes=20 completely abandoning the vibrant world as a lost cause, and
embraci= ng=20 the stagnant world as the only path forward. This isn't just
allowin= g=20 collateral damage to the vibrant world for the sake of expediency
in= =20 stagnant world solutions -- it's a suggestion that we nuke the=20 vibrant
world so it doesn't keep annoying people trying to develop=20 stagnant
solutions.

I'll admit that it's easier to see the=20 stagnant world, since the telcos have
quite a bit of money to throw= =20 around driving its deployment. But there are
people in the vibrant w= orld=20 working on new services. Go back and re-read
Greger's description of= what=20 he's seeing deployed. Check out the stuff that
AG Projects (http://ag-projects.com/) has been working = on,=20 selling, and
actually deploying. I don't recall whether you would ha= ve=20 been at the
meeting where I wore a t-shirt showing some novel SIP de= vices=20 -- I'll bring
it to=20 Anaheim.

/a


_________________________________________= ______
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch= 


_______________________________________________
dispatch mailing list
dispa=
tch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01213F6787srvxchg_-- From laura.liess.dt@googlemail.com Thu Mar 18 08:57:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5404D3A6C59 for ; Thu, 18 Mar 2010 08:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.353 X-Spam-Level: ** X-Spam-Status: No, score=2.353 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZfRIePyhadY for ; Thu, 18 Mar 2010 08:57:23 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id A10393A6C30 for ; Thu, 18 Mar 2010 08:57:22 -0700 (PDT) Received: by mail-ew0-f216.google.com with SMTP id 8so1306954ewy.28 for ; Thu, 18 Mar 2010 08:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E/mZ64aES9b+WuT9Y+5EDQJngSRQdjl+Co/iwzlisSU=; b=ZG1Tegqxst4KkSjdbSQfwJ4bUUdGzzSd16zV0c0TpI96xxLZxGXDYgqtTqoqM6dmFH DPEIBS5EXGENA9Uc89nNVbhV1ZR3dErzUVmmcxHj1Va26Y2LpW+Sd9O8cZVvJnEMgE0h ohV14VAjWWQnOPmv/MRxDnHmQ1P3Iqym1xW5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LxS6Fk/IZFsTy8Ird7PDzAgqK5WM1quhnB+SlQsKGaA31UBx7jRBXw5b6sbkBVCsWN aO+MUFvoPppqJIfsytoFNbf1FkIq7kGbLMHKpGgN2biRi7/j11gvXhD/Z2nyGbOyDuOW Ag/tM4x/XwTEvzL0O2m8ZK7N4u0ohjDdy5Nhw= MIME-Version: 1.0 Received: by 10.216.88.148 with SMTP id a20mr1600153wef.124.1268927853701; Thu, 18 Mar 2010 08:57:33 -0700 (PDT) In-Reply-To: <4B912555.4020604@cisco.com> References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> Date: Thu, 18 Mar 2010 16:57:33 +0100 Message-ID: <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> From: Laura Liess To: Paul Kyzivat , alan.b.johnston@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Liess Laura Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:57:25 -0000 Paul, thank you for the comments and please excuse my late answer. I brooded quite long about your comments. I like very much your proposal about the "modifier"-category. I hope Alan will agree to the change. I talked to people involved in the DT IMS /NGN implementation concerning some of the issues. Please find the answers/comments in-line. >> - Section 4.3.6 on crisis deleted > > Then why is it still mentioned in REQ-2? I will delete it in the next version.We just missed it when we did the change. > >> - "tone" and "ringback" combination deleted from chapter "Combinations o= f >> URN". >> - Chapter "Combination Rules for Alert URN Indications" upgraded. We >> hope the rules are =A0much more simple now when we distinguish between >> ring tones and ringback tones. > > ---------- > > Section 1: > > =A0 This specification does not change the usage of the SIP Alert-Info- > =A0 header defined in the RFC3261. =A0The Alert-Info-header can be used i= n > =A0 INVITE requests and 180 Ringing responses. > > IMO it would make sense to make an extension to 3261 to permit this heade= r > in any 18x response. This could help resolve issues about what ought to b= e > rendered to the caller in case of 182 or 183. This would be very usefull, but can we do it in this draft? Or we need to wait for 3261bis? > > Section 3: > > =A0 =A0 =A0... =A0The left-most > =A0 =A0 =A0label is called "alert-category" and is separated from right-s= ide > =A0 =A0 =A0of the alert-identifier, the alert-indication, by a semicolon.= .. > > =A0 =A0 =A0 =A0 urn:alert:tone:{tone-indication} > > The text says "semicolon" but the example uses colon, and the ABNF also > shows colon. Agree. It should be "colon". I will change this. > > Section 4: > > The way the word "tone" is used in this section could cause confusion, af= ter > having gone to the trouble of explaining that this mechanism is for > indicating semantic intent that might not be rendered as tones. Its furth= er > confused because section 4.1 PBX Tones are encoded using urn:alert:tone, = but > that 4.2 Service Tones are encoded using urn:alert:service. > > I suggest using some other word than "tone" in cases when audio rendering > may not be used. For example "indication". Perhaps "caller indication" co= uld > be used instead of ringback, and "callee indication" could be used instea= d > of "ring". (Thats in descriptive text. Perhaps the alert-category of "ton= e" > should be changed too, but I'm not ready to propose that yet.) Currently, the category "tone" is curently used only for PBX ring tones (in case of audio rendering). It is somehow confusing, because "service" and "ringback" are also tones. I don't like "tones", either. I thought about changing it to ring-tone or PBX ring-tone, but I didn't do it for the last version because such a change may affect implementations of earlier versions of the draft. I think such changes need a broad agreement before changing the draft. In particular, we need Alan's agreement because the PBX tones is his part. Personally, I would prefer "ring indication" and "ringback indication" to "caller indication" and "callee indication". I think the meaning is more obvious, even if the rendering is not audio. In SIP we also habe 180 Ringing too, independent of the rendering. But this is just a personal preference, I may be wrong . We could ask on the ML what other people think. Another problem I see here is that currently "tone" (or "callee indication" or "ring indication") is currently used only for PBX ring-tones, not for ring tones in general. Somehow we should enable also other kinds of ring tones. We can a) delete the restriction to PBX ring-tones and use e.g. urn:alert:ring-tone:normal also for public networks or b) splitt the "tone" (or which ever new name we choose) category in "pbx ring indications", and "public ring indications" and maybe others. People could then define new ring-tone categories in the future, e.g. "3GPP2 ring indications". c) define the category as a chain consisting of a main-category and sub-categories. , e.g. ring-indication:pbx, ring-indication:public. . The urns would be then urn:alert:ring-tone:pbx:normal, urn:alert:ring-tone:pbx:internal, urn:alert:ring-tone:pbx:external, urn:alert:ring-tone:public:normal . My preference is c), but then we have to change the ABNF Syntax and define the alert-category in chap. 3 as being something like a chain like alert-categoryr=3D top-alert-category *(":" alert-subcategory) top-alert-category =3D "ring-tone"/"ringback"/"service" or "callee-indication"/"caller-indication"/"service" alert-subcategory =3D let-dig [*let-dig-hyp let-dig] I hope I don't run with this into the combination problems again.... > > Sections 4.2.6, 4.2.7, 4.2.8: > > These talk about "this sub-level". But sub-level isn't defined anywhere. > There is "sub-indication" in the ABNF, but the examples given in these > sections don't use that. "Sub-level" is another relic from the old version. I will replace it with "alert indication". "Sub-indication" is no longer used in the current use cases. We (Alan and I) considered the issue, but decided not to delete the sub-indication yet, until the new format is consolidated. For the examples in the draft, it is still correct, just not used th the draft. If we agree to use things like urn:alert:modifier:country:za or urn:alert:ring-tone:pbx:normal we have to change the format anyway. > > These are shown as urn:alert:tone, which means they can only be used for > callee indication, not caller indication. Is that intended? Yes. This is described in chap 7.2, second paragraph. > > I know this might open old wounds, but perhaps it would be better to make > these values simply be sub-indications on those values where it makes sen= se. > But if you don't want to go there I understand. With the sub-indications we had the combination problem.....This is why we changed it. > > Section 4.3: > > Aren't there also country-specific ring tones? (I know the British ones i= n > the movies are different from the American ones.) Should there be provisi= on > for specifying these? See more on this below. Up to now, nobody stated the requirement that they are needed. I asked peopple within DT and they don't see a need for that. The DT ring tone is implemented in each DT end device. (I am not happy with it, but that's it.) There is no specific German ring tone, German carriers have their own ring tone specification, but this specifications are more or less the ITU-T specification on ring tone, with some minor differences. I think it should be possible in principle to define country ring tones, if anyone needs them. With sub-categories we could do this with < urn:alert:modifier:country:za> or just I would avoid defining use cases for which it is very unclear if someone needs them. But we should try to make the syntax as fexible as possible for later use cases. > Why no provision for non-country-specific ringbacks? This is potentially = a > case for customization - perhaps the callee's presence status could be us= ed > by the callee to select an appropriate ringback to the caller. It's true. We have to be change the format to allow more than country ringback tones. I don't have any clear idea how to do it yet. Maybe or < urn:alert:modifier:country:za> if we use sub-categories? Concerning the presence status...I think this is more complex and dedicated presence mechanisms should be used. We may run into privacy and all other issues connected to presence. I would define here as a use case. But it should be possible that people add this later if there is a need for it. > > Section 4.4: > > Are all combinations potentially valid? Or can there be at most one per > category? One per main category. I think we can state this if we use modifiers. > > How about having alert:modifier as a category? Then all the other categor= ies > could be mutually exclusive, and zero or more modifiers would adjust > whatever one was supplied. In that case, priority, zip, and delayed would= be > modifiers. I like the modifier :-). But we have to check with Alan and the Mailing list, because of possoible existing implementations. (Maybe normal also ought to be a modifier, and maybe country code > should also be a modifier - urn:alert:modifier:country:za.) I don't have any opinion yet. > > Section 5: > > I think it would be a good idea to mention something about what a UA shou= ld > do with these in more complex cases: > - alert-info received but in-band media also received > - an invite was forked and the UAC is getting responses from > =A0multiple early dialogs, containing conflicting alert-info > =A0and/or in-band media. > > It occurs to me that in some cases early media should preempt the renderi= ng > of alert-info, but in other cases it should not. Maybe that should be lef= t > to implementor discretion, but maybe there are cases where this should be > deterministic - I haven't thought about it enough to have a firm opinion. This is one of the basic SIP unsolved problems. I don't think we should try to solve here this problem. Every end device, carrier...has his own rules. DT already uses urn:alert:service: call-waiting. If a UE receives it, the user gets the message "This is a waiting call" on the display if a display is there. We have no conflict with early media. Other carrier or end devices can have other rules. > > Rolling all that up into some overall suggestions: > > You have some things that only apply to the "ring", some that only apply = to > the "ringback" and some that apply to both. And then there are things tha= t > can act as modifiers to any of the others. But the distinction between ri= ng > and ringback is redundant with the message it travels in. So how about: > > urn:alert:service:xxx has all the things you have as services plus all th= e > things you have as "tones". In an INVITE external/internal describe the > caller, and in a 18x they describe the callee. Maybe some additional valu= es > that are useful for describing the callee status. > > urn:alert:modifier:xxx where xxx is priority/zip/delayed or country.cc > where cc is a country code. > > Combinations allowed are one service, and one or more distinct modifiers. > (Must be distinct based on top-level.) > I think this would work and makes things quite simple, at least for the use cases we have now. I suppose if there is no service , but a modifier like country.cc, then the default ring or ringback tone are assumed. We also must remove the last paragraph on page 8 because country.cc is a valid tone but country is not. Country is here some kind of modifier type. I see only one problem here, which I don't nknow how to handle.What happens when people add new alert-indications? Just add them to the "service" or "modifier"-category? If so, we have two unstructured lists of alert indications, which may become long with the time. I suppose proxies may want to remove alert-indications which are not relevant for their users, e.g. public carrier would want to remove pbx-specific alert-indications generated at the other end of the network, e.g. internal/external. If there is no simple way to recognize the alert indication which are not relevant for them, they will use white lists and allow exactly the alert identifiers they use within their own domain...I don't this is what we want. But I may be wrong with this. Thanks a lot Laura From dworley@avaya.com Thu Mar 18 11:35:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879303A688F for ; Thu, 18 Mar 2010 11:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Q3EFGD4avy3v for ; Thu, 18 Mar 2010 11:35:35 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 551BC3A6911 for ; Thu, 18 Mar 2010 11:35:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,268,1267419600"; d="scan'208";a="180863171" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Mar 2010 14:35:44 -0400 X-IronPort-AV: E=Sophos;i="4.51,268,1267419600"; d="scan'208";a="443091404" Received: from unknown (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Mar 2010 14:35:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 18 Mar 2010 14:35:43 -0400 From: "WORLEY, DALE R (DALE)" To: Paul Kyzivat , "Patel, Milan" Date: Thu, 18 Mar 2010 14:32:35 -0400 Thread-Topic: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 Thread-Index: AcrGnaRk4mGaShW1Rxipo5Kn2crlVAAK7zLY Message-ID: References: <61CAF342FE1EE34EAC8FB19B765914000D763893@SABRE.InterDigital.com>, <4BA22855.2020407@cisco.com> In-Reply-To: <4BA22855.2020407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 18:35:36 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] But it doesn't alter the reality that the PAI also is intended to make an assertion about the *caller* while some of this other information is about the *call* rather than the caller. For example, how does it make any sense to include * 31 Intercept (trouble) - for calls to directory numbers (DN) that have been manually placed in trouble-busy state by Telco personnel _________________________________________ It's legitimate to add a parameter to the request-URI to modify how the cal= l is routed to its destination, and that covers a number of the CPC cases. = But number 31 above is neither a property of the caller or a modifier of t= he callee, it's a dynamic (!) attribute of the call itself. Also, there ar= e data-domain problems, as presumably the "Intercept (trouble)" status can = be combined with any caller-type, whereas the value 31 erases any informati= on previously recorded in the CPC. Dale From pkyzivat@cisco.com Thu Mar 18 12:09:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FA23A6896 for ; Thu, 18 Mar 2010 12:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.675 X-Spam-Level: X-Spam-Status: No, score=-9.675 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kPWFHCLxiUw for ; Thu, 18 Mar 2010 12:09:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 78A393A67E5 for ; Thu, 18 Mar 2010 12:09:02 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGcXoktAZnwM/2dsb2JhbACbLXOhR5h3hHkE X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="94021241" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Mar 2010 19:09:13 +0000 Received: from [161.44.182.195] (dhcp-161-44-182-195.cisco.com [161.44.182.195]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IJ9DT7029838; Thu, 18 Mar 2010 19:09:13 GMT Message-ID: <4BA27A59.5060109@cisco.com> Date: Thu, 18 Mar 2010 15:09:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, DALE R (DALE)" References: <61CAF342FE1EE34EAC8FB19B765914000D763893@SABRE.InterDigital.com>, <4BA22855.2020407@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH , "Patel, Milan" Subject: Re: [dispatch] FW: New VersionNotification for draft-patel-dispatch-cpc-oli-parameter-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:09:04 -0000 WORLEY, DALE R (DALE) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > > But it doesn't alter the reality that the PAI also is intended to make > an assertion about the *caller* while some of this other information is > about the *call* rather than the caller. > > For example, how does it make any sense to include > > * 31 Intercept (trouble) - for calls to directory numbers (DN) that > have been manually placed in trouble-busy state by Telco > personnel > _________________________________________ > > It's legitimate to add a parameter to the request-URI to modify how the call is routed > to its destination, and that covers a number of the CPC cases. It covers those cases *if* the intended use is to insert those properties that describe the caller into the PAI, and those that describe the callee into the R-URI or To-URI. But I don't get the impression that is the intent. Its explicitly stated the the actual content is intended to be opaque. > But number 31 above is neither a property of the caller or a modifier of the callee, > it's a dynamic (!) attribute of the call itself. Also, there are data-domain problems, > as presumably the "Intercept (trouble)" status can be combined with any caller-type, > whereas the value 31 erases any information previously recorded in the CPC. Yeah, even if you try to sort out those parameters that apply to the caller vs those that apply to the callee, then the rest don't fit anywhere. Thanks, Paul From pkyzivat@cisco.com Thu Mar 18 16:48:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33593A6A4F for ; Thu, 18 Mar 2010 16:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.069 X-Spam-Level: X-Spam-Status: No, score=-8.069 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I6-1zxihq3L for ; Thu, 18 Mar 2010 16:48:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 02E003A69C9 for ; Thu, 18 Mar 2010 16:48:23 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABdYoktAZnwM/2dsb2JhbACPBIwqc6JzmQKCUoInBA X-IronPort-AV: E=Sophos;i="4.51,270,1267401600"; d="scan'208";a="94223164" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2010 23:48:35 +0000 Received: from [161.44.182.195] (dhcp-161-44-182-195.cisco.com [161.44.182.195]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2INmZOw015102; Thu, 18 Mar 2010 23:48:35 GMT Message-ID: <4BA2BBD3.8020702@cisco.com> Date: Thu, 18 Mar 2010 19:48:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> In-Reply-To: <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Liess Laura Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:48:26 -0000 Laura - inline... Laura Liess wrote: > Paul, > > thank you for the comments and please excuse my late answer. I brooded > quite long about your comments. > I like very much your proposal about the "modifier"-category. I hope > Alan will agree to the change. > I talked to people involved in the DT IMS /NGN implementation > concerning some of the issues. > > Please find the answers/comments in-line. > >>> - Section 4.3.6 on crisis deleted >> Then why is it still mentioned in REQ-2? > > I will delete it in the next version.We just missed it when we did > the change. > >>> - "tone" and "ringback" combination deleted from chapter "Combinations of >>> URN". >>> - Chapter "Combination Rules for Alert URN Indications" upgraded. We >>> hope the rules are much more simple now when we distinguish between >>> ring tones and ringback tones. >> ---------- >> >> Section 1: >> >> This specification does not change the usage of the SIP Alert-Info- >> header defined in the RFC3261. The Alert-Info-header can be used in >> INVITE requests and 180 Ringing responses. >> >> IMO it would make sense to make an extension to 3261 to permit this header >> in any 18x response. This could help resolve issues about what ought to be >> rendered to the caller in case of 182 or 183. > > This would be very usefull, but can we do it in this draft? Or we need > to wait for 3261bis? If I put on my (new) sipcore chair hat then I guess I should know the answer to this. But I don't. We aren't planning a bis, but changes are being managed. Will you be in Anaheim? Maybe we can corner a few people and discuss how this might be done. >> Section 3: >> >> ... The left-most >> label is called "alert-category" and is separated from right-side >> of the alert-identifier, the alert-indication, by a semicolon... >> >> urn:alert:tone:{tone-indication} >> >> The text says "semicolon" but the example uses colon, and the ABNF also >> shows colon. > > Agree. It should be "colon". I will change this. >> Section 4: >> >> The way the word "tone" is used in this section could cause confusion, after >> having gone to the trouble of explaining that this mechanism is for >> indicating semantic intent that might not be rendered as tones. Its further >> confused because section 4.1 PBX Tones are encoded using urn:alert:tone, but >> that 4.2 Service Tones are encoded using urn:alert:service. >> >> I suggest using some other word than "tone" in cases when audio rendering >> may not be used. For example "indication". Perhaps "caller indication" could >> be used instead of ringback, and "callee indication" could be used instead >> of "ring". (Thats in descriptive text. Perhaps the alert-category of "tone" >> should be changed too, but I'm not ready to propose that yet.) > > Currently, the category "tone" is curently used only for PBX ring > tones (in case of audio rendering). It is somehow confusing, because > "service" and "ringback" are also tones. I don't like "tones", either. I found it quite disconcerting as I was reading. > I thought about changing it to ring-tone or PBX ring-tone, but I > didn't do it for the last version because such a change may affect > implementations of earlier versions of the draft. I think such changes > need a broad agreement before changing the draft. In particular, we > need Alan's agreement because the PBX tones is his part. > > Personally, I would prefer "ring indication" and "ringback > indication" to "caller indication" and "callee indication". I I was just looking for *something*, and that works as well as my suggestion. > think the meaning is more obvious, even if the rendering is not audio. > In SIP we also habe 180 Ringing too, independent of the rendering. But > this is just a personal preference, I may be wrong . We could ask on > the ML what other people think. > > > Another problem I see here is that currently "tone" (or "callee > indication" or "ring indication") is currently used only for PBX > ring-tones, not for ring tones in general. Somehow we should enable > also other kinds of ring tones. We can > a) delete the restriction to PBX ring-tones and use e.g. > urn:alert:ring-tone:normal also for public networks or > b) splitt the "tone" (or which ever new name we choose) category in > "pbx ring indications", and "public ring indications" and maybe > others. People could then define new ring-tone categories in the > future, e.g. "3GPP2 ring indications". > c) define the category as a chain consisting of a main-category and > sub-categories. , e.g. ring-indication:pbx, ring-indication:public. . > The urns would be then urn:alert:ring-tone:pbx:normal, > urn:alert:ring-tone:pbx:internal, urn:alert:ring-tone:pbx:external, > urn:alert:ring-tone:public:normal . > > My preference is c), but then we have to change the ABNF Syntax and > define the alert-category in chap. 3 as being something like a chain > like Or, urn:alert:ring-tone:normal.public, urn:alert:ring-tone:normal.pbx, ... That way you can trim components off the end until you find something you understand. The trouble with that is of course that it means that all the "pbx" extensions are not gathered together. If that is a problem. Or, maybe "pbx" is a "modifier". > alert-categoryr= top-alert-category *(":" alert-subcategory) > top-alert-category = "ring-tone"/"ringback"/"service" or > "callee-indication"/"caller-indication"/"service" > alert-subcategory = let-dig [*let-dig-hyp let-dig] > > I hope I don't run with this into the combination problems again.... > > >> Sections 4.2.6, 4.2.7, 4.2.8: >> >> These talk about "this sub-level". But sub-level isn't defined anywhere. >> There is "sub-indication" in the ABNF, but the examples given in these >> sections don't use that. > > "Sub-level" is another relic from the old version. I will replace it > with "alert indication". > "Sub-indication" is no longer used in the current use cases. We (Alan > and I) considered the issue, but decided not to delete the > sub-indication yet, until the new format is consolidated. For the > examples in the draft, it is still correct, just not used th the > draft. If we agree to use things like urn:alert:modifier:country:za > or urn:alert:ring-tone:pbx:normal we have to change the format > anyway. > > >> These are shown as urn:alert:tone, which means they can only be used for >> callee indication, not caller indication. Is that intended? > > Yes. This is described in chap 7.2, second paragraph. > >> I know this might open old wounds, but perhaps it would be better to make >> these values simply be sub-indications on those values where it makes sense. >> But if you don't want to go there I understand. > > With the sub-indications we had the combination problem.....This is > why we changed it. > >> Section 4.3: >> >> Aren't there also country-specific ring tones? (I know the British ones in >> the movies are different from the American ones.) Should there be provision >> for specifying these? See more on this below. > > Up to now, nobody stated the requirement that they are needed. > I asked peopple within DT and they don't see a need for that. The DT > ring tone is implemented in each DT end device. (I am not happy with > it, but that's it.) There is no specific German ring tone, German > carriers have their own ring tone specification, but this > specifications are more or less the ITU-T specification on ring tone, > with some minor differences. > > I think it should be possible in principle to define country ring > tones, if anyone needs them. With sub-categories we could do this with > < > urn:alert:modifier:country:za> or just > > > I would avoid defining use cases for which it is very unclear if > someone needs them. But we should try to make the syntax as fexible as > possible for later use cases. Yes, that is what I am pushing at - leaving enough wiggle room for these sorts of cases to fit later in a natural way. >> Why no provision for non-country-specific ringbacks? This is potentially a >> case for customization - perhaps the callee's presence status could be used >> by the callee to select an appropriate ringback to the caller. > > It's true. We have to be change the format to allow more than country > ringback tones. I don't have any clear idea how to do it yet. Maybe > or > < > urn:alert:modifier:country:za> if we use sub-categories? It seems to me that there ought to be symmetry for ring and ringback. > Concerning the presence status...I think this is more complex and > dedicated presence mechanisms should be used. We may run into privacy > and all other issues connected to presence. I would define here as a > use case. But it should be possible that people add this later if > there is a need for it. I was only using presence as an example of why you might want other sorts of ringbacks. How they would be selected is a whole separate discussion. >> Section 4.4: >> >> Are all combinations potentially valid? Or can there be at most one per >> category? > > One per main category. I think we can state this if we use modifiers. >> How about having alert:modifier as a category? Then all the other categories >> could be mutually exclusive, and zero or more modifiers would adjust >> whatever one was supplied. In that case, priority, zip, and delayed would be >> modifiers. > > I like the modifier :-). But we have to check with Alan and the > Mailing list, because of possoible existing implementations. > > (Maybe normal also ought to be a modifier, and maybe country code >> should also be a modifier - urn:alert:modifier:country:za.) > I don't have any opinion yet. The modifier approach is a different spin on things and needs thinking through. >> Section 5: >> >> I think it would be a good idea to mention something about what a UA should >> do with these in more complex cases: >> - alert-info received but in-band media also received >> - an invite was forked and the UAC is getting responses from >> multiple early dialogs, containing conflicting alert-info >> and/or in-band media. >> >> It occurs to me that in some cases early media should preempt the rendering >> of alert-info, but in other cases it should not. Maybe that should be left >> to implementor discretion, but maybe there are cases where this should be >> deterministic - I haven't thought about it enough to have a firm opinion. > > This is one of the basic SIP unsolved problems. I don't think we > should try to solve here this problem. Every end device, carrier...has > his own rules. DT already uses urn:alert:service: call-waiting. If a > UE receives it, the user gets the message "This is a waiting call" on > the display if a display is there. We have no conflict with early > media. Other carrier or end devices can have other rules. > >> Rolling all that up into some overall suggestions: >> >> You have some things that only apply to the "ring", some that only apply to >> the "ringback" and some that apply to both. And then there are things that >> can act as modifiers to any of the others. But the distinction between ring >> and ringback is redundant with the message it travels in. So how about: >> >> urn:alert:service:xxx has all the things you have as services plus all the >> things you have as "tones". In an INVITE external/internal describe the >> caller, and in a 18x they describe the callee. Maybe some additional values >> that are useful for describing the callee status. >> >> urn:alert:modifier:xxx where xxx is priority/zip/delayed or country.cc >> where cc is a country code. >> >> Combinations allowed are one service, and one or more distinct modifiers. >> (Must be distinct based on top-level.) >> > > I think this would work and makes things quite simple, at least for > the use cases we have now. I suppose if there is no service , but a > modifier like country.cc, then the default ring or ringback tone are > assumed. Right. > We also must remove the last paragraph on page 8 because > country.cc is a valid tone but country is not. Country is here some > kind of modifier type. > I see only one problem here, which I don't nknow how to handle.What > happens when people add new alert-indications? Just add them to the > "service" or "modifier"-category? If so, we have two unstructured > lists of alert indications, which may become long with the time. I It should be possible to add some hierarchy to help organize this. > suppose proxies may want to remove alert-indications which are not > relevant for their users, e.g. public carrier would want to remove > pbx-specific alert-indications generated at the other end of the > network, e.g. internal/external. If there is no simple way to > recognize the alert indication which are not relevant for them, they > will use white lists and allow exactly the alert identifiers they use > within their own domain...I don't this is what we want. But I may be > wrong with this. I haven't thought about this. You are ahead of me. Thanks, Paul From laura.liess.dt@googlemail.com Fri Mar 19 05:43:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAC93A6938 for ; Fri, 19 Mar 2010 05:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=-2.165, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaS9EUBgbPOl for ; Fri, 19 Mar 2010 05:43:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B89533A68FC for ; Fri, 19 Mar 2010 05:43:02 -0700 (PDT) Received: by wwg30 with SMTP id 30so729486wwg.31 for ; Fri, 19 Mar 2010 05:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=40li8kITrSA04aBuWxVW+DImReXt4eBIeY9gxDs3NyQ=; b=eEz1277ldbYQB8PyyCpEyIXUntGeIhYzoGs3sRtZ9ur2LDyStzLbvKF+BOuzkTeiyW 8CJ54GpC0dXMoAfFkhs+t50QMhME5RLC1YOQJwT/iH6LrINejwMbwrUU1fW5DscdApRs CdTVzWbpSz85V760k5VK1EIhb2PMfhlfxoWvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZJtBT7i8F8zmK9cBYDpqYn1eEZNfywvSMOW2GOAhHtT7mcyxWf1LxnyuEJEWtzl9n2 hmoV/jG2WrIDKA8znaYkYapzH73Kg8qrR+rwhgHYDjVrKJzQs/wHAl3vC5bXZd8mO6+y RWUhMnCgtGoOJaRDAsZ7nen078UY/UOj7FSBA= MIME-Version: 1.0 Received: by 10.216.179.18 with SMTP id g18mr1344094wem.52.1269002592276; Fri, 19 Mar 2010 05:43:12 -0700 (PDT) In-Reply-To: <4BA2BBD3.8020702@cisco.com> References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> Date: Fri, 19 Mar 2010 13:43:12 +0100 Message-ID: <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> From: Laura Liess To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Gerold Pinker , Liess Laura Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 12:43:05 -0000 2010/3/19 Paul Kyzivat : > Laura - inline... > > Laura Liess wrote: >> >> Paul, >> >> thank you for the comments and please excuse my late answer. I brooded >> quite long about your comments. >> I like very much your proposal about the "modifier"-category. I hope >> Alan will agree to the change. >> I talked to people involved in the DT IMS /NGN implementation >> concerning some of the issues. >> >> Please find the answers/comments in-line. >> >>>> - Section 4.3.6 on crisis deleted >>> >>> Then why is it still mentioned in REQ-2? >> >> =A0I will delete it in the next version.We just missed it when we did >> the change. >> >>>> - "tone" and "ringback" combination deleted from chapter "Combinations >>>> of >>>> URN". >>>> - Chapter "Combination Rules for Alert URN Indications" upgraded. We >>>> hope the rules are =A0much more simple now when we distinguish between >>>> ring tones and ringback tones. >>> >>> ---------- >>> >>> Section 1: >>> >>> =A0This specification does not change the usage of the SIP Alert-Info- >>> =A0header defined in the RFC3261. =A0The Alert-Info-header can be used = in >>> =A0INVITE requests and 180 Ringing responses. >>> >>> IMO it would make sense to make an extension to 3261 to permit this >>> header >>> in any 18x response. This could help resolve issues about what ought to >>> be >>> rendered to the caller in case of 182 or 183. >> >> This would be very usefull, but can we do it in this draft? Or we need >> to wait for 3261bis? > > If I put on my (new) sipcore chair hat then I guess I should know the ans= wer > to this. But I don't. We aren't planning a bis, but changes are being > managed. Will you be in Anaheim? Maybe we can corner a few people and > discuss how this might be done. This would be great. I will be in Anaheim. > >>> Section 3: >>> >>> =A0 =A0 ... =A0The left-most >>> =A0 =A0 label is called "alert-category" and is separated from right-si= de >>> =A0 =A0 of the alert-identifier, the alert-indication, by a semicolon..= . >>> >>> =A0 =A0 =A0 =A0urn:alert:tone:{tone-indication} >>> >>> The text says "semicolon" but the example uses colon, and the ABNF also >>> shows colon. >> >> Agree. It should be "colon". I will change this. >>> >>> Section 4: >>> >>> The way the word "tone" is used in this section could cause confusion, >>> after >>> having gone to the trouble of explaining that this mechanism is for >>> indicating semantic intent that might not be rendered as tones. Its >>> further >>> confused because section 4.1 PBX Tones are encoded using urn:alert:tone= , >>> but >>> that 4.2 Service Tones are encoded using urn:alert:service. >>> >>> I suggest using some other word than "tone" in cases when audio renderi= ng >>> may not be used. For example "indication". Perhaps "caller indication" >>> could >>> be used instead of ringback, and "callee indication" could be used >>> instead >>> of "ring". (Thats in descriptive text. Perhaps the alert-category of >>> "tone" >>> should be changed too, but I'm not ready to propose that yet.) >> >> Currently, the category "tone" is curently used only for PBX ring >> tones (in case of audio rendering). It is somehow confusing, because >> "service" and "ringback" are also tones. I don't like "tones", either. > > I found it quite disconcerting as I was reading. > >> I thought about changing it to ring-tone or PBX ring-tone, but I >> didn't do it for the last version because such a change may affect >> implementations of earlier versions of the draft. I think such changes >> need a broad agreement before changing the draft. In particular, we >> need Alan's agreement because the PBX tones is his part. >> >> Personally, I would prefer "ring indication" =A0and "ringback >> indication" =A0to =A0 "caller indication" and =A0"callee indication". I > > I was just looking for *something*, and that works as well as my suggesti= on. > >> think the meaning is more obvious, even if the rendering is not audio. >> In SIP we also habe 180 Ringing too, independent of the rendering. But >> this is just a personal preference, I may be wrong . =A0We could ask on >> the ML what other people think. >> >> >> Another problem I see here is that currently "tone" (or "callee >> indication" or "ring indication") is currently used only for PBX >> ring-tones, not for ring tones in general. Somehow we should enable >> also other kinds of ring tones. We can >> a) delete the restriction to PBX ring-tones and use e.g. >> urn:alert:ring-tone:normal also for public networks or >> b) splitt the "tone" (or which ever new name we choose) category in >> "pbx ring indications", and =A0"public ring indications" and maybe >> others. People could then define new ring-tone categories in the >> future, =A0e.g. "3GPP2 ring indications". >> c) define the category as a chain consisting of a main-category and >> sub-categories. , e.g. ring-indication:pbx, =A0ring-indication:public. . >> The urns would be then urn:alert:ring-tone:pbx:normal, >> urn:alert:ring-tone:pbx:internal, =A0urn:alert:ring-tone:pbx:external, >> urn:alert:ring-tone:public:normal . >> >> My preference is c), but then we have to change the ABNF Syntax and >> define the alert-category in chap. 3 as being something like a chain >> like > > Or, urn:alert:ring-tone:normal.public, urn:alert:ring-tone:normal.pbx, ..= . > > That way you can trim components off the end until you find something you > understand. > > The trouble with that is of course that it means that all the "pbx" > extensions are not gathered together. If that is a problem. We need something which helps proxies to decide quickly e.g. if it is a public or pbx alert indication. > > Or, maybe "pbx" is a "modifier". I would put "pbx" in both "ring-indication" fand "modifier" alert-indications. External/internal are pbx "ring-indication" and priority/zip/delayed are pbx modifiers. > >> alert-categoryr=3D top-alert-category =A0*(":" alert-subcategory) >> =A0top-alert-category =3D "ring-tone"/"ringback"/"service" =A0or >> "callee-indication"/"caller-indication"/"service" >> alert-subcategory =3D let-dig [*let-dig-hyp =A0let-dig] >> >> I hope I don't run with this into the combination problems again.... >> >> >>> Sections 4.2.6, 4.2.7, 4.2.8: >>> >>> These talk about "this sub-level". But sub-level isn't defined anywhere= . >>> There is "sub-indication" in the ABNF, but the examples given in these >>> sections don't use that. >> >> "Sub-level" is another relic from the old version. I will replace it >> with "alert indication". >> "Sub-indication" =A0is no longer used in the current use cases. We (Alan >> and I) considered the issue, but decided not to delete the >> sub-indication yet, until the new format is consolidated. =A0For the >> examples in the draft, it is still correct, just not used th the >> draft. If we agree to use things like urn:alert:modifier:country:za >> or =A0urn:alert:ring-tone:pbx:normal we have to change the format >> anyway. >> >> >>> These are shown as urn:alert:tone, which means they can only be used fo= r >>> callee indication, not caller indication. Is that intended? >> >> Yes. This is described in chap 7.2, second paragraph. >> >>> I know this might open old wounds, but perhaps it would be better to ma= ke >>> these values simply be sub-indications on those values where it makes >>> sense. >>> But if you don't want to go there I understand. >> >> With the sub-indications we had the combination problem.....This is >> why we changed it. >> >>> Section 4.3: >>> >>> Aren't there also country-specific ring tones? (I know the British ones >>> in >>> the movies are different from the American ones.) Should there be >>> provision >>> for specifying these? See more on this below. >> >> Up to now, nobody stated the requirement that they are needed. >> I asked peopple within DT and they don't see a need for that. The DT >> ring tone is implemented in each DT end device. (I am not happy with >> it, but that's it.) There is no specific German ring tone, German >> carriers have their own ring tone specification, but this >> specifications are more or less the ITU-T specification on ring tone, >> with some minor differences. >> >> I think it should be possible in principle to define country ring >> tones, if anyone needs them. With sub-categories we could do this with >> < >> urn:alert:modifier:country:za> or just >> >> >> I would avoid defining use cases for which it is very unclear if >> someone needs them. But we should try to make the syntax as fexible as >> possible for later use cases. > > Yes, that is what I am pushing at - leaving enough wiggle room for these > sorts of cases to fit later in a natural way. > >>> Why no provision for non-country-specific ringbacks? This is potentiall= y >>> a >>> case for customization - perhaps the callee's presence status could be >>> used >>> by the callee to select an appropriate ringback to the caller. >> >> It's true. We have to be change the format to allow more than country >> ringback tones. I don't have any clear idea how to do it yet. Maybe >> =A0or >> < >> urn:alert:modifier:country:za> if we use sub-categories? > > It seems to me that there ought to be symmetry for ring and ringback. Agree. > >> Concerning the presence status...I think this is more complex and >> dedicated presence mechanisms should be used. We may run into privacy >> and all other issues connected to presence. I would define here as a >> use case. But it should be possible that people add this later if >> there is a need for it. > > I was only using presence as an example of why you might want other sorts= of > ringbacks. How they would be selected is a whole separate discussion. > >>> Section 4.4: >>> >>> Are all combinations potentially valid? Or can there be at most one per >>> category? >> >> One per main category. I think we can state this if we use modifiers. >>> >>> How about having alert:modifier as a category? Then all the other >>> categories >>> could be mutually exclusive, and zero or more modifiers would adjust >>> whatever one was supplied. In that case, priority, zip, and delayed wou= ld >>> be >>> modifiers. >> >> I like the modifier :-). But we have to check with Alan and the >> Mailing list, because of possoible existing implementations. >> >> =A0(Maybe normal also ought to be a modifier, and maybe country code >>> >>> should also be a modifier - urn:alert:modifier:country:za.) >> >> I don't have any opinion yet. > > The modifier approach is a different spin on things and needs thinking > through. > >>> Section 5: >>> >>> I think it would be a good idea to mention something about what a UA >>> should >>> do with these in more complex cases: >>> - alert-info received but in-band media also received >>> - an invite was forked and the UAC is getting responses from >>> =A0multiple early dialogs, containing conflicting alert-info >>> =A0and/or in-band media. >>> >>> It occurs to me that in some cases early media should preempt the >>> rendering >>> of alert-info, but in other cases it should not. Maybe that should be >>> left >>> to implementor discretion, but maybe there are cases where this should = be >>> deterministic - I haven't thought about it enough to have a firm opinio= n. >> >> This is one of the basic SIP unsolved problems. I don't think we >> should try to solve here this problem. Every end device, carrier...has >> his own rules. DT already uses urn:alert:service: call-waiting. If a >> UE receives it, the user gets the message "This is a waiting call" =A0on >> the display if a display is there. We have no conflict with early >> media. Other carrier or end devices can have other rules. >> >>> Rolling all that up into some overall suggestions: >>> >>> You have some things that only apply to the "ring", some that only appl= y >>> to >>> the "ringback" and some that apply to both. And then there are things >>> that >>> can act as modifiers to any of the others. But the distinction between >>> ring >>> and ringback is redundant with the message it travels in. So how about: >>> >>> urn:alert:service:xxx has all the things you have as services plus all >>> the >>> things you have as "tones". In an INVITE external/internal describe the >>> caller, and in a 18x they describe the callee. Maybe some additional >>> values >>> that are useful for describing the callee status. >>> >>> urn:alert:modifier:xxx where xxx is priority/zip/delayed or country.cc >>> where cc is a country code. >>> >>> Combinations allowed are one service, and one or more distinct modifier= s. >>> (Must be distinct based on top-level.) >>> >> >> I think this would work and makes things quite simple, at least for >> the use cases we have now. =A0 =A0I suppose if there is no service , but= a >> modifier like country.cc, then the default ring or ringback tone are >> assumed. > > Right. > >> We also must remove the last paragraph on page 8 because >> country.cc is a valid tone but country is not. =A0 Country is here some >> kind of modifier type. >> I see only one problem here, which I don't know how to handle.What >> happens when people add new alert-indications? Just add them to the >> "service" or "modifier"-category? If so, we have two unstructured >> lists of alert indications, which may become long with the time. I > > It should be possible to add some hierarchy to help organize this. > >> suppose proxies may want to remove alert-indications which are not >> relevant for their users, e.g. public carrier would want to remove >> pbx-specific alert-indications generated at the other end of the >> network, e.g. internal/external. =A0If there is no simple way to >> recognize the alert indication which are not relevant for them, they >> will use white lists and allow exactly the alert identifiers they use >> within their own domain...I don't this is what we want. =A0But I may be >> wrong with this. > > I haven't thought about this. You are ahead of me. There are some, probably few scenarios where filters are necessary. E.g. an ED outside a PBX network sends "internal", just to get quick phone access to a person inside an enterprise. The carrier or the enterprise proxy should remove it, otherwise the callee gets a wrong information. (maybe this is a security issue?) I would like to have the structure which allows filtering which does not force filtering proxies to use white lists consisting of discrete values, other methods beeing too time consuming. Let's have a chat in Anaheim about this. Thanks a lot Laura > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > From pkyzivat@cisco.com Fri Mar 19 12:06:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B803A6980 for ; Fri, 19 Mar 2010 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.606 X-Spam-Level: X-Spam-Status: No, score=-9.606 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exA+Jur1Jm2J for ; Fri, 19 Mar 2010 12:06:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 625F13A67F8 for ; Fri, 19 Mar 2010 12:06:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPdno0tAZnwM/2dsb2JhbACbPnOhRph2hHoE X-IronPort-AV: E=Sophos;i="4.51,276,1267401600"; d="scan'208";a="94340046" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2010 19:06:47 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2JJ6l2C023722; Fri, 19 Mar 2010 19:06:47 GMT Message-ID: <4BA3CB47.9090607@cisco.com> Date: Fri, 19 Mar 2010 15:06:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Greger Viken Teigre References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4BA13444.6010709@teigre.com> In-Reply-To: <4BA13444.6010709@teigre.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:06:36 -0000 Greger Viken Teigre wrote: > On 15.03.2010 17:24, Adam Roach wrote: >> On 3/15/10 11:09, Mar 15, Paul Kyzivat wrote: >>> >>> >>> Adam Roach wrote: >>>> Greger: >>>> >>>> For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) >>>> provide about 80% of what you're asking for. >>> >>> Selecting a *UAS* that has the capabilities the caller envisions >>> using (such as video) were certainly among the things that were among >>> the intended use cases. >>> >>> I'm dubious about their suitability for selecting a route to reach >>> the UAS, assuming its the same UAS you are seeking. >> >> That's the other 20%. :) > > Yes, the toolset is there. Making it work in a multi-vendor, > multi-party, multi-capability UA environment is far away. I can't follow what this means after a couple of replies. The Accept-Contact for callerprefs is specific to selecting among registered contacts that have hopefully been tagged with callee capabilities. For use by an intermediary, at best it might be able to associate callee capabilities to alternative paths (presumably via configuration) and then apply the Accept-Contact rules to those to help choose the path. For instance, I guess a proxy that is choosing between a TDM gateway and a "sip trunk" might give the TDM gateway a minimal set of capabilities, including voice, and then perhaps give the sip trunk none, which would cause it to do presumed matching. But is anybody going to implement callerprefs in routing proxies? >>> Also callerprefs are no guarantee (not even a superset) of the >>> capabilities that will be used on a call. It is an entirely >>> reasonable use case for a UAC to invite with no offer, and then >>> negotiate the use of voice and video because the UAS offers that. Its >>> also entirely reasonable for a call to start out as audio only, for >>> the caller and callee to learn as a result of discussion that both >>> are video capable, and then add video to the call. >>> >>> As non-voice media become more mainstream, and as e2e sip sessions >>> become more feasible, we should be investigating how the >>> infrastructure can avoid breaking these kinds of use cases. Nailing >>> down the route in a way that precludes use of media not announced at >>> call establishment time isn't going in a very helpful direction. >> >> Nailing down a route... for signaling? I'm a bit confused about how >> that is going to preclude certain media types. > > I'm not sure I'm following this, but a video phone will for example be > able to make PSTN calls over one peering relationship, high-def > voice/AAC-LD over another, and video over a third. If the original call > was to a URI with hunt functionality forking across all three, it's > pretty random where the call will end up and any attempt with no offer > or renegotiate to video afterwards is not likely to work very well from > a user perspective. And the solution is ...? IMO its really bad to infer only basic voice except in cases where SDP is present in the invite and specifies non-basic media. *Maybe* callerprefs could help, using the approach I mention above. My simplistic answer is that if the R-URI is sip:... then the gateway ought to be last resort. If the R-URI is tel:... then it means I only expect telephone functionality via any sort of protocol that supports that, so you should feel free to use the GW as your first choice, if you wish. Thanks, Paul From lendl@nic.at Fri Mar 19 13:29:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E29A3A6929 for ; Fri, 19 Mar 2010 13:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGb1jN3ZDzet for ; Fri, 19 Mar 2010 13:29:27 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 52B283A68EF for ; Fri, 19 Mar 2010 13:29:26 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 481AC4CE43 for ; Fri, 19 Mar 2010 21:29:38 +0100 (CET) Message-ID: <4BA3DEB4.3060502@nic.at> Date: Fri, 19 Mar 2010 21:29:40 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <4BA13C64.80908@teigre.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F6787@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01213F6787@srvxchg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 20:29:28 -0000 On 18.03.2010 15:58, Daryl Malas wrote: > Are there any other thoughts on "Speermint-izing" this work? --Daryl > It's IMHO the right place to go. btw, you might also want to take a look at http://tools.ietf.org/id/draft-lendl-enum-sip-lr-00.txt and the ideas (routing vs. retargetting) referenced there. I haven't followed up on what happened to rosenberg-sip-ua-loose-route in the end, but looking at your problem from that PoV might be instructive. May next week's meeting be a productive one. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From gonzalo.camarillo@ericsson.com Sun Mar 21 14:39:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B245F3A6935 for ; Sun, 21 Mar 2010 14:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnQUF7ZOHHD8 for ; Sun, 21 Mar 2010 14:39:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 01D9A3A6927 for ; Sun, 21 Mar 2010 14:39:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-63-4ba6921cd55e Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7F.51.23532.C1296AB4; Sun, 21 Mar 2010 22:39:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 22:38:33 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 22:38:33 +0100 Received: from [131.160.126.142] (rvi2-126-142.lmf.ericsson.se [131.160.126.142]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4D9482702; Sun, 21 Mar 2010 23:21:40 +0200 (EET) Message-ID: <4BA68DE2.2010409@ericsson.com> Date: Sun, 21 Mar 2010 14:21:38 -0700 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Paul Kyzivat References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> In-Reply-To: <4BA2BBD3.8020702@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2010 21:38:33.0764 (UTC) FILETIME=[DB492640:01CAC93E] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , Laura Liess , Liess Laura Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 21:39:29 -0000 Hi, >> This would be very usefull, but can we do it in this draft? Or we need >> to wait for 3261bis? > > If I put on my (new) sipcore chair hat then I guess I should know the > answer to this. But I don't. We aren't planning a bis, but changes are > being managed. Will you be in Anaheim? Maybe we can corner a few people > and discuss how this might be done. we have approved a few specs that update RFC 3261. So, if needed, it is possible to update it without issues a bis draft. Cheers, Gonzalo From ranjit@motorola.com Mon Mar 22 10:23:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFDE3A6B2B for ; Mon, 22 Mar 2010 10:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.572 X-Spam-Level: X-Spam-Status: No, score=-4.572 tagged_above=-999 required=5 tests=[AWL=-1.703, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jl9erVjLnkl for ; Mon, 22 Mar 2010 10:23:01 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 3A5FD3A6A12 for ; Mon, 22 Mar 2010 10:22:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1269278587!8149588!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 1560 invoked from network); 22 Mar 2010 17:23:07 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-5.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Mar 2010 17:23:07 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id o2MHN7D3028120 for ; Mon, 22 Mar 2010 10:23:07 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o2MHN7vx002220 for ; Mon, 22 Mar 2010 12:23:07 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o2MHN5iR002194 for ; Mon, 22 Mar 2010 12:23:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Mar 2010 01:22:42 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BF26B@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B9F6475.2030002@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: AcrE97SxRQxwegjHTZaBVdJ72ODDEQE7CZ8g References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com> <4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com> <4B9F6475.2030002@ericsson.com> From: "Avasarala Ranjit-A20990" To: "Gonzalo Camarillo" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:23:24 -0000 Hi Gonzalo, Paul=20 I have uploaded the updated version of the I-D.=20 It can be accessed from: http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-04 .txt Please review and comment Thanks Regards Ranjit -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Tuesday, March 16, 2010 4:29 PM To: Avasarala Ranjit-A20990 Cc: Paul Kyzivat; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Hi Ranjit, there is a blackout period before IETF meetings in which one cannot submit drafts. Please, submit this version as soon as the blackout period is over and have Paul have a look at it so that he can confirm he is happy with it. Thanks, Gonzalo On 11/03/2010 8:10 PM, Avasarala Ranjit-A20990 wrote: > Hi All >=20 > I am not able to upload the updated version (-04) of the I-D due to=20 > some issue with the I-D submission tool - (Says I can submit I-D only=20 > on 2010-03-22). > Until then I am attaching a copy of the updated version (txt and html=20 > formats). >=20 > Please review and comment. >=20 > Thanks >=20 > Note: Let me know if there is any other way to upload the I-D document > and will be happy to do it. >=20 >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 7:19 PM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 > I think this all sounds good now. >=20 > Thanks, > Paul >=20 > Avasarala Ranjit-A20990 wrote: >> Inline >> >> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, March 02, 2010 2:16 AM >> To: Avasarala Ranjit-A20990 >> Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org >> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review >> ofdraft-avasarala-dispatch-comm-div-notification-03] >> >> inline... >> >> Avasarala Ranjit-A20990 wrote: >> >>> I'm still a little confused here. >>> If phone is on and subscription is active, then in general=20 >>> notification should be possible, regardless of registration. I=20 >>> realize >> >>> IMS doesn't permit that, but from a general standard perspective we=20 >>> shouldn't assume it. The manifestation in this case is that the=20 >>> NOTIFY >> >>> would fail and the subscription would eventually be torn down. >>> >>> So I think the cases are: >>> - there is a subscription and notification works >>> - there is a subscription but notification fails >>> - there is no subscription. >>> >>> Agreed. Actually instead of calling it as=20 >>> Notification fails, we can say - not sending notification due to (1) >>> no match of filter criteria (2) phone not registered or outside=20 >>> coverage area due to which there is no connectivity and hence=20 >>> notification cannot be sent Anyway if no subscription, no >> notification. >> >> Are you suggesting that you might have a subscription, and have the=20 >> filter criteria met, and yet not attempt to send a NOTIFY because the >> phone is not registered or has no network connectivity??? >> >> That seems wrong. ISTM that either you would remove the subscription, >> or else you would try to send the NOTIFY and then discover that it > fails. >> >> yes the subscription could be removed when the device=20 >> is >=20 >> not reachable. >> >> OTOH, this probably ought not to be within scope of what is discussed >> in this draft. >> >> yes true not within the scope of this draft. >> >>>> [3] in the example u suggested where sip:alice@atlanta.org with two >>>> contacts: sip:line1@alice.office.atlanta.com and=20 >>>> sip:line2@alice.home.atlanta.com and >>>> both the phones ring, then it would be a case of parallel >> forking. >>>> Now say one or both the phones have set diversion rules, to divert=20 >>>> the >>> In this case, what does it mean for "one or both phones have set=20 >>> diversion rules"? Does that somehow imply distinct rules for each >> phone? >>> I don't see how that could work. Aren't the diversion rules for the=20 >>> *AOR*? >>> >>> Yes the diversion rules are for AoR. So when there=20 >>> is >> >>> a diversion rule set for the AoR and when diversions occur, the=20 >>> notifications are Sent to the AoR. >> >> Not sent to the AoR - sent to the remote contact of the dialog for=20 >> each subscription to the AoR. Same point as below that you agreed > with. >> >> Yes agree with u. >> >>> I see they could be set/changed from either phone. But its a single=20 >>> set of rules isn't it? So I might set the rules from the office, and >>> then cancel them from home. >>> >>> yes single set and could be set from either of the=20 >>> phones. True. >>> >>>> call to say >>>> sip:voicemail@alice.atlanta.com, then the notifications would=20 >>>> get >> >>>> generated with respect to both the contacts. >>> Again I'm confused by the terminology you use, and how it relates=20 >>> operationally. The diversion happens on the AOR, and the=20 >>> subscriptions >> >>> are on the AOR, and the notifications are sent to the subscribers. I >>> don't see where the registered contacts enter into the picture at > all. >>> >>> Ya agree with you on this. Sorry for the confusion. >>> >>> If you have something else in mind, I hope you can explain it better >>> in the draft. >>> >>>> [4] Yes the value of N is configurable and depends on how many=20 >>>> diversions the subscribe wants to keep or could be dependent on=20 >>>> server policy (some maximum >>>> number). If the server policy is to send notifications as and=20 >>>> when they occur and not keep any divsersions information, then the=20 >>>> value of last N >>>> diversions will be zero. But if the server chooses to retain=20 >>>> the >=20 >>>> last diversion always, then the value of N will be 1 and so on. >>> All is straightforward for N>=3D1. >>> >>> For N=3D0 things are messy. If we are modeling this as state, and=20 >>> notifications are about state changes, then the new diversion is=20 >>> added >> >>> to the (previously empty) state and that triggers notifications to=20 >>> all >> >>> current subscriptions. Then if you don't want to retain even this=20 >>> much >> >>> state (because N=3D0) you immediately remove that version from the >> state. >>> But that is again a state change, so you end up with another=20 >>> notification of that state change. >>> >>> True. Actually the notifications are for informing=20 >>> the subscriber of the call diversions that happen. The notifications >>> are not for informing the subscriber of state changes in the=20 >>> notifier >=20 >>> or the number of diversions that occurred. As I mentioned in the=20 >>> abstract as well as 24.604, the main intent of CDIVN service is to=20 >>> inform the subscribers of communication diversions that occur on=20 >>> their >> >>> behalf in the network and this information will help them manage=20 >>> their >> >>> rules better. >> >> I am not certain, but think we may still be talking past one another=20 >> to some extent. >> >> The state can be considered just a formalism for defining the service >> clearly, regardless of whether it has intrinsic value to the CDIV=20 >> service. But it *is* a formalism. So if it is introduced, then its=20 >> behavior can't be ignored when inconvenient. Defining the state with=20 >> N=3D0 leads to some undesired behavior. The simplest way around that = is >> to insist that N be >=3D1. >> >> Ok in that case we can say that value of N >=3D1 and = the=20 >> notifier has always maintains history of last diversion at a minimu. >> It can maintain more than 1 too depending on the policy. >> >> If its important to you that no state be retained once a notification >> has been sent about the most recent diversion, then you will have to=20 >> find some other way to specify the service, that still meets the=20 >> expectations of 3265. I don't know if there is anything there that=20 >> Adam would consider valid. We will have to get his opinion on that. >> >> In that case I am OK maintaining the hostory of=20 >> diversions that occurred as part of state information and retaining=20 >> that state even after the notification for that diversion is sent -=20 >> so >=20 >> that in case I do not get a confirmation, I would be able to re-send > the notification. >> Also maintaining state of diversions would help when the=20 >> notifications >=20 >> need to sent only at a particular time (if fikter criteria mentions > it). >> >> >> Thanks, >> Paul >> >>> But if we want to include the information related=20 >>> to >=20 >>> how many diversions have happened till time (say from 12 AM ) till=20 >>> the >> >>> time the notification is being sent, then as you say we can store=20 >>> the >=20 >>> diversions. This would be useful when the subscriber specifies in=20 >>> the >=20 >>> filter criteria to send notifications only during certain time like=20 >>> between 5 and 6 PM and not whenever a diversion occurs. Then N is=20 >>> grater than 1. >> >>> I presume you don't want that behavior. If you can live with N>=3D1=20 >>> then >> >>> we don't have the problem at all. If you need to support N=3D0 and=20 >>> don't >> >>> want the extra notify, then we have to figure out if there is some=20 >>> trick to how things are modeled to get the desired effect. I've=20 >>> suggested something previously, but Adam didn't like it. >>> >>> This needs sorting out. >>> >>> Thanks, >>> Paul >> From fluffy@cisco.com Tue Mar 23 10:03:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743523A6993; Tue, 23 Mar 2010 10:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.073 X-Spam-Level: X-Spam-Status: No, score=-108.073 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00vRY-3U0OKD; Tue, 23 Mar 2010 10:03:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 500B93A6B89; Tue, 23 Mar 2010 10:03:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAF6RqEurR7Hu/2dsb2JhbACaS15zpAKZL4R9BIMe X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="501521722" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 17:03:54 +0000 Received: from [10.21.75.172] ([10.21.75.172]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2NH3sZ6027183; Tue, 23 Mar 2010 17:03:54 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Cullen Jennings Date: Tue, 23 Mar 2010 10:03:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100323161249.21FDA3A6A55@core3.amsl.com> To: rai@ietf.org, dispatch@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: IETF Discussion List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:03:59 -0000 As discussed at the SIP Forum lunch yesterday, there has been = considerable work on a specification for configuration of SIP User = Agents that is reflected in this document. I believe this document is = appropriate for progression as AD Sponsored thought it may still need a = few changes and discussion of community consensus. To initiate this, I = have requests a 4 week last call.=20 Please, do give this document a read, and as request in the Last Call, = send the email to the ietf@ietf.org list.=20 Thanks,=20 Cullen Begin forwarded message: > From: The IESG > Date: March 23, 2010 9:12:48 AM PDT > To: IETF-Announce > Subject: Last Call: draft-lawrence-sipforum-user-agent-config (Session = Initiation Protocol (SIP) User Agent Configuration) to Informational RFC > Reply-To: ietf@ietf.org >=20 > The IESG has received a request from an individual submitter to = consider=20 > the following document: >=20 > - 'Session Initiation Protocol (SIP) User Agent Configuration ' > as an = Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to = the > ietf@ietf.org mailing lists by 2010-04-20. Exceptionally,=20 > comments may be sent to iesg@ietf.org instead. In either case, please=20= > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > = http://www.ietf.org/internet-drafts/draft-lawrence-sipforum-user-agent-con= fig-00.txt >=20 >=20 > IESG discussion can be tracked via > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=3D= 19859&rfc_flag=3D0 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From krehor@cisco.com Tue Mar 23 20:00:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B9C3A6A2B for ; Tue, 23 Mar 2010 20:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.468 X-Spam-Level: X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww-m9AOulIj9 for ; Tue, 23 Mar 2010 20:00:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0F6C03A6968 for ; Tue, 23 Mar 2010 20:00:49 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIYdqUurR7Ht/2dsb2JhbACDFJctZnOlQIgxkGOEE2oEgx4 X-IronPort-AV: E=Sophos;i="4.51,298,1267401600"; d="scan'208,217";a="171199138" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2010 03:01:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2O318DR008969 for ; Wed, 24 Mar 2010 03:01:08 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 20:01:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACAFE.4073C4A8" Date: Tue, 23 Mar 2010 20:01:08 -0700 Message-ID: <7744FE52C78D944587F03773EB4514610331A941@xmb-sjc-22e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dispatch Digest, Vol 12, Issue 47 Thread-Index: AcrKu0XLQtH5tCeTRbu2k6wgpqPz2QAQvpeI From: "Ken Rehor (krehor)" To: X-OriginalArrivalTime: 24 Mar 2010 03:01:08.0758 (UTC) FILETIME=[40965B60:01CACAFE] Subject: Re: [dispatch] dispatch Digest, Vol 12, Issue 47 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 03:00:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACAFE.4073C4A8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmcgPGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogZGlzcGF0Y2hAaWV0Zi5v cmcgPGRpc3BhdGNoQGlldGYub3JnPg0KU2VudDogVHVlIE1hciAyMyAxMjowMDoxMiAyMDEwDQpT dWJqZWN0OiBkaXNwYXRjaCBEaWdlc3QsIFZvbCAxMiwgSXNzdWUgNDcNCg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZQ0K YXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBp biB5b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0byANCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQpDbGljayB0aGUgJ1Vuc3Vi c2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBsb2cgaW4sIGFuZCBzZXQgIkdldA0KTUlN RSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0byBNSU1FLiAgWW91IGNhbiBzZXQgdGhpcyBvcHRp b24NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlz IHBvaW50Lg0KDQoNCg0KU2VuZCBkaXNwYXRjaCBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8N CglkaXNwYXRjaEBpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRo ZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Rpc3BhdGNoDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1Ympl Y3Qgb3IgYm9keSAnaGVscCcgdG8NCglkaXNwYXRjaC1yZXF1ZXN0QGlldGYub3JnDQoNCllvdSBj YW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KCWRpc3BhdGNoLW93bmVy QGlldGYub3JnDQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5l IHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBkaXNwYXRjaCBk aWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIEZ3ZDogTGFzdCBDYWxsOglk cmFmdC1sYXdyZW5jZS1zaXBmb3J1bS11c2VyLWFnZW50LWNvbmZpZw0KICAgICAgKFNlc3Npb24g SW5pdGlhdGlvbglQcm90b2NvbCAoU0lQKSBVc2VyIEFnZW50IENvbmZpZ3VyYXRpb24pIHRvDQog ICAgICBJbmZvcm1hdGlvbmFsIFJGQyAoQ3VsbGVuIEplbm5pbmdzKQ0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogVHVlLCAyMyBNYXIgMjAxMCAxMDowMzo1NCAtMDcwMA0K RnJvbTogQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAY2lzY28uY29tPg0KU3ViamVjdDogW2Rpc3Bh dGNoXSBGd2Q6IExhc3QgQ2FsbDoNCglkcmFmdC1sYXdyZW5jZS1zaXBmb3J1bS11c2VyLWFnZW50 LWNvbmZpZyAoU2Vzc2lvbiBJbml0aWF0aW9uCVByb3RvY29sDQoJKFNJUCkgVXNlciBBZ2VudCBD b25maWd1cmF0aW9uKSB0byBJbmZvcm1hdGlvbmFsIFJGQw0KVG86IHJhaUBpZXRmLm9yZywgZGlz cGF0Y2hAaWV0Zi5vcmcNCk1lc3NhZ2UtSUQ6IDxCOUVFNTc4QS0wRTIyLTRFREYtQTk0Mi04RTFE RENBOTUzMEZAY2lzY28uY29tPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVz LWFzY2lpDQoNCg0KQXMgZGlzY3Vzc2VkIGF0IHRoZSBTSVAgRm9ydW0gbHVuY2ggeWVzdGVyZGF5 LCB0aGVyZSBoYXMgYmVlbiBjb25zaWRlcmFibGUgd29yayBvbiBhIHNwZWNpZmljYXRpb24gZm9y IGNvbmZpZ3VyYXRpb24gb2YgU0lQIFVzZXIgQWdlbnRzIHRoYXQgaXMgcmVmbGVjdGVkIGluIHRo aXMgZG9jdW1lbnQuIEkgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIGFwcHJvcHJpYXRlIGZvciBw cm9ncmVzc2lvbiBhcyBBRCBTcG9uc29yZWQgdGhvdWdodCBpdCBtYXkgc3RpbGwgbmVlZCBhIGZl dyBjaGFuZ2VzIGFuZCBkaXNjdXNzaW9uIG9mIGNvbW11bml0eSBjb25zZW5zdXMuIFRvIGluaXRp YXRlIHRoaXMsIEkgaGF2ZSByZXF1ZXN0cyBhICA0IHdlZWsgbGFzdCBjYWxsLiANCg0KUGxlYXNl LCBkbyBnaXZlIHRoaXMgZG9jdW1lbnQgYSByZWFkLCBhbmQgYXMgcmVxdWVzdCBpbiB0aGUgTGFz dCBDYWxsLCBzZW5kIHRoZSBlbWFpbCB0byB0aGUgaWV0ZkBpZXRmLm9yZyBsaXN0LiANCg0KVGhh bmtzLCANCkN1bGxlbiA8UkFJIEFEPg0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoN Cj4gRnJvbTogVGhlIElFU0cgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KPiBEYXRlOiBNYXJj aCAyMywgMjAxMCA5OjEyOjQ4IEFNIFBEVA0KPiBUbzogSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5v dW5jZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogTGFzdCBDYWxsOiBkcmFmdC1sYXdyZW5jZS1zaXBm b3J1bS11c2VyLWFnZW50LWNvbmZpZyAoU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IFVzZXIgQWdlbnQgQ29uZmlndXJhdGlvbikgdG8gSW5mb3JtYXRpb25hbCBSRkMNCj4gUmVwbHkt VG86IGlldGZAaWV0Zi5vcmcNCj4gDQo+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg ZnJvbSBhbiBpbmRpdmlkdWFsIHN1Ym1pdHRlciB0byBjb25zaWRlciANCj4gdGhlIGZvbGxvd2lu ZyBkb2N1bWVudDoNCj4gDQo+IC0gJ1Nlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBV c2VyIEFnZW50IENvbmZpZ3VyYXRpb24gJw0KPiAgIDxkcmFmdC1sYXdyZW5jZS1zaXBmb3J1bS11 c2VyLWFnZW50LWNvbmZpZy0wMC50eHQ+IGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDDQo+IA0KPiBU aGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBh bmQgc29saWNpdHMNCj4gZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uICBQbGVhc2Ugc2Vu ZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4gaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxp c3RzIGJ5IDIwMTAtMDQtMjAuIEV4Y2VwdGlvbmFsbHksIA0KPiBjb21tZW50cyBtYXkgYmUgc2Vu dCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgDQo+IHJl dGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVk IHNvcnRpbmcuDQo+IA0KPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxhd3JlbmNlLXNpcGZvcnVtLXVzZXIt YWdlbnQtY29uZmlnLTAwLnR4dA0KPiANCj4gDQo+IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJh Y2tlZCB2aWENCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvcGlkdHJhY2tl ci5jZ2k/Y29tbWFuZD12aWV3X2lkJmRUYWc9MTk4NTkmcmZjX2ZsYWc9MA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSUVURi1Bbm5vdW5j ZSBtYWlsaW5nIGxpc3QNCj4gSUVURi1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg0KDQpDdWxsZW4gSmVubmlu Z3MNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNp c2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRp c3BhdGNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp c3BhdGNoDQoNCg0KRW5kIG9mIGRpc3BhdGNoIERpZ2VzdCwgVm9sIDEyLCBJc3N1ZSA0Nw0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K ------_=_NextPart_001_01CACAFE.4073C4A8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTUuMTAiPg0KPFRJVExFPlJlOiBkaXNwYXRj aCBEaWdlc3QsIFZvbCAxMiwgSXNzdWUgNDc8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0t IENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJSPg0KPEJSPg0KDQo8UD48 Rk9OVCBTSVpFPTI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj4NCkZyb206IGRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmcgJmx0O2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PEJS Pg0KVG86IGRpc3BhdGNoQGlldGYub3JnICZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDs8QlI+DQpT ZW50OiBUdWUgTWFyIDIzIDEyOjAwOjEyIDIwMTA8QlI+DQpTdWJqZWN0OiBkaXNwYXRjaCBEaWdl c3QsIFZvbCAxMiwgSXNzdWUgNDc8QlI+DQo8QlI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUgaW5kaXZpZHVhbCBtZXNzYWdlPEJSPg0KYXR0YWNobWVu dHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxp c3Q8QlI+DQpzdWJzY3JpcHRpb24uJm5ic3A7IFRvIGRvIHNvLCBnbyB0bzxCUj4NCjxCUj4NCjxB IEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2giPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L0E+PEJSPg0KPEJS Pg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGlu LCBhbmQgc2V0ICZxdW90O0dldDxCUj4NCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyZxdW90 OyB0byBNSU1FLiZuYnNwOyBZb3UgY2FuIHNldCB0aGlzIG9wdGlvbjxCUj4NCmdsb2JhbGx5IGZv ciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlzIHBvaW50LjxCUj4NCjxC Uj4NCjxCUj4NCjxCUj4NClNlbmQgZGlzcGF0Y2ggbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRv PEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc3BhdGNo QGlldGYub3JnPEJSPg0KPEJSPg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUg V29ybGQgV2lkZSBXZWIsIHZpc2l0PEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGlzcGF0Y2giPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0 Y2g8L0E+PEJSPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9y IGJvZHkgJ2hlbHAnIHRvPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRpc3BhdGNoLXJlcXVlc3RAaWV0Zi5vcmc8QlI+DQo8QlI+DQpZb3UgY2FuIHJlYWNo IHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzcGF0Y2gtb3duZXJAaWV0Zi5vcmc8QlI+DQo8QlI+ DQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBt b3JlIHNwZWNpZmljPEJSPg0KdGhhbiAmcXVvdDtSZTogQ29udGVudHMgb2YgZGlzcGF0Y2ggZGln ZXN0Li4uJnF1b3Q7PEJSPg0KPEJSPg0KPEJSPg0KVG9kYXkncyBUb3BpY3M6PEJSPg0KPEJSPg0K Jm5ic3A7Jm5ic3A7IDEuIEZ3ZDogTGFzdCBDYWxsOiZuYnNwOyZuYnNwOyBkcmFmdC1sYXdyZW5j ZS1zaXBmb3J1bS11c2VyLWFnZW50LWNvbmZpZzxCUj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAoU2Vzc2lvbiBJbml0aWF0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFByb3RvY29sIChTSVApIFVzZXIgQWdlbnQgQ29uZmlndXJhdGlvbikgdG88QlI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5mb3JtYXRpb25hbCBSRkMgKEN1bGxlbiBK ZW5uaW5ncyk8QlI+DQo8QlI+DQo8QlI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPg0KPEJSPg0KTWVzc2Fn ZTogMTxCUj4NCkRhdGU6IFR1ZSwgMjMgTWFyIDIwMTAgMTA6MDM6NTQgLTA3MDA8QlI+DQpGcm9t OiBDdWxsZW4gSmVubmluZ3MgJmx0O2ZsdWZmeUBjaXNjby5jb20mZ3Q7PEJSPg0KU3ViamVjdDog W2Rpc3BhdGNoXSBGd2Q6IExhc3QgQ2FsbDo8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtbGF3cmVuY2Utc2lwZm9ydW0tdXNlci1hZ2VudC1jb25m aWcgKFNlc3Npb24gSW5pdGlhdGlvbiZuYnNwOyZuYnNwOyBQcm90b2NvbDxCUj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoU0lQKSBVc2VyIEFnZW50IENvbmZp Z3VyYXRpb24pIHRvIEluZm9ybWF0aW9uYWwgUkZDPEJSPg0KVG86IHJhaUBpZXRmLm9yZywgZGlz cGF0Y2hAaWV0Zi5vcmc8QlI+DQpNZXNzYWdlLUlEOiAmbHQ7QjlFRTU3OEEtMEUyMi00RURGLUE5 NDItOEUxRERDQTk1MzBGQGNpc2NvLmNvbSZndDs8QlI+DQpDb250ZW50LVR5cGU6IHRleHQvcGxh aW47IGNoYXJzZXQ9dXMtYXNjaWk8QlI+DQo8QlI+DQo8QlI+DQpBcyBkaXNjdXNzZWQgYXQgdGhl IFNJUCBGb3J1bSBsdW5jaCB5ZXN0ZXJkYXksIHRoZXJlIGhhcyBiZWVuIGNvbnNpZGVyYWJsZSB3 b3JrIG9uIGEgc3BlY2lmaWNhdGlvbiBmb3IgY29uZmlndXJhdGlvbiBvZiBTSVAgVXNlciBBZ2Vu dHMgdGhhdCBpcyByZWZsZWN0ZWQgaW4gdGhpcyBkb2N1bWVudC4gSSBiZWxpZXZlIHRoaXMgZG9j dW1lbnQgaXMgYXBwcm9wcmlhdGUgZm9yIHByb2dyZXNzaW9uIGFzIEFEIFNwb25zb3JlZCB0aG91 Z2h0IGl0IG1heSBzdGlsbCBuZWVkIGEgZmV3IGNoYW5nZXMgYW5kIGRpc2N1c3Npb24gb2YgY29t bXVuaXR5IGNvbnNlbnN1cy4gVG8gaW5pdGlhdGUgdGhpcywgSSBoYXZlIHJlcXVlc3RzIGEmbmJz cDsgNCB3ZWVrIGxhc3QgY2FsbC48QlI+DQo8QlI+DQpQbGVhc2UsIGRvIGdpdmUgdGhpcyBkb2N1 bWVudCBhIHJlYWQsIGFuZCBhcyByZXF1ZXN0IGluIHRoZSBMYXN0IENhbGwsIHNlbmQgdGhlIGVt YWlsIHRvIHRoZSBpZXRmQGlldGYub3JnIGxpc3QuPEJSPg0KPEJSPg0KVGhhbmtzLDxCUj4NCkN1 bGxlbiAmbHQ7UkFJIEFEJmd0OzxCUj4NCjxCUj4NCjxCUj4NCjxCUj4NCkJlZ2luIGZvcndhcmRl ZCBtZXNzYWdlOjxCUj4NCjxCUj4NCiZndDsgRnJvbTogVGhlIElFU0cgJmx0O2llc2ctc2VjcmV0 YXJ5QGlldGYub3JnJmd0OzxCUj4NCiZndDsgRGF0ZTogTWFyY2ggMjMsIDIwMTAgOToxMjo0OCBB TSBQRFQ8QlI+DQomZ3Q7IFRvOiBJRVRGLUFubm91bmNlICZsdDtpZXRmLWFubm91bmNlQGlldGYu b3JnJmd0OzxCUj4NCiZndDsgU3ViamVjdDogTGFzdCBDYWxsOiBkcmFmdC1sYXdyZW5jZS1zaXBm b3J1bS11c2VyLWFnZW50LWNvbmZpZyAoU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IFVzZXIgQWdlbnQgQ29uZmlndXJhdGlvbikgdG8gSW5mb3JtYXRpb25hbCBSRkM8QlI+DQomZ3Q7 IFJlcGx5LVRvOiBpZXRmQGlldGYub3JnPEJSPg0KJmd0OzxCUj4NCiZndDsgVGhlIElFU0cgaGFz IHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIGFuIGluZGl2aWR1YWwgc3VibWl0dGVyIHRvIGNvbnNp ZGVyPEJSPg0KJmd0OyB0aGUgZm9sbG93aW5nIGRvY3VtZW50OjxCUj4NCiZndDs8QlI+DQomZ3Q7 IC0gJ1Nlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBVc2VyIEFnZW50IENvbmZpZ3Vy YXRpb24gJzxCUj4NCiZndDsmbmJzcDsmbmJzcDsgJmx0O2RyYWZ0LWxhd3JlbmNlLXNpcGZvcnVt LXVzZXItYWdlbnQtY29uZmlnLTAwLnR4dCZndDsgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkM8QlI+ DQomZ3Q7PEJSPg0KJmd0OyBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhl IG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHM8QlI+DQomZ3Q7IGZpbmFsIGNvbW1lbnRzIG9u IHRoaXMgYWN0aW9uLiZuYnNwOyBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0 aGU8QlI+DQomZ3Q7IGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDEwLTA0LTIwLiBF eGNlcHRpb25hbGx5LDxCUj4NCiZndDsgY29tbWVudHMgbWF5IGJlIHNlbnQgdG8gaWVzZ0BpZXRm Lm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlPEJSPg0KJmd0OyByZXRhaW4gdGhl IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5n LjxCUj4NCiZndDs8QlI+DQomZ3Q7IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8QlI+DQom Z3Q7IDxBIEhSRUY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxh d3JlbmNlLXNpcGZvcnVtLXVzZXItYWdlbnQtY29uZmlnLTAwLnR4dCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGF3cmVuY2Utc2lwZm9ydW0tdXNlci1hZ2VudC1j b25maWctMDAudHh0PC9BPjxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBJRVNHIGRpc2N1 c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPEJSPg0KJmd0OyA8QSBIUkVGPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL3B1YmxpYy9waWR0cmFja2VyLmNnaT9jb21tYW5kPXZpZXdfaWQmZFRh Zz0xOTg1OSZyZmNfZmxhZz0wIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3B1YmxpYy9w aWR0cmFja2VyLmNnaT9jb21tYW5kPXZpZXdfaWQmZFRhZz0xOTg1OSZyZmNfZmxhZz0wPC9BPjxC Uj4NCiZndDs8QlI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPg0KJmd0OyBJRVRGLUFubm91bmNlIG1haWxpbmcgbGlzdDxCUj4NCiZndDsg SUVURi1Bbm5vdW5jZUBpZXRmLm9yZzxCUj4NCiZndDsgPEEgSFJFRj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2U8L0E+PEJSPg0KPEJSPg0KPEJSPg0KQ3Vs bGVuIEplbm5pbmdzPEJSPg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8 QlI+DQo8QSBIUkVGPSJodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5l c3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwiPmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbDwvQT48QlI+DQo8QlI+DQo8QlI+DQo8 QlI+DQo8QlI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+DQo8QlI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCmRpc3BhdGNo IG1haWxpbmcgbGlzdDxCUj4NCmRpc3BhdGNoQGlldGYub3JnPEJSPg0KPEEgSFJFRj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDwvQT48QlI+DQo8QlI+DQo8QlI+DQpFbmQg b2YgZGlzcGF0Y2ggRGlnZXN0LCBWb2wgMTIsIElzc3VlIDQ3PEJSPg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0K PC9IVE1MPg== ------_=_NextPart_001_01CACAFE.4073C4A8-- From HKaplan@acmepacket.com Wed Mar 24 00:43:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334B33A69DD for ; Wed, 24 Mar 2010 00:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.925 X-Spam-Level: X-Spam-Status: No, score=0.925 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Ba4Dz9Osa+rs for ; Wed, 24 Mar 2010 00:43:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 022EC3A696E for ; Wed, 24 Mar 2010 00:43:45 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 03:44:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 03:43:57 -0400 From: Hadriel Kaplan To: Adam Roach , Paul Kyzivat Date: Wed, 24 Mar 2010 03:43:27 -0400 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrEZdeis6X+RkcqTUGpYgW3gVLLqwGvTP4w Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> In-Reply-To: <4B9E6F60.1040703@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 07:43:47 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Adam Roach > Sent: Monday, March 15, 2010 1:33 PM >=20 > Daryl is working within the strictures of reproducing the business > relationships of the PSTN in a SIP network. And the path that has been > taken, for better or worse, involves the heavy use of SBCs and other > devices that impose a rather strict control on the way things are done. > These devices largely ensure that the media path follows the signaling > path, even when that's not the optimal thing to do.=20 Optimal for whom, and in what way? =20 > The chances of such > networks deploying video, hi-def voice, or any of the other really neat > things that Greger mentions are slim to none. This, of course, is NOT > Daryl's fault. But it's where the egress-route work comes from. You seem to have some very odd (and typical IETF bull) preconceptions about= what SBC's can do or are capable of doing. SBC's in general support video= , HD voice, or any of the other neat things Gregor mentions. Policies prov= isioned on the SBC's may limit what media one can do, or in some cases if t= ranscoding has to happen then obviously you're limited to whatever codecs t= he transcoders can handle (as any media gateway would be), but that's reall= y tangential. =20 > Greger is speaking more towards the network you seem to have in mind -- > one in which end-to-end SIP calls are possible, without SBCs or similar > control boxes clobbering new services and mangling the ability to convey > novel media from one endpoint to another. Networks where we don't need > to define alternate connection models for protocols simply to > accommodate network elements that do things that are explicitly > disallowed by protocol specification. As a B2BUA, what SBC's do is in no way disallowed by the protocols in the I= ETF. (although certainly I don't really care if they are ;) > Which is why I support a simple, non-normative, informational draft > about the form of URLs that one might want to put in ENUM. It satisfies > the requirements of the stagnant world, and doesn't even have any > normative impacts on any protocol anywhere. It's harmless, and lets the > people in the vibrant world concentrate on solving the problem in a more > general way without having to accommodate the peculiarities of network > elements living in the stagnant world. If you live in this "vibrant world" the rest of us don't, what problems are= there that need solving?? Usually one needs users and a population >1 to = have problems. The future always looks rosy compared to the present. -hadriel From HKaplan@acmepacket.com Wed Mar 24 01:13:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569313A6D19 for ; Wed, 24 Mar 2010 01:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVm6U+AspWbk for ; Wed, 24 Mar 2010 01:13:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9B6253A6D12 for ; Wed, 24 Mar 2010 01:12:51 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 04:13:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 04:13:10 -0400 From: Hadriel Kaplan To: Henry Sinnreich , Dean Willis , Adam Roach Date: Wed, 24 Mar 2010 04:12:30 -0400 Thread-Topic: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) Thread-Index: AcrFiQgQw1kkq8FSS0OSa8heIJGjwAFnn7iw Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1CC6@mail> References: <368839EC-1BFD-4115-80DB-E3A9CE4678C3@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79CD1CC6mail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 08:13:35 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79CD1CC6mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not to argue your general tone, but you do realize that most of those thing= s you list were actually generally profitable and successful in their time,= right? Sure their time may be past, but that doesn't mean they were failu= res. I mean I used to be in the IP routing world before coming to voip, an= d SONET was the predominant long-haul transport which actually connected an= d formed the "Internet" in the 90's and early 2000's. I dunno what it is m= ostly today, but I bet there's still tons of it out there. And it's not like there weren't plenty of ultimate-failure companies buildi= ng Ethernet switches or IP routers as well. Or even HTTP browsers. -hadriel p.s. and sadly H.323 ain't dead yet either - for some reason it seems to be= alive and kicking in certain regions of the World, and in certain niche ma= rket segments. ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Henry Sinnreich Sent: Wednesday, March 17, 2010 12:19 AM To: Dean Willis; Adam Roach Cc: dispatch@ietf.org; Daryl Malas Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-= dispatch-sip-egress-route-00) This really sums up the enigma why the IETF should do work that contradicts= every principle of the Internet architecture and its engineering. It may be useful to remember the _solid_ track record of the "stagnant = world" * OSI * X4.00 mail * IN * AIN * ISDN * SONET/SDH * ATM * BISDN * H.323 * current re-incarnations such as PSTN/SIP and other (avoiding flames he= re)... How many companies have disappeared building this stuff? Layoffs. Capital d= estruction. The other enigma is the tolerance to associate the IETF with the reincarnat= ions of these failures. >I have long speculated that perhaps the best thing we can do is punt the "= stagnant world" stuff to a different forum. >I seem to recall many times suggesting that SIP should just be moved to th= e ITU so we can get on with building the Internet. >I'd happily add ENUM to the same bucket. Well said. Thanks, Henry On 3/16/10 5:49 PM, "Dean Willis" wrote: On Mar 16, 2010, at 6:24 PM, Adam Roach wrote: I disagree profoundly with characterizing Rosenberg's Modest Proposal as an appropriate summary of the issues, as it gets the analysis precisely wrong. It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just allowing collateral damage to the vibrant world for the sake of expediency in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant solutions. I have long speculated that perhaps the best thing we can do is punt the "s= tagnant world" stuff to a different forum. I seem to recall many times sugg= esting that SIP should just be moved to the ITU so we can get on with build= ing the Internet. I'd happily add ENUM to the same bucket. The problem is that we might wake up one day and realize that the Internet = has been turned off, and all we have left is a stagnant backwater of teleco= mmunications boundaries established by fat-and-happy politicos eager to pre= serve their own domains. The alternative, perhaps, is to embrace stagnation. Then add chlorine. -- Dean ________________________________ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_430FC6BDED356B4C8498F634416644A91A79CD1CC6mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

 

Not to argue your general tone, but yo= u do realize that most of those things you list were actually generally profitab= le and successful in their time, right?  Sure their time may be past, but that doesn’t mean they were failures.  I mean I used to be in th= e IP routing world before coming to voip, and SONET was the predominant long-hau= l transport which actually connected and formed the “Internet” in= the 90’s and early 2000’s.  I dunno what it is mostly today, b= ut I bet there’s still tons of it out there. 

 

And it’s not like there weren= 217;t plenty of ultimate-failure companies building Ethernet switches or IP route= rs as well.  Or even HTTP browsers.

 

-hadriel

p.s. and sadly H.323 ain’t dead = yet either – for some reason it seems to be alive and kicking in certain regions of the World, and in certain niche market segments.

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Wednesday, March 17, 2= 010 12:19 AM
To: Dean Willis; Adam Roach<= br> Cc: dispatch@ietf.org; Daryl Malas
Subject: Re: [dispatch] War = of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

 

This really sums up the enigma why the IETF should do = work that contradicts every principle of the Internet architecture and its engineering.

It may be useful to remember the  _solid_   track record of = the  "stagnant world"

  • OSI
  • X4.00 mail
  • IN
  • AIN
  • ISDN
  • SONET/SDH
  • ATM
  • BISDN
  • H.323
  • current re-incarnations such as PSTN/SIP a= nd other (avoiding flames here)...

How many companies have disappeared building this stuff? Layoffs. Capital destruction.

The other enigma is the tolerance to associate the IETF with the reincarnat= ions of these failures.

>I have long speculated that perhaps the best thing we can do is punt th= e "stagnant world" stuff to a different forum.
>I seem to recall many times suggesting that SIP should just be moved to= the ITU so we can get on with building the Internet.
>I'd happily add ENUM to the same bucket.

Well said.

Thanks, Henry


On 3/16/10 5:49 PM, "Dean Willis" <dean.willis@softarmor.com> wrote:=


On Mar 16, 2010, at 6:24 PM, Adam Roach wrote:


I disagree profoundly with characterizing Rosenberg's Modest Proposal as an
appropriate summary of the issues, as it gets the analysis precisely wrong.=
It proposes completely abandoning the vibrant world as a lost cause, and embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency<= br> in stagnant world solutions -- it's a suggestion that we nuke the vibrant world so it doesn't keep annoying people trying to develop stagnant
solutions.


I have long speculated that perhaps the best thing we can do is punt the "stagnant world" stuff to a different forum. I seem to recall man= y times suggesting that SIP should just be moved to the ITU so we can get on = with building the Internet. I'd happily add ENUM to the same bucket.

The problem is that we might wake up one day and realize that the Internet = has been turned off, and all we have left is a stagnant backwater of telecommunications boundaries established by fat-and-happy politicos eager = to preserve their own domains.

The alternative, perhaps, is to embrace stagnation. Then add chlorine.

--
Dean

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

--_000_430FC6BDED356B4C8498F634416644A91A79CD1CC6mail_-- From john.elwell@siemens-enterprise.com Wed Mar 24 06:32:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967773A6B83 for ; Wed, 24 Mar 2010 06:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 K4uCRACVbKa6 for ; Wed, 24 Mar 2010 06:32:50 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F04913A6B2B for ; Wed, 24 Mar 2010 06:31:39 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1327190 for dispatch@ietf.org; Wed, 24 Mar 2010 14:31:59 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A4A2B23F02AA for ; Wed, 24 Mar 2010 14:31:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 24 Mar 2010 14:32:00 +0100 From: "Elwell, John" To: "dispatch@ietf.org" Date: Wed, 24 Mar 2010 14:31:51 +0100 Thread-Topic: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC Thread-Index: AcrKqus0WDI7+tyHT2erWEbf4HG6TwAazMkQ Message-ID: References: <20100323161249.21FDA3A6A55@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 13:32:51 -0000 Also related to this is: http://www.ietf.org/id/draft-lawrence-dispatch-sipforum-provider-alias-00.t= xt "This document defines procedures for how a SIP User Agent can translate an= identifier provided by a user into the SIP DNS domain name of a service pr= ovider. The form of the user supplied identifier is constrained to values = that can be entered using only a standard 12 key telephone keypad." This draft, from the SIP Forum, is an extension to the draft Cullen just an= nounced IETF last call on. It allows a SIP user agent to accept a provider = alias number (PAN) entered by the user and translate it to the domain name = at which the configuration service for configuring the UA can be found. The SIP Forum would like DISPATCH to consider ways of progressing this draf= t. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 23 March 2010 10:04 > To: rai@ietf.org; dispatch@ietf.org > Subject: [dispatch] Fwd: Last Call:=20 > draft-lawrence-sipforum-user-agent-config (Session Initiation=20 > Protocol (SIP) User Agent Configuration) to Informational RFC >=20 >=20 > As discussed at the SIP Forum lunch yesterday, there has been=20 > considerable work on a specification for configuration of SIP=20 > User Agents that is reflected in this document. I believe=20 > this document is appropriate for progression as AD Sponsored=20 > thought it may still need a few changes and discussion of=20 > community consensus. To initiate this, I have requests a 4=20 > week last call.=20 >=20 > Please, do give this document a read, and as request in the=20 > Last Call, send the email to the ietf@ietf.org list.=20 >=20 > Thanks,=20 > Cullen >=20 >=20 >=20 > Begin forwarded message: >=20 > > From: The IESG > > Date: March 23, 2010 9:12:48 AM PDT > > To: IETF-Announce > > Subject: Last Call:=20 > draft-lawrence-sipforum-user-agent-config (Session Initiation=20 > Protocol (SIP) User Agent Configuration) to Informational RFC > > Reply-To: ietf@ietf.org > >=20 > > The IESG has received a request from an individual=20 > submitter to consider=20 > > the following document: > >=20 > > - 'Session Initiation Protocol (SIP) User Agent Configuration ' > > as an=20 > Informational RFC > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits > > final comments on this action. Please send substantive=20 > comments to the > > ietf@ietf.org mailing lists by 2010-04-20. Exceptionally,=20 > > comments may be sent to iesg@ietf.org instead. In either=20 > case, please=20 > > retain the beginning of the Subject line to allow automated sorting. > >=20 > > The file can be obtained via > >=20 > http://www.ietf.org/internet-drafts/draft-lawrence-sipforum-us > er-agent-config-00.txt > >=20 > >=20 > > IESG discussion can be tracked via > >=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D19859&rfc_flag=3D0 > >=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Wed Mar 24 07:39:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC6D3A6A6F for ; Wed, 24 Mar 2010 07:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsoJZQdI+6ad for ; Wed, 24 Mar 2010 07:39:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3EE8E3A6B18 for ; Wed, 24 Mar 2010 07:39:32 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOLAqUurR7Hu/2dsb2JhbACbHXOmLpkNglaCKAQ X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="502126175" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2010 14:39:52 +0000 Received: from [10.21.67.62] (sjc-vpn3-830.cisco.com [10.21.67.62]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2OEdqLe006744; Wed, 24 Mar 2010 14:39:52 GMT Message-ID: <4BAA2438.9000807@cisco.com> Date: Wed, 24 Mar 2010 10:39:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 14:39:46 -0000 Hadriel, SBCs may be *capable* of preserving everything, but AFAIK in large part they exist as policy enforcement points to restrict one thing or another. If there is only one such boundary between the caller and the callee, then the chances of everything working that the two ends want may be pretty good, and if something doesn't work there is a reasonable chance that policy changes can be made so that it will work. But each additional hop between the caller and callee increases the possibility for some loss in functionality. By the time you have the caller, the caller's SP, the callee's SP, the callee, and maybe one or more transit providers, the likelihood of much beyond basic voice working starts getting very questionable. Of course its still *possible*, but what is the likelihood? Thanks, Paul Hadriel Kaplan wrote: > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Adam Roach >> Sent: Monday, March 15, 2010 1:33 PM >> >> Daryl is working within the strictures of reproducing the business >> relationships of the PSTN in a SIP network. And the path that has been >> taken, for better or worse, involves the heavy use of SBCs and other >> devices that impose a rather strict control on the way things are done. >> These devices largely ensure that the media path follows the signaling >> path, even when that's not the optimal thing to do. > > Optimal for whom, and in what way? > >> The chances of such >> networks deploying video, hi-def voice, or any of the other really neat >> things that Greger mentions are slim to none. This, of course, is NOT >> Daryl's fault. But it's where the egress-route work comes from. > > You seem to have some very odd (and typical IETF bull) preconceptions about what SBC's can do or are capable of doing. SBC's in general support video, HD voice, or any of the other neat things Gregor mentions. Policies provisioned on the SBC's may limit what media one can do, or in some cases if transcoding has to happen then obviously you're limited to whatever codecs the transcoders can handle (as any media gateway would be), but that's really tangential. > > >> Greger is speaking more towards the network you seem to have in mind -- >> one in which end-to-end SIP calls are possible, without SBCs or similar >> control boxes clobbering new services and mangling the ability to convey >> novel media from one endpoint to another. Networks where we don't need >> to define alternate connection models for protocols simply to >> accommodate network elements that do things that are explicitly >> disallowed by protocol specification. > > As a B2BUA, what SBC's do is in no way disallowed by the protocols in the IETF. (although certainly I don't really care if they are ;) > > >> Which is why I support a simple, non-normative, informational draft >> about the form of URLs that one might want to put in ENUM. It satisfies >> the requirements of the stagnant world, and doesn't even have any >> normative impacts on any protocol anywhere. It's harmless, and lets the >> people in the vibrant world concentrate on solving the problem in a more >> general way without having to accommodate the peculiarities of network >> elements living in the stagnant world. > > If you live in this "vibrant world" the rest of us don't, what problems are there that need solving?? Usually one needs users and a population >1 to have problems. The future always looks rosy compared to the present. > > -hadriel > From HKaplan@acmepacket.com Wed Mar 24 10:05:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D7B3A68FE for ; Wed, 24 Mar 2010 10:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 J2+1tuvs-fEy for ; Wed, 24 Mar 2010 10:05:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 23A5D3A692E for ; Wed, 24 Mar 2010 10:05:54 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 13:06:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 13:06:11 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Wed, 24 Mar 2010 13:06:09 -0400 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrLYCqru+gdEWSBQv+LWQVlyPSwowAEN88g Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1E04@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA2438.9000807@cisco.com> In-Reply-To: <4BAA2438.9000807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:05:55 -0000 Sure, then what he's saying is "because of policies people want to employ a= nd enforce, I can't do things that don't comply with those policies". Sure= I believe that... it's a tautology. With respect to media policies though, as far as I can tell, restricting th= e type of media, or even codecs within a given media type, is not _that_ po= pular - not for endpoint-to-endpoint sessions. I bet maybe as much as 50% = of the time, the codec/media-type munging by SBC's is done for fixing inter= op, not restriction policies. They're frequently removed because the equip= ment _inside_ the carrier's core network (i.e., gateways and media servers)= can't handle anything else and don't act well when given SDP they don't ex= pect. But if the signaling ends up going back out of the core, like to another UA= or another domain, some SBC's can "undo" the changes they made (assuming o= perator policies don't restrict that too). Although admittedly I may be wrong on how frequently it's done for interop,= vs. billing/policies, vs. bandwidth issues. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 24, 2010 10:40 AM > To: Hadriel Kaplan > Cc: Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route= - > 00 >=20 > Hadriel, >=20 > SBCs may be *capable* of preserving everything, but AFAIK in large part > they exist as policy enforcement points to restrict one thing or another. >=20 > If there is only one such boundary between the caller and the callee, > then the chances of everything working that the two ends want may be > pretty good, and if something doesn't work there is a reasonable chance > that policy changes can be made so that it will work. >=20 > But each additional hop between the caller and callee increases the > possibility for some loss in functionality. By the time you have the > caller, the caller's SP, the callee's SP, the callee, and maybe one or > more transit providers, the likelihood of much beyond basic voice > working starts getting very questionable. Of course its still > *possible*, but what is the likelihood? >=20 > Thanks, > Paul >=20 From adam.uzelac@gmail.com Wed Mar 24 10:14:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF583A69B0 for ; Wed, 24 Mar 2010 10:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFWRpRkPcew3 for ; Wed, 24 Mar 2010 10:14:11 -0700 (PDT) Received: from mail-qy0-f196.google.com (mail-qy0-f196.google.com [209.85.221.196]) by core3.amsl.com (Postfix) with ESMTP id 760E73A6C6F for ; Wed, 24 Mar 2010 10:13:56 -0700 (PDT) Received: by qyk34 with SMTP id 34so1980378qyk.22 for ; Wed, 24 Mar 2010 10:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=N8MR1lYUSVF5Fs0hJURt8ncnQy76e1Mgk92OoZg4r6c=; b=jL9brR7aNYF//4QgTW6MBQD6iN9SOP+FHiZqxlnfsNmFIz2XHSwUz3U+X84R6yfSGS bWtNqDA8iinATalzSKn0jHHGKfM0eGQLUAfmOXG0C0YMbSRJ1c7K0pxxElvTdGvCeGZd GhpyDaOZLS97zDDvfFGRszv2sOJ7afR5Gk08g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y8KPa+YxDqJh2U/kaV880DTClHPoMLD292krnW6jTnVKnVzNluooTmhdiCalfebxpp 4udRGlqCUCXDO6Ne2twiUP3axIQPjXOkW5c2Ohp7EGJecxUz0UNR5tOCCmCSXuXr3VS9 9+Ze14jpyJGC0i3AXE2Um8H1TVTVXbnYqAMDw= MIME-Version: 1.0 Received: by 10.229.192.68 with SMTP id dp4mr273562qcb.36.1269450853274; Wed, 24 Mar 2010 10:14:13 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1E04@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA2438.9000807@cisco.com> <430FC6BDED356B4C8498F634416644A91A79CD1E04@mail> Date: Wed, 24 Mar 2010 10:14:13 -0700 Message-ID: <3d58c41e1003241014n131ca183lbecf3422f4a72a53@mail.gmail.com> From: Adam Uzelac To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0016361e7efe2b541604828f0f5d Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:14:15 -0000 --0016361e7efe2b541604828f0f5d Content-Type: text/plain; charset=ISO-8859-1 I can confirm the notion that Hadriel states below. The "munging" that's going on is more about facilitating the session than about restricting a particular type of session. With that said, there are indeed times that we (as a SSP) would want to restrict, but those use cases are much fewer than sorting out Interop issues. Adam Uzelac Global Crossing On Wed, Mar 24, 2010 at 10:06 AM, Hadriel Kaplan wrote: > > Sure, then what he's saying is "because of policies people want to employ > and enforce, I can't do things that don't comply with those policies". Sure > I believe that... it's a tautology. > > With respect to media policies though, as far as I can tell, restricting > the type of media, or even codecs within a given media type, is not _that_ > popular - not for endpoint-to-endpoint sessions. I bet maybe as much as 50% > of the time, the codec/media-type munging by SBC's is done for fixing > interop, not restriction policies. They're frequently removed because the > equipment _inside_ the carrier's core network (i.e., gateways and media > servers) can't handle anything else and don't act well when given SDP they > don't expect. > > But if the signaling ends up going back out of the core, like to another UA > or another domain, some SBC's can "undo" the changes they made (assuming > operator policies don't restrict that too). > > Although admittedly I may be wrong on how frequently it's done for interop, > vs. billing/policies, vs. bandwidth issues. > > -hadriel > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Wednesday, March 24, 2010 10:40 AM > > To: Hadriel Kaplan > > Cc: Adam Roach; dispatch@ietf.org > > Subject: Re: [dispatch] I-D Action: > draft-malas-dispatch-sip-egress-route- > > 00 > > > > Hadriel, > > > > SBCs may be *capable* of preserving everything, but AFAIK in large part > > they exist as policy enforcement points to restrict one thing or another. > > > > If there is only one such boundary between the caller and the callee, > > then the chances of everything working that the two ends want may be > > pretty good, and if something doesn't work there is a reasonable chance > > that policy changes can be made so that it will work. > > > > But each additional hop between the caller and callee increases the > > possibility for some loss in functionality. By the time you have the > > caller, the caller's SP, the callee's SP, the callee, and maybe one or > > more transit providers, the likelihood of much beyond basic voice > > working starts getting very questionable. Of course its still > > *possible*, but what is the likelihood? > > > > Thanks, > > Paul > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0016361e7efe2b541604828f0f5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can confirm the notion that Hadriel states below.=A0 The "munging&qu= ot; that's going on is more about facilitating the session than about r= estricting a particular type of session.=A0 With that said, there are indee= d times that we (as a SSP) would want to restrict, but those use cases are = much fewer than sorting out Interop issues.

Adam Uzelac
Global Crossing

On Wed= , Mar 24, 2010 at 10:06 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :

Sure, then what he's saying is "because of policies people want to= employ and enforce, I can't do things that don't comply with those= policies". =A0Sure I believe that... it's a tautology.

With respect to media policies though, as far as I can tell, restricting th= e type of media, or even codecs within a given media type, is not _that_ po= pular - not for endpoint-to-endpoint sessions. =A0I bet maybe as much as 50= % of the time, the codec/media-type munging by SBC's is done for fixing= interop, not restriction policies. =A0They're frequently removed becau= se the equipment _inside_ the carrier's core network (i.e., gateways an= d media servers) can't handle anything else and don't act well when= given SDP they don't expect.

But if the signaling ends up going back out of the core, like to another UA= or another domain, some SBC's can "undo" the changes they ma= de (assuming operator policies don't restrict that too).

Although admittedly I may be wrong on how frequently it's done for inte= rop, vs. billing/policies, vs. bandwidth issues.

-hadriel

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi= vat@cisco.com]
> Sent: Wednesday, March 24, 2010 10:40 AM
> To: Hadriel Kaplan
> Cc: Adam Roach; dispatch@ietf.org=
> Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-ro= ute-
> 00
>
> Hadriel,
>
> SBCs may be *capable* of preserving everything, but AFAIK in large par= t
> they exist as policy enforcement points to restrict one thing or anoth= er.
>
> If there is only one such boundary between the caller and the callee,<= br> > then the chances of everything working that the two ends want may be > pretty good, and if something doesn't work there is a reasonable c= hance
> that policy changes can be made so that it will work.
>
> But each additional hop between the caller and callee increases the > possibility for some loss in functionality. By the time you have the > caller, the caller's SP, the callee's SP, the callee, and mayb= e one or
> more transit providers, the likelihood of much beyond basic voice
> working starts getting very questionable. Of course its still
> *possible*, but what is the likelihood?
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
___________________________________= ____________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--0016361e7efe2b541604828f0f5d-- From adam@nostrum.com Wed Mar 24 10:32:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F28D3A6A0A for ; Wed, 24 Mar 2010 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.78 X-Spam-Level: * X-Spam-Status: No, score=1.78 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmpNjgVd64N6 for ; Wed, 24 Mar 2010 10:32:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id ABDF63A69D9 for ; Wed, 24 Mar 2010 10:32:49 -0700 (PDT) Received: from dhcp-wireless-open-abg-24-56.meeting.ietf.org (dhcp-wireless-open-abg-24-56.meeting.ietf.org [130.129.24.56]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2OHWi6j061343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 12:32:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BAA4CBC.3070503@nostrum.com> Date: Wed, 24 Mar 2010 10:32:44 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Hadriel Kaplan References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 130.129.24.56 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:32:51 -0000 Ooh! A gauntlet! It's been a while since we had one of these. I guess we all need a bit of catharsis. On 3/24/10 12:43 AM, Hadriel Kaplan wrote: > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Adam Roach >> Sent: Monday, March 15, 2010 1:33 PM >> >> Daryl is working within the strictures of reproducing the business >> relationships of the PSTN in a SIP network. And the path that has been >> taken, for better or worse, involves the heavy use of SBCs and other >> devices that impose a rather strict control on the way things are done. >> These devices largely ensure that the media path follows the signaling >> path, even when that's not the optimal thing to do. >> > Optimal for whom, and in what way? I guess I should have qualified that. I meant technically optimal -- that is, optimizing for the lowest end-to-end latency, jitter, and overall network resource utilization. IP routing does a reasonable job of getting this right -- artificially pinning the media to various points around the network defeats that. >> The chances of such >> networks deploying video, hi-def voice, or any of the other really neat >> things that Greger mentions are slim to none. This, of course, is NOT >> Daryl's fault. But it's where the egress-route work comes from. >> > You seem to have some very odd (and typical IETF bull) preconceptions about what SBC's can do or are capable of doing. Defensive much? I didn't say that the SBCs were incapable of passing this kind of media along. I was attempting to point out that the operators who deploy these kinds of architectures are not typically of the mindset that lends itself to forward thinking. After all, they're sinking untold costs into a network that does quite precisely what their old network did. If that qualifies as "progress," then something as radical as hi-def audio on the same scale would probably qualify as "Ragnarök." That said, if SBCs actually *are* B2BUAs as you claim below (which they aren't, but let's buy that conceit for a second), then they must implement all higher-level services that the endpoints they sit between expect to invoke. Because, if they really are B2BUAs, then they're the "other user agent" in two different (but related) calls, and they need to understand everything that the actual endpoints say. That means that handsets will always be stuck waiting on SBCs to catch up when they try to deploy new services. > > >> Greger is speaking more towards the network you seem to have in mind -- >> one in which end-to-end SIP calls are possible, without SBCs or similar >> control boxes clobbering new services and mangling the ability to convey >> novel media from one endpoint to another. Networks where we don't need >> to define alternate connection models for protocols simply to >> accommodate network elements that do things that are explicitly >> disallowed by protocol specification. >> > As a B2BUA, what SBC's do is in no way disallowed by the protocols in the IETF. (although certainly I don't really care if they are ;) > Again, even if they were true B2BUAs, they run afoul of some rather well-established Internet principles. I know that things like the end-to-end principle seem like quaint platitudes to you, and I'm not the person to convince you otherwise. But that's not the practical issue. You're smart enough to know that SBCs are in no way compliant B2BUAs. They don't satisfy the requirements of user agents, nor do they hold themselves to the restrictions of being a proxy. They pick-and-choose between these behaviors, sometimes within a single message. That's out of spec, and it causes real and quantifiable problems. For example: if SBCs were actual, real, full-fledged back-to-back user agents, we wouldn't be stuck with defining alternative connection models to accommodate their peculiarities. As compliant user agents, they would have no issues with the MSRP protocol as defined. >> Which is why I support a simple, non-normative, informational draft >> about the form of URLs that one might want to put in ENUM. It satisfies >> the requirements of the stagnant world, and doesn't even have any >> normative impacts on any protocol anywhere. It's harmless, and lets the >> people in the vibrant world concentrate on solving the problem in a more >> general way without having to accommodate the peculiarities of network >> elements living in the stagnant world. >> > If you live in this "vibrant world" the rest of us don't, what problems are there that need solving?? Usually one needs users and a population>1 to have problems. The future always looks rosy compared to the present. > Although I'm sometimes guilty of reading through large backlogs of email and replying to messages as I come across them, I have generally taken it upon myself to at least read to the end of a thread before I reply in that thread. This lets me avoid asking questions that have already been answered or making assertions that have already been refuted. http://www.ietf.org/mail-archive/web/dispatch/current/msg01549.html (You can skip directly to the final paragraph) /a From dean.willis@softarmor.com Wed Mar 24 11:08:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C0D3A6D7F for ; Wed, 24 Mar 2010 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.874 X-Spam-Level: X-Spam-Status: No, score=0.874 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 1PVxnp0W1wTN for ; Wed, 24 Mar 2010 11:08:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 324A73A6D88 for ; Wed, 24 Mar 2010 11:08:10 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OI7gBm025033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 13:07:45 -0500 Message-ID: <4BAA54EE.1050503@softarmor.com> Date: Wed, 24 Mar 2010 13:07:42 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Hadriel Kaplan References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:08:18 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: >> Monday, March 15, 2010 1:33 PM >> >> Daryl is working within the strictures of reproducing the business >> relationships of the PSTN in a SIP network. And the path that has >> been taken, for better or worse, involves the heavy use of SBCs and >> other devices that impose a rather strict control on the way things >> are done. These devices largely ensure that the media path follows >> the signaling path, even when that's not the optimal thing to do. > > Optimal for whom, and in what way? Optimal in the "internet" sense: the shortest/least used available route, as would be described by the IP routing topology from address A to B. > >> The chances of such networks deploying video, hi-def voice, or any >> of the other really neat things that Greger mentions are slim to >> none. This, of course, is NOT Daryl's fault. But it's where the >> egress-route work comes from. > > You seem to have some very odd (and typical IETF bull) preconceptions > about what SBC's can do or are capable of doing. SBC's in general > support video, HD voice, or any of the other neat things Gregor > mentions. Policies provisioned on the SBC's may limit what media one > can do, or in some cases if transcoding has to happen then obviously > you're limited to whatever codecs the transcoders can handle (as any > media gateway would be), but that's really tangential. I believe Adam is referring to the fact that it's the old-school telecom people who are building this sort of topology. They don't have a great history of successful innovation. They occasionally try to offer a new service, but only after it's been much more successfully deployed in an "Internet" fashion by the new-school people. Does Youtube require SBCs? How about iTunes? AOL's Instant messenger? Facebook? > > >> Greger is speaking more towards the network you seem to have in >> mind -- one in which end-to-end SIP calls are possible, without >> SBCs or similar control boxes clobbering new services and mangling >> the ability to convey novel media from one endpoint to another. >> Networks where we don't need to define alternate connection models >> for protocols simply to accommodate network elements that do things >> that are explicitly disallowed by protocol specification. > > As a B2BUA, what SBC's do is in no way disallowed by the protocols in > the IETF. (although certainly I don't really care if they are ;) Right. What they do is controlled by the policies and mindsets of those who purchase and install them. They live in a different world, where innovation is slow and painful. It's also a world where long-term reliability and stability are heavily rewarded. > > >> Which is why I support a simple, non-normative, informational draft >> about the form of URLs that one might want to put in ENUM. It >> satisfies the requirements of the stagnant world, and doesn't even >> have any normative impacts on any protocol anywhere. It's harmless, >> and lets the people in the vibrant world concentrate on solving the >> problem in a more general way without having to accommodate the >> peculiarities of network elements living in the stagnant world. > > If you live in this "vibrant world" the rest of us don't, what > problems are there that need solving?? Usually one needs users and a > population >1 to have problems. The future always looks rosy > compared to the present. Why are the kids migrating towards Facebook/Youtube etc. as their communications channels? -- Dean From dean.willis@softarmor.com Wed Mar 24 11:10:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138163A6CAA for ; Wed, 24 Mar 2010 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-aNhDDqmWSA for ; Wed, 24 Mar 2010 11:10:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CEE213A6D44 for ; Wed, 24 Mar 2010 11:10:28 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OIAlrB025085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 13:10:49 -0500 Message-ID: <4BAA55A6.6030600@softarmor.com> Date: Wed, 24 Mar 2010 13:10:46 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Elwell, John" References: <20100323161249.21FDA3A6A55@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:10:45 -0000 Elwell, John wrote: > Also related to this is: > http://www.ietf.org/id/draft-lawrence-dispatch-sipforum-provider-alias-00.txt > > > "This document defines procedures for how a SIP User Agent can > translate an identifier provided by a user into the SIP DNS domain > name of a service provider. The form of the user supplied identifier > is constrained to values that can be entered using only a standard 12 > key telephone keypad." > > This draft, from the SIP Forum, is an extension to the draft Cullen > just announced IETF last call on. It allows a SIP user agent to > accept a provider alias number (PAN) entered by the user and > translate it to the domain name at which the configuration service > for configuring the UA can be found. > > The SIP Forum would like DISPATCH to consider ways of progressing > this draft. > This Provider Alias Number sounds like an ITAD identifier which sounds like a SPID. One ought to be able to do an ENUM style query on this number and retrieve a URI. -- Dean From xmlscott@gmail.com Wed Mar 24 12:40:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3D3A686C for ; Wed, 24 Mar 2010 12:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 fGkeKwGRkYxE for ; Wed, 24 Mar 2010 12:40:45 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id F2F003A6842 for ; Wed, 24 Mar 2010 12:40:44 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id x5RJ1d00B0vyq2s517h6zP; Wed, 24 Mar 2010 19:41:06 +0000 Received: from [192.168.10.11] ([98.229.134.198]) by omta05.westchester.pa.mail.comcast.net with comcast id x7h51d00E4H02bE3R7h6JQ; Wed, 24 Mar 2010 19:41:06 +0000 From: Scott Lawrence To: Dean Willis In-Reply-To: <4BAA55A6.6030600@softarmor.com> References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Mar 2010 15:41:04 -0400 Message-ID: <1269459664.2149.294.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:40:46 -0000 On Wed, 2010-03-24 at 13:10 -0500, Dean Willis wrote: > This Provider Alias Number sounds like an ITAD identifier which sounds > like a SPID. The idea was inspired by ITADs, but the task group felt that actually using the ITAD name and registry would not meet the needs of the intended use (that is, high reliability consumer-facing service providers). > One ought to be able to do an ENUM style query on this number and > retrieve a URI. Which is, roughly speaking, what the draft proposes: do a NAPTR lookup to translate the PAN into a SIP domain name, which is then used as specified in the UA Config spec to find the configuration service for the provider. From xmlscott@gmail.com Wed Mar 24 12:43:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18FA3A6A53 for ; Wed, 24 Mar 2010 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 0KjwSC5goNR2 for ; Wed, 24 Mar 2010 12:43:08 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id D5B013A6979 for ; Wed, 24 Mar 2010 12:43:07 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id x5Wq1d0041YDfWL567jV0n; Wed, 24 Mar 2010 19:43:29 +0000 Received: from [192.168.10.11] ([98.229.134.198]) by omta20.westchester.pa.mail.comcast.net with comcast id x7lw1d00N4H02bE3g7lwRe; Wed, 24 Mar 2010 19:45:56 +0000 From: Scott Lawrence To: "Elwell, John" In-Reply-To: References: <20100323161249.21FDA3A6A55@core3.amsl.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Mar 2010 15:43:27 -0400 Message-ID: <1269459807.2149.297.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:43:09 -0000 On Wed, 2010-03-24 at 14:31 +0100, Elwell, John wrote: > Also related to this is: > http://www.ietf.org/id/draft-lawrence-dispatch-sipforum-provider-alias-00.txt > > "This document defines procedures for how a SIP User Agent can > translate an identifier provided by a user into the SIP DNS domain > name of a service provider. The form of the user supplied identifier > is constrained to values that can be entered using only a standard 12 > key telephone keypad." > > This draft, from the SIP Forum, is an extension to the draft Cullen > just announced IETF last call on. It allows a SIP user agent to accept > a provider alias number (PAN) entered by the user and translate it to > the domain name at which the configuration service for configuring the > UA can be found. To be extra clear... the provider-alias draft is _not_ being last called. For various reasons, this part of what the SIP Forum Task Group came up with has been separated from the rest to be progressed independently, hence: > The SIP Forum would like DISPATCH to consider ways of progressing this > draft. From hgs@cs.columbia.edu Wed Mar 24 13:26:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C4D3A683E for ; Wed, 24 Mar 2010 13:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=1.564, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLGw7r2jZ9JS for ; Wed, 24 Mar 2010 13:26:52 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6C9213A6358 for ; Wed, 24 Mar 2010 13:26:52 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2OKR9Bk002291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Mar 2010 16:27:10 -0400 (EDT) References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> In-Reply-To: <1269459664.2149.294.camel@localhost> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Date: Wed, 24 Mar 2010 16:27:07 -0400 To: Scott Lawrence X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:26:53 -0000 On Mar 24, 2010, at 3:41 PM, Scott Lawrence wrote: > On Wed, 2010-03-24 at 13:10 -0500, Dean Willis wrote: >=20 >> This Provider Alias Number sounds like an ITAD identifier which = sounds >> like a SPID. >=20 > The idea was inspired by ITADs, but the task group felt that actually > using the ITAD name and registry would not meet the needs of the > intended use (that is, high reliability consumer-facing service > providers). Could you expand on the reasoning? Do you see a problem with the = accuracy of the data set, the ability to filter registrations to keep = out riff-raff or more operational issues (e.g., operation of a DNS = registry)? Henning= From HKaplan@acmepacket.com Wed Mar 24 13:56:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66AB83A6949 for ; Wed, 24 Mar 2010 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.885 X-Spam-Level: X-Spam-Status: No, score=0.885 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Ub42JDjB6gyS for ; Wed, 24 Mar 2010 13:56:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 733BA3A67D6 for ; Wed, 24 Mar 2010 13:55:58 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 16:56:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 16:56:17 -0400 From: Hadriel Kaplan To: Adam Roach Date: Wed, 24 Mar 2010 16:56:16 -0400 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrLeBGbxifmw3sSQb2Pv/VGz+TCPQABDU7Q Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EA8@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA4CBC.3070503@nostrum.com> In-Reply-To: <4BAA4CBC.3070503@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:56:15 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, March 24, 2010 1:33 PM > > Ooh! A gauntlet! It's been a while since we had one of these. I guess we > all need a bit of catharsis. > > On 3/24/10 12:43 AM, Hadriel Kaplan wrote: > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Adam Roach > >> Sent: Monday, March 15, 2010 1:33 PM > >> > > Optimal for whom, and in what way? >=20 > I guess I should have qualified that. I meant technically optimal -- > that is, optimizing for the lowest end-to-end latency, jitter, and > overall network resource utilization. IP routing does a reasonable job > of getting this right -- artificially pinning the media to various > points around the network defeats that. Oh, I didn't realize typical IP routing took into account latency, jitter, = packet-loss and overall network utilization. Oh wait, that's because it *d= oesn't*. MPLS-TE does more so, and its extensions for ospf/isis-te - but t= here's this funny thing that happens with that - ALL the traffic flows that= way (well, all the traffic for that FEC/prefix). So if you only want *som= e* traffic to flow that (better) way, like oh for example money-generating = voip traffic, you gotta make it a different FEC (which SBC's do), or apply = router-level per-flow/per-call gates/policies. Obviously going across the = public Internet there's nothing much better you can do than best-effort rou= ting, but for owners/operators of the network infrastructures, they have ot= her options. YMMV. > > You seem to have some very odd (and typical IETF bull) preconceptions > about what SBC's can do or are capable of doing. >=20 > Defensive much? I didn't say that the SBCs were incapable of passing > this kind of media along. I was attempting to point out that the > operators who deploy these kinds of architectures are not typically of > the mindset that lends itself to forward thinking. After all, they're > sinking untold costs into a network that does quite precisely what their > old network did. If that qualifies as "progress," then something as > radical as hi-def audio on the same scale would probably qualify as > "Ragnar=F6k." Actually, most operators *want* new capabilities, new services, new media t= ypes, etc. They're stuck in many cases because of legacy deployed gear, no= doubt, but they really do want to provide better and newer stuff. =20 > That said, if SBCs actually *are* B2BUAs as you claim below (which they > aren't, but let's buy that conceit for a second), then they must > implement all higher-level services that the endpoints they sit between > expect to invoke. Because, if they really are B2BUAs, then they're the > "other user agent" in two different (but related) calls, and they need > to understand everything that the actual endpoints say. That means that > handsets will always be stuck waiting on SBCs to catch up when they try > to deploy new services. Ironically, SBC's seem to be the ones usually waiting on endpoints to imple= ment new things. (seriously) > That said, if SBCs actually *are* B2BUAs as you claim below (which they > aren't, but let's buy that conceit for a second), then they must > implement all higher-level services that the endpoints they sit between > expect to invoke. Because, if they really are B2BUAs, then they're the > "other user agent" in two different (but related) calls, and they need > to understand everything that the actual endpoints say. That means that > handsets will always be stuck waiting on SBCs to catch up when they try > to deploy new services. Of course you're right, in some particulars SBC's are not a "full" B2BUA, b= ut instead walk a fine line trying to be less than a "full" B2BUA, specific= ally to try and avoid getting in the way of new mechanisms/media/protocols.= But I have not seen any RFC that specifies what a B2BUA must or must not = do - yes, it's the combination of a UAC and UAS for two distinct sessions, = but I don't know of any doc that says what I can and cannot copy back/forth= among those two sessions. And that is not specific to SBC's either - lots= of app-servers/softswitches/pbx's are "mostly" but not entirely B2BUA's in= signaling, and partial or not B2BUA's in media. > For example: if SBCs were actual, real, full-fledged back-to-back user > agents, we wouldn't be stuck with defining alternative connection models > to accommodate their peculiarities. As compliant user agents, they would > have no issues with the MSRP protocol as defined. You're not stuck with it. We don't *need* the alternative connection model= or msrp changes to function. We *want* it, for an optimization - in the i= pv4/v6 case to let media go "direct" when it can, or not be converted back/= forth v6/v4/v6; in the MSRP case so it can actually scale and be cost-effec= tive. They're more pragmatic/practical issues than technical. > Although I'm sometimes guilty of reading through large backlogs of email > and replying to messages as I come across them, I have generally taken > it upon myself to at least read to the end of a thread before I reply in > that thread. This lets me avoid asking questions that have already been > answered or making assertions that have already been refuted. >=20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg01549.html >=20 > (You can skip directly to the final paragraph) I read it, and it refutes nothing. I didn't literally mean a population of= "1". I meant a significant population, with numerous vendors, etc. (and I= think you knew that ;)=20 -hadriel p.s. Is it sad that when I read "gauntlet" I first thought of a great class= ic arcade game? :) From HKaplan@acmepacket.com Wed Mar 24 14:02:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF283A6DDD for ; Wed, 24 Mar 2010 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 ERjolg6pWpgG for ; Wed, 24 Mar 2010 14:02:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 41EB03A6DF0 for ; Wed, 24 Mar 2010 14:02:54 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 17:03:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 17:03:13 -0400 From: Hadriel Kaplan To: Dean Willis Date: Wed, 24 Mar 2010 17:03:12 -0400 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrLfO9FVL9Vbx53Qy2tNEG3au8CvgAF5DEg Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EB0@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA54EE.1050503@softarmor.com> In-Reply-To: <4BAA54EE.1050503@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:02:59 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 24, 2010 2:08 PM > To: Hadriel Kaplan >=20 > Optimal in the "internet" sense: the shortest/least used available > route, as would be described by the IP routing topology from address A to > B. Unless something drastic has changed in the past 6 years, the public Intern= et routing model does not provide a shortest in the English sense of the wo= rd. It is not based on physical distance or latency. Nor is it based on l= east-used. -hadriel From HKaplan@acmepacket.com Wed Mar 24 14:20:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22EB3A6D1C for ; Wed, 24 Mar 2010 14:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 4LYyqA-o1Dp1 for ; Wed, 24 Mar 2010 14:20:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D54A63A6BE0 for ; Wed, 24 Mar 2010 14:20:40 -0700 (PDT) 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.375.2; Wed, 24 Mar 2010 17:21:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 17:21:00 -0400 From: Hadriel Kaplan To: Dean Willis Date: Wed, 24 Mar 2010 17:20:59 -0400 Thread-Topic: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 Thread-Index: AcrLfO9FVL9Vbx53Qy2tNEG3au8CvgAGIs5g Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EB7@mail> References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA54EE.1050503@softarmor.com> In-Reply-To: <4BAA54EE.1050503@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:20:42 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 24, 2010 2:08 PM > To: Hadriel Kaplan >=20 > I believe Adam is referring to the fact that it's the old-school telecom > people who are building this sort of topology. They don't have a great > history of successful innovation. They occasionally try to offer a new > service, but only after it's been much more successfully deployed in an > "Internet" fashion by the new-school people. Does Youtube require SBCs? > How about iTunes? AOL's Instant messenger? Facebook? The application, protocol, delivery, usage, and expectation model for those= applications is very different from VoIP. And you know that. AOL-IM is cl= oser, but it's a closed walled-garden... how evil! > Why are the kids migrating towards Facebook/Youtube etc. as their > communications channels? What does that that have to do with anything? They're not replacements/ins= tead-of - they're something different altogether. Why do more kids play Xb= ox Live and talk over the game headsets? It must be because it's not provi= ded by a telco!? Why do more and more kids use SMS, or mobile phones? Those are provided by= telco's. -hadriel From xmlscott@gmail.com Wed Mar 24 14:31:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D693A6965 for ; Wed, 24 Mar 2010 14:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 3Jf3zbiP6z6g for ; Wed, 24 Mar 2010 14:31:49 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 2C5C63A684F for ; Wed, 24 Mar 2010 14:31:49 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id x5ab1d0091GhbT8599YAnQ; Wed, 24 Mar 2010 21:32:10 +0000 Received: from [192.168.10.11] ([98.229.134.198]) by omta07.westchester.pa.mail.comcast.net with comcast id x9YA1d0094H02bE3T9YAwP; Wed, 24 Mar 2010 21:32:10 +0000 From: Scott Lawrence To: Henning Schulzrinne In-Reply-To: <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> Content-Type: multipart/mixed; boundary="=-CyrF+gHwR5DpIL0muB/p" Date: Wed, 24 Mar 2010 17:32:09 -0400 Message-ID: <1269466329.2149.311.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:31:50 -0000 --=-CyrF+gHwR5DpIL0muB/p Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2010-03-24 at 13:10 -0500, Dean Willis wrote: > >> This Provider Alias Number sounds like an ITAD identifier which sounds > >> like a SPID. On Mar 24, 2010, at 3:41 PM, Scott Lawrence wrote: > > The idea was inspired by ITADs, but the task group felt that actually > > using the ITAD name and registry would not meet the needs of the > > intended use (that is, high reliability consumer-facing service > > providers). On Wed, 2010-03-24 at 16:27 -0400, Henning Schulzrinne wrote: > Could you expand on the reasoning? Do you see a problem with the > accuracy of the data set, the ability to filter registrations to keep > out riff-raff or more operational issues (e.g., operation of a DNS > registry)? The attached is a problem statement I drafted for the SIP Forum Board that summarized the issues raised in the task group and from some external reviewers. --=-CyrF+gHwR5DpIL0muB/p Content-Disposition: attachment; filename="problem_statement.txt" Content-Type: text/plain; name="problem_statement.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit The User Agent Configuration Task Group has included among the goals for the Recommendation it is producing the ability to configure a User Agent for use with a SIP domain whose administration and operation is independent of the network to which the UA is connected. The Task Group believe this requirement is important in many deployment scenarios, but a simple example serves to illustrate the challenge: A user wants to obtain home phone service through a particular commercial Internet Telephony Service Provider (ITSP). The user establishes an account with the ITSP and then purchases a phone (UA) at an independent retail store. The user connects that new UA to the home network, but our users network connection is provided and provisioned by a carrier that provides generic IP connectivity without any telephony service - the carrier is not affiliated with the ITSP in any way. When the new UA is connected to the network, it must find the Configuration Service of the ITSP in order to request configuration data. The process of locating that Configuration Service (as defined in the draft User Agent Configuration Recommendation) requires that the UA obtain the SIP domain name of the ITSP. In other deployment scenarios, the UA can automate obtaining that SIP domain name by beginning with the assumption that the SIP domain is the same as the default DNS domain of the local network, but in this case the local network will provide a domain name that does not have a SIP UA Configuration Service, so the location procedure will fail. A simple answer to this problem would be to require that the UA provide a means for the user to enter the domain name of the ITSP, and the draft Recommendation does allow that solution. However, the working group believes that entry of a domain name is not as simple and user-friendly enough. Entry of a domain name requires alphabetic characters that a simple phone would not otherwise need, and very soon internationalized domain names will require even more complex characters. The current draft calls for a mechanism that allows the user to enter a simple string of decimal digits that the UA can use to obtain the SIP domain name. This solution was inspired by (and the current draft calls for using) IP Telephony Administrative Domain (ITAD) numbers as the numeric values. ITAD numbers were defined as a part of RFC 3219: Telephony Routing over IP (TRIP). TRIP is not related to SIP and has not been widely implemented or deployed. In fact, the only element of the TRIP specification that has been used at all is the ITAD registry at IANA. The ITAD registry has been adopted as the numeric domain alias mechanism of an experimental Internet telephony addressing scheme based on ITAD Subscriber Numbers (ISNs), coordinated through the freenum.org domain. The 'ISN trial' is supported by the Internet2 Project, Packet Clearing House, and MIT. ISN addressing uses dial strings of the form *; the 'Freenum/ISN Cookbook' [1] defines a resolution procedure that uses a DNS NAPTR lookup of a regular expression to transform the dial string into a SIP URL sip:@. The Task Group has reached a consensus that it should explore an alternative to ITAD as a basis for the numeric domain aliasing mechanism in the SIP Forum Recommendation. Reasons for this consensus include: * The administrative and legal infrastructure of using the existing first-come first-served ITAD registry at IANA is not sufficient for the needs of commercial service providers. * Using the existing ITAD name and registry may create confusion regarding whether or not other parts of the protocols and procedures in the TRIP specification and/or the ISN/Freenum trial are also applicable (the intent is that no other part of these other specifications and procedures be used). * The numeric alias to domain resolution procedure in the current UA Configuration draft Recommendation has two problems: 1. It uses the 'freenum.org' dns tree, which the Task Group believes is not scalable and robust enough to meet the needs of commercial SIP service providers. 2. It is designed to take as input a full user address that contains an ITAD number, and produce as output a full SIP url (including a userpart). The UA Configuration Recommendation needs as input only the domain number and as output only the domain name, which means that the current DNS records and ISN Cookbook procedures cannot be used. * The ITAD number is defined as a 32 bit number. The UA Configuration Recommendation needs to map one arbitrary (but numeric) identifier to a domain name, so there is no reason to impose a limit of a particular number of bits as ITAD does; what is needed is a string of decimal digits, not a binary number of a particular size. The Task Group would like the Board to consider whether or not the SIP Forum should create a new mechanism for numeric domain aliases. This new mechanism would: * Use a DNS domain for resolution whose ownership and change control procedures are appropriate to the needs of SIP service providers and enterprises. * Allow the definition of a simple DNS based mapping procedure using only the hostname portion of the NATPR result to specify the domain. [1] http://freenum.org/cookbook/ --=-CyrF+gHwR5DpIL0muB/p-- From hgs@cs.columbia.edu Wed Mar 24 14:37:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3F33A6E15 for ; Wed, 24 Mar 2010 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PFiktMmXZZN for ; Wed, 24 Mar 2010 14:37:32 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id DAF493A6E11 for ; Wed, 24 Mar 2010 14:37:31 -0700 (PDT) Received: from dhcp-wireless-open-abg-26-78.meeting.ietf.org (dhcp-wireless-open-abg-26-78.meeting.ietf.org [130.129.26.78]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o2OLbjTF002497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Mar 2010 17:37:49 -0400 (EDT) References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> <1269466329.2149.311.camel@localhost> In-Reply-To: <1269466329.2149.311.camel@localhost> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-15--898311244 Message-Id: From: Henning Schulzrinne Date: Wed, 24 Mar 2010 17:37:44 -0400 To: Scott Lawrence X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:37:33 -0000 --Apple-Mail-15--898311244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > The attached is a problem statement I drafted for the SIP Forum Board > that summarized the issues raised in the task group and from some > external reviewers. To quote: The administrative and legal infrastructure of using the existing first-come first-served ITAD registry at IANA is not sufficient for the needs of commercial service providers. * No reasons are given for this determination. Using the existing ITAD name and registry may create confusion regarding whether or not other parts of the protocols and procedures in the TRIP specification and/or the ISN/Freenum trial are also applicable (the intent is that no other part of these other specifications and procedures be used). * I admit that I find this speculative. As long as the mechanism is = clear, the users of the DNS record won't care. The ITAD number is defined as a 32 bit number. * This translates into (roughly) a 9-digit decimal integer. It seems = rather unlikely that we would exceed 4 billion service providers or that = we'd want longer identifiers than 9 digits. In general, I agree that the ITAD registry would have to be expanded and = the use clarified, but re-use of the same registry (say, enterprise = numbers) for different purposes is not unusual. Henning --Apple-Mail-15--898311244 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The attached is a problem statement I = drafted for the SIP Forum Board
that summarized the issues raised in = the task group and from some
external = reviewers.

To = quote:

The administrative and legal = infrastructure of using the existing
     = first-come first-served ITAD registry at IANA is not = sufficient
     for the needs of commercial = service providers.

* No reasons are given for = this determination.

 Using the = existing ITAD name and registry may create = confusion
     regarding whether or not other = parts of the protocols and
     procedures in = the TRIP specification and/or the ISN/Freenum = trial
     are also applicable (the intent is = that no other part of these
     other = specifications and procedures be used).

* I = admit that I find this speculative. As long as the mechanism is clear, = the users of the DNS record won't care.

The = ITAD number is defined as a 32 bit number.

* = This translates into (roughly) a 9-digit decimal integer. It seems = rather unlikely that we would exceed 4 billion service providers or that = we'd want longer identifiers than 9 digits.

In = general, I agree that the ITAD registry would have to be expanded and = the use clarified, but re-use of the same registry (say, enterprise = numbers) for different purposes is not = unusual.

Henning

= = --Apple-Mail-15--898311244-- From pkyzivat@cisco.com Wed Mar 24 14:41:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED2A3A69EB for ; Wed, 24 Mar 2010 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.962 X-Spam-Level: X-Spam-Status: No, score=-6.962 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blsbltCRNe3c for ; Wed, 24 Mar 2010 14:41:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6F4853A67D6 for ; Wed, 24 Mar 2010 14:41:01 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI8jqkurR7Hu/2dsb2JhbACbG3OnVYsRCI11glYOCIISBA X-IronPort-AV: E=Sophos;i="4.51,303,1267401600"; d="scan'208";a="311417700" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2010 21:41:22 +0000 Received: from [10.21.124.241] (sjc-vpn6-1265.cisco.com [10.21.124.241]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2OLfMG5011209; Wed, 24 Mar 2010 21:41:22 GMT Message-ID: <4BAA8700.7090304@cisco.com> Date: Wed, 24 Mar 2010 17:41:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <114DAD31379DFA438C0A2E39B3B8AF5D01213F66AA@srvxchg> <564499D5-6303-4727-AD8C-996D182D9726@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66B8@srvxchg> <4B8ED7D2.8000806@nostrum.com> <7B1FAD89-E5FC-44EC-AA0A-F373CC37A407@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F66F6@srvxchg> <74FBDCFA-9869-4809-BAC2-AAA59304B69B@softarmor.com> <114DAD31379DFA438C0A2E39B3B8AF5D01213F672D@srvxchg> <4B99EAD7.9090407@teigre.com> <4B9E56B7.6070009@nostrum.com> <4B9E5B9E.7030907@cisco.com> <4B9E5F47.2040604@nostrum.com> <4B9E616C.1000208@cisco.com> <4B9E6F60.1040703@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1CB7@mail> <4BAA4CBC.3070503@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79CD1EA8@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1EA8@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:41:03 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Wednesday, March 24, 2010 1:33 PM >> >> Ooh! A gauntlet! It's been a while since we had one of these. I guess we >> all need a bit of catharsis. >> >> On 3/24/10 12:43 AM, Hadriel Kaplan wrote: >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Adam Roach >>>> Sent: Monday, March 15, 2010 1:33 PM >>>> >>> Optimal for whom, and in what way? >> I guess I should have qualified that. I meant technically optimal -- >> that is, optimizing for the lowest end-to-end latency, jitter, and >> overall network resource utilization. IP routing does a reasonable job >> of getting this right -- artificially pinning the media to various >> points around the network defeats that. > > Oh, I didn't realize typical IP routing took into account latency, jitter, packet-loss and overall network utilization. Oh wait, that's because it *doesn't*. MPLS-TE does more so, and its extensions for ospf/isis-te - but there's this funny thing that happens with that - ALL the traffic flows that way (well, all the traffic for that FEC/prefix). So if you only want *some* traffic to flow that (better) way, like oh for example money-generating voip traffic, you gotta make it a different FEC (which SBC's do), or apply router-level per-flow/per-call gates/policies. Obviously going across the public Internet there's nothing much better you can do than best-effort routing, but for owners/operators of the network infrastructures, they have other options. YMMV. RSVP? >>> You seem to have some very odd (and typical IETF bull) preconceptions >> about what SBC's can do or are capable of doing. >> >> Defensive much? I didn't say that the SBCs were incapable of passing >> this kind of media along. I was attempting to point out that the >> operators who deploy these kinds of architectures are not typically of >> the mindset that lends itself to forward thinking. After all, they're >> sinking untold costs into a network that does quite precisely what their >> old network did. If that qualifies as "progress," then something as >> radical as hi-def audio on the same scale would probably qualify as >> "Ragnarök." > > Actually, most operators *want* new capabilities, new services, new media types, etc. They're stuck in many cases because of legacy deployed gear, no doubt, but they really do want to provide better and newer stuff. They want the new capabilities that they can monetize. But if its some new capability that can be realized by cooperation by the two ends, with just a "dumb pipe" connection, then there is no motivation to remove inhibitions. And don't get me wrong - I think its a fine thing for SPs to monetize added value services that really add value that the callers want enough to pay for. Thanks, Paul From pkyzivat@cisco.com Thu Mar 25 11:50:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106E83A68D1 for ; Thu, 25 Mar 2010 11:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpa43CbTwsd5 for ; Thu, 25 Mar 2010 11:50:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BCA503A6895 for ; Thu, 25 Mar 2010 11:50:14 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHNNq0urR7Ht/2dsb2JhbACbKHOmMJkThH0E X-IronPort-AV: E=Sophos;i="4.51,309,1267401600"; d="scan'208";a="105835547" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2010 18:50:37 +0000 Received: from [10.21.91.15] (sjc-vpn5-783.cisco.com [10.21.91.15]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2PIobdr015436; Thu, 25 Mar 2010 18:50:37 GMT Message-ID: <4BABB07B.9030805@cisco.com> Date: Thu, 25 Mar 2010 14:50:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> In-Reply-To: <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, Gerold Pinker , Liess Laura Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:50:16 -0000 I've been thinking about how the "namespace" of alert-info URNs might be reorganized. My goals in doing so are: - allow the different "aspects" of the alert to be specified - make it clear what the combination rules are for these - allow for comparable expressiveness for rings and ringbacks - provide room for extension The following is a rough outline of a what I have in mind: The urn syntax is as in the current draft, *except*: alert-category = "reason" / "priority" / "source" / "duration" / "delay" / "locale" / extension-category extension-category = token The principle for choosing these categories is that they are orthogonal. Hence there is a single rule for well-formedness of Alert-Info: there can be at most one instance of each alert-category, and in principle any such combination is valid. (Though some may be silly or uninteresting.) The above doesn't distinguish ring from ringback. That is to be determined from context - when present in a request it describes the ring. When present in a response it describes the ringback. Again, in principle any combination can be used for either ring or ringback, though some combinations may be silly or uninteresting. The exact way in which the various categories are combined for rendering is left as an implementation issue. The implementation is free to ignore any or all at its whim. Its my intent that things previously discussed in the draft can all be mapped onto these categories. Here is my swag at doing so: urn:alert:reason: - normal (default) - call-waiting - forward - auto-callback - recall.hold - recall.transfer - private. urn:alert:priority: - normal (default) - low - high - crisis - private. urn:alert:source: - unclassified (default) - internal - external - friend - family - private. urn:alert:duration: - normal (default) - short (or could be "zip") - long (for completeness, or omit if unneeded) - private. urn:alert:delay: - none (default) - yes (not sure what to put here) - private. urn:alert:locale: - default (default) - country. - private. In the above the "private." syntax is for extensions specific to independent organizations. The is in the form of a "reverse FQDN" such as is used for Java package names. This gives a way of assigning unique names without the need for a new registry. The namespace for each alert category is independent. Those assigning new names must ensure they are in a position to assign names uniquely for the FQDN they choose. (I have considerable reservation about introducing such an uncontrolled extension mechanism. I see how it can provide a lot of flexibility in providing tailored user experiences. But it can also lead to vendor lock in if a device is only capable of supporting a particular vendor's specific extensions. So I think this needs a lot of discussion.) For example, I might want to define: urn:alert:source:private.com.cisco.customer If I were to do so, I should first ensure that I speak for cisco.com when coining this. Additions to the values above other than via the "private" mechanism would be by standards action. The same for adding new categories. (There could be a "private" mechanism for categories too. But I'm not at all confident that is a good thing.) I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem quite right. The reason could still be any of those other things. For the ring indication its far from clear to me that it is needed at all - the recipient already knows it is on a call, and doesn't need to be told that. It may make more sense for the ringback - in that case you are being told something about the state of the other party. Perhaps this should be replaced by something about the state of the party sending the message. E.g. urn:alert:state: - unknown - waiting (in a request, means the caller is waiting for the call to complete. The normal case.) - on-a-call (in a response, means the called party is on another call - the call waiting case. But could apply to a caller as well.) - away (in a request, means the call has been generated automatically and the user will be summoned if/when the call completes. This is the converse of waiting) (This "state" is really a form of presence. Whether its good to encode it here, rather than actually transmitting pidf, is an interesting question.) How all of this might be mapped onto actual renderings is probably not something that should be standardized, but it might be worth including some possibilities as examples. One that comes to mind is: (Assuming all rendering are audio): - the device has a set of possible clips it can render - each is attributed with the values it matches for each category above. (none, one, several, or all for each category.) The device just finds the maximal match and renders that one. This might be augmented if there are different sorts of renderings - e.g. audio, visual, tactile (vibrarion). In that case it might seek out a match for each sort and render them all. Thanks, Paul From laura.liess.dt@googlemail.com Thu Mar 25 18:26:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AB23A6830 for ; Thu, 25 Mar 2010 18:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziyeQXinJhlL for ; Thu, 25 Mar 2010 18:26:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 727C33A68F8 for ; Thu, 25 Mar 2010 18:26:38 -0700 (PDT) Received: by mail-vw0-f44.google.com with SMTP id 12so1708269vws.31 for ; Thu, 25 Mar 2010 18:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=8m3dd4yWV9spOZziJKlVtJqN/tbDVjMS7mcYj2iFEQ0=; b=bcEeXeDFg6MG5sSFsTh7F3aMxcJYFdeAmMeLDZpoSmUg0NldD6+d6qJ+52YPteYHEM JVL/bwwErF/HdxEUUBK4NUVdXCvXz+t5VdHo3XroC54a6/9RE3Ic8X0gwKDL1/qPykgY nE29l5L3898/e/5W9e/a6P0Jj6UEtpvfJsU+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Swt3JTvb6RC1oUpNYOw8En4nET2Fnhvb6LQ1OVUMHI/dCN993jS8qPG6A7187bdzdV AnHA0sGgkomBXmozxHuxHSOLWtu9t8dlY4wDbJ8o77mLbkD46KPJRdTHQFAx/w67YXVA Z+T7eomMjbJ5Ovqp4RehQ4kHaZZyTAjBxYuoE= Received: by 10.220.107.4 with SMTP id z4mr135420vco.27.1269566820562; Thu, 25 Mar 2010 18:27:00 -0700 (PDT) Received: from LauraLiess ([130.129.24.189]) by mx.google.com with ESMTPS id 31sm8189140vws.7.2010.03.25.18.26.53 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 18:26:58 -0700 (PDT) From: Laura Liess To: "'Paul Kyzivat'" , "'Laura Liess'" References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> In-Reply-To: <4BABB07B.9030805@cisco.com> Date: Fri, 26 Mar 2010 02:26:51 +0100 Message-ID: <4bac0d62.9f15f10a.6892.1325@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMTA/pFr3Ua0neQR2Mi1JmxHe+jQANugmg Content-Language: de Cc: dispatch@ietf.org, "'Martin.Huelsemann@telekom.de'"@core3.amsl.com, "'R.Jesske@telekom.de'"@core3.amsl.com, 'Liess Laura' , 'Gerold Pinker' Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 01:26:41 -0000 Paul, Thank you for the proposal and the elaborate description. I definitively like it. It seems to solve the combinations problem, it is extensible and easy to understand.=20 I have two comments on it, connected to "call-waiting". 1) It seems to me that there is some misunderstanding concerning the = meaning of the "call-waiting" alert urn. It is not the callee's presence state, = but the state of the call itself. The "call-waiting" tone tells the caller: "Your call is temporary queued (waiting) at the callee's side because = the callee is currently involved in another call. The callee was informed = that your call is waiting." Having this information, the caller can decide to wait for a while or to cancel the call. This is an already existing PSTN-service which customers expect us to provide also when we migrate = to SIP. Because this urn tells the user that the service "call-waiting" was performed at the other side of the call, we name "service" was choosed = for this category.=20 2) There are already implementations of urn:alert:service:call-waiting. = This syntax is used in the 3GPP Specification for the call-waiting service = (TS 24.615 "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem"). If we change this name, people either change their software, which means money and time for them, or they leave it as it = is, which means lack of interoperability e2e. The "reason"-category contains = in principles names for services, so I think it does not harm the proposal = if we just replace "reason" by "service" and keep the interoperability with existing implementations. Thanks a lot Laura -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Gesendet: Donnerstag, 25. M=E4rz 2010 19:51 An: Laura Liess Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold = Pinker Betreff: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt I've been thinking about how the "namespace" of alert-info URNs might be = reorganized. My goals in doing so are: - allow the different "aspects" of the alert to be specified - make it clear what the combination rules are for these - allow for comparable expressiveness for rings and ringbacks - provide room for extension The following is a rough outline of a what I have in mind: The urn syntax is as in the current draft, *except*: alert-category =3D "reason" / "priority" / "source" / "duration" / "delay" / "locale" / extension-category extension-category =3D token The principle for choosing these categories is that they are orthogonal. = Hence there is a single rule for well-formedness of Alert-Info: there can be at most one instance of each alert-category, and in=20 principle any such combination is valid. (Though some may be silly or=20 uninteresting.) The above doesn't distinguish ring from ringback. That is to be=20 determined from context - when present in a request it describes the=20 ring. When present in a response it describes the ringback. Again, in=20 principle any combination can be used for either ring or ringback,=20 though some combinations may be silly or uninteresting. The exact way in which the various categories are combined for rendering = is left as an implementation issue. The implementation is free to ignore = any or all at its whim. Its my intent that things previously discussed in the draft can all be=20 mapped onto these categories. Here is my swag at doing so: urn:alert:reason: - normal (default) - call-waiting - forward - auto-callback - recall.hold - recall.transfer - private. urn:alert:priority: - normal (default) - low - high - crisis - private. urn:alert:source: - unclassified (default) - internal - external - friend - family - private. urn:alert:duration: - normal (default) - short (or could be "zip") - long (for completeness, or omit if unneeded) - private. urn:alert:delay: - none (default) - yes (not sure what to put here) - private. urn:alert:locale: - default (default) - country. - private. In the above the "private." syntax is for extensions=20 specific to independent organizations. The is in the form = of a "reverse FQDN" such as is used for Java package names. This gives a = way of assigning unique names without the need for a new registry. The=20 namespace for each alert category is independent. Those assigning new=20 names must ensure they are in a position to assign names uniquely for=20 the FQDN they choose. (I have considerable reservation about introducing such an uncontrolled=20 extension mechanism. I see how it can provide a lot of flexibility in=20 providing tailored user experiences. But it can also lead to vendor lock = in if a device is only capable of supporting a particular vendor's=20 specific extensions. So I think this needs a lot of discussion.) For example, I might want to define: urn:alert:source:private.com.cisco.customer If I were to do so, I should first ensure that I speak for cisco.com=20 when coining this. Additions to the values above other than via the "private" mechanism=20 would be by standards action. The same for adding new categories. (There could be a "private" mechanism for categories too. But I'm not at = all confident that is a good thing.) I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem=20 quite right. The reason could still be any of those other things. For=20 the ring indication its far from clear to me that it is needed at all -=20 the recipient already knows it is on a call, and doesn't need to be told = that. It may make more sense for the ringback - in that case you are=20 being told something about the state of the other party. Perhaps this=20 should be replaced by something about the state of the party sending the = message. E.g. urn:alert:state: - unknown - waiting (in a request, means the caller is waiting for the call to complete. The normal case.) - on-a-call (in a response, means the called party is on another call - the call waiting case. But could apply to a caller as well.) - away (in a request, means the call has been generated automatically and the user will be summoned if/when the call completes. This is the converse of waiting) (This "state" is really a form of presence. Whether its good to encode=20 it here, rather than actually transmitting pidf, is an interesting=20 question.) How all of this might be mapped onto actual renderings is probably not=20 something that should be standardized, but it might be worth including=20 some possibilities as examples. One that comes to mind is: (Assuming all rendering are audio): - the device has a set of possible clips it can render - each is attributed with the values it matches for each category above. (none, one, several, or all for each category.) The device just finds the maximal match and renders that one. This might be augmented if there are different sorts of renderings -=20 e.g. audio, visual, tactile (vibrarion). In that case it might seek out=20 a match for each sort and render them all. Thanks, Paul From pkyzivat@cisco.com Thu Mar 25 19:02:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C853A6872 for ; Thu, 25 Mar 2010 19:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvvMtMy-lx7H for ; Thu, 25 Mar 2010 19:02:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 445E53A67AF for ; Thu, 25 Mar 2010 19:02:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADqyq0tAaHte/2dsb2JhbACOdow0c6UqmRCCVYIoBA X-IronPort-AV: E=Sophos;i="4.51,310,1267401600"; d="scan'208";a="105992115" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2010 02:02:22 +0000 Received: from [10.21.148.186] (sjc-vpn7-1210.cisco.com [10.21.148.186]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2Q22KIL019367; Fri, 26 Mar 2010 02:02:20 GMT Message-ID: <4BAC15AB.8090308@cisco.com> Date: Thu, 25 Mar 2010 22:02:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <8b95410e1003050437w70a3fc51mbb965fcc1e1f22db@mail.gmail.com> <4B912555.4020604@cisco.com> <8b95410e1003180857u59bbe073mf172949f87351a9e@mail.gmail.com> <4BA2BBD3.8020702@cisco.com> <8b95410e1003190543s5aac608ct85c7d9747e5a48b9@mail.gmail.com> <4BABB07B.9030805@cisco.com> <4bac0d62.9f15f10a.6892.1325@mx.google.com> In-Reply-To: <4bac0d62.9f15f10a.6892.1325@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org, "R.Jesske@telekom.de" , "Huelsemann, Martin" , 'Gerold Pinker' Subject: Re: [dispatch] FW: I-D Action:draft-liess-dispatch-alert-info-urns-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 02:02:02 -0000 Laura Liess wrote: > Paul, > > Thank you for the proposal and the elaborate description. I definitively > like it. > It seems to solve the combinations problem, it is extensible and easy to > understand. > I have two comments on it, connected to "call-waiting". > > 1) It seems to me that there is some misunderstanding concerning the meaning > of the "call-waiting" alert urn. It is not the callee's presence state, but > the state of the call itself. The "call-waiting" tone tells the caller: > "Your call is temporary queued (waiting) at the callee's side because the > callee is currently involved in another call. The callee was informed that > your call is waiting." Having this information, the caller can decide to > wait for a while or to cancel the call. This is an already existing > PSTN-service which customers expect us to provide also when we migrate to > SIP. > Because this urn tells the user that the service "call-waiting" was > performed at the other side of the call, we name "service" was choosed for > this category. I wasn't sure from the draft whether this was about the ringback to the caller (which is what you are describing), or whether it was about the "ring" to the callee, which is of typically different in this case. As I noted, I didn't think it made that much sense as an indication to the callee, since the callee knows its status. So I think we are in agreement about the important use - for ringback when the callee is currently handling another call. As I was writing things down I realized that this is really a statement about the state of the callee that happens to be known to the UAS and hence reportable. I realize in the commonly used case this is a "service" in the network, and hence is different from a feature of the UAS - such as a multi-line phone. But the two are functionally equivalent to both the caller and the callee - the callee is occupied on some other call, and may (or may not) be delayed in answering. (Whether this delay is likely to be longer, or shorter, than would be the case if not on another call, is debatable. I guess just reporting it to the caller as a datum does permit the caller to make his own judgement. If this is reported as a distinct category, then it can be reported in an orthogonal way. For instance maybe the ringback will be "normal" but there will be a display on the phone - perhaps akin to a "on hold" light. > 2) There are already implementations of urn:alert:service:call-waiting. This > syntax is used in the 3GPP Specification for the call-waiting service (TS > 24.615 "Communication Waiting (CW) using IP Multimedia (IM) Core Network > (CN) subsystem"). If we change this name, people either change their > software, which means money and time for them, or they leave it as it is, > which means lack of interoperability e2e. The "reason"-category contains in > principles names for services, so I think it does not harm the proposal if > we just replace "reason" by "service" and keep the interoperability with > existing implementations. How to name things is a second order issue. If its just a matter of "service" vs. "reason" then I don't care very much. (I'm not especially attached to "reason", but I also find "service" somewhat confusing for the purpose.) The orthogonality is more important. The way I partitioned the data is just a first cut, and I'm entirely open to alternative ways of doing that. But I would hate to see the categorization warped just to fit one preexisting use. IMO it would make more sense to special-case that one - perhaps treat it as a separate category of its own. Thanks, Paul > Thanks a lot > Laura > > > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Donnerstag, 25. März 2010 19:51 > An: Laura Liess > Cc: alan.b.johnston@gmail.com; dispatch@ietf.org; Liess Laura; Gerold Pinker > Betreff: Re: [dispatch] FW: I-D > Action:draft-liess-dispatch-alert-info-urns-01.txt > > I've been thinking about how the "namespace" of alert-info URNs might be > reorganized. My goals in doing so are: > - allow the different "aspects" of the alert to be specified > - make it clear what the combination rules are for these > - allow for comparable expressiveness for rings and ringbacks > - provide room for extension > > The following is a rough outline of a what I have in mind: > > The urn syntax is as in the current draft, *except*: > > alert-category = "reason" / "priority" / "source" / > "duration" / "delay" / "locale" / > extension-category > extension-category = token > > The principle for choosing these categories is that they are orthogonal. > Hence there is a single rule for well-formedness of Alert-Info: > there can be at most one instance of each alert-category, and in > principle any such combination is valid. (Though some may be silly or > uninteresting.) > > The above doesn't distinguish ring from ringback. That is to be > determined from context - when present in a request it describes the > ring. When present in a response it describes the ringback. Again, in > principle any combination can be used for either ring or ringback, > though some combinations may be silly or uninteresting. > > The exact way in which the various categories are combined for rendering > is left as an implementation issue. The implementation is free to ignore > any or all at its whim. > > Its my intent that things previously discussed in the draft can all be > mapped onto these categories. Here is my swag at doing so: > > urn:alert:reason: > > - normal (default) > - call-waiting > - forward > - auto-callback > - recall.hold > - recall.transfer > - private. > > urn:alert:priority: > > - normal (default) > - low > - high > - crisis > - private. > > urn:alert:source: > > - unclassified (default) > - internal > - external > - friend > - family > - private. > > urn:alert:duration: > > - normal (default) > - short (or could be "zip") > - long (for completeness, or omit if unneeded) > - private. > > urn:alert:delay: > > - none (default) > - yes (not sure what to put here) > - private. > > urn:alert:locale: > > - default (default) > - country. > - private. > > In the above the "private." syntax is for extensions > specific to independent organizations. The is in the form > of a "reverse FQDN" such as is used for Java package names. This gives a > way of assigning unique names without the need for a new registry. The > namespace for each alert category is independent. Those assigning new > names must ensure they are in a position to assign names uniquely for > the FQDN they choose. > > (I have considerable reservation about introducing such an uncontrolled > extension mechanism. I see how it can provide a lot of flexibility in > providing tailored user experiences. But it can also lead to vendor lock > in if a device is only capable of supporting a particular vendor's > specific extensions. So I think this needs a lot of discussion.) > > For example, I might want to define: > > urn:alert:source:private.com.cisco.customer > > If I were to do so, I should first ensure that I speak for cisco.com > when coining this. > > Additions to the values above other than via the "private" mechanism > would be by standards action. The same for adding new categories. > (There could be a "private" mechanism for categories too. But I'm not at > all confident that is a good thing.) > > I'm not quite sure about "call-waiting" as a "reason" - it doesn't seem > quite right. The reason could still be any of those other things. For > the ring indication its far from clear to me that it is needed at all - > the recipient already knows it is on a call, and doesn't need to be told > that. It may make more sense for the ringback - in that case you are > being told something about the state of the other party. Perhaps this > should be replaced by something about the state of the party sending the > message. E.g. > > urn:alert:state: > > - unknown > - waiting (in a request, means the caller is waiting > for the call to complete. The normal case.) > - on-a-call (in a response, means the called party > is on another call - the call waiting case. > But could apply to a caller as well.) > - away (in a request, means the call has been generated > automatically and the user will be summoned if/when > the call completes. This is the converse of waiting) > > (This "state" is really a form of presence. Whether its good to encode > it here, rather than actually transmitting pidf, is an interesting > question.) > > How all of this might be mapped onto actual renderings is probably not > something that should be standardized, but it might be worth including > some possibilities as examples. One that comes to mind is: > > (Assuming all rendering are audio): > > - the device has a set of possible clips it can render > - each is attributed with the values it matches for each > category above. (none, one, several, or all for each > category.) > > The device just finds the maximal match and renders that one. > > This might be augmented if there are different sorts of renderings - > e.g. audio, visual, tactile (vibrarion). In that case it might seek out > a match for each sort and render them all. > > Thanks, > Paul > > From mary.ietf.barnes@gmail.com Fri Mar 26 10:49:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9D93A6BA9 for ; Fri, 26 Mar 2010 10:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 VfyfU0zr8wLs for ; Fri, 26 Mar 2010 10:49:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0DF743A681C for ; Fri, 26 Mar 2010 10:49:29 -0700 (PDT) Received: by pvh1 with SMTP id 1so5006831pvh.31 for ; Fri, 26 Mar 2010 10:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=eVqYY58aSaSOU6JIKXRa1SNO7IuJdX7MwVAYAJyAF8c=; b=KZ4CkoOjLrzhDJiGPJMlSXGPLzfYGyxGLAsFd523/iaX20sW2HnJ782gPtxbSmIWGY McjuUL9W54vbKmglAog7I/Ah9H45qkb/YcmTJC3qO9Ay/YNINNhwyLFrRAC436/fDIQC CADmDbs7y9jDUbSCKBA31xlDnsMzsqVEz9vLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=wVWkKRp0m9e9a8FHKlLBl27PwR9vXHA8f356Hi2ZRgysFaLfjKQuE0dLlx38mUzjIV l/8EMhARwGI5L0T2y6TA4l+eT+X837lxPCd+7nbJYZImfK7aiQFKBN/XJUAqu28xYv1B uMJvOcKjT5q7lShKnXH2JgaZTfhKdoRSx8V9Y= MIME-Version: 1.0 Received: by 10.231.169.65 with HTTP; Fri, 26 Mar 2010 10:49:52 -0700 (PDT) Date: Fri, 26 Mar 2010 12:49:52 -0500 Received: by 10.141.3.3 with SMTP id f3mr1233246rvi.215.1269625792865; Fri, 26 Mar 2010 10:49:52 -0700 (PDT) Message-ID: <184b5e71003261049x5566aa37y7caeeed8f91533e@mail.gmail.com> From: Mary Barnes To: sipclf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: dispatch@ietf.org Subject: [dispatch] DISPATCH WG deadlines for IETF-78 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 17:49:29 -0000 Hi folks, Per the discussion in the SIPCLF WG this morning, the following are the deadlines for topics for DISPATCH for IETF-78: * May 17th, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline] * May 31st, 2010. Cutoff for charter proposals for topics. [One day prior to BoF proposal deadline] * June 7th, 2010. Topics that are to be the focus of IETF-78 are announced. [One week before AD BoF approval and deadline to request WG slot] * July 5th, 2010. -00 draft deadline. * July 12th, 2010. Draft deadline. These deadlines have been published on the DISPATCH WG wiki page: http://trac.tools.ietf.org/wg/dispatch/trac/wiki Regards, Mary DISPATCH WG co-chair From adam@nostrum.com Mon Mar 29 08:35:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB173A6A84 for ; Mon, 29 Mar 2010 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDKaZrY3wGnT for ; Mon, 29 Mar 2010 08:35:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C01593A6405 for ; Mon, 29 Mar 2010 08:35:22 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2TFZeTU022193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2010 10:35:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB0C8CC.6080009@nostrum.com> Date: Mon, 29 Mar 2010 10:35:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Henning Schulzrinne References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> <1269466329.2149.311.camel@localhost> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000803090600030201030502" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:35:24 -0000 This is a multi-part message in MIME format. --------------000803090600030201030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I tend to agree with Henning on all the points he raises below, and want to expand just a little bit. The use of ITADs has in no way confused people participating in the Freenum trial into thinking that TRIP was required or even an option. In fact, the separation of ITAD from TRIP in that experiment is so inherently clear that freenum.org doesn't even feel the need to discuss the hypothesized confusion in their FAQ (http://freenum.org/faq.html). Unless we expect a materially dimmer group of people to be consumers of the SIP Forum's output, there is historical information that TRIP conflation concerns are unfounded. In addition to the points that Henning raised, I'm a bit confused by the assertion that the use of "freenum.org" does not scale, given that it is modeled on the general DNS delegation model, and is basically the same mechanism as ENUM uses. The current sipforum draft appears to counter-propose the use of a single, flat, non-delegated database at "sipforum.org." Could you clarify how trading a hierarchical, distributed database technology that provides domain naming services for approximately 400 million Internet hosts will have inferior scaling properties when compared against what is presumably a flat relational database hosted by SIPForum? /a On 3/24/10 4:37 PM, Henning Schulzrinne wrote: >> >> The attached is a problem statement I drafted for the SIP Forum Board >> that summarized the issues raised in the task group and from some >> external reviewers. > > To quote: > > The administrative and legal infrastructure of using the existing > first-come first-served ITAD registry at IANA is not sufficient > for the needs of commercial service providers. > > * No reasons are given for this determination. > > Using the existing ITAD name and registry may create confusion > regarding whether or not other parts of the protocols and > procedures in the TRIP specification and/or the ISN/Freenum trial > are also applicable (the intent is that no other part of these > other specifications and procedures be used). > > * I admit that I find this speculative. As long as the mechanism is > clear, the users of the DNS record won't care. > > The ITAD number is defined as a 32 bit number. > > * This translates into (roughly) a 9-digit decimal integer. It seems > rather unlikely that we would exceed 4 billion service providers or > that we'd want longer identifiers than 9 digits. > > In general, I agree that the ITAD registry would have to be expanded > and the use clarified, but re-use of the same registry (say, > enterprise numbers) for different purposes is not unusual. > > Henning > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --------------000803090600030201030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I tend to agree with Henning on all the points he raises below, and want to expand just a little bit.

The use of ITADs has in no way confused people participating in the Freenum trial into thinking that TRIP was required or even an option. In fact, the separation of ITAD from TRIP in that experiment is so inherently clear that freenum.org doesn't even feel the need to discuss the hypothesized confusion in their FAQ (http://freenum.org/faq.html). Unless we expect a materially dimmer group of people to be consumers of the SIP Forum's output, there is historical information that TRIP conflation concerns are unfounded.

In addition to the points that Henning raised, I'm a bit confused by the assertion that the use of "freenum.org" does not scale, given that it is modeled on the general DNS delegation model, and is basically the same mechanism as ENUM uses. The current sipforum draft appears to counter-propose the use of a single, flat, non-delegated database at "sipforum.org." Could you clarify how trading a hierarchical, distributed database technology that provides domain naming services for approximately 400 million Internet hosts will have inferior scaling properties when compared against what is presumably a flat relational database hosted by SIPForum?

/a

On 3/24/10 4:37 PM, Henning Schulzrinne wrote:

The attached is a problem statement I drafted for the SIP Forum Board
that summarized the issues raised in the task group and from some
external reviewers.

To quote:

The administrative and legal infrastructure of using the existing
     first-come first-served ITAD registry at IANA is not sufficient
     for the needs of commercial service providers.

* No reasons are given for this determination.

 Using the existing ITAD name and registry may create confusion
     regarding whether or not other parts of the protocols and
     procedures in the TRIP specification and/or the ISN/Freenum trial
     are also applicable (the intent is that no other part of these
     other specifications and procedures be used).

* I admit that I find this speculative. As long as the mechanism is clear, the users of the DNS record won't care.

The ITAD number is defined as a 32 bit number.

* This translates into (roughly) a 9-digit decimal integer. It seems rather unlikely that we would exceed 4 billion service providers or that we'd want longer identifiers than 9 digits.

In general, I agree that the ITAD registry would have to be expanded and the use clarified, but re-use of the same registry (say, enterprise numbers) for different purposes is not unusual.

Henning


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------000803090600030201030502-- From xmlscott@gmail.com Mon Mar 29 13:52:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7323A6AAC for ; Mon, 29 Mar 2010 13:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 O5Fx1wIwTXmn for ; Mon, 29 Mar 2010 13:52:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9EF373A6B77 for ; Mon, 29 Mar 2010 13:50:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id z0ha1d0041ZXKqc538pFaZ; Mon, 29 Mar 2010 20:49:15 +0000 Received: from [192.168.10.10] ([98.229.134.198]) by omta21.westchester.pa.mail.comcast.net with comcast id z8uj1d0074H02bE3h8ujRN; Mon, 29 Mar 2010 20:54:43 +0000 From: Scott Lawrence To: Adam Roach In-Reply-To: <4BB0C8CC.6080009@nostrum.com> References: <20100323161249.21FDA3A6A55@core3.amsl.com> <4BAA55A6.6030600@softarmor.com> <1269459664.2149.294.camel@localhost> <9DAF1F09-7EEE-48F7-A0B6-DAE48F87ACC4@cs.columbia.edu> <1269466329.2149.311.camel@localhost> <4BB0C8CC.6080009@nostrum.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Mar 2010 16:51:18 -0400 Message-ID: <1269895878.2053.147.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-lawrence-sipforum-provider-alias-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:52:48 -0000 (changed the subject line to accurately reflect the draft being discussed) On Mon, 2010-03-29 at 10:35 -0500, Adam Roach wrote: > The use of ITADs has in no way confused people participating in the > Freenum trial into thinking that TRIP was required or even an option. > In fact, the separation of ITAD from TRIP in that experiment is so > inherently clear that freenum.org doesn't even feel the need to > discuss the hypothesized confusion in their FAQ > (http://freenum.org/faq.html). Unless we expect a materially dimmer > group of people to be consumers of the SIP Forum's output, there is > historical information that TRIP conflation concerns are unfounded. I don't personally think that this is the most important of the problems, but we did get people asking questions about this - more were about how the new usage related to what Freenum.org is doing than about TRIP. Which serves to highlight that while the ITAD registry identifies domains, that ISN does is _not_ the same as what this draft proposes. The ISN dialing transform takes as input a dial string (usually carried as the user part of a sip uri) into a full sip uri - the input has both a domain identifier and a local part to be resolved in that domain. This draft proposes a transform of one domain name into another, to be used not for routing any sip request, but for subsequent resolution (also through the DNS) into an http url. When I was editing the SIP Forum task group draft, the difference was brought home to me by the fact that there was no ISN 'standard' I could claim to be profiling for this - we were doing an entirely different operation for a significantly different purpose. Of course, as it turned out the Board decided we needed to take the whole thing elsewhere to be made a standard anyway... > In addition to the points that Henning raised, I'm a bit confused by > the assertion that the use of "freenum.org" does not scale, given that > it is modeled on the general DNS delegation model, and is basically > the same mechanism as ENUM uses. I wasn't saying that DNS doesn't scale - I said that the _current_ freenum.org infrastructure was not appropriate to the needs of commercial service providers. Not a protocol issue at all. Suppose that you are selling a small business or consumer phone service, and you are relying on the (appropriately simple) instruction that the customer set up a phone by entering '555' (your alias) when connecting a new phone. If it doesn't work because the translation can't be done, do you think that the average small business person or consumer will blame the operator of the DNS service or you? The current freenum.org infrastructure is some non-profit research institutions and universities; a fine thing and a great organization. That doesn't make it appropriate as a key component in commercial services (if there are significant commercial deployments of ISN I am not aware of them, and if they are making money then I want to meet their sales people). The current sipforum draft appears to counter-propose the use of a single, flat, non-delegated database at "sipforum.org." If you read it as proposing any such thing, then I accept that editorial work is needed (if you can divine how you got that idea, please point out text). It proposes the use of DNS NAPTR lookups with all the marvelous scaling and redundancy properties you so justifiably admire. As for 'sipforum.org', the draft says: The lookup key for the S-NAPTR request is the Provider Alias Number concatenated with a fixed root suffix (for the purposes of this initial draft, the value ".pan.sipforum.org." is used) to form a DNS domain name. ... the key words here being 'a fixed suffix (for the purposes of this initial draft'... The actual value chosen can be anything, but it seemed clearer to use a real example. No one (most emphatically including the SIP Forum itself) believes that the Forum is the appropriate organization to actually operate the resolution infrastructure regardless of the domain name chosen as the fixed suffix. Personally, I think that the most important reason not to use ITADs or freenum.org was the first one I listed: * The administrative and legal infrastructure of using the existing first-come first-served ITAD registry at IANA is not sufficient for the needs of commercial service providers. If I were a service provider and was going to count on this to provide me with that vital first connection service, I'd want to know that the rules on how registrations were added to and modified in the registry were subject to carefully spelled out contractual terms with enforceable agreements as to service levels. I'd want to know that that asset could be transferred under well specified terms. RFC 3219 has no such infrastructure. From richard@shockey.us Mon Mar 29 15:18:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443DC3A68FE for ; Mon, 29 Mar 2010 15:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9cXjVN5NVqv for ; Mon, 29 Mar 2010 15:18:24 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id AA4A03A6822 for ; Mon, 29 Mar 2010 15:18:24 -0700 (PDT) Received: (qmail 6703 invoked by uid 0); 29 Mar 2010 22:18:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 29 Mar 2010 22:18:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=FpK+fxO+0HQ5OwOA1yhqSoFvmFICz/0Zf0ALJ5hrxOI2l4aMXvKw1TwMbbxUlFDSMGRZK4jtAFZ2HNgl+800V39qYigvncetOBshSLB6yGzl/s7QGEvTuPEBhq2j1LHt; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NwNIK-0007hX-G0 for dispatch@ietf.org; Mon, 29 Mar 2010 16:18:52 -0600 From: "Richard Shockey" To: Date: Mon, 29 Mar 2010 18:18:48 -0400 Message-ID: <020901cacf8d$ce8d5e30$6ba81a90$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020A_01CACF6C.477BBE30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPjc3yNxrpbWI5SDS9vpNf3MRfTg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: [dispatch] draft-lawrence-sipforum-provider-alias-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 22:18:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_020A_01CACF6C.477BBE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott accurately described what I believe is the business case for the SIP Forum to sponsor such a registry, though that decision has not been made yet. The SIP Forum would NEVER actually operate the registry. There are lots of companies that can do that. The PAN registry IMHO needs the kind of strong contractual agreements common to operators of ICANN TLD's for instance or public / private ENUM registries. ... the key words here being 'a fixed suffix (for the purposes of this initial draft'... The actual value chosen can be anything, but it seemed clearer to use a real example. No one (most emphatically including the SIP Forum itself) believes that the Forum is the appropriate organization to actually operate the resolution infrastructure regardless of the domain name chosen as the fixed suffix. Personally, I think that the most important reason not to use ITADs or freenum.org was the first one I listed: * The administrative and legal infrastructure of using the existing first-come first-served ITAD registry at IANA is not sufficient for the needs of commercial service providers. If I were a service provider and was going to count on this to provide me with that vital first connection service, I'd want to know that the rules on how registrations were added to and modified in the registry were subject to carefully spelled out contractual terms with enforceable agreements as to service levels. I'd want to know that that asset could be transferred under well specified terms. RFC 3219 has no such infrastructure. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_020A_01CACF6C.477BBE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott accurately described what I believe is the = business case for the SIP Forum to sponsor such a registry, though that decision = has not been made yet. The SIP Forum would NEVER actually operate the registry. = There are lots of companies that can do that.

 

The PAN registry IMHO needs the kind of strong = contractual agreements common to operators of ICANN TLD’s for instance or = public / private ENUM registries.

 

 

 

... the key words here being 'a fixed suffix = (for the purposes of this

initial draft'...  The actual value chosen = can be anything, but it

seemed clearer to use a real example.  No = one (most emphatically

including the SIP Forum itself) believes that = the Forum is the

appropriate organization to actually operate the resolution

infrastructure regardless of the domain name = chosen as the fixed suffix.

 

Personally, I think that the most important = reason not to use ITADs or

freenum.org was the first one I = listed:

 

   * The administrative and legal = infrastructure of using the existing

     first-come first-served = ITAD registry at IANA is not sufficient

     for the needs of = commercial service providers.

 

If I were a service provider and was going to = count on this to provide

me with that vital first connection service, I'd = want to know that the

rules on how registrations were added to and = modified in the registry

were subject to carefully spelled out = contractual terms with enforceable

agreements as to service levels.  I'd want = to know that that asset could

be transferred under well specified terms.  = RFC 3219 has no such

infrastructure. 

 

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_020A_01CACF6C.477BBE30-- From ranjit@motorola.com Tue Mar 30 03:10:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C115A3A6816 for ; Tue, 30 Mar 2010 03:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph+gCUQ5A8jG for ; Tue, 30 Mar 2010 03:09:59 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 982DD3A67F5 for ; Tue, 30 Mar 2010 03:09:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-55.messagelabs.com!1269943823!98683462!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32411 invoked from network); 30 Mar 2010 10:10:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Mar 2010 10:10:23 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o2UAANZ4022178 for ; Tue, 30 Mar 2010 03:10:23 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o2UAANsp027408 for ; Tue, 30 Mar 2010 05:10:23 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o2UAALWi027405 for ; Tue, 30 Mar 2010 05:10:22 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 18:09:59 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A4025E5@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BF26B@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] thread-index: AcrE97SxRQxwegjHTZaBVdJ72ODDEQE7CZ8gAYNO8EA= References: <4B7EF1DA.60002@cisco.com> <4B7F1368.6040603@cisco.com><4B7F223D.3080008@cisco.com> <4B7F2CFD.8070901@cisco.com><4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com><750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com><4B9F6475.2030002@ericsson.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BF26B@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Gonzalo Camarillo" , "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 10:10:00 -0000 Hi All Any update on this I-D? Thanks=20 Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, March 22, 2010 10:53 PM To: Gonzalo Camarillo Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Hi Gonzalo, Paul=20 I have uploaded the updated version of the I-D.=20 It can be accessed from: http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-04 .txt Please review and comment Thanks Regards Ranjit -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Tuesday, March 16, 2010 4:29 PM To: Avasarala Ranjit-A20990 Cc: Paul Kyzivat; dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] Hi Ranjit, there is a blackout period before IETF meetings in which one cannot submit drafts. Please, submit this version as soon as the blackout period is over and have Paul have a look at it so that he can confirm he is happy with it. Thanks, Gonzalo On 11/03/2010 8:10 PM, Avasarala Ranjit-A20990 wrote: > Hi All >=20 > I am not able to upload the updated version (-04) of the I-D due to=20 > some issue with the I-D submission tool - (Says I can submit I-D only=20 > on 2010-03-22). > Until then I am attaching a copy of the updated version (txt and html=20 > formats). >=20 > Please review and comment. >=20 > Thanks >=20 > Note: Let me know if there is any other way to upload the I-D document > and will be happy to do it. >=20 >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, March 02, 2010 7:19 PM > To: Avasarala Ranjit-A20990 > Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review=20 > ofdraft-avasarala-dispatch-comm-div-notification-03] >=20 > I think this all sounds good now. >=20 > Thanks, > Paul >=20 > Avasarala Ranjit-A20990 wrote: >> Inline >> >> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, March 02, 2010 2:16 AM >> To: Avasarala Ranjit-A20990 >> Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org >> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review >> ofdraft-avasarala-dispatch-comm-div-notification-03] >> >> inline... >> >> Avasarala Ranjit-A20990 wrote: >> >>> I'm still a little confused here. >>> If phone is on and subscription is active, then in general=20 >>> notification should be possible, regardless of registration. I=20 >>> realize >> >>> IMS doesn't permit that, but from a general standard perspective we=20 >>> shouldn't assume it. The manifestation in this case is that the=20 >>> NOTIFY >> >>> would fail and the subscription would eventually be torn down. >>> >>> So I think the cases are: >>> - there is a subscription and notification works >>> - there is a subscription but notification fails >>> - there is no subscription. >>> >>> Agreed. Actually instead of calling it as=20 >>> Notification fails, we can say - not sending notification due to (1) >>> no match of filter criteria (2) phone not registered or outside=20 >>> coverage area due to which there is no connectivity and hence=20 >>> notification cannot be sent Anyway if no subscription, no >> notification. >> >> Are you suggesting that you might have a subscription, and have the=20 >> filter criteria met, and yet not attempt to send a NOTIFY because the >> phone is not registered or has no network connectivity??? >> >> That seems wrong. ISTM that either you would remove the subscription, >> or else you would try to send the NOTIFY and then discover that it > fails. >> >> yes the subscription could be removed when the device=20 >> is >=20 >> not reachable. >> >> OTOH, this probably ought not to be within scope of what is discussed >> in this draft. >> >> yes true not within the scope of this draft. >> >>>> [3] in the example u suggested where sip:alice@atlanta.org with two >>>> contacts: sip:line1@alice.office.atlanta.com and=20 >>>> sip:line2@alice.home.atlanta.com and >>>> both the phones ring, then it would be a case of parallel >> forking. >>>> Now say one or both the phones have set diversion rules, to divert=20 >>>> the >>> In this case, what does it mean for "one or both phones have set=20 >>> diversion rules"? Does that somehow imply distinct rules for each >> phone? >>> I don't see how that could work. Aren't the diversion rules for the=20 >>> *AOR*? >>> >>> Yes the diversion rules are for AoR. So when there=20 >>> is >> >>> a diversion rule set for the AoR and when diversions occur, the=20 >>> notifications are Sent to the AoR. >> >> Not sent to the AoR - sent to the remote contact of the dialog for=20 >> each subscription to the AoR. Same point as below that you agreed > with. >> >> Yes agree with u. >> >>> I see they could be set/changed from either phone. But its a single=20 >>> set of rules isn't it? So I might set the rules from the office, and >>> then cancel them from home. >>> >>> yes single set and could be set from either of the=20 >>> phones. True. >>> >>>> call to say >>>> sip:voicemail@alice.atlanta.com, then the notifications would=20 >>>> get >> >>>> generated with respect to both the contacts. >>> Again I'm confused by the terminology you use, and how it relates=20 >>> operationally. The diversion happens on the AOR, and the=20 >>> subscriptions >> >>> are on the AOR, and the notifications are sent to the subscribers. I >>> don't see where the registered contacts enter into the picture at > all. >>> >>> Ya agree with you on this. Sorry for the confusion. >>> >>> If you have something else in mind, I hope you can explain it better >>> in the draft. >>> >>>> [4] Yes the value of N is configurable and depends on how many=20 >>>> diversions the subscribe wants to keep or could be dependent on=20 >>>> server policy (some maximum >>>> number). If the server policy is to send notifications as and=20 >>>> when they occur and not keep any divsersions information, then the=20 >>>> value of last N >>>> diversions will be zero. But if the server chooses to retain=20 >>>> the >=20 >>>> last diversion always, then the value of N will be 1 and so on. >>> All is straightforward for N>=3D1. >>> >>> For N=3D0 things are messy. If we are modeling this as state, and=20 >>> notifications are about state changes, then the new diversion is=20 >>> added >> >>> to the (previously empty) state and that triggers notifications to=20 >>> all >> >>> current subscriptions. Then if you don't want to retain even this=20 >>> much >> >>> state (because N=3D0) you immediately remove that version from the >> state. >>> But that is again a state change, so you end up with another=20 >>> notification of that state change. >>> >>> True. Actually the notifications are for informing=20 >>> the subscriber of the call diversions that happen. The notifications >>> are not for informing the subscriber of state changes in the=20 >>> notifier >=20 >>> or the number of diversions that occurred. As I mentioned in the=20 >>> abstract as well as 24.604, the main intent of CDIVN service is to=20 >>> inform the subscribers of communication diversions that occur on=20 >>> their >> >>> behalf in the network and this information will help them manage=20 >>> their >> >>> rules better. >> >> I am not certain, but think we may still be talking past one another=20 >> to some extent. >> >> The state can be considered just a formalism for defining the service >> clearly, regardless of whether it has intrinsic value to the CDIV=20 >> service. But it *is* a formalism. So if it is introduced, then its=20 >> behavior can't be ignored when inconvenient. Defining the state with=20 >> N=3D0 leads to some undesired behavior. The simplest way around that = is >> to insist that N be >=3D1. >> >> Ok in that case we can say that value of N >=3D1 and = the=20 >> notifier has always maintains history of last diversion at a minimu. >> It can maintain more than 1 too depending on the policy. >> >> If its important to you that no state be retained once a notification >> has been sent about the most recent diversion, then you will have to=20 >> find some other way to specify the service, that still meets the=20 >> expectations of 3265. I don't know if there is anything there that=20 >> Adam would consider valid. We will have to get his opinion on that. >> >> In that case I am OK maintaining the hostory of=20 >> diversions that occurred as part of state information and retaining=20 >> that state even after the notification for that diversion is sent -=20 >> so >=20 >> that in case I do not get a confirmation, I would be able to re-send > the notification. >> Also maintaining state of diversions would help when the=20 >> notifications >=20 >> need to sent only at a particular time (if fikter criteria mentions > it). >> >> >> Thanks, >> Paul >> >>> But if we want to include the information related=20 >>> to >=20 >>> how many diversions have happened till time (say from 12 AM ) till=20 >>> the >> >>> time the notification is being sent, then as you say we can store=20 >>> the >=20 >>> diversions. This would be useful when the subscriber specifies in=20 >>> the >=20 >>> filter criteria to send notifications only during certain time like=20 >>> between 5 and 6 PM and not whenever a diversion occurs. Then N is=20 >>> grater than 1. >> >>> I presume you don't want that behavior. If you can live with N>=3D1=20 >>> then >> >>> we don't have the problem at all. If you need to support N=3D0 and=20 >>> don't >> >>> want the extra notify, then we have to figure out if there is some=20 >>> trick to how things are modeled to get the desired effect. I've=20 >>> suggested something previously, but Adam didn't like it. >>> >>> This needs sorting out. >>> >>> Thanks, >>> Paul >> _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Tue Mar 30 07:49:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77E63A6BDB for ; Tue, 30 Mar 2010 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.383 X-Spam-Level: X-Spam-Status: No, score=-8.383 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw+CiOS3WYZm for ; Tue, 30 Mar 2010 07:49:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D60A53A6BFB for ; Tue, 30 Mar 2010 07:43:24 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN2qsUtAZnwN/2dsb2JhbACbL3GmVZkZhQAE X-IronPort-AV: E=Sophos;i="4.51,334,1267401600"; d="scan'208";a="97497764" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2010 14:43:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2UEhreM006530; Tue, 30 Mar 2010 14:43:53 GMT Message-ID: <4BB20E2D.2090304@cisco.com> Date: Tue, 30 Mar 2010 10:43:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <4B7EF1DA.60002@cisco.com> <4B7F2CFD.8070901@cisco.com><4B7FFA2B.5080303@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31824D@ZMY16EXM66.ds.mot.com> <4B832169.8090100@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318476@ZMY16EXM66.ds.mot.com> <4B83E1D4.7040108@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318504@ZMY16EXM66.ds.mot.com> <4B8422E6.1060709@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318794@ZMY16EXM66.ds.mot.com> <4B86E6AE.6010308@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A31899F@ZMY16EXM66.ds.mot.com> <4B87DC79.6010104@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318AAF@ZMY16EXM66.ds.mot.com> <4B8C277E.4000701@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A318C2D@ZMY16EXM66.ds.mot.com> <4B8D173C.9070102@cisco.com><750BBC72E178114F9DC4872EBFF29A5B0A37C581@ZMY16EXM66.ds.mot.com><4B9F6475.2030002@ericsson.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BF26B@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A4025E5@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A4025E5@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review ofdraft-avasarala-dispatch-comm-div-notification-03] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:49:01 -0000 Ranjit, Sorry! I was busy last week at ietf. I will try to get to it this week. Paul Avasarala Ranjit-A20990 wrote: > Hi All > > Any update on this I-D? > > Thanks > > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Monday, March 22, 2010 10:53 PM > To: Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminaryversion ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > Hi Gonzalo, Paul > > I have uploaded the updated version of the I-D. > It can be accessed from: > http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-04 > .txt > > Please review and comment > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, March 16, 2010 4:29 PM > To: Avasarala Ranjit-A20990 > Cc: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > ofdraft-avasarala-dispatch-comm-div-notification-03] > > Hi Ranjit, > > there is a blackout period before IETF meetings in which one cannot > submit drafts. Please, submit this version as soon as the blackout > period is over and have Paul have a look at it so that he can confirm he > is happy with it. > > Thanks, > > Gonzalo > > > On 11/03/2010 8:10 PM, Avasarala Ranjit-A20990 wrote: >> Hi All >> >> I am not able to upload the updated version (-04) of the I-D due to >> some issue with the I-D submission tool - (Says I can submit I-D only >> on 2010-03-22). >> Until then I am attaching a copy of the updated version (txt and html >> formats). >> >> Please review and comment. >> >> Thanks >> >> Note: Let me know if there is any other way to upload the I-D document > >> and will be happy to do it. >> >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, March 02, 2010 7:19 PM >> To: Avasarala Ranjit-A20990 >> Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org >> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review >> ofdraft-avasarala-dispatch-comm-div-notification-03] >> >> I think this all sounds good now. >> >> Thanks, >> Paul >> >> Avasarala Ranjit-A20990 wrote: >>> Inline >>> >>> >>> >>> >>> Regards >>> Ranjit >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, March 02, 2010 2:16 AM >>> To: Avasarala Ranjit-A20990 >>> Cc: Anders Kristensen; Adam Roach; dispatch@ietf.org >>> Subject: Re: [dispatch] [Fwd: Re: Preliminary version ofExpert review > >>> ofdraft-avasarala-dispatch-comm-div-notification-03] >>> >>> inline... >>> >>> Avasarala Ranjit-A20990 wrote: >>> >>>> I'm still a little confused here. >>>> If phone is on and subscription is active, then in general >>>> notification should be possible, regardless of registration. I >>>> realize >>>> IMS doesn't permit that, but from a general standard perspective we >>>> shouldn't assume it. The manifestation in this case is that the >>>> NOTIFY >>>> would fail and the subscription would eventually be torn down. >>>> >>>> So I think the cases are: >>>> - there is a subscription and notification works >>>> - there is a subscription but notification fails >>>> - there is no subscription. >>>> >>>> Agreed. Actually instead of calling it as >>>> Notification fails, we can say - not sending notification due to (1) > >>>> no match of filter criteria (2) phone not registered or outside >>>> coverage area due to which there is no connectivity and hence >>>> notification cannot be sent Anyway if no subscription, no >>> notification. >>> >>> Are you suggesting that you might have a subscription, and have the >>> filter criteria met, and yet not attempt to send a NOTIFY because the > >>> phone is not registered or has no network connectivity??? >>> >>> That seems wrong. ISTM that either you would remove the subscription, > >>> or else you would try to send the NOTIFY and then discover that it >> fails. >>> yes the subscription could be removed when the device >>> is >>> not reachable. >>> >>> OTOH, this probably ought not to be within scope of what is discussed > >>> in this draft. >>> >>> yes true not within the scope of this draft. >>> >>>>> [3] in the example u suggested where sip:alice@atlanta.org with two >>>>> contacts: sip:line1@alice.office.atlanta.com and >>>>> sip:line2@alice.home.atlanta.com and >>>>> both the phones ring, then it would be a case of parallel >>> forking. >>>>> Now say one or both the phones have set diversion rules, to divert >>>>> the >>>> In this case, what does it mean for "one or both phones have set >>>> diversion rules"? Does that somehow imply distinct rules for each >>> phone? >>>> I don't see how that could work. Aren't the diversion rules for the >>>> *AOR*? >>>> >>>> Yes the diversion rules are for AoR. So when there >>>> is >>>> a diversion rule set for the AoR and when diversions occur, the >>>> notifications are Sent to the AoR. >>> Not sent to the AoR - sent to the remote contact of the dialog for >>> each subscription to the AoR. Same point as below that you agreed >> with. >>> Yes agree with u. >>> >>>> I see they could be set/changed from either phone. But its a single >>>> set of rules isn't it? So I might set the rules from the office, and > >>>> then cancel them from home. >>>> >>>> yes single set and could be set from either of the >>>> phones. True. >>>> >>>>> call to say >>>>> sip:voicemail@alice.atlanta.com, then the notifications would >>>>> get >>>>> generated with respect to both the contacts. >>>> Again I'm confused by the terminology you use, and how it relates >>>> operationally. The diversion happens on the AOR, and the >>>> subscriptions >>>> are on the AOR, and the notifications are sent to the subscribers. I > >>>> don't see where the registered contacts enter into the picture at >> all. >>>> Ya agree with you on this. Sorry for the confusion. >>>> >>>> If you have something else in mind, I hope you can explain it better > >>>> in the draft. >>>> >>>>> [4] Yes the value of N is configurable and depends on how many >>>>> diversions the subscribe wants to keep or could be dependent on >>>>> server policy (some maximum >>>>> number). If the server policy is to send notifications as and >>>>> when they occur and not keep any divsersions information, then the >>>>> value of last N >>>>> diversions will be zero. But if the server chooses to retain >>>>> the >>>>> last diversion always, then the value of N will be 1 and so on. >>>> All is straightforward for N>=1. >>>> >>>> For N=0 things are messy. If we are modeling this as state, and >>>> notifications are about state changes, then the new diversion is >>>> added >>>> to the (previously empty) state and that triggers notifications to >>>> all >>>> current subscriptions. Then if you don't want to retain even this >>>> much >>>> state (because N=0) you immediately remove that version from the >>> state. >>>> But that is again a state change, so you end up with another >>>> notification of that state change. >>>> >>>> True. Actually the notifications are for informing >>>> the subscriber of the call diversions that happen. The notifications > >>>> are not for informing the subscriber of state changes in the >>>> notifier >>>> or the number of diversions that occurred. As I mentioned in the >>>> abstract as well as 24.604, the main intent of CDIVN service is to >>>> inform the subscribers of communication diversions that occur on >>>> their >>>> behalf in the network and this information will help them manage >>>> their >>>> rules better. >>> I am not certain, but think we may still be talking past one another >>> to some extent. >>> >>> The state can be considered just a formalism for defining the service > >>> clearly, regardless of whether it has intrinsic value to the CDIV >>> service. But it *is* a formalism. So if it is introduced, then its >>> behavior can't be ignored when inconvenient. Defining the state with >>> N=0 leads to some undesired behavior. The simplest way around that is > >>> to insist that N be >=1. >>> >>> Ok in that case we can say that value of N >=1 and the >>> notifier has always maintains history of last diversion at a minimu. >>> It can maintain more than 1 too depending on the policy. >>> >>> If its important to you that no state be retained once a notification > >>> has been sent about the most recent diversion, then you will have to >>> find some other way to specify the service, that still meets the >>> expectations of 3265. I don't know if there is anything there that >>> Adam would consider valid. We will have to get his opinion on that. >>> >>> In that case I am OK maintaining the hostory of >>> diversions that occurred as part of state information and retaining >>> that state even after the notification for that diversion is sent - >>> so >>> that in case I do not get a confirmation, I would be able to re-send >> the notification. >>> Also maintaining state of diversions would help when the >>> notifications >>> need to sent only at a particular time (if fikter criteria mentions >> it). >>> >>> Thanks, >>> Paul >>> >>>> But if we want to include the information related >>>> to >>>> how many diversions have happened till time (say from 12 AM ) till >>>> the >>>> time the notification is being sent, then as you say we can store >>>> the >>>> diversions. This would be useful when the subscriber specifies in >>>> the >>>> filter criteria to send notifications only during certain time like >>>> between 5 and 6 PM and not whenever a diversion occurs. Then N is >>>> grater than 1. >>>> I presume you don't want that behavior. If you can live with N>=1 >>>> then >>>> we don't have the problem at all. If you need to support N=0 and >>>> don't >>>> want the extra notify, then we have to figure out if there is some >>>> trick to how things are modeled to get the desired effect. I've >>>> suggested something previously, but Adam didn't like it. >>>> >>>> This needs sorting out. >>>> >>>> Thanks, >>>> Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >