From speermint-bounces@ietf.org Sat Dec 01 18:43:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IybzG-0005c5-5c; Sat, 01 Dec 2007 18:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IybzF-0005ZM-JH for speermint@ietf.org; Sat, 01 Dec 2007 18:43:05 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IybzD-0000hc-MG for speermint@ietf.org; Sat, 01 Dec 2007 18:43:05 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB1NgxA27434; Sat, 1 Dec 2007 23:42:59 GMT 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: Sat, 1 Dec 2007 18:42:24 -0500 Message-ID: In-Reply-To: <1196293525.1297.405.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Service Provider => SIP Service Provider thread-index: AcgyF+70OyASHCkdR7GEEtiK3LJNbACVlMpw References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com> <0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net> <1196293525.1297.405.camel@montag.eng.level3.com> From: "James McEachern" To: "Daryl Malas" X-Spam-Score: -4.0 (----) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: speermint@ietf.org, "Livingood, Jason" Subject: [Speermint] Service Provider => SIP Service Provider X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org OK by me if we want to change service provider to SIP service provider, or SSP in all of our documents. In addition to the Terminology Draft, here is a listing of the other WG drafts where 'service provider' should be changed to 'SIP service provider' or 'SSP' for consistency. draft-ietf-speermint-srv-naptr-use-02.txt Abstract: "The objective of this document is to specify the Best Current=20 Practice (BCP) adopted by a service provider... " =3D> SIP service provider Section 3: "SIP systems are represented by user agents (UA). The diagram below shows the case of direct peering where a user agent (UA1), hosted by a service provider SP1, initiates a SIP session to a User Agent (UA2), hosted by service provider SP2." 'service provider SP1' =3D> 'SIP service provider SP1' 'service provider SP2' =3D> 'SIP service provider SP2' draft-ietf-speermint-architecture-04 Introduction: First paragraph mentions 'IP Service provider...' =3D> SIP? Second paragraph: 'This architecture allows the interconnection of two service providers ...' =3D> 'SIP service providers' Section 2, in the bulleted list, the second, third fifth and sixth bullets all have 'Service Provider' which should be changed to 'SIP Service Provider' Figure 1 has two instances of 'Service Provider' which should be changed to 'SIP Service Provider'. Section 6, third paragraph: 'Centralized or Distributed: Addresses the question whether the logical and physical peering points are in one geographical location or distributed to multiple physical locations on the service provider network.' =3D> 'SIP service provider network.' In addition the following sections all use the term 'Provider' in the section titles, when I think they really mean 'SIP Service Provider' or 'SSP': 5.1 5.2 5.4 5.5 (also note that this section says 'Initiating' provider, when it should say 'Receiving' provider.) The term 'Provider' is also used twice in figure 3, when I think it should be 'SSP'. Finally, in section 8: 'In all cases, cryptographic-based security should be maintained as an optional requirement between peering providers...' =3D> 'SIP service providers'. draft-ietf-speermint-consolidated-presence-im-usecases-03.txt Abstract: 'The document describes several use cases of peering of non-VoIP services between two or more Service Providers (SP).' =3D> 'SIP Service Providers' draft-ietf-speermint-voip-consolidated-usecases-03.txt Section 3.1: 'Direct peering describes those cases in which two service providers...' =3D> 'SIP service providers' Section 3.2: 'Indirect, or transit, peering refers to the establishment of either a signaling and media path or signaling path alone via one (or more) referral or transit network(s). In this case it is generally required that a trust relationship is established between the originating service provider...' =3D> 'SIP service provider' That's all I found. Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Wednesday, November 28, 2007 6:45 PM > To: McEachern, James (CAR:AR00) > Cc: Elwell, John; Livingood, Jason; speermint@ietf.org > Subject: RE: [Speermint] [wg-business] WGLC fordraft-ietf-speermint- > terminology-13 >=20 > I think I am actually more of a fan of the "add SIP" to "service > provider" in Section 4.2 (and, throughout the document as necessary) for > this reference. Then, it will directly relate back to the definition of > a SSP in Section 3.9. >=20 > --Daryl >=20 > On Wed, 2007-11-28 at 00:53 -0500, James McEachern wrote: > > Comments inline. > > > > John Elwell wrote: > > > > --- snip ---- > > > > > > Finally, and again I apologize for the lateness of this comment, > > the > > > > definition of Service Provider in section 3.8 suggests that the > > term > > > > "Service Provider" when used without the preceding "SIP" > > > > means an entity > > > > that only provides layer 3 functionality. This definition > > conflicts > > > > with usage later in this and other documents. (e.g. section > > > > 4.2 states: > > > > "Layer 5 (Session) peering refers to interconnection of two > > service > > > > providers...".) We either need to add "SIP" before "service > > provider" > > > > (in several places) or modify the definition slightly. > > > > > > > > Perhaps change the existing text: > > > > "A Service Provider (or SP) is defined to be an entity that > > provides > > > > layer 3 (IP) transport of SIP signaling and media packets." > > > > > > > > Change to: > > > > "A Service Provider (or SP) is defined to be an entity that > > provides > > > > layer 3 (IP) transport of SIP signaling and media packets, > > > > and may also > > > > provide layer 5 processing of SIP signaling and media packets." > > > [JRE] This change doesn't work for me. I think we need to go for > > your > > > other proposal (inserting "SIP" in appropriate places). > > > > > > John > > [jmce] I've gone through most of the drafts to identify where we > would > > need to make changes by inserting "SIP". I've found over 20 instances > > already, along with a dozen or so that simply say "provider" - and > hence > > presumably need to add "SIP Service". Before I document all of these > > instances, I just want to ensure that the group wants to go this route, > > rather than the simpler choice of changing the definition. > > > > Let me know. > > > > Jim > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 06:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz956-0003YH-95; Mon, 03 Dec 2007 06:03:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz955-0003YB-MC for speermint@ietf.org; Mon, 03 Dec 2007 06:03:19 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz954-0006Di-9W for speermint@ietf.org; Mon, 03 Dec 2007 06:03:19 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lB3B3Faa024988; Mon, 3 Dec 2007 04:03:16 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 3 Dec 2007 04:03:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Service Provider => SIP Service Provider Date: Mon, 3 Dec 2007 04:03:09 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695C43B@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Service Provider => SIP Service Provider Thread-Index: AcgyF+70OyASHCkdR7GEEtiK3LJNbACVlMpwAEtAJZA= References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com><0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net><1196293525.1297.405.camel@montag.eng.level3.com> From: "Jean-Francois Mule" To: "James McEachern" , "Daryl Malas" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org, "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org James, The use of SIP service provider terminology has been discussed many times before and some wg drafts have used it since before IETF#69. We can't keep revisiting those basic terms - let's stick with this one. Thanks for checking the inconsistencies in other wg drafts. Let me know if you see any issues with the use of 'service provider' in the requirements draft - I'll fix it. Jean-Francois. > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Saturday, December 01, 2007 4:42 PM > To: Daryl Malas > Cc: speermint@ietf.org; Livingood, Jason > Subject: [Speermint] Service Provider =3D> SIP Service Provider >=20 > OK by me if we want to change service provider to SIP service provider, > or SSP in all of our documents.=20 > In addition to the Terminology Draft, > here is a listing of the other WG drafts where 'service provider' > should > be changed to 'SIP service provider' or 'SSP' for consistency. [snip]=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 06:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9LE-0001qq-8V; Mon, 03 Dec 2007 06:20:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9LD-0001ql-Ih for speermint@ietf.org; Mon, 03 Dec 2007 06:19:59 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz9LC-0006k6-5T for speermint@ietf.org; Mon, 03 Dec 2007 06:19:59 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lB3BJu32032142 for ; Mon, 3 Dec 2007 04:19:56 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 3 Dec 2007 04:19:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Dec 2007 04:19:51 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695C43C@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: won't be in speermint due to BA / Heathrow airport issues Thread-Index: AcgzYNW2g2lkQA0mQiWwPpP+0k800wAAEzqQAABtVFAAjL4rEAAB+J5g From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Speermint] won't be in speermint due to BA / Heathrow airport issues X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org My apologies in advance but I won't be able to join the IETF wg meetings today, including speermint. =20 We are about a dozen folks from IETF stuck in London. We missed the connecting flight from Heathrow to Vancouver yesterday due to bad weather conditions in London. Re: the requirement draft, I would appreciate if folks could send any comments they have to the list. Feel free to talk to Jason, and Dave about this ID. I will hopefully be in Vancouver from Monday night until Sat morning - feel free to catch me. My plan is to put out a revision of the requirements draft just after the IETF, by January 15 =3D> comments are welcome. Jean-Francois _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 06:20:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9Lo-0003kL-SK; Mon, 03 Dec 2007 06:20:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9Ln-0003gl-NM for speermint@ietf.org; Mon, 03 Dec 2007 06:20:35 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz9Ln-0006lA-4N for speermint@ietf.org; Mon, 03 Dec 2007 06:20:35 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lB3BKXTw032456; Mon, 3 Dec 2007 04:20:33 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 3 Dec 2007 04:20:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] new version of draft-ietf-speermint-requirements Date: Mon, 3 Dec 2007 04:20:25 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695C43D@srvxchg3.cablelabs.com> In-Reply-To: <20071120173032.GA22290@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] new version of draft-ietf-speermint-requirements Thread-Index: AcgrmxHsUNYrO2MERq2C7AL48NGWvwKASaIw References: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com> <20071120173032.GA22290@nic.at> From: "Jean-Francois Mule" To: "Otmar Lendl" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, Thx for the comments. More inline. Jean-Francois. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl > Sent: Tuesday, November 20, 2007 10:31 AM > To: Jean-Francois Mule > Cc: speermint@ietf.org > Subject: Re: [Speermint] new version of draft-ietf-speermint- > requirements >=20 [snip] > The document is much clearer and more consistent this way (e.g. in -02 > the IM sections already listed requirements on protocol features > whereas the rest of the document described considerations for SSPs). Ok, credits to A. Houri, E. Aoki and S. Parameswar on this one as noted in the ID. > As with the terminology draft, I'm a bit worried whether we're really > clear and consistent regarding the term "indirect peering". As I read > this paragraph, in the case of the scenario SSP-O -- SSP-transit -- > SSP-T > this language suggests that "SSP-O" and "SSP-T" are doing "indirect > peering" with each other. Daryl's mails seem to indicate that he > intended that term to be used for the relationship "SSP-O -- SSP- > transit" > and "SSP-transit -- SSP-T". >=20 > In other words, is this an example of two indirect peering > relationships > or is this just one indirect peering involving three SSPs? >=20 > (I don't particularily care one way or the other, I just strive > for consistency.) Based on the updated terminology-ID, this will be fixed in draft-04. > >3.3. Session Establishment Data (SED) > > > > The Session Establishment Data (SED) is defined as the data used > to > > route a call or SIP session to the called domain's ingress point > > ([I-D.ietf-speermint-terminology]). Given that SED is the set of > > parameters that the Session Managers and outgoing SBEs need to > > complete the session establishment, some information is shared > > between SSPs. The following paragraphs capture some general > > requirements on the SED data. >=20 > I like the "SIP Route" you mentioned in Req.#5, and perhaps you > should reference it here again, as the next SIP hop information > and the request URI to use are the central components of the SED. I would prefer we keep using SED as the SIP Route is just a sub-set of SED. > >3.3.2. URI Reachability > > > > Based on a well-known URI type (for e.g. sip, pres, or im URIs), > it > > must be possible to determine whether the SSP domain servicing the > > URI allows for session peering, and if it does, it should be > possible > > to locate and retrieve the domain's policy and SBE entities. >=20 > Shouldn't that be "allows direct session peering ..."? >=20 > Plus a second sentence like "if the SSP domain servicing the URI can > be reached via an indirect peering involving a transit SSP, the > identity > and the ingress elements of this tranit SSP need to be learned". >=20 > > For example, an originating service provider must be able to > > determine whether a SIP URI is open for direct interconnection > > without requiring an SBE to initiate a SIP request. >=20 > Hm? How can there be a direct interconnection without a SIP request? That belongs to the solution space, may be it can be done, may be not but it is a desirable requirement. > Shouldn't that be "without requiring a pre-established SIP > connection"? I'm not sure what you mean by SIP connection? SIP request/dialog/session? > >4.5.2. Signaling Security and TLS Considerations > > > > 5. SIP and SBE servers involved in the session establishment > over > > TLS must verify and validate the client certificates: the > client > > certificate must contain a DNS or URI choice type in the > > subjectAltName which corresponds to the domain asserted in the > > host portion of the URI contained in the From header. It is > also > > recommended that VSPs/ASPs convey the domain identity in the > > certificates using both a canonical name of the SIP server(s) > and > > the SIP URI for the domain as described in section 4 of > > [I-D.gurbani-sip-domain-certs]. >=20 > I'm not up-to-date familiar with the SIP / TLS standards, I just want > to make sure that customer-owned domains in SIP URIs do not cause > troubles here. Any txt to be added? > This draft is a huge step forward for speermint. It still very much is a work in progress. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 06:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9Tq-0002w9-1b; Mon, 03 Dec 2007 06:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9To-0002tG-Rk for speermint@ietf.org; Mon, 03 Dec 2007 06:28:52 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz9Tm-00070Y-KP for speermint@ietf.org; Mon, 03 Dec 2007 06:28:52 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lB3BSnNn001508; Mon, 3 Dec 2007 04:28:49 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 3 Dec 2007 04:28:49 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Dec 2007 04:28:36 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695C43E@srvxchg3.cablelabs.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0441600@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Requirements-03 Thread-Index: AcgsZjfSV1bztBsHTWmO5MhpimN6KwJOIxSA References: A<0D5F89FAC29E2C41B98A6A762007F5D0441600@GBNTHT12009MSX.gb002.siemens.net> From: "Jean-Francois Mule" To: "Elwell, John" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org Subject: [Speermint] RE: Comments on Requirements-03 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, Thx for the comments. See inline. Jean-Francois. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, November 21, 2007 10:45 AM > To: speermint@ietf.org; Jean-Francois Mule > Subject: Comments on Requirements-03 >=20 > Jean-Francois, >=20 > I am now a lot happier about the way the requirements in section 3 are > formulated (in terms of "protocol mechanisms must...". Thanks. >=20 > I haven't done a complete review, but I happened to notice the > following: >=20 > 1. "Requirement #1: protocol mechanisms must exist for SSPs to > communicate the egress and ingress points of its service > domain." > Why do ingress points need to be advertised? >=20 Putting NAPTR+SRV records in SSP domain name a la RFC 3263 is a way of advertising ingress points. There are lower layer considerations and traffic engineering considerations for which you would want to know in advance which ingress points to use for a given peer. Typically this kind of discussions happens today between 2 SSPs and a few put down lists of hostnames or even IP addresses. > 2. "a mechanism should exist to allow SSPs to advertize their > media border elements responsible for egress and ingress points so > called Signaling Path Data Elements (SDEs)." > There is confusing use of terminology, not in line with terminology > draft. What are "Signalling Path Data Elements (SDEs)" and, if they > are > on the signalling path, why are they another name for "media border > elements"? My bad use of terminology; to be fixed. >=20 > 3. "Requirement #2: protocol mechanisms must exist for SSPs to > communicate the egress and ingress media points or SDEs of its > service domain. >=20 > Notes on solution space: SSPs engaged in SIP interconnects do > exchange this information today in a static manner." > If SDEs are indeed media border elements, they are exchanged using SDP > on a per call basis. Why is there a requirement for anything else? To > me, the preceding paragraph does not really give convincing > justification. Ok, we should definitely have a debate on whether or not this is needed. SSPs would like to know where media is going to flow from/to for traffic engineering considerations and to optimize routing of media traffic. It may not be a requirement for all types of SSPs (enterprise, user groups) and all types of SIP exchanges (IM) but it is something done in today SIP interconnects for VoIP traffic > Anyone else? =20 > John >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 13:01:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFbP-00031L-KF; Mon, 03 Dec 2007 13:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFbO-000309-2i for speermint@ietf.org; Mon, 03 Dec 2007 13:01:06 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFbL-0005V1-Mg for speermint@ietf.org; Mon, 03 Dec 2007 13:01:06 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4505928000303 for ; Mon, 3 Dec 2007 19:01:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEu3Ufyvuns9 for ; Mon, 3 Dec 2007 19:01:03 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3413F28000302 for ; Mon, 3 Dec 2007 19:00:58 +0100 (CET) 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: Mon, 3 Dec 2007 19:00:56 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF391B84@mx1.office> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C695C43C@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on requirements draft and BCPs for SPEERMINT security issues Thread-Index: AcgzYNW2g2lkQA0mQiWwPpP+0k800wAAEzqQAABtVFAAjL4rEAAB+J5gAAipe8A= References: <9AAEDF491EF7CA48AB587781B8F5D7C695C43C@srvxchg3.cablelabs.com> From: "Saverio Niccolini" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Speermint] Comment on requirements draft and BCPs for SPEERMINT security issues X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dear Jean-Francois and all, I have one comment: crrently the requirements draft defines requirements, but for security issues maybe a BCP draft is needed to help operators to configure their network. We made already some study about this in the VoIP security threats. The question is (I will also raise it today in the AOB slot): does the group want to have a security BCP draft based on the VoIP security threats? If yes I will submit one after IETF, otherwise I will just stop maintaning the draft. Please have your comments ready today for the WG slot or post them on the list. Cheers, Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 =20 =20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Monday, December 03, 2007 12:20 PM > To: speermint@ietf.org > Subject: [Speermint] won't be in speermint due to BA /=20 > Heathrow airportissues >=20 >=20 > My apologies in advance but I won't be able to join the=20 > IETF wg meetings today, including speermint. =20 > We are about a dozen folks from IETF stuck in London. We=20 > missed the connecting flight from Heathrow to Vancouver=20 > yesterday due to bad weather conditions in London. >=20 > Re: the requirement draft, I would appreciate if folks could=20 > send any comments they have to the list. Feel free to talk=20 > to Jason, and Dave about this ID. I will hopefully be in=20 > Vancouver from Monday night until Sat morning - feel free to catch me. >=20 > My plan is to put out a revision of the requirements draft=20 > just after the IETF, by January 15 =3D> comments are welcome. >=20 > Jean-Francois >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 14:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGl1-0008CU-9X; Mon, 03 Dec 2007 14:15:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGkw-0008BA-TU; Mon, 03 Dec 2007 14:15:02 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzGkw-0006be-HH; Mon, 03 Dec 2007 14:15:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2EDB0175B3; Mon, 3 Dec 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzGkv-0000EE-N0; Mon, 03 Dec 2007 14:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Dec 2007 14:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-04.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : VoIP SIP Peering Use Cases Author(s) : A. Uzelac, et al. Filename : draft-ietf-speermint-voip-consolidated-usecases-04.txt Pages : 23 Date : 2007-12-3 This document will capture VoIP use case for SIP Peering. It is a consolidation of Speermint use cases drafts. This document depicts many common VoIP peering use cases. These use cases are categorized into three types: Direct, Indirect and Assisted. They are not the exhaust set of use cases but the most common use cases deployed in production today. This document captures them to provide a reference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-voip-consolidated-usecases-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-3131415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-voip-consolidated-usecases-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-3131415.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Dec 03 14:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHG4-0000fj-E3; Mon, 03 Dec 2007 14:47:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHAo-00039v-Bm for speermint@ietf.org; Mon, 03 Dec 2007 14:41:46 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzHAn-000834-6R for speermint@ietf.org; Mon, 03 Dec 2007 14:41:46 -0500 Received: from [130.129.19.166] (dhcp-13a6.ietf70.org [130.129.19.166]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1IzHAg29fV-0000Yh; Mon, 03 Dec 2007 20:41:44 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) To: speermint@ietf.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-19--639659218 From: David Schwartz Date: Mon, 3 Dec 2007 11:41:12 -0800 X-Mailer: Apple Mail (2.752.3) X-Provags-ID: V01U2FsdGVkX1+B3d5UJZ8kGIbRQoU5+h1jljUN2Pw/gCneMpb f0E23QQ+ERVNLJd5JglNPtpnOHtS7NjCc4x+adHuSh0nChr3Sy rZ+dY/FiWCjFc1zE9mv/w== X-Spam-Score: -0.0 (/) X-Scan-Signature: 0efa77bb10bbdeb46e512cdd96a47708 X-Mailman-Approved-At: Mon, 03 Dec 2007 14:47:11 -0500 Subject: [Speermint] Some quick comments on Use Cases 04 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --Apple-Mail-19--639659218 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi. First a general comment. I still see confusion between assisted and indirect popping up in various passages. Here is a high level diagram (sorry its not ascii art) of the way I understand it and perhaps this can be used in discussions today to close this issue. --Apple-Mail-19--639659218 Content-Transfer-Encoding: base64 Content-Type: image/tiff; x-unix-mode=0666; name=pastedGraphic.tiff Content-Disposition: inline; filename=pastedGraphic.tiff TU0AKgAA8ZyAACBQOCQWDQeEQmFQuGQ2HQ+IRGJROKRUALqMP+NP8APqPRaQSGRSOSSWTSeUSmVS uWS2XS+YTGZTOaTWbTecTmdTueT2fT+gRsAByiAACUcAC6lAGgU2nU+oVGpVOqVWrVesVmtStT11 /up6uoAGEumEAPwDPwARyOVu3W+4XG5XO6XW7Xe8Xm9Xu+U0BgC/ufBAA+HE+AB3Ox3ABfr1f0y+ 5HJZPKZXLZfMZmn11T1+w2Oy2e02vSZrTafUanVavWa3Xa/YXW/4HB4XD4nF43H7Heb3fb/gcHhW /OZ6xWSzWi1Wzh83nc/odHpdPqdXLbMAYJz4TDYjFYzHZDrePyeXzef0VDi2Dj6HlaS2+n5fP6fX 7ff8fmp9jtdzbu+3TxP1AcCQLA0Dsw9bPuQ0TltLBEIQjCUJwpCsLL0/jau63DwN3C8PxBEMRRGh kFPa5LRuZEkVxZFsXRfGD8wy7bbO83LwxjHMdR3HjeRM0EUQc+MeyJIsjSPJEkqBGb/RtDsBSVKM pSnKibR/Bj3xVKsty5LsvS/FkmRrDkAzBM0zzRL0rvdFMHzTN84TjOU5tZMUNwBHE6T1Pc+QhNcg vhPtBUHQlC0Mm87P/G8PUPRtHUe2M/wbQNIUrS1L0xPtEydMtM09T9QLhSUszdUNTVPVFUxBTcyT zVVX1hWKW1HNsh1lW9cVzXTgVZPFGV3YFg2DWkhWFY1j2RZK6V7RcoWVZ9oUfYlKWipymKYcZyHG ABbFoWwAGGYRhgAeFyoSf10AACF1gAHAdBwAAfB+HwABbewAAFfNq33fklWZJ9+4DgU42nLWBpMA V8AAep7nqABLEoSwAE6TZOgAex5HsgVnJioV84SIwliMAA9j6PYAA+DoPrWANbYPl+YPnf9O5jmu bSLgtS5uhlr0CXBblwABDkIQ4AHCbxwqsf5/I4BAFAQAAzjYM+ojRqgGAWBlqZ3rmuoAAIFA4JBY NB4RCYVC4ZDYdAwGAIi54oAD4cT4AHc7HcAF+vV+AYfI5JJZNJ5RKZVK5ZLZdL5hMZlM5pNZtN5x OZ1O55PZ9P6BNVPQ3+6nq6gAYS6YQA/AM/AA/6jQapVZOAgBWHq93qAFcrFcAEulEuAHI4XJApFK H/bQAJBOJAAWi6WgAVywVwADQYDanUp/IpE/cIAEGgUGAFCnVCAH9j4Tj38ABMIA8ACyRyIACMNx sAA8GQxUbdJwDpwA+X2+wAy2q1gAmVcsQAxGc0cdpYPhH6ABGJRGAEmmEmABcKxdAqxf6tzedz+h 0el0+p1et1+x2e11IjE4rF4zG47H5D2/N5/R6fV6/Z7fd7/h8ejQ1PRaPSaXTafzPl8MEpp+qgUR QFEABLEmSwAHUdCkNOtabH+fypAWBwFgAPY/j2AC8iwiQCoim6sKwfB9HwAA/D2PwAFSUpUtIwCB raqQGAWBQADYK4pgAMAliSAAFASBMXp4AUigAYBmGcABBE4T4AG4cS0oQyQAAoC4KLETSyhwGwcO UgSpRg/sxzJMszTPNE0zVNbzO6ACKHOiyMI0jiPJBB82TzPU9z5Ps/T/QFApu+j7KQpSmKcqEw0E qkRLMcq0jsOg7NqX5iLUkoOAuCq3g+y4Sg6Dimn4qBrnAcIAHWdx3gAcJznTUaoIY1bWBsHLPkeS ZHgAEIPhCqIAzEkgCABYhHEeRwAEiRpIgA3khgGAiIj0pSkicJliyNYTsgHboAGSaZqAAOFmAAcc GABBymn2qAeCCHgAEwThMAACIHgi/ibP+cd+AAXRdl0ABzHIcyCxkAAEYSAAZBmGQAB+IAf2KAli UZi2L4xjONY3QU3ThOTwzq8k8Y5kuTZPlGU5Vlc0UIo1DPzRN85Y010gAfB8xMOI2jiABaliWt0g EkWDgMAwCgANwsCqAAxifbAFyDIaX6GkR7ZwABRFqW4AEgVBVAAex6xNm1YgAGYbhmABNk6TYAAv uGZqzuZ4nkeKki8phlmQZaC6NpBAjOMjMCOIqsuW3Ux26iJxnOdAADKQhEAAaZum/sqJWk4RLuLH ol3SAmiKmhD/5xExQE+UCxEksp4HceFMJxKgjCUIwADyPg8reES5bLReaeB4PheH4kz48785vFOz y+L5vnef6Ho+lP+XPvQ79UV0fpoG/6CMOxJPE0TzHMhKgIgcBwAEQNw0AAJAdBzucwJ9xYAGCZhm gAO5KEyAByjoVgukkStENhcQ6IYRAhmEMKIQIsRQiwACUEeJRqZqBABoDEjsJbn0jGkT0/U1xsAz CFEUAAdg73YQEBaDAFoABPCifGBsDIG3YqLUcOkdasA1BlDUAAZQyBlQCZIT9CJUgEgMSEIAQggC 7hUL0AIApWHfvbipFWK0V3pvHTieBOh407xYjBGGMUY4yRlIK9VmCiD9xTeio4dw8SOhbCqFsAA1 BoriUWBNexwg7ByAAD0GAMCBmTcSdF+o2BwDgAAGIQQh1zDmcePwwoGwOQ0FCKYxoKgUAqAAGcMo Z2fCzaCjADwGALAAFGIQP5vgNw0YOxpaSxA/CZE0AAT4sRbLOMKA0BxfhPCkfGDwGq8BqjbGqAAN YaA1gAG0NcbUQiCpUA0BhTgagphSAAEsHb8QKR7kKZEyA0BszPE2LIWa/hit9H6P43pBGDv1D4II jIYAvBgQ8RGNkZp9T7n5P06sWmQRdeXEOf1BaDUHoRQk9EaD8Rqeytt5wBwAUSESIwRLXRGiQfIV JoxERFBtmWFIIYQIBJgogdYAoBGkC4GOMYAAbxFiSAAPMepXR803AAHYPalAcvwAAGYMQZgARwbu AUA6xBIhzDgAAJwPgelTkJSdQQAlvDoHWOwAAXA/CBAANgbw4gAD6H0PmrIYAuAAD0H4PTTQvBjA AM0ZT+UixSLcjRGwYwoBNp/XkvYC0LSvJcuoYQzxoAAEOKAUYABrDccvO4tz9RGCREYAAKQUJsAB dC3KhVm7OWds5QCLjymR2etJaW01p7UENoY9dmU+XiNIaQsdZIkKM1hNWaCUwABViJEKAADYFksT fPbXOoY8x6SdEPCUYgzxpFZNRY6jgB2kClEHEwG4LJOQeqkyhg4Xg/mJGEbdzBCFnglA+B0sQeA5 gABOCFX6wbXE8XVJI3ogROPjFILQXL5DJwECCEQIK8V5l7L7Zq1OB8EYJZPaB5LIov4KwhhHCWE3 nWrZjGt7TwqJUSGCMYYLkAxBlToqwGAKC5CeD+RkDIFAJ38TSupq49zMB7q4M8a42XtAJAOAZZVS gABJB4DqQcHni3EHgPIecixBwKGSNI2CRSRUqIiI4OAbgABPCAD6ASYbtnPuIPEelxwzOSNqM8ac uioQrhaJ8UaToZQ0d9hnCmc86Z1PRgxkMXnmZ2z5n3P2fz5YWodgZlB/z/iFEJb1zhZTHlSDyGML oAA1BUR1B24SZ5YgAFYL0XoAA6CPEqAAe9OAgA0BiAATgfXdY6olFa6TSJyi0MMJl8Y9B74yDWFe bAdwvaRaOsSwB59MjQG1jgMgg6LjnquACAghBEiEKSF8pkUIpZy0BtfbG2SY54oFaPbW39wbh3ET TQT2NCMnWIsQX4wRfgADSGUNMJh2DtspSMAAiQ3Q9QrX/S6ebiDfHIOUjQ88kgsBGCIAABmKbW3G T9+o5h1DrkWIGBQ0RtjcgXRISomNQhKCOEoxwA5CcM4byXk2fduWiwfyflnLeXba3La3kjJwEMIO EcR9QhaLqkNYI4OQbS7hFM3OuqOXeX2bx3jwSLXwACLkvTMemSQzBpqEH/q1EwEUSMmZPo/XevWm 5Tg7PfX+ydl7NQnmOGOjHqUcLbtySw/iCf8OPgS6iV30AACIDYGgACwEc5MCYDwHtT7PaVdSEjJh 9EuJyVAs5c1UIiBoDvfB0P/l1O0hbRQEY8B1kGZAbJlg19EVkAe1e1+F9R6l4xEk3vIzzQP1XsfZ ezeb2mh56j/rsNYHgOgeLdCoFXNAm4+rbhq10AAPAXwvAAQ/tX2lpNMjaHEqgMAf7equcf3ZCBbg CcK3cGzeIbQ4dA83zW+Pz/0fpOh2HPVBP1fv/h/FM/ttznTP+ou6r4BNvjiKwYtwBLrIAAHzUwAA FYEIEA4wEjhAcaHAAAaAbgboAAXwZIZgAAd5upw4rATQPr3wIwGwGotTLj+Sg6+ZUhyDnQAAXsCj 4QgZTYCRt4CJfCkqN4eR/yqz+og6/zAAABZgRoAADAC40b88EcIkIolb9j2EI0JUJcJg6j+kIbLx uYegey44MQLqDIY4YoY4grKRE4MiDILYJJwxD7YEJsMwgi4gbocYtJJh8YYAZYZ7hiAgKZHJ9QRZ yZGqv7mcM8Pj+UJDb0PsQMQUQYlcJ8PY5zDZrIUxAoPAOr3ydgya4gPQMb5ZpyvQAY1D08Qj+JdT 4g1g2QWCCIVIsIe4fBEz3Ifg1gPIPx3SZKZYAQAz00TcWb2cP7lcWkXEXMTcQ0TQnrdJ+wYbD4Mg MBwbMIroDICrFoUyJYAAEoDy9C7UXUaSlJpAVgXwXx24SRehsZEwfasQAAIsMRAwTJBJGgBkHEaU dLb8WzscdUd0d7+EXg6BRyFBVgL4LYL41sFYCwCQCDVAP6tYGoFIFKqDIkeEXS+YwoM4QyEoXYY6 IJKg344IVYWD4ICwCqU8KEg8jbCcdj90jkkEkLl8eQ562AAA25JR64cwcxOIIgHAGgAAToPpDRo6 fEXskUM5+oabi4AALoPwxKE52AAJoYAAQIQqrgMILgpgf4ApRcm8nEqCgsj0qMqkqrcMkg5xRwRg RayZZZZroiVAQQPoAAIQG0mB+bfsq0QZ+obYcQccnqeJcwdQpDKAAAUoVYUoAAHgHBeD1kdEtUwC MMqcwMwkwrCMrA5o/4QAPyJgTgTIToACJBIQVgRbaAFgEh3oyEp8w0JRdQPQSp/oUgWoXDZi28n5 FQMwMioQAYAyfEQ8zk2B6Ewc2M2k2qg8xAoA/6SQqDd7eIWrxwAAD6acuy6rvIDjvkaM20QjTIbY casAL4QC3qxisAHoIKp4UQUZAoBABT80185U75lU2c8E8c8iKk3AwJmwfof43oN4NYN4AAV8ii3x K4AAU0o4t8Z4gUzU8sPi4gd4eUGoMTigAAYwaK5sgcggWYXCc4BZGk/lB54E8VCFCdChlM85RpuY QdDQ2J/hYqlM+ARaBTEoE0/UjVCr9BB5bpYiEZyYVwXwYEZoEYuQVoWgVsH4Cw0brdE9HZi1CVHl H9IBPlC4oMRJSzdp67gi44L4JzkAQYNCoSlKulIL+FFJaKn4QtFoXtGAE4E1EgVwWosLFi4M71Kd Mo+FH1M1NNNQ91IYoEX4bocECMpIpgbAbDHAFQERX8+yVYDAChLBKlNb2S4jJEKoQaRwYYZ0OIGN RYrwWIsIBJqMv9QNSY7VNFSlS9TA+Yohl6hrc1EwoDHjHgTATZegQ9QwAAeoewe0cBW44QOpnoB4 Bkc7YNTLo7hRpAY4ajM4L76wjSFCsqs4QtYThLzdSVWtY45tS1ZFZdZgm1NoqpRwctaTK4JgJ4AA dIc5BotYRIOCZYLAIgISGszdZrOrTIUbt4PASR/o1YfRJYQ7uQMYMKtzalY1clewnFZVe9fVfYkd Z450kzJy5sKyDIcwcpgssAGIFAEoAASoO4Ok4I0TwlfjO0tgcSsALQPSJhc5WAEgEwuQUAUp1QEQ EDhDONcdidlAk9fNlNlllFfw6JRweAeJ2AMrEIAAY4YkLa4hKgBpGoAATQPgO6P9Rgto3stNlqgx +ocgdJWALcuIbgcKsAAi6TpoRyCAKoKJpgf4Akp1pFrwmtldr9sVZFl8eZuYWIWA2gRoRcHwb5y0 FggUbgAAOoLgLLTwL6s70qk1sazbTIQgTxJwTIVg2kVIqAEwFNEgVQV5sFMVetvlx4hlsNyFydNN sonaNx1xG4NINhSpS68YhRKgCABovwS4PVh4Htok9cgw6zVi3QkAADxSWoHwGSQQQgNDEQB1WViV UClQAAWIYQYQwwTh1QNIKgKIAEMII4iUTIkx+oaNOxdNKwGQE9hYPQSx/oXIZJvoUgQIjIEYDhUU 5I6BdRnCsgPYS6WoYYaC5soh7hAAyYHAFgFAAAP4Mqt0fkF9QChJ+oasCAADY5ycBjiTng4wGI5I TwUJ8YDWBZg1MlymB4g1yWCGCdE9yxfRmzxAAAOQNyPwVwVYsL7U/QyB84vwJYHwHcvQF45IHQFy FuEl3Y6+EIAAQwxg4QVVGwEQDQDK3QRS3oDQCzFpCI5po5pAWAYDD4NgRJXYPJaoMgKAJxw9vYht W4AAWwYylwQeGoQAMopgJSnwNKisFKuM+ARqRwEaVtvdk4mpdQfMb4OIRymQWYYJS64ghETxE4Mw pgMwKIKAiUTF1afR+oYQZpJQOYSDUIczZZqpIYRoSUHwKoKRphYstGCmSokeCWS2TM8eCwmMX4YA YVGANAMZ9rgjJJg4CCXoAAQgNaoQJoHpeA5eBw9LyAACr4tILarYAACsGIAAbIcL6gJjkAO9vCaC 4gbWX4AAWYYYYpsJEkvQGA5IH4GKQUoYgSm41gVwX9GAbhggAADkZIuYJQJDhLhYezW+XtqIAAEG Bkfp9J15u4U4XIXYAAdrJAAAF4Eg4IJYHuFCDwQwT5AoUoXBgIOluqpgHxeEUysgdQeB2AFbg4xy daZli04xUQYtAwAAaUngKYIJiQEoEAD5dItzWzGVF1GAeDMMnoJOcYcwdirABQA6iQD7vekQwA1G NtdoN4RijQYNRMmIPqtd1AF4AAeC4zH4N69YCZ9AAAVARAxIA5b2KwZEBwbQbYAAGgFIE8cBLi5x ERI0oIAAVQXkbArdVYLoJRHwC4CcF5Z+XysBqLmoZIag2GDIJ4H7LV1tWg67L+lIM8FFRC5pborB UgqBWwz5eReiU1HIx2TWxuS71hj60LsUj+x2yogAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0VU8 Zf7qerqABhLphAD8Az8AD/k8XiQIAEsUipUgAO5zO4Afc3AAFAwEACINhqABVIZBAABAUCf8olVL pkOBAGAwANyNSAAXDFZAATx/PQAR6kVAAbzmc4AUSBPYAFgjEYARylsKbWCzAByLhYAD6fT7nqfU YAJY+HQANRTKAALp+QoAFwlEQALRKI4ASyqVoAbricoAWSQRQAabdbwANqIRoAQBoMYADYWCoAN6 MqpjJxMAAkDocAB/TKdAAfDIY3ZmMQAPiXTQAbjicgADATCQAMZRJoAaDYbYAXbJZYAWyS07LazW mSQS1FAQBABRIQ+0Dcb4Aa7d+KUPBzAAl3OQPiAAAFgSBIAB8GYYusbBsgAaRtG6AAyCi2w/DK4p /H8pSBnyvTYNkABgmcZ4AE6PquiCGoZgAVpel+2BFqqFoTBIABND0OrpEIRIAHgeJ5AAIYcBqABa GCYjfg0DIAE+rjOGFIg+kqTYABwF4VgACoIghIJhGMABGDiNgABsFYUgALw+kGABtnEcbnAsCb1h +9w5i6LQAAOAoCpOpKmz2hQAz8AABgEo4/OREJZFsoqBqTC6BECQxAgAMAujAooCvUlFGT5TVN05 TtPU/UFQ1FUdSVLU1T1RVNVIUAdAAAc9YOMOI+AAdx2HcABfxU9VV17X1f2BYNhWHYli2NY9kWTZ Vl2ZPaMlOjaOo+kKRpKlNM04o6jnieZ4gANIyDSABhGAYSRn6foACuJAhgARQ2y/O1WwtZqmUEo5 5HmegAC2PtIH2fiTFSREzk6WJaAAShUFWABOD8PIACQHQcgANBDM+Xxlmbho+4gF4SrbDxoAAH4Z BgABkGoasNqqKwiXaOwwC4ABrG5Bp+z0GQUBQ7ximKAA1kQRwAEGNIygABQEpYPhLOSQo1aOKYhK IXRkmUAAPAu4QXhMtpIFMVUuFIU4AExGjAB2wY0kQRYAF6ZWNu+8LxgAOZGkmAAsiQIoAEINQzZ6 Y4ADY0wAEON1xADPQ8EoTIAD0MYvMIKYogAWBhGHb5DEYAAzCk6sJQpeiCQyfQADiRpJKsYysgqC csUFVp3x2AFuHqAA6C8LIABOD4PAAOxJPOPKQAAMTarcUuyE2Vy6FqSXOFEWxbgAVZdxWs9aBaEi 2iqO4+gAC4JSwNIqikwhEc4vfTFKQlIBGDgNqRTF6oU9L1HhfXHkw5JamCz9RaeSUAKAWAoAAlxO iXAAEAHoQCigDUuSl+sE4KQVgtBeDEGYNLDVaq1WBZQ+KzVqrdXKu4NwnhRCmFUK4WQthdC+GEL1 nrRI8SAkRJCTP0VATwngcQ4BxAAKoVDYR8k4EEapzrlFEqYWxDEgSdk8C/GaiAMAfxCAAXuABK4D U8kCHOOkdiAwZgvAAJsPgeAADyHq7cNYiWhjOGsNhc66QCAFJ4HILbuw1BUcqI4UzZBOlzAAPYew +SBK8BiCkEzDYzgAGUNUa7g3CuQckFYIq7TYlVF83Ago/UKqRCcEoAAhg0uAEuK4WIABGijFNAds 4S20rfbY26TjcgAHiPIHIRjqhArgeME4JYABnDYG03kPZ/kJEiGmNo7IrBfjBAAK4RQhwAM6BKh0 Z40QABcmOmQJoSTdhkQonp0iGg4CNEiAAXgyRmAACYYIAASgdsUAqBBLAKgRmPAeAsBbYpWiKFAK Uhqfj1CADOcUVYvEVoLG5FhQUnZPAABMCADrhg2BodPLs24HzdCYDwjVpJLIAwvoIUVP4jxTCpAA JAUtKkKkoL1IYPLD3BhqS+AMAyrYdROp5T2n1P6gVBV9B1V6sYQq0VsrhXQv1eVCqdU+qFUapVTW AQGAACBQOCQWDQeEQmFQuGQ2HQ+IRGJROKRUAKeMP91PV1AAwl0wgB+AZ+AB/yaLQsBACVup1x0v lsvgBns5oAAOBgLABQn8+AAVCQRQJ/v6TSeU0mlRUA00AIBMpwAJ5YLYAAGVwl+v2jCMPBsALFGo gABEHA4APF5vQAKRbrcAK1fsIANlvuIADIUiYAKhDoMAA4EgoAMJozdMq1YABjNFqAB8Pd9ABSoY /AB5vZ7gA2opHgA8GAuAAylEngB/P6Sq1fMEAKNbLkANdvuDAgvCWKyLdjMkAIxRqYAJc9HUAEsd joAGlEIsAL1lM0ALZJI0AMtrNYAHJGJIAIE0mQAGInEsAM5sNoAFk9oAAH0ySFuuRx21bLq4opDX kUCUAGCZ5ogALj2gALwmiSAA/jIMTUH+pCBnyfTJjeRhIP+ZxngATo+j0AAdhgF6jn6o6BASA4Dg ASpVlcABFFCUjti2K4ABqFYVNQ1KWKcEINrANhEusdJ3ng94xi8AAGAUwjUqMBwGAZHYAgAL4/kI AAjh0G7vjNBp/KRB8IKXMcyIKpspwnChGki6ZhmPHKjAwDQMIuVpTgAoQSJMAMxTLP0/0BQNBUHQ lC0NQ9EUTRVF0ZRtHIEAYAUic9KAAPg4p+dx2HcABfl6X8p0fUVR1JUtTVPVFU1VVdWVbV1X1hWM yIwU6NI4jyQJEkiUT7MgDABX5TFS4Q6DiOiRH3Eg7DALbOCuKiWAFKcH1lPwBWuABxnOdAACaOQ7 gAFwShGABMOKAAEANFICgIAjpmKYzlkO6w1CsKK0nkeaeFq2Q5RnGoUhQ95NE2AAIAYtDSiaAA5k cSgABMD4OAAO4vtGWpizeUZaFwABREEn7Ms2zrPkENDxNwBIADiRk2QPBImB0HAAElFjZm8b4AFc RhDgAXJjt8RZROEIAZhiAAqiIIQAFwY5kAAXhkmY6bquu7Ltu677wvG8rzvS9cCj0j4ACIG4agAJ w43Aeh7HsAAXhPPRtHCcgAHIdB0gANgsWgPwypC1M+wlCkLQxDUOQ9EERQfElqUkAdIm2cK8C0PT 3MGBAAD3I4AE2VxZAAbxynOABZLGABamPN5BkyT8DCYJAABQEAPgAQZOFA44eOU0onAAMhB56Iwc y2QMuwconHWrP0T1+SxWliABCk31x7nwfAABCEYQp4UxQzwEU9KuoiUeX83z/R9P1fX9n20VSNJ0 rS9M03TtP1D938/1/f+f7/z/4AQBgE/9WitiOkfJCSMkpJ1epjJWSsQggkriYEqJhaJKxUCIEEAA HILQWPJfLAMg4BwDAFJ4LQuAdxJCXRkjQNoVwquPSmAQAcJhojaGyAAK7lm3gkXIGwK4UjtiPYeO UdI6yCgEAKpFsRMwxhPCYZwRZ1hZDAGKVcpw+x+ElBSCIEAABUiHg2Moao129CIOsHwMgYGyA3Bo AANYiRHAAGkNkbhAlQj8K2AAMwVDTiBDKg0XQyBlgADgmsAA7h4DyYYF8LIABzjrHYACQchTqHWO wdo7h3jwHiPIeY9B6j2HuDwxZAwS3YiSFSKwAAjxSipKOScF4JlyDWNrKdBIfj4oOcEhMACFULjB QyhtDqH0QojRKQVa5Kw8iUgsKRfkWCBR6RIGgKoUGKBeC6AAeQ9S2BhECfuOo23kAAASicqYfQ8g AA8BlOgWQ8mXCMlpLiXkwPKhEQdM5mG2oGD8YAZo1hsAAK2iQTooxOgACQEV2KknyQNnzRGiVE6K UVosmV+EkH5KYkS/VTyoKL0hpFSOklJaTUnpQ+yApG4Dq5gUrxMqU0poSHygMLBoxhjCiuDIE5/h PCAJ+BkCgE04UpqM+uGi7mmrxE8LIqwWwkBGAAFIIIPznjMOkF6f7egrBTAAHULoWpeSxqPSipIA BtjjLwF8QAhQADdHAfUEEXgACsFjKwDVeaYVlr5X2v1f7AEPoypR0j86Oqco+/iwNi7GWNsdY+yF kUy0rVvAhXUC4QlLpkAAelnWyA/CI6GW4SQdszEsHhY4C5z1ksla1Qq0kpmZbcHoSwmXUJuJFFsA EWiSpZS3adY66Vf2upEAcAsJhMiwFmAAQgmhPAAcGb8SIjEBhVNGPwAlmKIXEu5d27130/2Do2/S xD97wXnvRem9V672KIspS2BKu4GUxfGPUew9TjhHPMNYatAwksyAAJYPNqbVphvbgchk+x6j3M2L YYzTxtjiPqCGdwAAmA9B2AABoCwF2swQ/5yCkRmDVO0F4P9bhzjqI6HgPS4A6hyOMsCh+H8aY1xt WW8VhaOKavLSDG+P8gZByFkOiV71cXxu1fRKZmm3BRCavcaIzxpAABuC0FaGw/TrAqBACFY8iZfz BAO2FnMGEeEEfsYgzCbgtBiC0AAoBSO5TmBo1Gdcw53zxnlVGOVLY7o9ebPWgdBaD0JoUhmRrLUv vmmSzdNCPBcJCMEX5rgNAXArGAQ0GwRAcLAiW7ehtQahULPu6IbBFmfFqMEYgAASgpP8KYVBwgNg aLAP9Pmotca510QPPlhseP2x9rvYWw9ibFrLoil18rMplV+r8UAo3c2oDwSYowABJh4DiAAKAQKr FNgZp/Y24dwz7K4UYPglhNMeFmXACgFqiCvFoK8AEXihvjr3uLfG+b069z9j2xW+uAcB4FwNVOyM kb3T8u5dw3hwDeSoFwmY2WvgoBC7UUwhT3AaArpdJvBOPahn2PofY+5fyIFga0oAKwUltFOjEDIG gM8I4/zPmlKd+Xk2Bv/mvO+ec958QTg1l+ZKA4UAAM4ZgzulFg6AATkJWhyDa0hpVY8Dc/6th/MY 9MyhhzOYUZgzgAA+B+D7AImxLAAAqBPjmdur9t7c/nm9h+c9v7p3Xu2hug6K2WoCB7dhyt1b4FgA A4RvDhKutIAAiQ4Bqh0ES0O3pk938lY7EIAMR4lxOAAdI7IkBpDWGk94fg+rAhJnXavk/UepVH3H X9ifVev9h7G7vedlbgT9CaEwlBKsPEMIM/e5QAAb0tm8PweygFCIEjr23svmQDuNCYSYqpWCJE+K UAD1jNiKEgIoAAYAsRsH6AVxve/m/l/MRL1mf9g/n/Z+390IvaZJUZRkR4jjPiPEYZ/A01AATzBs AAEcDg6iAkLOy8/fAOfO8qHAHMHM+6nCNmG4ZyBOBUL4MUFaAAAnAy6HARA4/c/S39A7BDBFBGVY /jA2feocGmGqGmAADGC+DGAAHMHJAan2wMAKAMXcCcB8B6QGCSqkBiBMP8KwKzBJCKUQ46C2D4Pc MaGqoIH6JKYcjmq6CsKuAIWm/JCNCy7vA+7nC1C9C/DAKVBM0WVKoyFsFuKsD0DsQ884kmn2IQS+ JOAWAQRSCWB8wyl0jYAeAYAaw9DDD+hGAMV+LcNkD6EsYKXyX1AmBOJ4FIe+A+A8dq3tDJEBEq55 C49dEtE1E3DDDHCwVO6KG0G4PUDwDu2mGUGMGUIaHqeuAADylMDmC6kemk6rE5CMn2D4EwYKFI3W oIR0AeAgAeJ4FOe+BmBgBmIEKzEpFsVcs2i05IGWGSkKF5GoAAF2FyF2bsHEbqNU2q50vmAUAQMI BKBUP8B7B2AAB6B/B4BoBkjeAJBxGYVbEw0BHlHtHu/ZE8+WVMs2vmF2F1GyE0Eu3SMOQEH0MkAA HqHyM2D6DGJCDgC1CoQhFrHw/cmWLaFqLgECE2dyHwHypq5G5IDgDqDgO2DiDkAAAKuNBPIqUc76 HQHUW4EuEqhYFgFYMWHfJy+SIG50TI46AsAuJ2DWDgDWh0CwRoNww7GXJaUJHo/XKZKhKi7dH0f0 9wOmFwKsDcDUDcAAHeHiHiN+DiDY+6CYCVF8KNIpKk8mn2Ea1gAAEyFW3lI8MnBqWojkESAACwCq 8EACALCvH3LUKW76qwamEED8g3IKJMH6KRJ6VSvms2CICQtCD4J8AABAA8i+JZMCKTKdMbM3M/NA 3FKofzKsFkFqdBLE2ykWkYEZLFLJLM+BLTNCy+6aUiHKHQW4FGFuPwBPEgSwBwbOASAQZVNlJ4Kc 5E5IFyGQN8E0FedAGoG0G6y8KQj0JLKHKKDpOy9IV/KW31GcH45IFqFoFqP+GANcG2GynJPQnIHw HsewXUV+A8BCA8AAAkAmAkAACE6mCnP4AAAsAqJ21tMAUU6KF4F8F4NADq2mHOdGfGVDG+JQARHE 3mBIyuB0B2PMBkBqCGAAAwAxPoIQwMG4G4ymyiNcGmGiTeG4G2ynPavwhC51GebemOM8+45UyuAC AHM9NmILM7R5R/SA13NGfdNLNOZWDZNUHlNZNcDBLLLPD9SCxtIuHIHSbyCyh5AWdJDeUHLSCqC0 hiD8ECMuAeAbGFO62MozPMGAAA+KMuG8G64cT5QeUMvmrODYDhLGDODQ6SAWAZKVE/M4ocFUFWFU uYEASuHdUSKu1sT2KMXSw6CMCWrECkCo8YAcAgAohAUZIu7+4cFMFG+5GjQQH2Qkjw+SKLAxA0mc YeBzVaUkhpJZKlR9SjVpVqz1SGfa76HFV2vyPMW2I6DgCyWgDuDAJmXaWnQHVstczGHwl8DUjQZ8 weAAXaXdRyWmH4vnWSwNT6w6CcCkd8DQDUDQeyA+e5QE4C77I8ewEYEWuoFCE6e/IWpq3sIIS+KM AaAaAiYgBQBhMsBERwBGBIzdEEw6WuSm7+PUHCHAoGGeGYNdJykmnLRjPAAABiBkaOjQLJRuKvR0 IioyG0G2PUDSDK9AGzZNUWSmH4H85IByB3LMDMDUSuAkAkAufY8rRWMeEnAC8GHChyzsWS5JP0aW ZauoJ0TpTOKYfG+wAAGUGTFUGBagAAGOGITeG0a/PAJLJUhMBWBYyuB4B8B4AACGCLQ4BeBaREhq Ui4BVnWVbaIAAIFA4JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGY1G45C1PH3+6nq6gAYS6YQA/AM/ AA/5bHZhEgEAJm7ng7gATyWTwA2Wu2wAVSKQQAiDcaQADASCpa/5dMahUalU6pVatV6xWYYA64AG 24XEACidTyAHc73kABGJxGAFCpVCAGezmeAGCwGCAG4225BX9fwAHQ8HQALMMAC2XS2AAmEQmAH9 kK1k8plYfM5mlEmlAAk0gkwA93q94EAYE/n/kQkEwuACSSy4ACIR8WEAgFIqAQDM3y+XsAGOxVsA FutVEAG822mAH6/H7pYE+34+wAJRMJQAlk0lgAKhSKgBu9NLqfA9Npn0+30ADibjjxFmt+ZzuY/5 YOx6TAAZTQgwACAJAsgSnMsmKuJmcxynC7JJjsABqmkZLIH857nJYOA5jgAA2Q4AAFAYpjyIizAA Hkei0k6TZOgAUBOlAAB3nad8BvMizUMiDEcgAN45jeAApCoKQAATIkCyNI6OgGAElHPJoAD4OI+L MdicF+XpftNJEtS3Lkuy9L8wTDMUxzJMszTPNDJo+U6QpGkqTpSlaXvLNKEPO5kKAAPQ7j0AC4FK AAFgUBIAFsSZGrUDYNwHEU60dR9IUjMABUoAB6ns34vD8QjgGk5YGAaBgAE0T5NAAIIeKIfwBsjR tJVfNMlSUYtaAAOQ3jkABy128Lyt0AAnCmMygivHwFAUBcjq5JRsmwaDskkOgAHCcBtJawB+2y/Y 0jKAA7DpBwFAcpkSGiaRogANAyDQAByXclJ9uoFYWhw9g7NACoK0XGlYIkAgBgIABpmoZAAEiRkN HWdJyABeLqB4HweAASRLkkAAMAuDE5vDjh9H49ZFEORQAFETzjnye58uhI8RARl0nkBKQtCsLQAA IBOA1dfudoHWQASac8nyjKcqyvLOeaRpOlaXpmm6dp+oajMc1zakiTJQlSWZ1ngDgBrpPlET4ADw Oo8Jo3YAEwPdpCQHQdPCALyTpqW6bruysAMAgCgAUxclzsZJEwAFMNIG4dhvPxU0BQVk63u/HovE h4nkeIADIMIyAAZJjwk1KXWWxAvjqAAlCalADANQl+S0AQBpmdR0nKABIEUNwAGsaxlX51ADAARJ HESnImp4AQCpmOA3w0WhXFphuPgABwHseOg8EqwoXBzuEldXyAC70ABgGAWAAEySs+xOeEJsiPmY pKL6UAQBYEAAfB8nwABD/yABSE+UmGj5OoxwgpLjIgLAYBAAAJASgtAADIGYQAAAZA2W1ShMyCDf G8NRgQ0RjAAG0NcZwADesqe4xsAsJwAB9ECH0AAWQsBZa8AlrrjnIJcZ80BoSUh3JUAAlZLENYgR BiFEOIkRYjRHVe1QkTVk4NZY20pgLARsjbGyAAMAXAwFeG2N0AANAVgnLcIEPwAAKgRAehNucSI1 RrZ495vYiBQnHEqKgVrziWAYAyxoUwrBTAABMCQEzK4aRshqiQdA6R0AADGF4MYABqMDYaeoAAPQ fk8DKGpThtjHlOjSmZ0AvBdCpAAJ4TQgQAD0Hm5U3RphBiJP8NQaUGhXirFeaEe5vwbA5CMAANoc RHPQAcBGQhBXQDiHCtYQ4g5GoJHAoxPQf0+gEmkAARwipfj1HmPUlrcUlutAAEII4V1iO2AoBQDJ VV/sBG0NtdApBQvBGmM8YhkB+qtm4scpgkhLMWCEEEITNm8xPmGVKG6TkoQ6h5D5o9A6GUNodQ+i FEaJJciUm5q6cWtEvadFE7IlzuCJEK8Ee4+H7hPCAD2agcnbQya7ROl1LypyrAAHUST1hUi4F6cw 5oAATgpjAKcVgp2LgWY0ZEyNMG7M+HGOQcYAA0hmKQNAZ6zzmksC8GJPoTworDAI6iZzO0DgAHMO ZBYhhABfXaOQb5pynpZXiyoHklQABrDeyMBkBym1HohBVKY6QACFEEGI5A3TlmSkEalrwBymBkDV KYH4QAps2hQU1I9MjmnURTKYXguRUEpPSAA9J6wxBnsEHe0z0AHgOoFUgiFBWg0HaJD1o1rLaW1t tbe3FuWmUViY1hOUg2eM+GuNga4AArBSCslNGYDwGrJFIIUP4AAXgnOwAE1FGrdXZpe3lvYpBcC4 AAIATAnlLD3NJJwAAixIiLAAFcKk4gAgEPHdi7TSGutdFuLs+Qbw2I+HcO4dpagRwMDuHwTcEQNA fKbJ1WFMqZCsFSZxxQj5InrV6AABAB1khwDsxYGoNQhnhK7ZSl9YRVCnNAKsVBoB9soNKaaepzzE ujCgFQM4AACgGfniRL1lh+EsEoJJBww3xHMOkh5EAABNifwO25t7AElXAtxa6HNsaFX1yxlnLWW8 uZdIZbxN9vqM4MaW713otRcC1VsrhEo8C0gDAKkoTofiyhCBoDQgarcyKPr4PEeg9KnCGvYLwZYz AABfCWEkAAhA143AMV3PeXqHTpAANccFawxiBEOtMc8iSCAGAO707R3AjBEl2ktGmkdJJkRIrt2Q XAsmxG0NhazGTCB5D+JwAAIAQHgZXfRp7oBSCgeCLAVoma8gADgHQSIAAcg7CViJ7aBLaYOV+JwT AgD4NiAmBYDQAMC4HBCCHX0AtgJnxy10YQv5aibEslId48B2M2mnqMAGpZdgD0fau3OVLYQ7aLD/ VfA+CcF4NweIGYKLxOyk029AXgtheAAMMXwwyUp5BmCmQImw+llAwBICRkNqL9dakoRwo4+iQFKK pjeUAACUDsrkJoPQd8iblqrhDj6+Dpv+fsQgiC5DXWsQQv5kQ2hzDaewOB79QO94bzlMD835iZE9 shkLI4d7zCCEa5Iaw2dAfiqLHjdXQDlHIN5/AhHMgZAzgoNAbHggRAibi9F2jdEzHkPLeYuRbKAB YC/moJgTAvJpN5pVMhJiPDmXbdkIqRo/CukIQghZMgRgR0+mG/mh8AtlwLqHn/Qeh9F6NAvCom2/ 3O1FO7Pg6BzWkKYUkfa+EEEEGpboXgkhIPDBbkaYq+DhHM0EMwhWRjVG9WsASvyEHSJYEsHj2RIB 0R8AspeC/SbBK6LtzgAA8iW2QOiHjRx9fjm+EWf4kxLmgAkBHkPmPrkxTudI6juBrAAHZ/cAALQW QMAsBVAQeQeYtINgNINh8AXgX4ABjIDwADTSoSokBbsb98CQrCmSvgSoSAO4ACUCoQfIfRlQNoOD pIOoN50YAoBpvb9yiDzShDgKhcCcF8GEGMGTqD0zMTfiIBvZvYWYWwWYABHrxaVDQBuCZwOYLyGA NQKpIR4zKJAp0AaAbCKoN4RzZobocQc0IaEQ3oACLA2IO4PcDL2wNRzQYpCRs4gYlwPIkwAAMwKQ KKbqr63CvgeZTAAAOgSAzgWwYYY8M5DxQaXgLCyIMQJgJZIZl7upLR0AZQaYapgwVYVgAAYoZpdC eqvQgTH4lgDYDpRZUhUwF4Frwg8UG8GZfxmwAAZAZRgoQIP6UwagaKDRzzX4i5eI9YKgLANa4wLI 95lxZKEsUcXwjamSkg34QYPziS4jQwf4fqtojTGKngFCMAMgNJzIJsagpKA0URpkFbKy2cX8bsb0 b8cCh0GqjEbCIMHIAAQwQ4QxBg7kQ40664HwGgGAAAPwMaLIE4EIEEd71IjCmQeykhUYV4WQAATk gQAAeYeg36AUS4AAFYFwFbJTJgtQDotoZwaSEKK6LIdodbAJERvRJQPQMDiQMIJ4/QAZX7nCgamQ 9I6gPAShwQVgXcBD5QhDopi4Cox4MUksLYJCXa5pxr3ojqmUhgXQZQZbJQVwWLoIoC4EhgGQGoGS 9IRy9gE8qpuC+clMcIgREgVUrrtLTcjbAK7EFwjI6Q9YORe4ACx8NwALEcoMrUuAhamQpwyIUITo QoAAWoWRF6y7F4qJG4wIwbcEL41wJDRTpscpSUbTzjK8uMx0x8yEyKJIkCJbMMckFKIREgRYRS9g TEl5hqz7cwg6mQFIETBQGDwUPp1UoJ1wmYbapYAAZgaq4pEybQhkhgFwGIFzl4TIzgEYEAtqARrZ nwSc4oAARgRIRiekSr6wNAKsNwOILacQBLUD6yJDkoAAdAdYdcH0O7iYZxdDogwA1bkIDADRjSD5 a0mwji9ABhQUQprodom0fgia9AAoA5vZPkDIMIMQlCE8FE+kyRnrVAYgYyeYOYNzxZBMK6jQf6bg BAAwpgG4HgI4AA/AJw7oFYGxQIBYBoAAeAeDAJzY+TvhQAbobRdAGIGqf4OIOrZoB56U61AVGYgx 0AdgdZoIRQQzG4nyEJgBgKBSBgEYEs3aE53qmQs4kgcQcCKocwcatat4hr+UtQIIH6agSKX7tic8 zBMExahMblGlMNMVMdMgqEcbhlAKI5O5O4TYTLA4RIQx4L8bCxL0hiXNDb7w7lLUxJGrGBbQQAPz bTYZ/09bPIwAHgGceYRINhdgDxHUdxx50AZ64ZsYSpwQaobitcuZAgA7DIAARQR5kYKQJpIQUQUo 44R4RjCksMWJLytr5IAAHgIBiQOIOY94GQGMqMUNLkuJEhlI0lRkAoXoXanIfwfiow5iPwE4GJdL uDXYEQFBjiC0+jHw6j44bB6ABqBACoC5RZO9MtcDwomYcYcYvphSpoEbwYABUKBAiDPom8vIWi8g XoXCoQs7ebkRlYfYfo6gJcQbRYRBTgC4Cw1tXkRDVCHDf9L7z1cNhth1h9cNM71ErMlRjkZoUYUI UZtISxwQc4cZoM0Qi0+wAxva94KiXkEIAADgDQDibdigiJO5EQRwRiX8C56xbI54hC9AHAF4FgAA QYM6RoEzXhXtgxLavgZERdn5FyRwbQvqTsmx6K1VUBkYJQI7aK+MrAiIY9rgADFQVZgRTwAFE6Ll Qoh0WADADhjQDQDbb4/DmoLwL7iVgdgtNNiAgZEgdgdreceyRoaAZpZ8WYAAGIGlKwNwOCX4CQCj b409u9xzw5X9nAADvg44VAUgSEg4ehGajR1xJQQQRIQSFoKiGBm5nNuxZVhCgzzdhcslx911192E CdiTMd2Iq5EgZ93AAANwNZ2wcAbiZstt1qr6sIFwE4EgAAJAHJxAKAH6lADACYx4qimQcYdCRIWI YSeYVoXwvIbocZ2V4Qg8mwGoHAGtT6aqBIEV484V092pnlNZjgN4NpHwWIVkpQfIfh+7iJ0ZIEW8 +6lst99uAJWB0FEotwT0vAeyVBhtfgAFkyv4QcvABoCND1owqtL0FuAWDODWDbLF2dPmDgjBEgdQ dgkgRYRC9iWaWqEcq5EZ1wAAD5jGF4Dac4E4D804EgtpQaGYp6vgboch2Qc1vQAAcRJwZ6KYAGEY nELAh8myAxZINgOEAoM+KagBgOEBx8c4aRCAAFoLG4b2L8BNbpPQPxsQEAETcpo9l+K+Nayrwo0w V4VpwQVAUaX6kibVTp+YSISjZoJII7RQAQAwmeCoqGC7zt8GNmRGRORRx+D2QeRYipEgXgXoXgAA S4SgS4AAZoZQZp9RMi9B0AHQHxt5cBaQGAF8edXd9mR5pREgR4RzClmw0I30HwO47gHYHkQgASac COVeXpLzSl3AYQAFUJ2wd4d4kgBuZJUZUrZwHB7Ll2RwjWQsxuX2aua2a5R2RuVWbAjhEhTwaQAA VwV4V0DQW+SgcIb5BamQrFyQDwEMBYKoLAKqFoLaGADACpjVB2NWbhnZO5C2LgMbG4XoXWSgBIBi 1QPYPq8gFAFQGdvEPmfmiIydarl4SJBwYQXyWp+p+4LQL5mq6EvABICBQmaIjOadMGiWlOlWlYqe bWfelhL5El+5lUMIAAWQWEgc/RHYN5Hyrt02l+mBphEjNx9IKwKC5IaQaRZ4GwG9CoOAOtzABwBz 9uAGoOq0oRX9wQQ4QSRoueYRY5+YThFoAAHQHJt+XWQWbZJN1K191eDGq+uGuOuQgul2uZOsc4ZA ZZgoLwLTiR3gAAUYVNjQFoFSBgmjVOuxyDVpXgLoLQLpB4aY5YHwIAKCXgObChQcoGoGxOzhnoro V4VjZAU4Uc5QegeotITYTzA73LRTfUJmzYi+k9hmzu2m2uR+uu2xLxEipappmZmoct7w7I7YAAI4 I1CrVGD+3JpOxZ2Wxux5CGcAIAImeY9xRFTukmqu5W7QgSNwAEKAuqVxzIc9JwAAMQMwlAPG9Nda 5m5OQmtjKsxmlG7e+e+lx+3G+oyZEgd4eJGYMILglAYwYqDtVU5W527mxG/D1RjqSQLIKqGAZQYp goEAEsiBsuTADYDgttSHBO3LSgsBaykBYd3y4oLMIwAAP/FB6ACC1Wkoim2WQ/DnGPGUrW+/GYqi jgXwYAX28oLqwVljb4UDYd9F4+fW9vGxSS9AOjZYAG0CWrHRQgPYP5sQFQFd8sreiHI+uzSipYvo RQQpYdE8RnEqGHFC6IB3FfIwmHF/LPNnNsUfGvNwjMc8VxdAMSq5GGYwAAVAVyzoGIF9ZmVO2HOJ Mi+8DQYOSmmos7ALZ7aJXCX5D6M+XnQeldIxB4apCSsywUjavwOwPhBwNAMxdmg2kmtQjnNfSfVH VLg/OHVQiU4k4wQhTYsQKkNwRIR54JUOCnUvVpM6jiLYoHUBdga4aa4ruZAQPQPrXSQEebX/QXXm AO7oYYYbNRQ5DQeO/hgwSzZoKYKCyIAgBGn4yvU/Z/cncq3HVncwg7M2wAU1jQPIOwso6w7CoCoQ CY1fNPdJR0c9YgXbNZXNG7eaAy1QshwQFwGB7I3WK3XffN169AQgP7iQZ4ZmYQCwDJAQTITrZAGQ GFXUk/fHU299hWt/hnknkqgfdHfMc4YgY6ee/x+ABR+YUwVKPo7w8HIvFvkxMHdcmXfsH4AE7c7i qshpelZsdYDwD6MHnODaaRvdjDoAWAVZwQeoerQAMAMqLIQIPSUwBAB5+dZBI3cfpXsXsZyHlHdJ O4PQPBPrqq8gK86U44Rk5THR3vr/sjw9ixPIOIN494WgV55o5o54yI5+qQx4MyTAAAHAHT3Qrhvc Xvu1GasNG6RIQywNsY5QAExEO9zEnr3QAgA/cPsHkOt2Q3x/0v0y3cyiiz092nkjqVT9UNT5kWsg HZt4TwUa8nXPj/06TzVAZYZso4PwPaMYatpUZMZbZIA4A5QgNoOSX4HTaErb3nZ33bz+7obobqDQ RYQ4pAcwciLkDw6gP66CRQL6RoAoBVAH6YjfsP6n9v9xM3s3VBEgs4nAL4LitAZQY53QR4SggCPA BYKpYAABAoBAD/hYAh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0ehUKiCmUqmACMRKMADtdb th0Mh0qiD+f7+AALBQNABxOyTAAyGpCg4BlT/nEnqEehjgcDYhc4DgcEYAAoFA1RigCsQAd7udgA dDocAADIaEIAAYCAYAc7ntYatwABQLoVgv1+pkKez1egAcrlboAfj8fcRf2PAAaDYgAAQCAVv+Zz WbzkbANjerzeIAR6MNgAZ7NYYAfT5fIAFIrFIASybSwAEwkE0HAUKhlPzsZudzurnAB8OJ8AFmdw AX69X864PT6nV63X7HZ7Xb7nd73f8Hh8Xj8nli6n9D/dT1dQAMJdMOKAz8hvA833/H56cpABmMYz AAWhZFoAA0DUNAAD6PQ+oOA7fIa/UIwlCcKO4AquAAVpYFaABAD2QCZncmwAn+3wAp8BYFgeAAgi GKYACYKAxgACwLA7CqTKcnxBD8LgAHhEQAQ+TwAAoCwOJu+yoAOA4EgAYBfQ4SpIjqAAxDNECxAE ABXFUSgACcKUECEIYqAAAQCAJJLyq8A4AF0W5RgAUZPkUAA0jaRAABqGwhocsarq4Aivl2XZUgAT xMj8uABzUAwEScfbXOWdz2qyEQADqPJMAAD4QtmnKHyVHFSI9LQAHUdRygATZLwYZxmF8AB/H4nx 9VuAAjiYI4AESRZEgAC9hPq/LhrourjuS5Z2Oa57o1LaFo2ladqWra1r2xbNtPM9BTvU9j3Pg+T6 N/bdzXOkj+S3LZIEeSAAEOQJDgAKYsxeRJG2AoAF2JdF/X/gCUIOxR+voN41jeABbloW7FMXgaFC aKYyAAKorjgAAGAYoSnVHgKIx0AEeR9ICbD4QZQgAaZnmKxR/MaCgKA2ABZFgTUz5wLoxD1ToPhP QU3GMYxbAAV5WNuDYOUwD4QNmU5SEaAAxjKP4ABGEoWgAZJjl0o4aCAAAJgmDLnF6VgAAcB4JAAZ RkFyAAQhEFmKixhJmmWXoAFmWJON4uaCjaAAWhaHMzzQAGCn1AJaZSYphFkvS+AAKgrjcyINMoTJ KD2ABpGi1YXhlsAhCJF4aBpPwAgGuYCgHC9C0OTZK84H4hikAAvjBngGggCYAFIUF5liV2bjmPDb hmpIAGsahkgAVZUkkADBsKKws8sGAYh9RkLnuex5gAUxRpkaprecFIUhrivKgACQJguABum6agAG iZxhcioRhGAV4ACUE0L4AAcA5CU4ZLbHV0AEUaAAajzV4CCRmPQeQ8CFokAAAaDAABECMT0E4JoT oLgIK+uVCSxjirJOUcxsqz2PwthdC+GEMYZQzhpDUjy3VvntPefEfh81+w2iAqVdYAB0jrHSxUKA VQADkHCOQAAkxNFGCYEYJiswCE+hJEGLUWzxFfK+KwWDZw9h3c4PIeI8lZj+H6AAJ4UwzgACyFwO IAAEAIL6hCLTIWRo/SCH8QopE5ifXmN8b41wAD5HuPVVA6onGtNeD4IQUQABrDanYdw7jjCFEAGJ Y5a3Vpqjqk57xhQ1hwaiPsfQ+E5vBAAGAMaDATgqBpA+ThrpVDtVUAAIQRwrgAB4D4J4ABNCWZ4O odETh9zJAAbprIdHjgAA6B03YthbMpFQ+MAEZh3mKmUCYFAMHJvXAAJ0TCICaDmcRGpegVzThaC6 HQACaULwKdeoZVjswAO1du7lngDgIgUAAJwTByhbCzFEAAPIfW+l8RW5png3huDTYdGsDoHgSAAD mHk24HwPmzFAJwQQABcC2TkPxXA/R/xrC6F8PAAAohVDUAAXguVDijFAIaC6jyyDvPaGkNiegiBH IMqeBC54FJqG5RFkQfEfDxHgTZgZVyGBnDZG8OAb2MF8X5Fk/UJlkHIhSsyFZ0ouVlrNWetFaa1V rhdDg9cOlxQ9XJHitldTpxDHsPkewAAyhhDLTIXAvAAB/EE1UM1hy4AGLnVyu1jbHEZQuhcWQtXI B5U0csdpzQGgOAgAAOwehMgABWC0G5Sy5k3rRHpHsfCbR+kAKUUKwBljJsEHwQLKQQAhBUaQRbgR 1DpidbYUCiBNCDAANgarzg/CFJc0krYphQp2Q3aENAbk9UmNfTZecrkGAolkh0PYWplgnBeAAOAd BIlcAGV9X9MTCGjDcHERzGQGIrD4HgKzcARGzBmDYIswhKs8BwDqAoXwxs8LqOFhQtWUhSCkGkAA yBji4S4KsSoAA2BxJkDUGoRE/pbUCAVQYAHYKIEy1U0MaKokQmSa8FoMAeYYDgIt34n09DjHENyz wfFOAYAuB5kQfoAgTAq2QGwOL/qJaqEwJ7FAphWDWAAYQwX+ieE1SENQbVgDsHXOgTomhA0uCphB wE8QCIXqLDEpiWzBxoFCJ8QpzheIcpM4onhPgL4+AAJV2QAAaAylmo2xddDw1eONWBZazToVksfo 3R2j9IaRIgQEgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVACnjD/dT1dQAMJdMIAfgGfgAf8mi0pl Urlktl0vmExggGAE0YDEYEekAABoOBsXVinAAnEgnkwBk9JmVLplNp1PqFRqVPAIAqtKN5tN4AWa tWYAfL7fAALRdOoAKRUNU1BAIgT/k9TuUvuD+ACCPxcADwdztAB/QqkACkUCIADSaDFAB5P6dAAf D4pACZSp6ADfbzVAB7QCeACWSR5ADmcjdAB6QCfAAgEGSYC+VwASqROgAMZnQIAfb6fIAUagQ4AM BjPtDFQ0u58LYAFQtG4ANZvRYAfD3eoAQh/MFvu3NHFWANVYjCr4dDolAArF3PoKUjxm4pEIxaAA CAVXuAAA4HBIAVZUEiABWFS9w2jkRoABqGoiIE+y3pOAoCJoXZdlSABPEyP4AHoeZ4AABYGAeAAE ASBQAAsCwNrIL48AADzzgARhEDSAB4nidwABgGQfJqA63GeZqcgWBKfhQFgbAAWxYtUGQaiDE4Lg 6ABznMbwAGaZRfgAMw2EKsB7ns3zCgAL4xD2AAhiKKz6gIAkHrnOCHPCqp+n4kpVlW9xZFYTDqHu e7dH4fYAB8IUeEoSz3ApRaULjOKFAGAFInPSgAD4OI+AAdx2RwX5el+qtH1FUdSVLU1T1RVNVVXV lW1dV9YVjOKMFOjSOJ0kKRpKpVZV7X1foMAT6gAbzMAALApiwAB32YycMAAIIfSfSS3pRYFr2xbN tImA79AAWRbFkAA4jcOManhDwkiYLqPDJDQEAUBc323OC6ruvK9r6v7AsHMbEMUxjHMgyTKMszDN M4zzQNE0jTNQ1TWNc2DZNo2zcN03kxOC4bihO47sD9dk02UKQrLW3ixkAPq9AsCsVDINJBAACAIA okz8gKAtumGYJYAAS5KNELgvjuAAiiOLMNw7K5mS0GgbQYXhdKEVxUkqAA2DkRkEwXBthZuAEIwn CoAE2Sszh+IYpTIMDLAPeM3vtYR6noeQAESQwzUkAYC3GOhIAABgGgmga7AIAc3GCYJYgATBJtEM uYgAHgeibNk3bBw83FoWhQP8U0AjkO73BUFYavBSNq3opu5AAep5niABHkcrZnmWnLeH1HIaBhsp PE2AANeFRtUUjSdK0vTNN07T9Q9X5/oej6Xp+p6vrev7HsoRWlbI6j9cpJ4ntfH8iB27bpDkW4JH EWR1CB/HhOFCTgAAV+3y/x/P9IeQpBS8KATjnh8j6LGHUPImQAA5B0EgqwA3Un5f2SlexeC9F8L8 YAwRhDDL/MWY0x5kTJmVMuZkzZqT/CqPcMkYgt2sBwa2CgFIM2ftBAAeMWh0A3iJYwb037GziHGO QIRkKaAirKCiFQNAAESgMAAItGYAByDhG2AAOYeRLE1AMW4TQlzigyBoD+D4KAACQEWVsDoHgTAA DeHQR5hxoDGM+JIOxaAqo0H6P4uwtBYP0DYHFraCkGH1a+zhCQAEKIWbM2htTbG3NwbAnMAEdx+m fEgWcaI0TFB2DyJcAAEQJAXAAKETwhjmAsdOCIEQLImiGiSEEIyayyhzAAMEXzjBljKFyAAK4Wlz DXGoMwAAqhUOADkHZ0jpnUEDUdBEiEDlImYGsAAQwggxAAHUOgch9QArCD4IJTIXwthfbCApvqvF RPGSm8hTCmlOAAU8qCZk8Z5TznpPWe0958L0e4Rt7xO1dPinzQFUqbnNi2huGlyIAARgiBGAAUAp nPAdA4lIqy1Zl0CoxRkqRVSqjzo8AAKYTwpgAGqNEaZ6QXnfdE1cCgFQNLzo0QqCa+ILL7gyv4xM HWBQgYLCMakJXPIRW6JoTCZxijCFqfqLIAATAqhkNobAzgABkDMbkfUBGNHCh+x6IMQ2RgAiPEmL J/R3juHW3cQgZAADZqjJEfkkwW0pAAGoNoigAAcA8egaAzxhGyEhHMdQ6hxFvKqEQI6ygwhlOKOQ ciVhGCHRoOkc44aQBXDWWQswAE2t9cO32Q7ZWzgAbS2sL7bT9SOggQN1qzKzmzLOM8ZhOR9m7AAC QEwLwAIGQQCUEtuBcC2FGAAT4mxCOuaXFktwWQuG1CcFGtQuhcCmmC6AADopjunPC6la1MSCzOAA OMcQ3AACKEMGcAA4BvDXSgBUAAmnfgABlfE+oA1hTmLlOhSg51LTreXO55t3MAYBwFgPAmBcDKjn 2rd75Inw32wPg8hzfW+jMtgrgAFV3dCrFeKsAAKQVGSkhg7CGI8IYSncMJLQcg3ByNGOQcoAAnhV vMF4MBomcrdXtiTHWO8eFMQi30ZAyBdOyESG4AA8h5F+CWE0Jl4xG12k8BGgF91qX5v28qds73nY 9y5l3L2X8wZhVNgmfr4Fd3bzFgSjlFSqiNEWggRYhTphXC4FcAAh7HxKRJlPNOfZ5vnAAKgVgqC/ h8Q0PEeDsQtBeNrEctabU3Fwovn7SmlcBXeHWOscyMRDlrGsNMZVtQUAkIuKsoQGNUKkvxOrLDzJ 4aW1hrHWWs9aUZzJhaf+Itaz2JoTQTQnRNAAEAHwQAAAXgytwKIU4omZgOAhnzXe0Xo69K4Lcr4e Q6GiHdtsAAXAxNFCaE8MrYQCTltTtLdG6XsAGqWKgUrWxVCmEmSiSYjRIoICcEoJx9QD31zQU/Vd +nkzs1dlvdXB+EcJ4Vwspet8F653/wx7Swm5nWNsF8Md/ktCDEKIM2wY+MgCALv7SfEuTKn2oLPa xp4DAAHSOodIAAqhYyNcqWVm2b8l5PzvnicMfw1GJUkS4kmijsmuAAPogjihoDFEkAgC03F2LsVL gOV+Cca4Nz3rXW+uddy7w6f2DeI9eWzmsfw/y7B0DibUUooRSpkDFOIQwhZSAEARpHsfZO9FLnQN bv1Uww1qG4NwbTkweb7DcHNBACwG7P7R1PvfkfJEQAFfTFo4NhHKAAOEb42WsBvDYAAO4dGigIAc W7XRTOq8Dv7lryfr/Yex9k9PsGZtoezVdoAQgiLiiQEa4BNIQ72ic2CvAt3uPkErzWPtQTWA0+hF 0LXIaEiadJuC6U5CDZlfJ+51s8Lcx6IeDsHIJ95xu3qCqFlNYgRCm5AlJ72/qsq6s6v677v9/8f5 /0S72uDMzudP9i5uKAAB0B0h0CPAuCQhnwFjPhNorgogmgoiBHMPUwAv9s1hEBDDDBOBMH6B7h8E wjhlMgmAnJqmdPjtzwLQVNZnWh4B3h2OWKRhvBuJogzA1G9A9A8jLAFAHETQKiZPVr+Msr/wVwiw jQjvcP+uIQAQkCmNJAAAvAtgvJ3BdEtA3g6itg7g4Gih/gDilQmCJwBhqBpqfhDg+jgvoshnhKXg Iw2iChww4AAI8C7AtgxDlg3g8CtgLALgLP4wmqBJ0BxhyBxgAKEEaBnhnKpAGgHgJIqA7mrgXgXg dmvKYQ/xLMdnNAAJLjFBHhEg2uXB0psg/BBg/EtgwG9ABgFFIwfiYwgtWusRLxYxZRZt0BUBThUB /h0h6uYgwAujth+gDJJxWRaCIM1u0CThqhrjNOmIkttkcBJhLt5gjrDDdRqiXB1BziOhMBIk+hbB XhbEyAvJxAyxyGuHTw2spCCQ4LKBUx2rzhwPMBNhOHgALAMw+hBBGmZASgSD0CSiSxiJ7E6pJhQB PHPBIhHkAh3h2h3gAAbAcEGAsrMgRgSAWw5B/JJyASMruGciaBbhahQqHLiE/EwhDBGpSAsgpGkg AgECru8u+P5uBQhOCyNSaSaybMDRbRcRdOYuHuxQwSbiECkCqhyDSKQAnKRjdlBhIhKEAghm0iwS oCKShR3vMA9A2jLAdAbgdIsCaA8SvOsiWBkyxNJCTh2B2wYBHHZjsBIrigVS3JIy4SgHss1h9B7n dBcLoOkA8jih2h1wYAIgKJQOZxPsliQtzyfy5TEltnWskSGBGhELLkgBggAIzkpBRBUNmASgRj0B /ikE4xXP6wiTFTRzSTSnsQlSfTTCDwBh0OjgvgspxBsBrhsAABHBJH3AqgqAqiRTeRiqKh+h8pJo ttgh+B4iShvvOKHBPhQSwE4hhznh/hzB0NNhqBtKfg1g6LLt2CaRhzVFYs1k/lABRBQNmBLBJori +kcHWgWAXytgsAtlzHSkkQnzvT6lZLvBahaSQBRBNLih5h7G7AzA0m9A7A6o5gFgHF5TuwgSYOrP WzRT7UI0JUJsxhTFah1h7qzgwAuDtwl0JtqBAhBDchNBMtggjgkgjomhFDpgHAJAHQ/CEKCLhBND VAIADtnxMguAuguTmlRznhhh/hEBFDDEfFug2A7PQgaUlRqlB0KOyqKvmFBxDEkhZxwGcm+w5gAA JgKAMJdAuFzAhAhk1tIOc0nUzKNw5E6s7q0gALYLZLZkYhImtgqgpTdu7O8TEUGHjyYxXv7Uz0/1 AVAiVTUP/z60ZBiBjhiJdAos7ANANqXhVBYBVAAAQgOgQzeR/iHj+j+hWBXhWPNhqrKDIAPwoAvA vUelXBjVVB/htBvPCgKAOmbAdAfStiCUF1BFHs1iCBZVeNOGtx4PMSpqKiEo8JJggAiAqAAQpCzg KgKEVVb1cUJTGB5SGEZC1hphnjFUogAA0A2Ikg8A5EWgDAHTuSXOqUGvWQhtX1o12V213BT0LB/0 MUNUOP/UYSaQBkbHYg5A4sWBhBfK+g4g6lzQowpgGAIImOpCGsTQxqfhZBVFxB1h0KzhOhOBO1UF Y1VBjB/hy2OgABxB1rBgwgxiQiaqLV3T7lqKTBorcq6DLhthviBVUQnrkAAA7A8E+gZgbAhM0QU2 UUJucBYBXIENlmth7B7B6CeCfAANlNmAZAYgZL5uSNVV0SZRYWf2sWs0JScxcxdtcTUnoQBroMhh RBMtmBtBrvChwhwLKC2i3APgQVSAZgboZA0A5IkgUAToxJJyMJmRjB+CThbBcxwA0mYAAAZgaIZQ Ok+gMgLgMy4W+iFOzB7C7BYhaHGBzBtNNgenKAAAgAgggWMFfBgXSB/h8B8ixhrBvpogygztxndH dWtFsM1tMqzhRXbgABdBbshtPpo1ij3jigqArRPk7Um3ZTVHWkqLBhGhEkaQZqfrZlB1HKXhLhOJ OWn2ovK2plTzQUH113j3wXwyaWuB0h6ReMaJIxg17lSs1h8B6CxhNhMHgBbBWRwAv37pghVVJgnX +AAAcX/0tAJnCW3AABqYDAABi4EgAAWYGDqB8CxlED3AuAyC9AxAzpq2+HstABVhYsOA2gzxPgPg Q1SBUhWkLQ131iCtABcYWKSBljNSBC7hBBBXRFtg8A8g8B/heBfBeAABXBejYgGvGQ5YiXxFrl5F 5BMhPoEA7g7PSj+OkBBNmAXAYSti4HnU84jQVptlhBhBgDYhRBOjgi+uYlrVtgiglAim7hEodXHJ QFe3u11Ya4tY6Y6v7hTBShTB/h3B9kcAuyI30xhVzFRUZBvBukrEMDPPT0XsmHLBnBmqpA1ZJY5i FBTZLXTYH3/YAAyAyq1AtgzDlgsAsllAAgCyW4slWwBh9B+HdQbi1hYhXnGA9A+DLA25bFJADRV5 BiDVNmfhMJOAWJUlJPKgAAiAigiXRWOhyh/h+5mprLAgAUlAaXRBAZqh/h6ZsUyiGBG5uZKCCgrA sArB/g1A7i1gZgYIZXYY7Fe4kDJ4lvRYnD9EfDTg/EmAaEeCTlQ2fZ1uDrvBaBZDPYvHGASgTAXI iM7IzoxD7SwD8C7BlBkpchYBWoEBuBshpU0yMFQ5mpJgSgTj0RoN5y3AVJBXtlXY4yZ5+aU6VPk1 4UL0MjhV60PFRs1gAh9iqhWhXhWp3BZEtAkafEPgFl5Apah5vCXBhajh/hVBV1JgFAGkTAcAfDvr DEGFB3jFYp0B3wXDJhMIEBPhOjVAlAlglAAA6aynggOKX2FCIZChuErBhBeK+hzhxL9BEBDhEZvA q68h/h86+U2wGBx7AXRAPbBh/gHbDE0AhvhUyCEZuBG6iiBhfbIh/hi1soqA5JZFAFAaVlW52hNh RHgA7A6I5gDGdDTg/57Z8Vh597NtZGxAABbhbrghPBMNi4HkwpICnK3iSgVgWAVppBFpSAYgXgYl JHD4UlV6T2r7WbliAACBQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRuORtTKVTP93Pp3AAulo ugB+gZ+gB/y6OxQDACZqtVKsAN1pt2VPuWohEogAzGNGw2mx/iEPiEAPcAvcAGAyGAAAoHAqYS+i R0CACusllskAHU4nUAPm0ABEIxEAAdDsdV4CV2X1qHgUAXhptBpgBqtFqzR/zMwGEwUOHlXFP+0P kAM/IABx5PEQoO5d/jjNAANZ25V2EI3RZWIkglkikiSmGw6mwABvYSrZVvabXbbfcbndbdUKZUAC 2IumvZ+AAqFg1gAkEovAADgisP9/v7d9XrdfsdntdvuQ0AgIBAB6PJ3gBMJY9ABlMVdAB+Px9wLS Rq658AFkuFkAHA5nAAAqCgKqy7qOAGAEDHPBIAD4OI+AAdx2JKX5el++cCQvDEMw1DcOQ7D0PxBE MRRHEkSt0U5TFOf51nwdaoi2qh+AM4r6uwA7nAAXhfl4ABelgXoABIEYSAAN8jQtDxRSUf5wyaAA IguCIAByHocyCFEiOK4sMKGoZ8HmfAAEcSJHAAS5JkuAApCsKQAEgSZIABLsBopOZ3TuAArCSKwA GcZRnSQhrFCqxi0sgZ7JMohgQUYf540eAAM0k9z3gAQFLgABFNTUKQpUChg01Cf4JAsCTlCgJAAB eGAXgA+L4xNWNZVm7U5mIYRiAARREEUx5m0QJImOaKwtP8CQJAuAB/H8ltaWdZ9oWi7gBgGrpSlH XpaliT4AHgeB2gAQJDECAAxi4MYAG4chuAAal3AAbZsm2s60gpewABWFoVgAFl+gACYJAm+VpInA 0EQVBkHQhCUKU/gmH4hiOJYnimK4ti+MRIj6Qnefbyi4LQuJUAqWxq3Suq6b2VAAURMlEABynEco AFUVBVYdERB50f5ynNmYjCiIwACFollAG6mTO1lC/GywIoCUKAAPA8JSFQUgABsGYbVdrk6zkgSt MmcYADSLY0gAYxiGNnCE0HQrHUPRJx7YEW6n+cG8WVZaCkfvoAATwAADRwe2IQPA8jwf4GAeBgAB uH4bgAzQcAAfXK4zzHMwy8LwmkaBpV0RNel2XL2h6IAnAALYvDwAAPA+Eu9WbzXadr2zcAFakHnY dAAEsSY7gAZpkl/f4K1MTZPk2AAZBiGU5AGoek9ui+DABBJzwXBvd4ZCvqe/8Hw/F8fyfL81oFQU 5UH+dJ6nSAAwi6MNXANWDdTmfx7uoWn+AAbw1BvAACBANobRHCojEoJMSg/zvlDAgBsCAAAohPCi U2Cx3B3wZbIGRs4w4PJiEgmUk5KXLOWIwnMmC6RuLsDuGp4KO3vETbcY0x5kWxNsMuB0zJmwsw9A ABaIDejqA+iJAchQfokD/AUA0rAMQcgxAADuKRZ4qPnitFdqUWYMnlE0JgTQABOCaE438BIDnVBf LMEIIgVyBl2ixG+OC0TvnhHgO4dQABKiRDsAAaAzhgqUOKHsQAewABiDCGIvIBy8PTjiQp6z2HtM KQiABCcMZGyXkxJmTUm5OSdO0KaUBIh8klhGSolidDbAIUyAAWIsxYswGwzNZZ1A7h4DvEZWYmhM iaOkAgl4RwkBHAAA8CwD1lTHNu5xB46SSiREsJEAAphRCmAAFwL7Ig+B+Qc1OVBMR6j0HqAAJoQA mgAGiM0aMuCCBdnYP8es7wACznkAACE9WpHgSCCRIgJp+I5F4jxyYABV0DnURML4YAvj/AuBlZIU guJtBVRFrj9pPUVYiXgvAwBfjALUUF4QyxmgABiDQHs1Qvh5AACoFYNVKUUotS+mBFy5l4HEOIbL vo9AAGwNWkI+h+OWDSGts4aw1HJVIqaRlMJHsIe2wuSjDaY1RqlVOqlVarLSFKKQUo/x5D9HkAAL QWQtMjZLCkoicx+1pAAKMTgo5oigmoFUKAVQAS1luxaXUvBRiorcJsU7ywMAXAwbJ2ZtSZkzFAKM UClg+iAAAC4GALjzCcEwf9AM3SO0YnNOgnI2SeASAaqYJ1o5cBhtMP8e1qQAC+tZPc8JBJ9T7n6N C2lKaJCltxQUiQUQphRH+B0EAHX4BrfmCIEIIj3XJqvctDsyhxDhHEAAR4jhHgAFYKknAEgKAZAA FcLIb2hhFjYtQ0FZrmXnk8fVqwjQAC3FmKEAA8R4HlBOCoE6uhHK9BmDIGZArX3LqW9lhL3KnyWv RgfBGCcFYLwPVmrdXav1hrGP1klmCOWHAANkbFNz1jKAAPIdlXw8YjNIJDEw/w94pABO8erbG3Nx hpDeHI/wD41pEDGKE/0eHSLqdKMgCSCgeyEeoZQylA15OkAsl4XnVgAHtk42mGBhDGGE4IMgaG/g KyAKAUliwTgmvvFl3EWR1jpRcLMVgsz1DEw8KkVAqbdLQFBnOrg/qvhmDCGbFee8GZ9Oy9YaI0xo kmCwSkdo61wANAdBEQAhhTpBBKCxvRBI3Z+0sxibg7XeJuEcf4ao0hjuVHw5YGINYoCWEyJYAAH3 XkuADpXACB3r1Mkk93OOl9ca511rvXiH8HVcq9WCsVZMLEbRujcZozKQjhG6OEAAGAI2DCMEcI2J cT4pkJizFxi8YFpxkZjGqN8cRQFtuXH6Cw+IOERuvIOQ8i5GIQDQHANB/gWAuBYAAmhTRfAWAoBc xzqQna+PsfB8Rci8FyAAPYd5CKSu4JASScQV0quSls2ycx98ZrXW0AAqBRG/GYMgZmt1nKhDSP8J IVwktDB+EKKhjte8xIzWhZgAA2hqDaAAWgrxaEqH8cUIoST9BrDaIl6BoMfMUS6YgYIvxX4ZGxSE KoVw3JPAnvg6esOZRXm5O+r4lhJR7GQMXhNaTigDdyAARIkOjBRCdBUAoCJF3muZgGSOBJK8k633 vvnfe/d/IGihFQ6x7ouDAFxGKM9ikWTnq8oY2/IV1hdgVQOJhIYoxVtohmLzI4xMpjPcON9ybm9C Gf0wAAlepJd0kgcRAfKBCkFQKQ/9FxmDYHY1wJfdcVIrCjgIzxoqICuFKNgEfjAAaq1cFIJgU0TO y0tdw1DzCNsqPkfBjmas3YsJsTQmx/j7AKfEJP456AXgidTgPgP1EKmUOX9xYw6FmGOMPUJaEwta 5cGQMy5ANAcuQYIWoLw8gUQE2EqD6XgG2GgWUUqAWAagiDsD2sqBaBaB2v8MQ9Y/WYsADA29WJeF EFGOEG2FgE6AAEkHwTCA6H6PiFu4mAABmE01UA6BIdiga8W7q1kkgwGqc7zAzB7B9B/CAwU8ERW8 KKi8QPc8UqS8Ya+ACH6KGGRCg+QEwauwc8q2u8yne22UI26Mc2+h09C3GAAF3DGIKAfDMAAAZDSA AAbDYTlA4GPDgUCDaDcDaH+ASy0aGCc5cB2BzAqhKIqmUHMHOHMAADUDODUAAL2L6EGEOEGmqC2Z ES0O6fwH4OoGgGfAUEaECvYFuFqFu70Q6ETFEH+AEAIPCA+BQA+AACWCUCWAATCTDCDFkIOaWEaE gvYESEG6MAMAKLxEqOKCgCmDOfgDID9DcelAwua7SFqFmE8AAE+E0EEkBGOISH6UqBQBYBo4UD+W 4AcAcYEOk/S1wHSHQHJDQAamNDSjMx4Wgm4HYHYeyEuEkeCGcGYo4IIdmA4kUAAFK38AABGHcPKH +rUkKOasYIFDujawQ7tB0knB5FnIhIjIlImfNCG8I8NCORkRo7o4ES7CcAAbUVyFYE8FYAAFCFAF DCs8u2wxXCy822486288+3AxtDC3KFs3O3SQcE3J5DXDbA2KHDgGOUCDdKKH+OglUCECa5cB4B0B 45eIiTmH01GAAFsFvJwDyDqpQzABMAAEWEcOEvsBU+cQwlUlVDGF2AAHMG9EIH+H4JeDWDYDXFAQ xKcB0H+AoAsAoTcE4Ti+MSk/RIpFmesHWHcRcC+C2C+T6GWGcLzF6JVGsAACICQCwABEOEMJoAMl VHCc27SFaFWEpH4FAV6OmOoH4rUBMBRK6B4B/KeFEE6ZeIIPePiBwB4VSDmDs1UxqyBM4wOAIWqA AF0F0moE4EsD+ABAajMDG/2SmB05WgYja60Q0WoQMGsGqGYAAEoEeDiZgHIG/GpHZBqD8EPGkDA2 oQPOWJcGY0GJc4CCuCmIEEWLaUylUwPIYqbIcqhMFP3P5P7P8WhItCK8O8TI3Ok97CZOg8gXmhah fP0INJ4+8DtQkmqC4ZE9DKBOQAW3+bquQENQ8NeNiCPRER6F6SASa2cDzRTEKDVEQcAyBJ0P2DgD gziCiCot89qAANYNcn5K7EkIYTm6yAAGuGwGufgfkVcH0PiEoEvNCB8B4B9LIQ+TmHGHCbGF2FlL SB4BtKecnLoOuDkDmDkt+BGuECECM5cBABGBA95P/IgTmHyH0McEQEILaFSFOFSPEHkHoTkAFGQO oBGBKBau6C2DmVUBhKfF4RvCVKiO+crKmkoF4FUAAFgFci/HIuimQPqASAWyADqDuLMCuCsjYnqg iF6F8SAECD+XIG6G4J4hTF4JmCsC3O4COCUZEAYAWmNUWkudyPCGCF8FdH4FEEYAAHWHQbHDcITU 0AQcaBoBuCCAACGCNMqBQBSpYAOANUUI3QwH1TiAAGOGKFq50FjBIG+G8GtAW4CQsH65q4cAAEKE WEK5Y5cAIAMLorMteZWSKDkIEGcUQcqVgDFMUAAD0eCmGmMbAqjPu1q8pTbYdYfYhYiOxQDIxQJB tI6euHKeyDCCsfmGUGM3gIOE7ZGH+DHZMISLmK6A/ZWAAD/ZcABZHBIGDZmISCZZsAAUHRXRacDR hRlRmIoCCCGCCVGAoVMEIEgEIUiAwu4JasKISTmH4HqOKE2FAeWEMEHMwCOCSmEEqEwEqOcxtV2Q vKkHucs6aj+FIE0aulcFnS8Nyb6EegZT7DQAscaCxbvKhYlP2aWE+FGW4EAD0scPgOLQw0ox8BUB apYCMCSZEBoBqCHQzV0OnafUa68nMGeyqFqFlGcGsGoGXGoIQrSJaDcDm6rZ8JpWwQGaWGCGGj+D WDOOSHfIDGo7MAACYCgfmC+DFAOANWzA6kwAKAILwF8F/WCE4EvAOHovkYGIzM4AcAeYEBE0iAAM uBGjIjMBCBGX3d7Pqa+HUHQuiSbXQHCHAG0AAHQHOHAW7MMIGcKPeOK+ZK6Emd+Xw4pBrbEteHWR cAADjO4koVzUcIECgnKAAENGkP+3xYSorYW7xQdb1gfghgjgkIW1+wg2EwmwrbEIswww0w4GKw8x AxExIIIGzhKH+EvhQQOd0IIm5Q03+UuEAACtwq2/cZmFjhuAACfh1RAA2dUC2C2ACSMDexoxth+C 2VUBeBezjJOFCUcH6HiAADMDEz0nCnDR+a+H6H0JaEqEta+EID/aSWC5WEvePORU24AVnSAJgGAF 2o4G+GtO+A4AwA4ABbuCxbcIyCgCiCgH+AqAwQECmC3PgLeLiVfgnYeWYOoFvkXBKEaEkp1SHPAI GQMIFgIPuIHJwIEmoIEfst0lmNeA5h6yuDIPuh9DScbMCIYmUHmHoHm7UEO6MFaFSFaPEHpT3QxN KseBlKeC4DCpQBGBCX2jmdsdyQMHQHM2cFEFAEOeEGSR4/tPAx80LMqDkDhX4AuA0WSF/m2TMTQT 6GZMa4yPjcKO2PrVgckB4coqCbOBrcddQJng0ImteueIEP4IEGTOwXoIECwCoIEEIXInogik3gZB 3gdkPoPoRoTP5gq2Cwk2Jnia8KHdE42rcFMrgAA5C5GdqdOB6H+E0FQi+oZaYNmIWs0EeEguqEOE LmYCMCQaEi8sqAQATM3I4WkmUUfigEUEGV6HkHUq/WwRvZjjwIQf4FoH+EIELaSDyEKpRSfKeACe jYvoVYgmUGMGZc+G0ETWICkGMLEAgb3nyXKIGXAIcAsAw3wB8CDSgC6C+JSBgBaBgv9YTQNYwPqF AE8sWLZWIPHT2a+IKH9cnaXFUWIvAB4B6dTF6RvgURHA2PCG/jeAAFaFUEmPUGPLSp+hNAuhSK0C sCyT4D0D8PSAkAiqRpqIUTmHntSR7VOV8UQG0GzfNtTlcHGHAbGvmHhCYM4A+A1eoMuABWqBQABK 4AACKCMCKh/Ly1droO6teHltwAADnYMFuPbFe5gCLWgukOE2eu5sWfLoJPywNqnvFvHvI78lAJCH clGJMJQlMrLuWI1LMlYlclglkb2rtqGQ2+4+8H4AKOKCQCSVSAg/NjQIQettgpuDiDdO5SobGEKE VXluMaFM1nhtMYefwb3NeZeFUFBUkCOCKmEyEA8XLZMziGZxMH+EZxSAAHCHI2cEUEsV6BSBW+am 5ohvLTaNAFs56rqQcADHIxWyGFhuuAAG+cDHEx8ArySABa0mEBAA9TXqhvwI2mUF2F1LSD2DykJE Gey8deY0omOKW+aCaCcXQB0B7FccAcbHYO5QwGkGiGG50FksWnOyqH3W7y9IUJfOoP3mqAADKDMD KKqAYOjwqwStevmIEDsdavbuoHvFiCK5cOBPmA1h7r8fHu+1txv010304z6fSfWfafefifmH2fqO qfwHsOoFiFoleHMG1EID71jykO7v0Ok1eOcAgRuCqCoroKgKgIRKkHqcsE6FDBJTmLaByB0Staoe WAaAYAbqkfDtuAAGGF7zhjYo4ueuiHqHmnCBYBg0lrhUECMCWaEAyA0u5lT07oSteGBHvK+IEGVc +AAuMIEDkvAAACmTaLlIUcwmUQiHY3yEui++yAA00XBy70sIiJe0XL2YC3wcA3/0oSJRceuHNfUH kHmPLucXA00d6p+VgoLnMAKJmCqCyroDUDZEQA4A7jpFn0OJKAADpYMFwR5FfFiCRuOV1MwUjt54 Uc10xYb3X6H6J6KosY2H+Y6Y+ZDof0KKIs0FWuwX+AWYEAgAYgiCACCCB1mOxNYB4H+AmAqYEEWE sOFySQF3UIMTmHOHSeyDaDO5yGapBZaEFOODEDGkRab6N72qoMQGMGQIEEYvZJAGMIE1Znq5zZxP hdR36fEmUw2GwAAEiEemgF8F2F8ycHqyfnIRN5GJmCACGCBMtdeAAsjrjXqvLMFuaq/5kDoIEFtu o+uIECPchK9PmAz0r1ucx6DIf75999/+Ae/IsRaRfYtxsJjvj1WleGwGX8iEF+f64N0unbiAMAaJ m3lG0BSBY+bkNwK1kGqGmMCEUEWV62SpCDaDg5yC8DAObqB2j+C0wiyHR/mAAHIHFHMxY58Jaeci gIADwiDwBBYNB4RCYVC4ZDYdD4hEYlE4pFYtEALBWUxoKfEBBWk1YKEoIAD8e4KTCbBQYCoM/4vM ZlM5pEgEAJu8Xm8QAw2CwwAs6EAGOw2OAHg73hBZhBQDNQA/6kAAiEwiABOKBOACMSSMAJUTAAFw sF6dULRabVa7ZbZxBXs9IKfT/BVWsLg9oKORvBUgi4KIRHBZvbsNEQGAMS58YAD4cT4AHc7HcAF+ vV/T8Pm85nc9n9BodFo9JpdNp9RqdVq9ZrddFVQp1Q/3S9HSADAXjAAH4Bn5qKfT3e6XeAFwtlxO HxNzSajTmtfCVX03+/uqAHS8duYjIYgA+e/DODBX9BWOyaOXSwXQAFvcAFIqFIABKIxLvPx0f1+/ 5/Yqpp2QCAA4DIOAAA6DQOskdrKialQAF2XhdgAGgbBoABHEYRwAEARSPhoHULg+DgPvw37/RQ6L CsmgoxjO8xlKYpo5jcgo4DkgoDMSpkUx6ibxm8cBvAAbJsGyABqGkagAHvJoAADKCEKkmAFSqAAU hWFMrhRLQQBCEEnyjH0xzImLNH8fqCkMRKCk4T6CnqvQASygpKEggssIKAboKbMs9MUADGHOxzIM kyjLMw6E/UXRlG0dR9IUjSVJ0pSrXFOUxTn+dZ7nW3AuN23rfphPrSvGAB9oKUpRlKABpGQaQAE3 WdFNWPI8Dyf4CAOAgABQGAUAAJooJXVNUofKYAGmaJpgAPA6jwAEAnYABCEMQgACWJIl1RbtLW/c DXAMAFxlFcwAGIXRiAARBDEQABJ3iAAv3oAAW3vWqHHXfZ/l5fwAF8YBfAAfB7HwAAFgmBYAD+Q6 6gOBADqjidw0izR+WOOg7oKVJWoKfdjiqKKCkcRSCgThceYrleWZbcDNOuAE1zbN4AHmeqChMEU6 kigoXhhPTC4pFDEsWxrHsiybKsuzOXadp+oajqWp6pqurIsUxSlMf53H2youiy9h+gNNNSOijKMm 2bRtgAT5MzeC4JLMKQoilOYVhXfK1nFvh/i8L4vAAJQqCUAAxjIMcngMp+zIfXtemqa6RCuKgrt4 fTfk+Us3huGi+n+AWzVLq/SafooAGMYSOFwWLknqeGcB2HgdgAMXbb0txznQc5/nkeJ5AAVRUlUs YSLMLYsi3gnl9K07oMKReTAARc7gAfzygAGYYoKTxMoKDQOLOl/m/J8vzLU6DNEsS2SEkgvf++DS CkxnoABqvoAAJHehtb09BKEaSodpjuHzwFgNAeBECYFQLUYbE2ZtTbm5N22Nsr/DonjHoPIuQlBH CUAAMsYQywAB3hIAAJEJ4CESF0LkXQ/x8QvWqtcAARwoBHAAHEPAcUpQWIWeMAI/CnitFix4OocA 6gAA2B4DYABWiwY8BYCoFnrRTgZFVMo7x2nFGaMUZoAASAcBIAASwlX2CdE8J2FJoRBiCEGP8Yoy BigACiFpkbdWRgEASr1xsViLp8IKIoRpBRLiaIKPMuQAAiBBZI9IDMS0nujj5JGSTVF8iXEwQURr 9X4AAA8+EACdiCg1BwQUAkfjVv+aOoVpSiGmyTldK+WEsZZSzakphTSnFPBgVAbw3zE5IJjPGPmY QABSieVaK0UzHhwDfHAdgc5twDAHXGByaiFAdoXDSHENLdwVk4AGTePZMlxrjECIIQIABNCZkIEc JMNnomAAcBIB0vpaT1M+dY8pcS9DtHKO0AABR+kZG0NgbQAAphUCnGk1AxxjDHH+KYVIpisAtK2E QJIRAAAYA0BgACaU0z1T6L0XpBRFobAAM0aBBQWgsILEUgoSIbTefHPamlNWLUzEtJcAAkIPGSKW geRwlBHkFBu/gAivWVGilQoNpChmlqJptVGqVU6qVVqsQ8U9WR/jqHqOoAAYQuhhl4qOHlVibk3H oXEAAbQ0htAALQWQtAACDEMIMAAZgxhmcU4ystV6/EMYkxIRQiWTASAOBIAAQwihDXsCwFtCjX1Z luPBTwJ6KAABwDuUZv0TyxM0L8X8f6hgAGYMwgpWiCh0h0AAJy3Env7l/X+2VszTGFE4J2kkgQAD vJ4WOKQABLvuAADcHRBQCtCtiW6pcAKnSsshbS6F0bpXTuoj6BxtB6m3rBWJUU9LZgIABeAOoeoj iYEpJcKYVgpzoE5IQ8r2Lq2zPGP4fh5Rp33AALYVQtgAAgA8mANYag13PP9QcKY/wGANAYAALIZQ sgAB4DkHh4TwQKH+Zoc45iChmDQQUZFpgAYKIKH8yJuDvMfvjinFRozCiuFcQUQK2FAm3AAA+edO xGEFCLTFHVMy2XLqbKuAeK8iZFyNkfJBFrJVbq7V+sNY7vVWcfGIS77BAB6I+E4KITnpiRngA2ec 4ck01rOUgeJSx9jvWOU1nQJsCI9GdnEf4zc6LkAguMIOecQgTAbFO+DV6kDNxAHwPpBRnjRIKBQC qapzlcpiAhcdScx6T0oTMwp08YCFIKOpamNc+vTEMQVbZBQDkZ0kTHIEqoBVQ0rq3V2r9YS0yXVy r128oZizIW+3hxQqhQCqAAbY2W2CQEsncKQTG7D+AIeXXGsZJkuJcKIUook4EJDPtfN6ZBfC9F8P 8Zw1hnOCCc4UDIHgM5+atUhZZBQ84lGbuEqhVwACB0K4K1wCwE4+2dvvfhB0diyFiR0up2FPYhwX XPgYUb13h1NX0iGqYA1Plbv3inFeLcXUtLarY99ahcu5L3ZsssyjyHq8ANQZA1AAGCL8YIAA+iC0 KF8LgX1yAKXHyHjEBzxj254d8eR4ABj9MSCADgIFFBV6QptfYABq9NnQJqQgUepABEj1Uf4b+sRy 6lP8ApGV/C8AAPLsRvB+WdIKBHtG8SriV7YAAaHb5EBEowlUlzeG8kLET3kf4FgRRSco5Ye6TGnG FHuzgAAZEXnG7AYpHdbC54laHcnnPk9YVIGEMAgocojgAHEOQgoCmUiGI+AAKTdrwsS1OQviFzch +U9d6/2HsTRcaHVxyr/Htb8OlhYE4wvTkhvDUG8qgFCrpuE4fQEh9y3+ygW2gAA1xqDXpOMiLo+R 5ngDiHIOKigrfd6Up60tpgw/jAAJL8wAQk/pH+Lf9nWmR9dIz+wW5WATlb/qVsDH+bwgIvABP/wA AZEAIACkSkYDcAwADa5F4NcBZ3DbbboZIawZJAYNhAwvRORcJi4fQgoNZAyJgvBMIgoM5xJarGSj r5kE7fqpAYjlpAbzYcocpHLSLEggoLILRk7SLhz1bITVkFEHsH0H8IAgq64dK7LJzj6sjySSJ04d gd5agKIJhkYbgbQbidAT6QgKAJgKAAEDUDUIKAyYIfY8AbAZgbBcgfxcZ2QHbo7pJJrwIccN47Ad I24dEOgAL/IDBKYmAHUPZ/Ko6/IWy/gOkQTtRAYOAOB3ANsRIf4akRgAAFkR4AAA8SQAARkSp3Dh QKIf4DoEBBQMINasQEQEJnazhR4zStIgoWMD4QLUJmx4AAAHIGwgoQ4Q4goE5LTFEL0XLWBHYYYo AADzQgsODrggoPQOwgpv4grfB8cHTVbicXUZ8aEaLSZ4QVQf4XoYykYIYI6xgfgfrsyzxKKYQ8AS YSASak4ZaLoMYMpxIJAJYJBVBkEaR85KAp4dQdCrwZYYaEQUgUIUh3AK8gAf7so34ekgoADuhJhJ wBMhZVwaRWIGkiEPpXsQC/kNpgiGCo5XoBsja3Yd4d4AIXUkJUoaMkghAOsk53AL4MAL4f4I4Kam JSBMUbwgqiAgoX0FiGC4ZC43DmjGrG8eUoDfib4gobgbp+a3AAAczDTxggpkTHSxgAIBIlweBQ4V oUhjweoehnChgY7bMoMr8sEsKScRgagf4M0s4AEgqQ6mkehmwegeYAAb0uUiSLwESMJiBiRZMsR5 oAIAQp8RKtxxAMkf8gMgYAACExDpjpwbUxiu8tAWsyAAAFUycugWEyy4aopeZeoEszjsg34H00Er whoO00j74nsXphABZhcvRMgecVwcspYfULqaQgr/Uw7eQqcvc3TShMUt4gsF4gqYYhA949osw6wm AHIHQHL/a8ASYSQSc0U3c6U6c6k6oiwKE7Af5aZIgbJI4TE76gwKahM6x5oVk8xUoKk9J3D0oKS2 MhxWIb8+IAAGE+gAAdU+5CkiMjMP8QMQbtAq8Q0Q4zaEgO5UrvIRM6I04f4QaNoAARq3QeK3oNxG o+j5SE5J4EgElBM8lDi6Af8XomERpZxaIAAerwwHCUYAAQrTQAIH4H9DdDtGNGQ1QgKAACBQOCQW DQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRlKx1/muQACQGsAAeTABHSkAxuWS2XS+YTGZTOaQVzzd/ wQMzuVwcpT+cwd/0MALWjAAz0kALCmAAaU8AASpABbVUAHSsAAI1sAHCvT2ZF6xUGBKKzWCaxR/s 1mzl6vWBFMpwJ2OyBCoVQJYrGBLhcAAAmw2Wi04XDYfEYnFYvGY3HY/ITB/sNhznKQJ8PiBIRCQJ /P6BFUqwICgXAKZTYTI6vWa3Xa/YbHZbPabXbbfcbndbuWFDfP9icEAEPiAArccAXIp6rec3nc/D IXpWQAHvrWgs9nqQQgd0AILwABL+MAH/zAAUekAAL2ABb+8AHX5AAIfUAGn8cyWvP+dQGv+/THH+ bhuJy4oAHCcKBA+D6BF6Xq+r+wLBuhCsLQvDEMw1DaGH+bpupyaZpoEdZ1oEOQ5IEt6BBWFaBFAU DABmGcAw5G0bxxHMdR3Hkex9H8gMWjpKn+d0jAAzjOpGAAdya5K5RrIMpSmmhjSs6gdSzKMOEXLr qPkOstsMf5KEonL4KoWyBBKEqBDcNyBCQJDABIEkxSpPE8z1Pc+JYf6mJzEqBQSgUuoEfJ8oEMAw IE/7AEmSc7z7SdKUrS1L0xTNNU2hLfCgf6jFqAFIEmAAK1PJ7l05VdLk3Vx/m1WIAS6RdJOgdVcO pWlZy7W0/TKnJtm2gRJEkgQJAkgRAkCgQeB4gQGAZOk7VZatrWvbDbn+ahqJyaJooEex7TdOAAHu e8FwaAEH2nX1s3feF43led6XrCxg3wf56X2AAl38AEZhmAAf4IlCVXthEOKqWx/s+0ECG4rqvxwR OKuoO+MXci0yTMAEjvKP6BASBKBEURSBBgGCBAwDF24Tl+YZjmSErWtoAHSdKBLEui7AAnaBE+T7 ATljWZ6No+kaTpWlx1Tx/n3qCiqOVuqVToumUvblukhrgAGTr4AVibQAANsoAQZBuCB+AA57akqT g3uOroXhZ/hHu6ChPvW5tjWjqYcAGMDvviGwHAoAC2LaBGYZiBVQAEy5RlQAzrwmscvzHMwrmqc5 wgRyHIgQ1DUgR+H4gU6oEpoAWiwAQBBy3Ndl2fadr22j3wYJ/mh3j4vmFvgYHgqUkd2PbwrrR/3F cc3zgwQ2AAPHpAAMnqgAG3sYBGYAHh7oAG98AAdyACzFEAA+fQABQ/WAAg/cABEfj4yClP+rqOyL P5sUdH+H+cr/wAPLAAD2Aj+iBuGJy24ABfmRMkAAG0NpAgvhfQiYAwUBnjwZg1BtMYWAsE5PwQIJ 4TyBPeAABMCbqhYGAgLByF0L4YQxhkj9pxdS7DZhwAATEO2rQzSCH2IBkzLquE215sAXIkPzEtEs f4LonAADzFFxDiQABois/N+opx/oPQgQQTkX4ME1WcDw6gh4zQDhaRtjhOVzkCDsHYgzJoGpxTm5 RakPo8R5j0TEf6+QAHCABF8gQ3xvuSkMAFGEYY9yLkZI2R0Lncj/DfJMACuB1M+Z+2pgzxZHoWF5 J9UBR2oD7AAFqUwAEsg6kUQsTsrR/i5lg28A7Eg4PaRoRhxIWx/vVDIABEqJjjhWlWRYXUxR/s4Z zMUXQAIJwUCJM9wka1zLoABG+OLJwAMjjoy6Ts3ZvTfIKP9YRbi4PfG8QIpUvkTAAbiQIVYq1oLS ADE6Yc4J7T3nxPlHqQ0ipHSSSIkKTQdw9n0bdUMx3PSWei9KepGHmj/A1REgr0g8OEK8HAf51g9g AWWswH1HzjHHoaQeEYTx/vYBsAABFK22NtfnNKa001lLMAAsibcdqR0Fp1Ttow/43k5iQQIJQSnP uhAAAsBZAhRijMAT+nNPKoVRqlVMmkkV/BLAACGrTZGzFsGbU+qhFJgnUFVWWsBGw41pOoI+tj8x rVvH+6Z05lBhgAO6EAACLQVxhreNZwzEXujwjQD0AArrDUtDm0WBAAH+ECg8QIm5AioAAFKKWCqE 6z1hs1ZtTg/xpDSJy4wgUQCBDmHMQKdoABUCoIEBcC5gE2WZs5bO2ltZuz8YWABb64JgpMSccq2V tovicOpV48R47gkvbqfweYAHAP4fmEe6Q/2RskhtTWmwMbtAAuMBy7wAInAuAAMq8l2Fk0RA0AAe V6wAApvc6x1oTb5WKQITlfgAAnBOIEOMcZAnXkCFYKxByEAAxvuTbbBGCVJj/UWTkMYYyBRUABfw gQDgHECfqQKpBgGCYHwVh/EGIWYSRX2PRfq/2AvCbW8TD1tmnEEKYLDFtyiqj/F/jcgqtJ6xjH+s hZIV8gEFGPkMgt0gjkFhwNm9V7DwCCpesAACxSBKyfaEEgQQghVCqIAFGeM8RZfzAjqIRObygAmK QLM6pgKkCmeac1OYc4Zxzk7WfkQA+gAmeEQAF3gOSby9gioYSjqMLz+TAQehzqZ20KY0f5qCcivF eQJqoAAPAeIFg8gRxQApaznp3TzMB/jgHATkbA2CBGCIEh8gUKCyvmABa5GUt9P6z1prVSsNS6gA yTDqHlwNbEveedRMolGi6QFeP8PWyQAP/HLb6gYFNoAAqWKMAIYdrD/F9tkABmTNEErlJuZkE1bC y3IP8Um5yC1lFVosmWjRTak1MAA6SjQGkCgUDcG88TAac1/v3fy2B/voJyouEUJAAVvIFSzKKxgA AKAUYBxO7N/8T4pxUhc/ElpLJNLPFnFiL6B0GVVW0nxeU+ms6B0LZQDAAJuOcABojRmlNMQSwwrq VUsKkAQAG33ibhC+0UP3QTqZN4kn6DxOWogA0nhbAGAr4b7lVx7qXU1L2Ld6AAQwhiBdXAsBYgRK SBRPACCwFnReqdn7RiBpxwRiHDOLb3X3aSHiR7odsgckw3q2LEF4f5ey+WVssEzwQAchjHH/QpwB qBTAAGf40ACiFE38HHGHcgsh/rF4YQPknZiJD/6P0oVvCQEattba/TfUe5ep9Unwf8ECchiDEopR gAFueiIEeGvKLgAtE9X7333Fp+JGHckgzlACSUCoJ78g/QQ/d29ueBW3NR/jV+oAARn1wAMpZV7D 2J9QIXOM+ACLM5pzhm/MABvQJwAAd/ZNmbROwMuE5AQTQhu93E5XEQKKzpXTnVo25u0yCG6g84+V ALAMI0H+8aJyLYIEKOAAFmFmNI5m8EUKEWdcdhAPAzA0w+acVCVGUgzUzW7jA2IIDLBM+cAAiIaK b8vQ2kqWAAxuF+4a4cMAACJWyMAAGRB0AAAHB6AA5kAABrCEvMAAa4EgcI72OofLAI/ugCXGiqDQ /4IEOs9s7dAHBJCxCyQ2H+lMJynTCpByGQIEbMAA2sscCwhYB7AJC1DZDaUuxIX4qulsxUz9DcIG 2CIQ2GVs0qA8H+VOzW42AASsGMACP+AaH+5UlKlOf4HQ8Y8c8gwmv4nqOUOoaoFaz/CaIIZ252/6 gUPtCs9PDXDtFHFIIcH+6yJyyCd8IEKsAAKIAARQTWTaAC9hFFFLFvFwQuaclGakVFEs+TFK+ZBQ 6IIgouH+vIGUe4e87wAARERG78AAiWEsfILNEcGe8eUREi8mJo/mIG/qMi88g+AA20AAHiHiIFCG AAjkXWwIiBFtFzHhHiIEQ8RBGaRGAAGuGuM2M7E4yuyyAAYqMAnpHlIJIKU4kid4Ggd8DqAAeABb Do47FwfWFDBQmaaK8AH+uYAA3OFIPQPUdGdInengvcBSAA1EHAABF40OEG8o3KII8wAA82MVHCJy 9qAAWFHQBqZKmwXYADHdINKBKCNs5MJzE2NQIEI6IEjapCIEJ+qaClHfKFKlKmIs1whuhyh2ExGB FzImH+/GIIL8FxIusrIyP5I23QPSBQABJAAABlLcACfK1C1FJSajJWjDJW0TJ+MTCbFiZuZyAA9g v8BBADCvKpMNMONWW2W6t0XAAAHaHajcjhH6e0IE3QACtjMRMzM0NmkjGYXOXQWiWkk1IjIM7oEi Oo7xKiIuFpNYYa/DF5BGj40c6w604OGsIEYKAAyxMJFDM3N9N+NcH+GKGLJqGoIEemyWIE3wIE3m ACfdNVOBOjDY7WOEea9yRdNjKDNMH/AhAiIJJkRufiEQOoTYTbOyjU8+RWABNYcczWAAwCIEXwMB L1OlPrPsMROFOJEdKUmopjFeLlAkMAtXOhPvQK7SqsX+q0BCq45Wq9QI09G7FY5ERw2SD0Oo6yEM peMEJyH0H0IEE0E1Cqsqw0qS92CRQfQNRTKkxsF+JyVwIEesABPURaReRiy41lRVRzM0n5A8HfR8 AABzSC2dK3MRO2a0ILBUQu2sDCOoCNScAAugLU9cABQ6IEEyEzREssqPRK95R1S9S/MSnGAAs+IE JCkqkuvAvFFWAC4jTBTdFKkjEZEUC0+yZTIgYPQKGFT0s9TJEgbasSN2TAOouuaCE+sUL9RdTRBN HmKCnSO9S2aHRPTfUnUoLSnEG2RDHu/yKQDOXDCeLwIEFSFSMA7JRRUrVOm+n4KwDoimcUwswvNJ S8E9VnNcNBF4PwDTAJUFLcBkPoPsCTWAVsH/URRknKwkMynRU6q4IEX/RNVNVRWhMzASGfUSIEC6 C6IFRekwaAaFWdWjW+4okiRgRjJE/Qb1Tuk5TBVmE8H+K2AivGvKH7XlHUZMz/WuC6H/ECl4ABR8 HeABWACTWFSmRgUOUTNoIE7JAaVEACUhWfXBYfKnWnWq2W2aoBP4IEq2AAL3RIMAbvYdYhZAZmn5 M+KuKyRQRS+RPPUnHyGun6+GtWtYYgABXWkw/iJpISH/ZOAA0Cu5AYizYEDaJysPL8IEqCAAseak UeUjZDaZabL2MonIIElOY8+GhOhSKWhWACjTada4qmacmUoWDxOvSJZC8KH/ZJB6AGsQ5u9HVwAA LwLzbTTSBcAC7ZHoG6fgfjCJZorYEe14ExaBaE5taJTrH3YVaVY/a7cVQLLkvsxMAAN8IEQIWOWS +sEYMBFrcXc0ken4WEWHZpX3ZSShc2IKkjT+3AjMEPHxHyQQUIPYAEAAdfMHV5bDbYKiKm/TWFWI wkY+CiCitQA3WYqxW9dJeLeMMk1FccqKIFDM5Y5cAAZY6bY4ACu1cTePeuNamQH/SvSxIndaQU2+ MMu0BiAA+YAATqBJIaeBetN/WGFwJy/OAAdAskBpOU3yxPUjfZexf3QM4CD4JzaQX/dbY5BdKff0 VZCMH+tMtO3VJNLmMVCFJ1JhSCBzgPf4T6wCFYH+PMZDZY/ANANfZ4V2x9ZrgtII9baDYoIE0hco IFRHaTYZaXgvhnhoJpMU3gIErTeWnZeCtUtY1e9NMwm6i5ZcABQrJvJwNe5yAAvkCbctcubuBHhN TBEGH/Q7Q85rGtNtNu+EAA2gApBDh5eDd9d/BaU9He/MDMH+5bAfAgIiAGAEJWA2Aq++CSBuTaB8 BeBGK0Aa9GAmAc4eBaBGZaAIAMNMGaGuv6FuGRH0FuGSbGGqG8kuHsHzQ8IZdfXM/USHN0yxinA3 hQJzLMfUFDhaspS0KPhjk9hrlXS/lAAA4IAACoCoIFgeUcABKPUhOcCCw9ZxTlNYFoAAGdmEAA1K 1NX7ashTBahQhTjTSgOzQJGEVJX5R+IgZG5Wu0BMvwCcWeb0A65u5WRaBEAAoizWtMRM2yGbPWFo GMAAyGGqsYHRMhXlhAIWpW9G5hm0v05hlVKDGQH/mas+Glg+MW4c4ecFdscEqfB0GQH/XuABZkKG O3BsIECiB6RcEQDOqIBGA6WTdguCLIGIGikKEOFIGAXWGcYiH0H2H6ISbQABocSTn46lldSqABSv SzenS7lZp3p5MSiYj+7bWKL0L5BnJ2gsQoI2r6eU/zSXHtHuMbNCAAefbyEQqfmKoQZzqafAnOIQ P+ZIvkWeEAEADCAATY0sM8MSJWagdOF2F3GSfissOCRHoiITibZqABRAE1plC1mEGdqWXGmaAAQ/ bwNfnsgeghfOdSKSDOjDUFZhG0ISBWBCteDsCwbWCoCFIeAUAQ5XFdBQMeHyH6NAFyGQ1MDUEchW HKHWHkILkxbhY1Y3ijr21sH+GAGAJzTJZKIEJO3CIEfflzp1p7uFuGMZC4C1C9WVUXoeYiuwIEVc IE66MASaVsbE+m+rVXsE1UNfCAo1dsoojC+uEYH/fMgEIQYIZUWKDe9zj3B8NldgZw+GTKwEh2L4 LrHOIJCArvXoZPfHtm+VI4wY4JfCIOAOAK50C0CKZUD4C8yyBCA0WSaLjjMcHeLgE4FpGSE6Fqca G8HNnkH9s/rtoKABVEFSaKo+B9PyGKABXlpYIIBgBKvSFkEMC8z2AxXeADFeQvjgAAGKGgnOC0EE tYHGHSsE+cZMZOursODafnO7ZzFjc8Ji/SABJW/dq+vmw+H+SvcJE3WQSezYz1qKAClNv9uJzLYg H+OnaPDQABd8IFJtt4ylzC4iPeFuH+l+ABma24ISWiZIJ+bWiAgoTrrPxWImJXvhh8F5rwE1AjHy QVroIJEDBw57fQVsyACuaeajiyIIPYJWRm/UKZdUoi68IFxaQs/DnaGPONlkD5nhaqIHEDuwOkEK fm2yF8r/v3uXuYI3kxLTdq73zIc02C2NYpYqIOCuCEvEEEDGyOBMA9avs+I1wkHgHmM0EsFfnYEi FU7aHUHgnKIHxFsWAAiQC4lsP0eSxKAATkTmsDBqIEBEAyhSFaELWwBeBMvTxXnoRtnoG2HGRMCu D8FOt0G6tOIJXcigikjeDsaLoCH+itCjEGMe+Rb6euex2AUyH+0Q3kELCkYMIE2jzEC14tzMIAAI FA4JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGY1G45HY9H5BIZFI5C/263X+AGm04Eh0PAmYzIEFQr AkcjoELhcAEIr1eAD7QYaZjMTQAikUaQADweDJJAwGAHQ6HYADOZ0UAFyuWUAHy+X3BQVYwAn7MA AtaQAQbYAYYPrg/2Tc69X4KaTSUAAhkMZgAEAgDYHKafhYPbn7iQApVKup4hFEAG223JBR1lwAOc 0AEbnbdD29oX+7dIADlpwAw9VhoMBtcAB5saBQrYQc/rNxud1u4Q0d8/09wQAmOJdXyAAUCAKADM TBsADoWyAAA2FQdAn9hN5Bu05HU8QAZESrAAumW24LgAgADn7dmfQC0Pk/2d9QAa/wAHv+wAEgaB IADG5y9jMI4AAIAiogAf7tO3ByBAKqJIFKYIADiShaISpCsjtDrboKP0Qn+RkSAAe0ToiGISg0AA dBaD4ACQGwToSYBoG6ABgGebwAGabJyoisYFAANsigARMkQ/B8lyYkpBkGlLOoEeZ5oEPY9oEFAU IEWRZAAAJUFRJUmzJMszIqZU0n+d02AAQU3gA3xogAEM6gAFU8AA0MeMm9AOT+AA80EAAI0KAAl0 RMcz0XRlG0dR9IUjSVJ0pStLI6f8RAAK4roEMQxIEZpmgAfp+H4AA/IGSaBgQCwIgAUhRj4AAdh2 nYFgWBDByaxDFTCXoASeUAAGybJxoKG9kgAG1mAASdnw+GNpH+Z9qoKAoCgIABWlaQYACaJrpoEs NLpBKiwkkSRUAAPg+E2goHXi5iiABEhGQ+SF8n+/Z7gAQF/uMhtsW0FgWBCAAfh+GOEB+F4AYGAB 8Hw45jGMawAF8XyZN9HEGQahIM5DGIkCQsqzUVcuU0qHGWH+cmXgBl7KgDmgACcHUtj8MgjAAGQS g27B/UbmqCESUhgAASBVmGqR3HogtP1AEGpgAuZkgBNh3AAY+uYeAgBYQGARgATY7imAAQAyCWg5 Uj4BLccx4HqABFlCX2klWYiC4KFgAELv+I4lE0UDZwoAHrxCE6IKIfBXZw3ieAANAs9YAH9oSI7e AB2nfuY7EuW1YF0ZwAH0fnMIOBvVaTfIAJomondjlG29oh5/4qlJ6aeAAqCogR5HkgQp7Ph7l5sJ 0vi0LXZ9r5vnIFDo7H+avqP0/gyewAAy+3Ok7TwFU9NCyTJgBLsvER9CpKnWBSFIAAGfgAAP/n5n n/t+/8fz/X9/5/v+vTGqvtaw/SfIHFcK5rCDAACOOSAAFglQ4O8CoEJ94DEAECY+mY27YA4hxEiA ASwloED6dMQUL8JwAGuAMQUWkLQADnhgciBpNw1gACyFlAy8YLoLf8RFbTGSZBvDfB8ag1EcEEPa HMAAJomAABHE8AD1BqrsXaABKiVSEAJATCsKQUgfrBEGGV7rQCBD9Iix4AA4BwDpioJoACYW7uXd QQYCUdTOJSDDHl+sPY+EScKGwf4oZBRWSoAACgDkhiyEQF8AANQVgeQO0R+4fBOGOEyLEZAAB2Dx HsoRQy/HAj4P6f8AAng8hWAAEkHAJoUoRgxH0jMCgAOfFuAATotSujvHmv1kIGQADvmBKEsQCIVh jCUDSWYXDpgcAqA+DEGSSOaHEOg8AihSi/lsLUZbEYSkEBhN8AAL5xAAkEKGPcsFGu3GMSl3pAoY gACYEwgSuCBOxeS8udE+UysVnWoIPIAI/lLKYAAI1BZzkTTkP+Eg+lUIhAAGiiAAAn0ToPPqi1F6 MUZo1RujhIkkCJH+xKUQf6SIHIGEUC6rxHivEMAAE4OWHECVO/Ytz2xEgAE4JxDJBFCqvpE9Zfpg CnGqErA4FgJCBxmo6REtzyhAgAFOKcXhBQO1VZizCNBBF4gLlsJ0PAAAoBQi+ghB5USVjcgklgya QKskDNqgesgu65UVqW81aQMR/u6aen0AAHnKLsDBBQMoTgcNsfyZ8fQ+4zC3GONgAAXxDirAAPEe koiCH+QAGMJoNQACHDMEkAAAwBmfmhXUhg+4FDBGbWgKIe33D0HuccggBpXBHBpKwUggAsAAkQrp BdpUmGfHnCUR6FAAB/E8LsgquKuO9d9OWulpiOTqJTCh8JAmEkCLU8ee90bpXfIRR8f7NC3OqMEV MdAABA3ru8R5dIkh/tTBA1trtPxH33vbeC/V+7+X9v9f8i6iAlj/Yy3eUCnIKCVEqHIAAEwJnXf8 2AeA8HghKCUHYAAyxljXAAqapRA5xNjFiLGm78wLYAIaW4dkmwABdC6IIAAvBeKjw8QUDwHgLgAE yJkOgAAhhDmQxCV6jVtVyK7B2D71BvkFBpk2Tyr65C7vzihMt4g75XhMEkGYABQB6lRb+WDmh3yc AAD4NomAADWG+Opy0CmDAYAAMEShfj/JDyowKH4yhsgADAIayQ5B0jwh4QIMGWjOBveQBIBQB2Uo JAAMQaOSw2iNFgnEbo5swYtxdX3G7fm/5TzvBhJ5KY1ECOEAAC+OYFk4fKl5MCYtQ6xIGIvWg/wW 63AAN/XQAC8Bp1ASJ8w/9U45FhsWzpLtf6y2VsvZmzdnJMnKP8bG09jkvwcdd7ZRiXBnn1LI0OmM LY9G0NoyqCCossfBC0rJTCnZD2YYktwwRgkyCiFFWbwG5sQC8F5ktOZ/xlZUcsYAwJtzxww4iyxA 4TyMuhs9Rr2wyj/hahmGA5wABYCGDBvwZ0DAiAyq/Qc+pXDWG7ekJ4d1hgcAtM4UgfbdgbkPw4hb NR5D1lEIm4wRwbVIB2C8EVoX+M1DCIYVWXBbqjIJfKNMatk36H/qPpZAhOidIEvI4eaNWpfTD03m UPRddfH/HKq5ldhrfXB1wwowu1D/Hj20ADwHgxoC53PtHXe7d37x3nUKbxBKZocQR7E8hNtlV3Ro 5bGWruxq/3MIoAL7wRi08bvRA1tMVGgAAWYsxigADgHAKpaALATS+AG4GjQAEximFYKyqY1XpAF6 8AGxdKy9ABk0GndfJkNvkP+9DpS7CODbPIMATLOAP0Wdj0vuflP2GmN69IZxFwIGONUcR1ANtA3q FEAAlPue4ovdSWeGMMzboEQIIUFLuABeV975bznlBatKKb+X7DcU5E4P/17YE/gcoJQb9r/8AEAM ASi5lgHAf4ZEBCFgWim5RCL4gShkAcCJ2gtwOgOgSjq5LxxBfpkhkpIQACA4Vz+i/xMIVAf7qbqg X8FLDpUwhIpiZwJMGAABaoZ58Y9AE4DoChqoTQNgAA/6FcCUIB5ofiBQYwaYcAAAKa1yX6yoACu5 1gSAlQlYAAaUKgAAcsK4AAccLQAAnQncApZZZoGcMUERJr8B9ogSQYgpcCep5Agj9SfEIKjbCwJR BoW0O0Mg7YVcPS0oKsPsPEOMQEQMQTZjzIWYf4r447HYTLGLGS364A9SVMGMGYADcbPZgrn5rjNA sa3zkMQcTxMotxE6UQm4VJeoRgU50ofRoQMcVhkZkqIoakGrXLXYxKMycRhwy4HTTiSEXMP5SZNI ZQf6LoKTsY3AOgLAHxugNieRyyOcT8Z5M5mrsQLAQAUwAAV4YSKYfgfsZwkhvgAAS8cKGRIcMQGc Xwib8EKo9iJUNQowAAIgIggQskN8c8aBRkDhBoXEfUepJbicQ4ux4YKcfke0gkgsgxlIa0hIf4dU hjPgMAMDpcI4khXBAAq55AzqGsg8jRJcUIexU7FwP8D4VwYQ3D/Koxvr7kC4uAH0gYwx6If6qMVE LRY41i3oAAVQQQLUd4GgEq0JzUjcoA3b2APQTKWoTQWJq4doeSTo3b2jvgAAFMqI2A2Mlo7jqBwT TwgSsjq8eRIcekoKizaIgjhaPYbkswf7BSoskwzoRpD5f4QAf7uC3heUt4AKJL5KCopy8hfxf6Pb 95Br+QU0qssEwkwswwj8tgf4oIPpwcpgwx1RAAYgYgSyoxsb2Ew8zAkAqINQNQRqrpLyEimY3T65 oAm4nEDxcAJswYjBvgf8hJi7sQggDLB5WAPpToH4GRsZBQhxmp0xU4ZIahY4B4BpXQFgEaXwASWU zM5YkCWQZYbAyobwcodr2oFD/gEADRV5BJsETog72AbAcKNgSIVYYwAAVgXxOYdkpYhrXqJyKECo OkP4f77glIOoOpcZcgm4gQCkHMr85ifKsIKBBr2SPYSNAwf69ap80igSZ0OcWbJYswT4AD/ciIAK 8wf6b7jRZg54gh+EvRmsuohhbgVq8ZmqFSeCeM1c/9FdFkgoItF4f5UxU8FKbENwz6qrHI4Kf7H6 zjgE3gAAfYfahhriKYwAwQnSVlH1FtJYjA1ROZYpY6sIHqQwCjkBywh6swaY9BJ4UMkRCoxMbog8 +EUxe5R8lYf4cNNIAFNIcIgoHwF5g4P4MTxoIQGZsbTMvFJlPSPgz8pSUQT6XBYIUJYDmq2QgYA9 RAAD86Cij8LgnTZIf8s59QgQLC3aF7iz2qZAxYUogRNK7tPZ/IrYXJBscIS72LYqPZfISEtDBTt5 4D0Yt0JyYAd8KIlh19Cq5gf5v4QsLMLdDp+MvdEIhdEYf4UFYwgsQtFVUFZdZjyZTgK4f8Qsxogr fZAy+4Nw/oCTCE7tZtbqHoqMBAlgq4rJ6kI9MA9IwCUo4QtLE42IHlZSciQQf6JKTTFZ94BLRgVY QYLbHwGipAAsy9b1gS0wfpmoXgZIbRTYP9TgeLmwgtW58wzIzSPdSIbh3J3ae1XogRPIADEYgUfR L5wteFgYkNAwSJBqIQN6ug4gTAf8tjJ9RwnbiYAFRDRiOptZrNNdNIAI9Qf5eI68D1n60K0S+gY6 /KPIMJBtCNkdklptpyjlUQf5xBucYYgs/iZwnylo2JhamVp9ryfItwdIdNWgzsa0cIWIAB3Rfskz 96GyG5Q5RI1hK4PYf4cVuwAAUdvKQz4wqwJ6woQYMZniSVr9wijJoiBQ8QVoAAUQXJUYfZ04ACLR AFiND1iQHL0lSTH4gVNR+RGAAAXpYAAFkAANkVwp/JEIPxBrviulVQf696QhKq0QqIDV2kXdIFIJ OI3zsYANXMh8iEGC0ESDsUla/N1F1RN9pl015V5Z5tlgf9uZzY0pZgFMkQQj6wmt5l7KdAtxNhKo NwN0KAxgxwgl2hFjwZd7AUP4Et9ZfY/hmSBwELHIS4OsYgHgGNO9x97V/SHpzTQA8AIoOBd4bIcg dbTIGuA9oYqIY7uYgQW6WoAEOwgV9YgV74gRkhL4EgEl5N/YjRJ5KAgkxd1hfV16NFGVVx4MVgMc K0LEyRvUK4ct3hXFXRwGDKpF4Ry7MouC/KDoOJBq+4R+DeDmIWIZJdM5qxgJEgNQqwM53x+DyVPO ImKJSBy4lLadNpRDDD1quBbVCiNQcEP5IoNof5Z5VYghboLgAAKQI1rgsGKWNx/QfAwgQITIXBI4 UxpFJMa5moFKWVdLxwR4gWBCCpL5qeION4ikmJBqG4LOEVVd19eivmByWsLsFZU4mImUmeGIBeGd XjzoOD+kv4gkwOQ2Q+UuUwiZDYf5Pbq7NBLSSDx5kawtruU+WhSwtzCZKonUiELTNggkRWJYM5lA gICAACBQOCQWDQMcQl/siGAAHAsEABfJAygAZiwPwJ9vyDx2PR+QSGRSOSSWTSeUSmVSuWS2XS+Y TGZTOaTWBgQBgBKKxigBKppcgBWvR7gAUQMBCIRQJTKaBBgMAAAiAQAGbVesVmtVuuV2CLmwP+CE eyVaSJa0P9QWsAPm3ABy3EAEm6AB/Xe7XhsXsAM+/AEJYF/oXCAA04ezTMoYuxQNYY/E17JZPKZX LZfMZnNZvOZ3PZ8AFLRP92aUAMNhsIADIZUdPJ48gAXC4SwOOaDcbndbveb3fVcCADCJ4AHw+JyC hrlABzc3IzEIdF/vDqAAShwJxJIGYABwMhGBP1/b/yeXzef0enKgXgplWsYAMdGK4ANuBlJIpEAH Q3m/nvVAEAwEkQ2QKxqBEpBL/wGg5GwdA7rBK2onQpBcGQvDEMw1DcOQ7DcJBKf57xGAB1HUdAAC EIQaAATJMjoAAPA8DKBn7D0bxxHMdQ2AQANKeYALQVYAD+P7iA7JAACvJYAEZJ0LJSA0pH+fUqtk EcaF+SKKgkCAGIEvEdzFMcyTK3IDgKABcGEai5jqT6CyWK4AFTOsoTNPE8pGtBLQgNU/zvDAvUHC BRUNQM9UTRVF0ZRtHJM5QNSpKx6HoeS5iSG8gktGCoOzMFH1DUVRx3Hp4niewALWWgADmOZKgABl ZAAF9agAYVcUQksQH+bdfAADIJgaiUtqMEUaAAfkbVJZlm2dAacAAbBvHPFI3k2ABznbIEQPrX1d WfcL0jrckIEXc9wQEQd1wgPt3XTcV43led6XqkYfXwf9TniABqGoaYAB2HYWAATRNDwAAThOEDbX th2H4glyrLcjheF4ZIADQNBGgAdB0HfWNZuoeF4JCOmTn/JxGIKUw/CwAAsiVFgAH028AAFHpqG7 apPlqZYAH+xomh2FQACCGgRzBCCRrMfh+PGZhsHJGILggAANAtqy8pWASrGgbJy5pZQABiEoNAAA oCpzoDe2U8ZoG2cwAa6qzWg4gWgvSAKrFyZJszVvwAAHnAAC8JAZNkEwNvC8aOlMXZoAAZJrHEAA IAaBIAC4I3EBKDwKIKb5ynaABxnSeCpb2grxPGFtjgACYIgXpUxcGAByHPkAhDgTT6nJ0lu18beS 4j4rJFt5B/mb5aC3cPviN7cg6wg1nECz6/oeN7Xt+57r0PySJ/m58YAEn8wABIEm7kURQ0gAKIoi DhrOac8ePHYABvm/aqS1lzIKQUsMAQAgA5A2lnnfqAAdI6XSDrHW6hhQHgAAJASRFvBuirIjH0AA bw3mpsUKMCgDoAAFAKczBc3pVh8D4g2M4ZzfxYixGGAAA4BwDAAB6D0FyKQhAzcEANtZAx6j1g2M cY40U1C4YwBMCYDgABMCYDwAALQWtJLujZEw7gADaG0ON1JzwCLROUBUAAHwPlRhQhcqw/Y2AAGI MQaQAAyhlEU/kb6KFZJfZG9kjowI/D/CBIEgoYWZAANgFVvEBzfrRFALMZQAAyCJFYAA8TSwEpoA AHsLr8g9hlCOQIfI+yRnsAAMsaQ4AAA6DUJYAAbApA6AAI8OATkwONkUSEAxwQjhuEyAAZg12pjU FEHFYAFWtJhMo6oeo9x8nCFEL8AAdQsg+IKCoLojn0HYNOJgNZAmxnklyAAQRQAACHFLNAfA+WbE CPYTkYYlA0AABuDAEIAB9j2maGgRgr5DC2GYR4EoHXQCyEOF8owKoRhoEAKdFosmMEhAoBB2Ypg+ svCKDoo89lloeWiNscA6VrLYHIOtfgMaTF9L+96lRmQm0tluLOmEfDNirppLcKtN6ZUrp1TunlPS sPgH+HqoQAB7VFAABECKwxUCoD+ACQINm0AFluZNNI0xpt/puH5b0Xi71TIJTd+QhxDhnAACMEbd 1QHpJyXuVAWwtiBAAVRGgiREvufS4uNJlDgjJGSwAaQ0huAACUEp+Q8h5JAEAICXo7x3qXSKdxgT BJvQYABEMfD5RJyTXPQwdw7lLkEBQCiCSRQwgACwFgIwABujdbDXQUYABSilF3UQe1lyCIqcQkUM ZqwZAmnKIe14jhHCoABCuDZHQaA0BOkQP9pQlhLBy6lHteTzFWSqjYX4v2fhnDOxwc454tAUvEcw 5xMagPjsC+YSYAAJAOAUAAMwTKoCGDQEgqRu3VD0lCAAU4uhngADgJIWQAATUCAALMRFpQJgVicK gWs/wznzAACsEQFwAUEDAAADp33GLiLMO+dU0RHixAALcZA2AAC6EcRUFYJlkD7o2ekfzqhjSnAA EMN7vQwhLh8JgPKcx5DuHoAAJYdziDSG9SAZAmQ1Qcd+AAKgfhSgAEQGgJIAA3BaCAAAa7cbBB0E 6VIAZVhjiVm6JAVcMxJCtJ6JAN0tAyBTlgNUbEXghhwzCAYAqPRciNt2CsEjZ1k4xQxnoAAvBjDX AAEUORyCCMnRgyqnNPtKEhKaKY0hpilFLAXp1owQQg6TMoGHUiEAWanVaq7UWldWat1dq8AFSxUD /DbrUAEDh1tkbKAAWgtBENXA1GQ3qPWTiUToKkXoABCCEIrTcIUJAFQFupq1HrHnSBUCoHwAEACM rut2jLYRdloX8FOLwACDspoUB2AAOQcgtL9GoN4AFiTkXGAAHkPIXAAV/sCKoVU0E/hSAAF0Lt9h ZCyJ6IEQJyH0t3DuHcLeF+EAApoMCTIe8MqDtTTQX04hBJwA4BwC1zLdkJBWjU9SPbDFFFIKQW4A A4hxEkAAB4DzwIq2enUVOqyBVAFPz+lF/y3TNC8EdxAjw3hNvYAyE5oGugAHmPWZoSQ55hHSO/IY shEUGBQB/kYAQCI9G8ON0gPg1iXNkCRGgoQ9pzce5GdMGxt5PHMOxIAZQmg1PiNVyoVwhAtbICkj I7LPMZEWfS1kWhFhrCVL6YF7AHOZDEEvvQjRUmqaAVYOQWAe38F45EcQ6HUBJB1csPYmRcAAHlEQ AAnQ8cCBSCNs4Ai8ZrPgJ0Wkjx9j7PGFkIgLwAB2DAEPA4wWABsEdiQgRVguhHBhaYIfzxXDATaC ADTVgvhNBwAAA2YwACin8ToVh8IWEcEAGMIgAAnA+8BGFHorBexIHMOtS9ynFnHF0Xk8YhQzX2Bw BcYYAGbyIKAQhuFYFyGcAAC+EIFSyoysAADOCs86H4HusuEQFG4slyR6DqC2fkE+FsZ+DkEkFmAA E2DsCoAACsCQBicEaeywEmwGAuAeS+DsC4fk+Qn4E4FoZ+18oMCWB8sk7CNCDoOIFuGOb+GqFGDk AABEwMkocaQ0WiEOFA3MD0nIIIExCyYyY0541g1eElDAH+OabkIIERDNC6KyY0DQQg6GAAE/DfDR C9DlDnDoYcNECkH+92lEphBIbSOCrctTDeYQN2jYR6j8Z+QoYQDgDgTmMIrIVBAGu+1yu4EWAAGy Gyi8C0C0tSsSwy92R64OmgX8G6WSH4LEVwci3aCsy4GuHCimdcPiGOGs4kGIlalcAAByByYIXIVg q648IqBgBgBSAAuyGOlKGWb+DGDGCWRKHUdQFYFYmgRUh8Tq2SGYGYb+3aTmC4C5GYhWKK17FqEg EgFUAAOoyGB4B4+BHGDaAAHEHEpADWDWmwhcPtE0/S4ItSr/FIHIHIfxHkCivYMDFY3kD29OtUtY AACICI70EMEMO4jCgKGKGKv+F8F8GasECUU0RcVYL2G+3uDyC8AACeCemorSIOf0WqCK0ZFwBy5O UM20iGRsNeFgg4g8MMDS4FHeRQC+C+EMAA1qCnJAC6sq6k2O/zEui8DEDECYNOGGiQXcOQ5iCy+C DsoMu+RQuEKchjFqfYm6MWB+fmPQ2q9EliEeKcfYKcRkgk4JKIMIELDiIE0gH/DavUILBmIiFCD1 FWCeCEh2bEMyQOHAHMi0CkD6te8yxSEct2AqWEw6HoI2J8FWJ6ESFK4s3yy2HOHYyGzXFqBCA0Oy CKBmBIAACQBuNqDyE0/yA8AsAeJ8DmCgAADeEhBIGMGqlQEIDGk+HmnwAAD8E+tmO+WGFiERJEF2 GYsCEWFMGCAAFGD6TmmWg2CkD4te68AkAADwC7LCb6G0ABNupAua/SHgHmKKnM4sDACQh82CicEe FTFqtEdADKCcU0EUFLOZFaHUygCAYIh0KWFUGAjiHSHcSAE0Dq4EFmGK0UERMs0WBqNqB0BWIyEw ocAAAqdkJ8DgCe32Z28NJqBMA+dADGkKGOGqi8GMGolQD4DA/SDMCkujMAcER67mfw4Wtmtkv+II AsAiS+CkB85ODUCm3WBa0CAAGKGi3kEAE6/yF5OQIKAmAeveDECU70DYCs3WIggKEIE8tmFOF6ci Cy+jJGB3GGGGGnFcE8Z8jKAwPAD+DGCKaMBkaTCeQwWiFs0S3ZBHEsHE1y5wAAAtT+1iqXLjDq0o T+DUH/LWAAvEdAZwR7KWDFUGJKLAFyH+qKVSF3UwR8NM38FVUjUJU/VBVCUYIAy4E/2NBQA3IQAE nCwBDYaKhUHwAjkccAARyOOIc+4dHY9H5BIZFHgCAH2+34AGAwGaADabUkABGIw2AFarUGAAMBgQ AGq1W2ACoVD6AAOBwMADsdi2AFIpFyAHE4nSAFms0QAGYzGyAC2W0EAA6HQsACQSBuAB+PxeAEYj FQAG63XMADgcCoAHa7XmAEqlVdMpoADqdSxNlawgA2Wy4gAqFQgAAuVyygAlEpgU+nzwAAaDQWAC EQjeABEIgyAD2ey+AGEwmjVlmxQAmEwdJ0BgIAC0WkCADKZScABkMhMADud0uABgMBKAEQiDPhDr y2UymvvC0QwAVyv3L+rwAu13luunAAx2O0wAXy+hgAOx2LQAYzGSwAhEIowA9Xqe7JlyRrxvKAA6 DoSwABeF7ntWLqFEmVoAGaZqulUVSwiSJIeI2hySnxEAADwPBNAASJIlWjyjqSjAaAAQxDDQAAVh WEgAHkeR4gBDQ7AAgr2ACkoAAqCoIgAKwrCCtxGDYAABAEBIAE6TsJLuSLVD2L0diStJhmGaQAD8 PxOrEsgAF4Xkrg0DQKocfqRzhOM5TnOCkquX4ACcJw8o8H0/AARVAgAHFCSFOlDocKVFH+dlGgAY tIAAftJo8B4GJ6Rw2CYAAuiQGYAAKAVDURUiOgKAYAGkbJytENxMgAGISpqVxCQeBtLocf4AH8ft dCyQJTgAVhgPYYRKOmP5PF4ABom6c4AG8VEegaCIGR8ZhuAAHg1uWP4wiJbQXBAAAiDi9A/jBcBA DW/B/HqfAABOLhGVAAdUGsUo5gAI1zQnVYAHAVQ7gAQZQF6ABFlQxRjEuNIAByGrjlAVjaDCRBWA AZBMDUAAbhiEYAHGcZ2YQU5ggAVxhGoABynWeSvCKGCnEGLgACeOZPR8ahwgAaxRjkzwFAOAAUi5 AYJAdKJeEeMoABULpHLUF4QgAUo/sOfwDAKABQlgZAADeSRZAAT48irkJ0x0PxPF0pw+iyAAlZiA BAkkWYAEligAFqRQwLUG4ToafKOTilKGl6ZJtLcVBhgAX5nm6owDVQUw/bgJ4ghchp+JSk83lOXj YkkVpjAAaBt1YCoHtCYRKxkVJezAPpO7ajoEgO3bQJ6EgMgkABPbNeIQguhp+n9UvkeT5J3npAA6 EqW3flqZYAAR6wAB77IADX7gACh79R+V8Xx/J8vzfP9H0/V9fzGx9x/sYrpQ/nghBpzGgV/D80YE Mf57P/AAAmAQAApwFAACiBD+n2QLgZA2B0D4IQRglBOCkFYLQXgxBmDUGyQBYg8P8k5HCboSJCBJ pCS2OBhDCE1N0EnOENPUbE7xkgiBERcKAUAeiTD7JKLEWKeAwBgPgEsJZGgQAgA0AAa41xvgAIEV 2HCfB3DuL6GwNgjz8iEDM9sNYVypDiHGls3AHwPvEh8Ik1wwhnveChDoNAaApAAEAIBJpmxUgAEE IIUCEDSjnHOO4AAhRCiiAAJcS6+jTxJCaE1gYZAyBQOQHdLQsBYMHfsKEAAbg3BWAAGkNJeRyjlH JIUS4sQAQ+caVMdQAAhhDBkZcSgcQACvFe40zCEhHiPlkC4FwK0lnoF6L0lr9gxkqGAbEXQujLSG NwDwHjMjrnsPsVkEoJQOr7CMDVQAihTAADmHNuEngopnF49QN4b0rzibAG9s5DXjkjJK/9eBVzaE LYwhQoILAWNUjnMWIgOVcgAHeO9l4rFhgAE4JwWgABqDUiaDFWKYQ/GtGis2PAgpMD0HoPYAACgF E9o8T2Gqnyls1ogcd4sHHkKoFKKUqIfQ+ibAAN8b6zwQ03AAAunVDKGwKgcooKT/oAC4qISICCuB CBlCQ9sKoO3NpvgcAFXQ6R2j1PaIYVQABpjdHQAAU4gAtAAB8DRGwAIXjvHwRwPYlBak2GCewSgc pIDHGoY4UwvI1iuEKloHAMQRUMGvKMKofRSEyA4BMAC6FwBOD1JgI7EQACiEA3Adg9F4BoEJHc7E YRbCLDElIWhlhUOxAAKkQNYRyDqR0G0SLYxJBwCeAAKoS1Pi8GAysLwhas2vOGC81DNg+SEHCOcd 4AAPgYAgAAfQ/HjgrA+m0UQfDDiDFCwcVYvz2Czb6mVNoWQ8SYHSO8vt0ZOBmEUeKj7WxYCHS0Aw By1hajATAxZFIbgp1OBQB8sobRISmEQGgJSnAolpFKLEyweRMPREwHUKcBAjAxIaPgfRHh42WQmN pVlx0jAjsOAAeg+iOCYFW6UQIoFlhlCaDabwVwfAAGe6hBQJCagdA1ckeA9B8gAD0Jatt10wCQDb Cwe4+03zolMFoImEA7hbB+AAEgHk2qSnfSqBg+R/K6FwMYaxXhBVZXfjkDGYbIiikIEbM1PsqZpz VmvNkGn3DYH+pNN5/qrH2mKfKpxhQ6mCBHmhOEuRHj/L+JWLIhIAwDBPomA8Cc26N0do/SGkdJaT 0ppXS2lYPBYH+kRNoydPAAOuZYkKhJfB/D/Z8s5aZ3QMJKP/Vxj7RzbFKAAIoRZtB5DylofQ+k3y CE+2QT70SjtDAKqG5WvAAAmBMBybwc4vE/HAABC4vksN+N7Usq4xIsno1IACmDfhTin2oX9CUVo4 m9XUICPYxBiGxk9JAaDpytFcjkICYo4BwFVRPHcMwZlNzqfmLfWG1AxBitiBcC9yRAiBTJQ0bwAA JgTAeAAe4914BPCeD06hh35lRUgew1dn4jmp4Wq8nbW8zYqP1JgtZbTkt+A4Bx4gfA+IJFGKMqOu Gay0ZOPEeNHBLCWaAcU457hDgAj8OuFAAJeHPIarrV4ABtDajDKGVdEAUgAAiBEBoABzDmlXCro5 jNokUDcAADwHiyjzHnRw5px+t8Toa5E4MaEQY5M3Dot5cRgjBGht4PqDwohRybxG5KT9LpwAFF+r sjisi/cfWYfib0xB+acRAAGmc/PlUCIof4kPQdIj8ADVyuk4lIN2KcPxhwlA9BYUbxfT4IJBU4IO O6w0wJJc0I+uQAB3PMAAGcRSEkv7RECGMIoAAuZJX2HM9AJgOptE4H2LwFQIGhFKLYltMRcSZvuZ 4BbQxECkGAw8FhEhAhmCOAAUYtyWiVb0EEGTIA8hcSUHESjd/SENEmHGSARIUr8oZYa6MIUQPaTg GYE6a4OYSpu4ZAaoxwPpdIAARphRIb64/JTSmYcbpQOAR4WA3j5jjKXwNARg8QCYBpKIRYO7Bocw cgdp7YRZCQKgIBzSx454NxsQABSwnr/qSAeRd4AAMwRJCQDEFA/IMYIxQAU78q1IvoSYOCFgFZ4b 5QQirIdAdpl4S4OqOIF4EYDD2QhoAhVAP4TgqISwVoY4+oJZFwOALwIQAAdK1Q+oQqO4fAfIlK/6 pYVB0IAAWQYw7I6QJL5QJibQY4aKJoOC/r8BoYPILYICrQbwqoToWh6gNwKipwNgKYHRyRVD/bxJ OIAbxYa4cLpQQgT4Xa0q0h4x44mZkA06v5BYtot4RjzcUEW8XEXKCgdEXgf5/gsws4/o/wxYxjrz r43IpIG8ZQAAIMZopQpaSJgZ/EW0XUasa0a8bEbMbUbcbiCShITgf5EBeA1YPYADnxHRQ6nQnoWg WgRQAAIAIDVQADHKBok7xYVYVYqI+yNCPKYowpB4fIfJXQQ4Q6mQRZhLaRDA0QITjSTQQrDx5oAA TYTbPYOQOTQgWoWsNQZBjRMoDzFwZ49gGYGaYqc5s6XIP4AATITKPaN5egWQWTo6RbAJ75Jo8h6g aQaTX4NQNRqKipbKhqTEjJr6II+CWkh574/AiimQ5ITBZgaLX6b4ShkMDjeamQcIcIqo4qYqTy2I t5gZJBfQ9RlYgSmTMJ3wmYw8dRVIaSQiRZHpNAZgACYKLAHQHRzRRSHUdkNTdkqYTwTx6Mv56IZw Zw9CfTlwO4RclQTKUwgo5YiCsqswhxraHxPB76HRRTFoVK0z0jV5PxJo64bDeZEqlsVIRoRqO4u8 k4R5gcrCJos43CPxkknKPYhYwISRvI2QrKVotJezKcaprZLwlpJElMXkGAjoiAFRJzxChoakah8Q V06If4LM6kecgJ5IIJj4x604AACwCRaxXb0yCL2geTCwGAMQSCma4gAAC876sx4wvTn5Jz2gXoSB poIAHk5QJxVxjKuqhgUSWQCwDBIwaBnZh4NJBIMQJabQSsLgAALwQKbrnCNbrhKIpBVELAegmQDS xAbQUw3AKwP7WYWoY00QcIVgzoS5ryOQT5ZZpYMiVgHyXwVIWYywLAQBYIZgTYNovwV8NTYMuQOQ K7jS4a4oxJlYGwFKa4ZITZJoK4PrWYVQX5MAEJ3pvAN44YPATDgS94noX51xhAUZPBMZtr6K5L1B gCP62QIYtoTysAAARIThtoRIUz8oUpywswIhmQQISBsYSYV50oW6zx7Csghq5b0j2gcodIeAAAJi 75VIuk7oCDroBAA5VAqlRgEgDQCglQSiLYezIY+INQ5aKiji465IewfAlIdS8Q5gEqJIXQR9GARY Uhk4SAVjbRTLf8TCp8bZIStJ47hhtoREAIjxexVAGtZIzwz5AgXc58btaFaNaQW1agf7OkYgrrr4 uoncZMZcZpJTMIDFZ9aVclctc1c9dFdNdR9DvoYIf4adeA6jPbipABQ4z4BQADwbjRGA6YDYDYsr VaBZD7CQADoIwJKahbgo/CKwvLk4xBPCS8zpXTtJ4leDh8uyXyTRs8zbah9xniOdGBQhzUzcVJQK QiIkTkiyLyQyUzMjgRA4poJQJQjSOZMknJbI4KFkjjLaJZnjMkcrmhMgZ4Z4rsv4zqfSv8lwAEXi QBEZmqPJnMXi4rMybTTzLcnLh4wow6FRTaKxqNnZ7AHo+kzMCgRqrKiBGzhY6Yv5jEv6hYz5KIho kodIdKQDgrAMkwADmg9AhBViQxoAGwGxzVryJQa5yJ+ccosZ4j2ghwpMmD8rfqNA/xeDrbrofzK9 pcLCbDFR+YnJSEuQ4IrKjReFfyxFulRg/yjgM4M62JGFHic8l4WTbQW9QQAFwKXxe0apVCJbh4oY otntiQAAB14YACoj7oz7roFt5VcZOJPwHwf8gLHLTwZIkhITtRIwRANMQYLBubKTS88QdgeCq1KR MAcxlx71GQAAGoFcj97xXpXS1JHQdSKiA4EAsp3Qk1Q4bQcTpQALxAFQER4gf9zAecIIa4cRkiay xAOBuyhgbiroWQRJLQkokocQdBHWAAsty544awcDpRNgBwAAEIDZ3wfAewjgaYbxZ7DlTgB0FJ0w bKUYWwYwroJwHjrNKp3wa+DxGYEYsoAo3QlQZZyJZpZ4K4IhzREAjgexwZGYEMMAo43bCpeAXYZY oN/ZkgKYIKX0BWATOIvQeCjkrNTLDoBij4AAdlVsDhHQDwC5IwCxarp88Qj7KYcAcyQAVQXw2JwZ N4IYGZGwHhcQj5IQfLZAaAbgutEg7IB2M4JIHBwIFIEGAT/YdQvgAAcMOYDgC2EOTRIxXc37xJIW O6qwRgUpPAR4VTbQkICmVisRP5+x+5Gl5ldeWmWuW2W+XGXOXWXeXmXqCDTIf4X2YQAAdWYojwnY 3bfo4Y5IprmLKLR4kodYda4ouZViXhkCkIkAkqKZl7ab3wdxl43r5LtMMBIJXVoYoNyrtGNoABew 3dukGCmguomYmuVhIx9zaLtiqwFIFJqgBgBhocwhbJezxZGhcd4CnRoam6a7qbaKKYvua4AGf9fF uiQAuaUYGgGgFA3JrYm4xTfAuoLpTuYlVmT546fRqjiojihJsZIhIzwZDjeJbN4Y0OfhcZJ7VrV7 cJg4a2Do+oMZTaI+cr2gcgcjpSUIqskZwIAgAhoehoAGfRWAGI45J72JOQko67Lagz8qARoZJBJR GhkFgIjzxYlYls6IxRNaxCN6SACACGENuRaAbwxymhZ6XhGxIh32sbSDVwkqmiUY0aWUrCrojpII krRJwMmBsYvcGAHOx2WYkd5wf8rBnmygAGwxm0/KOQMkJQF53h4uUGXx8V3IZuA44ARQwIbwc0GA Cyo4/tgmQolISwOaceG05QBBycMO0W3eW0MZVJf4G4M8qbCRwwkCoBlE6OyG3m5e5m5u525+6G6O 6W6Yj6KwNgf4TW7LY7CYjoRIRJhwu5uAne6m8m8u8xOY3Yl5AYzattyYj1cMhKrO+DZQE25QkI9w L6EAk4AAU2/ojwDMI4WQRBvwGl9lXu85UgAr1L9wAANARowMIDHNSo3YIwGg44UYPiTmF1uNzHBH DzSzxCgijgKQPaTAYgaRnjyeUF5BqqloAG+FwIG2+3D/GnGvG3G/HHHPHVc7zof48kVPH+dt3OkU JTmhvwmbZilPHfJfJlctuaqkYA3GmQkWVlTjm4/hDQJPGYj6aoEof6miJpzglIvBDgP4Mr5ICB2/ JvNfNmWhUWNGMJvAVZxpCJ0rG5eAjrwacfPR+pZ/MSmampD3NvQfQnQvQ3Q/RHGpJ5rZIMVJSZID 2iHCHQLwLyFlQ3RPTHTLStS+CyAgKaHUwhxVy+Oai4sJ6wnopYO1cZA4Ogf5kSMMzaO76w0INQKK gAQBb/TXXXXbSb2mQojgLIQAuIWbLU954+zDcJYI+zv7Vx45/9evXnaPaXafanavayqIhzKZxRJ8 VOfgiUmCNA06a5zfa/cvcx9fJ8GA4Mdwq50ojvKtspAe/FcaHAUAf6IJvwjoOwLTJoRJdm0B8rxA bAb6rtNGEaxET+OyQCmqQADACTroFIEUMGT7SubeAqrQbZZ695KODIozYuOXc/kIkDV7IZN61NTI DdTlxhQ88QcFNSNqQgaSrkZBGZGii6O4ygrvkXnfnnnvn3n+6mzALgLhNswgZyTqT09k9qdYvLXB B+3R8rqJHCqxRtRligAGpg3eblwqJqjxKIEgEjZmmigLSSjRAFi2T5N+mwACEy5OvfoHTAkuqIxi MKiA5+gh8wnozDWYl5K4jqnQ0Igp0sWUWyI4EAf7fDaIDICjroX4SCLYE/iXA55G3wT4WV6gQgUT agbgU7PYbJkYAAFoL6LGzACgCFfCjbCbtrHK0ysIKwIZmQGwMgmMLKqwYwSxjihR6i6jahwe4okY LYIrCATYPiLwBKBRU5VIbBVgIwOQ9B5hAACeRkc0INVIjgR4NpTYNQKpDgpLSPBQAAZIaSJoIgOC mQMIJSbQRQOI4YBHDrNfN4LAPyboWIYgaoAG4hOQQwM6pYgBtKw9AAMAwDAAAf8JhkNh0PiERiUT hwBAIAfr9fwALyFVIAYTQb4AVKBLQAGwtDwAAj/i8OAoEACdWDHAB1Sy2ACHMxIABdJY0AAKAsIh UUpERAkIZzYcgANyPWIAMhMGoAKhCF0FBAFhMLpMshC4YzYABxSSyADYcTrAAUuAAA1zADmu0vsN 5vV7vl9v1/wGBwWDwmFw2HxGJxWLxmNx2PyGRyWTymVy2XzGZzWTHGdf7y0FrbFmHI5FQATabPAA FIpEUMfmFi7TabdAB+PydAAiEQbABoNBSAB2OySAC1WrIAARCINAD5fL7AD4fD5ABGIw3ACTSZuA DHY7VAB3O6Yn5dI4AKpVIAAM5nRgAZLJa1J3gaACEQhmABZLIjNghiLnEtoAEKQpPgAThOFooYFA SAABgGAQAHoeh7AA0oWAATRNDs1jXQCzaJIudJ0ng7ZJlUABVFUX4AEWRY2AAJ4nh9ETHoue57n0 ABZlmYYADMMz4nieJ6IkAilgAHYdhaABMkzD4ThOEEcRGh8dHu6RWlaXrhjs8zgOE3AxoZHqHwo0 ZzAAOA4Pid53nmABUFQQIABCELfISfrEoucBwHSABEEQUQAHqep8QUTg7gAA4DgMhiwL6fh+I2YJ gmcAAvi+QwAHKcp2AAGVSShKIABrVK8IcAVWn+f1YAAGISvwX5Iv4B4HAUhNYr+iwACWOpPAAfR+ T6XdbgAR5TGEAA5ErBpIDaJoADeL4hAAUxYmSAAtkGVAACAGIRx8RAvxoPJQgAaxwHUABqFCOIAF oY5rgAMBDFWABAjEIgACaHQUgAYxqnEm6cgACoIAWABkEwNYAAyCwHz4jaxXmYbxCaO5QAAPYuiC /I5CgABfGCagACKOROAAFgQAuABgkoNAAAgB0IAAf1JywhqXnzYr5YKAAMAmBwABMDwKq/neeISB NIjeRJWgASRWGKAA8i5kIoh6FYAGWbBxzaScGgsCOGGHmc8A4CmK6aiQBIudp4HqABrm/QQZBODi hgSryjoemIAGcapwgAHQ0ksAAyia7RJjkJ+lq+yAtEDcFQnjmO1IVpi9wmAA8EqnRElMYCHDp1AA EZ1dV7f13X9h2PZdn2na9t2/cdz3Xd953veg14B/n14YAHse05iaJodgASpKjmAAJgnileMGjKFl 8XxmPG8oAD4PgwAADwPAzTYvkEAEqA7DhNDqABwnDQQ1jWR9Dnqe4AEgSDvTjOY5jmJU856T1g/S EkQAA8B4JIEAIB8ADQGsME6J1Bp4DxBtIEx4PYYiGHWIaM8Z42nFhlEUAAB4DznJRee8M2MFhIF1 HMqISIkQ4HXCMDhK7sHrAAHUOodoABzjnHcAAFAKCVgKQepIyKWkeo/SCGwNj9FUmnDqHUK4ABtj bHKjARYp1HAHK8JcS6HweA8Bimd2ivR3DuRQN0bo5wAAWAsBBPAIT8OTTSaJNibk4JyTonaOaeyM J+AAPMeZ1hTCmFwosWaizVgvBeCYhifTAEXHIOSIKhGOvNFewkCrSghSfJIKkVKqw9ylH+KOVAAE CMGESGgJJVAog5AABIBYB1eOdKQAFCgjhVLNFCLUZrzA5uRBiCQ/AbxJyLFUL0aS/wdsCDsFo9oK wRAWJYq0hLnxsN4W6IKLgIQMgSUGGoJaBhRJfeyNsAAoA9RVB+DJcg4h0DvXuIVFbnDthwciC0Ej MCEoUnwKQXY0F9ieF2zUBqEA6BYIIEwHRpwFt+IeWAYI0BvAAEAJ4XgABgUWQjNgMpVnuhkCKAA2 qghDCgoON2SwAB+KvQir8ixFwkg3BO90MdJQFgIUigijY2RwruBsColYvRmzqBOB1pQgCe0mG+Oi jAmZEtgKeQ0IwNQSgAD/K5iIEznCMFAL4AAoRczBfsj0GAJHyB/DIgAKAPGvM5Ysr9OSGBCChrEK oX0zQ7hagIGaWMgx7HWECJ0XQABijSHAAANIUJZDQG4mwV7GSFM6ZqzejC/ZBj1R6IET9Bxxjqcy hMi4YwmA2SEE0q4oBbqaG0OMtwfAxUlB0CwlYnVtmoFmMsrAQUNgkA220OglRagAC0EUGDoGtAAF WL+Ztw7ijzsHCSnZLACIUrSfgTAdAonyGswaEQrrBHWAwBIBi1SBgADaFR5aXholnuJLOhIAB2jy QwGIJZVwphAa8GYRN4gtBGjK1lkM+C9kvG+OdFAfBNyJFNQOIUQ3QB4NWGDCzrXfYZw1hvDmHcPY fxBiHEWI8SYlMYnUVA/wsYrIcKwVggwABTCmgAhMHDBkXQshgGgNAyNHaQAAWQsoWjCGEcoH4Pw2 sRnCAATwng8gACQEgHUkSIFeEEIITdWg/rDexC0CQEmjAxBimYHwPgX0cGAJQhhXhKCUi5Cw1Am3 2heC8EwuQBi8KRGGMO3gSwlmrATRKMAdAABOCcjdJREUKJxcyFwLghAAC6F0MqlyxnwgeZg9h+gH wPvkjGxAdA6IenUR7oEBEJAHsMeMooW4t4Rm8Ne/kUoAA9B6EyAAT4n8niWEtJuHc9Bci5EbpcDA AAlBKQ+LsXelCMkbiNqcVYq3zhHCOtjNqhsKHm1IQUBiEBJCSDeADRwTkDCFyyoQUgANePPC6F3c isH7hRCiHoAA0RojcZiMESZvw0bDGyNlgysCNyEfuLYWwiwADjHGoIMgZBEvFumQ3FYQyZid3ofp jojhHLg4NwjI8shmjNoIEMIcM3/BYU+OUtydaN7BEcAAG4N2BBiDFCPaKX9tpUJWN4b0bt2npRix AQYg2OodKmohRRzGjbREAADMtqM6dNGKMW94/yXX0Ha5lBaHx2DsczxpFaPxEAABXNQAE2DCleya VN1EAH+LODkHJmoEI5G4D8AF1AdB/yiI/wpsQig0hKlhDYCICpbM5lwWENwkZFjAGfRcTIdGSA4B kCQAApBbPaD/g0AA4B0IoAaApSIPwYGvD+GBfwLwUG+G4OFUQWxBCmTxksRE5JzToGZOoUM7enAz XIJ8Wb2hBUqAAC4Eb5BGhsnKCZthD0ljFGnYsQImxcgAF2MzfBS0KAt+OWcKrywpBBK2zohYjBSu mE8LV7QKgQswZ+bEdcCTxhcWwBaWi+xOUHGeNtNgGgKmjAfAXErBzB1h5AAAHAGNTg/g0pXh3B5H 7hBBMCdATgPJrLagPgABLhYDlAWP2j3AnjtBPhbJghWLnAAAXlaAAB7jogAMEogg3gqAeAAAQAMg IgABFPzqXLLAOAKmKBqKnjrqsGPPUAAAOGJpbgAK6j8q8EWK9jxq/EhApJZBdhlp1BABNrDgFCuj fwQLEBpHDBMBZDlPQtTgjAbKsgegWkrBcwqmvhrmxAWARNih0h3E5k5H7g9GQLrCEP0ntAsgiMzg yCggABIhWhjAABYhhDxAygnDtMwEIA5hKLisArkguAkihA3hGhYAAP9osgeQ1L6QHmGhrHDAhvKj xgtj2hDBRkXhohuk2RPkrBthyIegHLqhRA9grGBnCkhL/iMKYAWgQtig0wpFZQUgzBFGplZj8H2A pgAFfi+G4wkh6jrBPBZFuLoJOJPJQO+MMMTRvxwRwxxRxxyRyxzRzx0R0jFBYR2B/goR3iHBYhYh DtCgnFsMajCtFh3nMk8oqgwgwpXhHhHtCFQCnpPtwhtBtCnqZgAAVAVQMA+g+nwArgrsaRngAMrs sg/stmShfMvMwFZMxunMzM0HFFEEkAqAqA+gABcBcFuDkIRjsIbNEkBDph8Eej1g+SWBcNKCGtON inURdMLPBAEAELznsFuNDDVlSJIAQQaI+kvn/IqoFgwgAAgggtwj5l7ALgLwbAegeitgOAOGYHmm psguxuSHlsZH2t7IQSWuXuGuxh1v4iQBhM1EWkXopnFMdqbgNrggABXBXEguGpyjyAtgAApApSVk CKoN5QZNlJggGNuvrBdn6DUi1EDhRt1BLN2Auruj5ntSUyVyuJxBeBeOXgtvYSOlNI4QbIhwMBSB SSVylAAI2IsuSAZAABqmhSEnDEWnztApbArArA/MtSqg3g3guOKrxO4t9k6umhaBaGrhThTp0BfD jB9zsj1Aqg/tuNTyrrkhfhfr3ueIsuGs7DgGSD1yVzJEIMxJINokXgmKHAAM2n2zkNhkuhgtULzg OgOprEfoRoPBsnyhCn1n2gkgknllHqADBivBmBmDxMZA9pVBxFBOYjtFHpbMiBhAAoYhIh/juN9h uUSEDAyj0gzgpspgJwEwkC/AvBDEVh0B2E5hGPbAXASp/SLlewqIQBGhUFmhjhrGxH7DrAwglChA xRLjhhMJEtUpbBHA4tyBLRDAABRQRgAB4lEiJAcKiFlA3JygaoiEIgBiXvEiGElhjrFEYHSmShmt 8UtDrAogfENgkQzxCBWRDgj07mAGBP4m6qMqDgnmugAAPgMQbBHBUlmguAjzcg1ApHli4DnBFhRK xBNQNyMK2wvLFhiU1zOLuwVjpPFipgrghMzgUAPmlLPKNgoVCA3AriCALmFo7P3p6kVhrhxF3BCK cgAPQkIA/hPrDwVjYhVBBCT1DQbCGh9qXtCg7kEhehnDbVlpJCIMzAQkoA6DhGiLzglA6kEm4kKB Sg/IqgPVDlnRJCSBeqCBWhBguiUQBAAB0B1EUAjg5jdAXARHyA2AppZAtBBFwAnAdjTqrqsuHBWF 7gkgZmsAxEAA1BFWDhhqPRcIqrWJghh01hYBC13AVgUG+BRBaNKA5hJJFhALNBkBqmxBlGwyMWGE 8VzBGVFAABlUhrmBBzDhFBTT9v9o3ViiTgYm9kInBBVhdhnrGBGpNn2DhAlgekNgDxvC9ElhLhWm rtbPqoEn7hQ2so3o4AAUEgk2nx1Ww2xWx2yWy2zWz20W0x1R2BYR3R4CGoUICgqCGDpDCCmBnD6g ZgZgylTNCEhjhCEjYp/gAS5ogjiHFTojlI0nMnomKH3l9DUpFzkDjTAtIAXPjAAW9MekjG6iIyil InUOUOhg1IzCwkKFEG6yNlhy8AAJKi3ElCEDwBLkUmpsXHTBRRcQiweM4kGpDqNhqF4AAH5OXupm UOeCPnowbDoFFAdHEJOGKBDhDmaSDjzifNvjVkatwlMKCBiBiIAXot0yWtKXgF1AMmJMqJs0Ko3I hzDyUoCTkAqqTDaj3AzthjyCT29JIR30KCkC4GKJDzigigil/DgSVkoi1N7EE3LknlMRDggAgDvM KTD3ooZx8R3lGhkBkF7C7TmA5M1JNIfBzxN3VAATqKNzdlDMiL3sVumx2FPO6Lz4HjvMroNSIg0g ATskkATATCT3zJxA3A3W5j/E7j9EzUEpZBlBlF7A0g0z812AAOeE2Ip3Zx5R6NDR7jnyauy13ARg Rj8BXhXlPEJCjHADBlItcxNuaOxiGhMY2t+A0AAhQY5B/lCOxjRizK+j2g4AtEbgMVZvEC/0YUZU aHVUb0cnOCLh5RqAAKdiZACFIAABXhfmUA7hLkGswGGBAAwlsBBhQnTUngAUotyBK08rmBer3gfA YVrglKbAAASvm1UGlAItUuzi8urCErpFFEHivACAClIhiBoqLg1BGJNoHpbAX18kfBjF7ByB1nMi kA8RUwZ1zBG2Y1GVHVIC3v7haBhj6g8BLidU5mvBhPHouiZBIA9RdBzRaCoZiAAAsAhszpwQbBCx WMYgfkN1X1Y4/iwVQtxJvREBiD6iNUzgbgVH1BVBAzD1yo5VlVmAmg7FhhhhpnDAngeDTmuDTgMm iwTwU5jQkh4n7tkDdUyiEBTA/oqgNAKI5AyWHgABeQ2hZBDlzvVG+B8QVgAAeg1jzADCigABYBEH wAwiPLxgAK3mvBHmrRCA2s7Amq4AAAxBDl9Bh5gtcA834hNrdmv2V2MgvOyWO0rWQAAWRXJAqwZV oN8BkBqGDFi1qCH6NmjWMzlHSWdBt2eVjFZWgAB2hWiWjWkA62lWmFHWwCw6etIl6ifhAouV53Uy NpZsvlqzkbCW1bKbK7LbL7MbM7NbN7LzxBfh/yrsCiGXogzsJlz3AjC2728292+oC3AJA3Fz+UyC EEdlFNqHns9pmsgx6JKl3A1A1H6XKvi3MMxEzXPt+HIoxknz/JrEqQMFW7Ji/EKThydNonTIYjvS tFssHiksvmjUIMs3hrEBi3jBvXkAJ6G5ayKUKHsFNNvoZgtHKmqBJDvILTlEal5Xty6s1IFlh4VX 5Xy3zk+U0Sdmr0En2i9SNyqsxPLX9gAAYAYKsgxgxpy3LjXynHyHxNiiEpbDgNIYDt6ho4FAXYGB g4HYIMJ4JhD4K4sj3uHkFkGhpBpGOoEEkNPgABDBDD+XWYuj8MXOXhShSxNtHMYYXO54Y8UYaAAY bYcB94dYeAAHgJxEhnIsLFPC9bhTbCbg64qR5x64sMbCL4tgAce5I4w7ZokDCJbSWlm8DnTnUnVh GAA4MhkB/uGse3gGURbNTyPW+AZgWQMYcXBC9Gnl9mEZqkghhhKmaAXxQAug9FDBSBdWip2RdAvw uh3h2QDAjV7G7KgqTBQIZiOkV0LEUF4F5dEF9hPqNhYBDavAn54sa26i/HPg+hNPqhF02g9P6Dxr NWnCElglhhnBso3MnRnA4PGGIgKDnBZ6gi69NEWQTQ/oyh3UtDrg6DdBGg1pygvAnIbACiMiErrk hapYSheL3lEkevdoqgsAmChBsP+EmAzoAZ4LkhDAzj0gXgwhIgAAWw5AABWhGkzBqw3gAN5l1AsR AKXB9CFhSBeFNdFYb18wbUfkggVxhAAAmWBJrsqiZAtg+t0kXJmhXhCV3AkaLiWZblWCLmfjpAkA 5FhurCFhYlzISAIrzhTPMiqGpclgvFsA5KSaXhgj6grg/TNAqggszhLA7DhBspuAjA5MsrpEegZA TD8BahFINAIL5iOiPhbCy2azDxZoeg8hMBbl91eAwgrEbhJ1KidhRkvg+gvOKAB9xhEwchMA5rug kvxKxiagAACgBCEVWjT4mpNwXCSaFQZwa9xCZBYBgJmgyhEWDhJp9ajCtAAAERpYyi9HBBjKPApd IAAB0h3kkEhj+AHfUnVHWbOfW/XfX/YfY/ZfZ/aDJYBAih/k4p6OQntFSKboIt6JHKs7UDAEKBrB rIspSs1HgAJ/VmINJHtDgIR4BLUIIsnuum6yBTNJDkvonLuz3jztIYmHI8qCsAqSdH3lBTTH6SHP LfiZbCwIrmxYHtwynNipROmi4JrE6idCAG02pAAFotEUADodCsAHU6pcAJdLnUAEgkD8AKpVLMAP t9v0AFcrkQAHs9poAK5XMEALZbIsADEYioATV9gBvt9zgAgEA2gB1ut5AAQCALABbrdHAAIhEJAB DodOgBPJ5agBOJw7gB3u96AA3G5IgA/n8xAAzGYsgBMplSABCoVRgBKJQ4ABDIa5g4HAsAMRiJQA OBwOoAJhMK6ClojAB2u14gAjkc6AAnE4dgBWq1ETUAPzPaGavl8gMAINBpgAJBIKsALRaIoAD8fj cANhsNrZj+fjIZCYAKxWIMAAEAgQAEslnIAOFw4ZkMjVXwGWgzbJSKRcgAEgkDxFL5UtlsngBXq9 bgAvl9DeA5gDfcCFGkAF0uke6JQ8gBjsdmgAJQlIoEoSg2AA+j6MAAPGQQADgOArrIP41teWhdAA aZpm6AA8DwLjNFaliDQa85CgAKAoIQmp8M80wZhmMIAA6Dqjs24gBgG5Can+0Uex9H4AAMADomeA AhCEu57nufKQpEABUygALQlRKh/ixK7RDEJYagATo8CpHceSBH4CuQWphGoAAnjyUIAFiQ4vuSIQ XAAep3K+Kw/lKlpkGzIABgEATXkTOIkByFCEjOSoAHKdihmoUI4gARpUmGABAk+XgAFgQwvTUIYX tGm8x1I4wAH0fjQDEQxWIyXxoo6fp/SAVBAC0AApiUGbXl4aQADKRTXHYeB7NEG4Vg8zRBi2ABzH WeYACKOZOUmNYlgALwnBwAACn6kAAAI0xrm6nYdDSiAQgyp5akVOIMgwp5pm2coAB3RQACsIVQkm PwsAAX5hmqkI+rmeh71GzwXhIDS/kqNE6nwfSKjoqZpG4dAAH8f8eXDQRPjwKqQiOGNuTI5Atj6t 5VF/XxXkILqKh4mgCY3HoBSkfJ9JuJA5E8AGNx4WJETiB4GASmoEAKAA8kgWQAEcVVLZ1b7PCvOa qD/W4FZvjJ/VmLZBlQ4JfmmAFarWJ4hhhcFZWwQpUpaYxsAAU5ALWHwXhEAAwENuBYGGa1Tn4kAc hWD4AGcbJyAAPgwCGAA1CgHNfkTVpZ7kAB8n20DQkSNIk8gKjMjIQrXG8c52oyQNmBADIIpqA8hE STxdgATZZmUABRD0KwABsF3D5pUnhzLIZom+AAoj2UQAHQdtoLSMwAL4BwAEZ68peH7Xt+57vve/ 8Hw/F8fyfL83z/R9P1fX9n2/d9/4fj+X5/p+v7fv/H8/1/f+f7IAwIAD/GhANByDwAATAmA8AAaA 0BOAAIQQgZX0KCG8N4wyCBLLNHMOx3Qog/AAAeA8CAABTCmKuQIgiqWqE1hCdU9Z+BACALOMoZQ1 wABcC4IRyAajylpPKFQKgfDmjhHSAAXgvBHgABUCoEhnnOPeZwPlWZLhiQ3C4g0ew9kmGhAOAdpR ygdAAE0JoOyLQABrDWTBKAvTRAMaMAAM4ZwoOMD4GMkoe1FkqJYS4mBMiaE1NAkpWZGhcFgDcJIA Aeg9KeDuHcs48h5DwKgIcUCXROlXFCKEPYAAbg3ToHEOJSxRCiO2aGNzRz1ugEiJErYwRgjHAAE0 JpW4spMOMlKJayRhjDgyM0ZqfgkhJIoZczJmzOyASAaQ0xqDVGsNcbA2RPTbLeJuLsXcsAxBiM6O d1BxVTRLBAk8VIgQAArBXE1bys5XDMTUms+AMgTgAFkLIQ4AAFgLhGedC56z2iTEmpKHCYBFCKIg H4PxU1TAAAoBSEc9wEAAAgBB6pgDBQQTaIgRCe0fhMCZGEWYsyYQlkKeM4iJUTopM8TccQ4hzExB jHaVYborQORW+xpQyxlq+SOXcejBkmoRSgKl7JNSZAxH/T0r426lTlBCBciIdApAAB6DIEZNonql SkOEdZkRICoJYPofSsxJBwgcjlQQ7h4rFFMLtIonBZjLhAAuh4W2RkhVAACLrShlDTHCAAYQ0hwI LCIqEbI44ODIGrX0IgNQSgAB4C4EKYXztcHOO5aAoRaTsRCmmBICobhGBlLEHgKYQAMoePhzTcW5 iaFkMkpgDrPBuCnGEHILZwjXOeAAXYyhtgABMBwCYAAiA2saARQJNbKDsWgLgZDcwCqAIqDm0gFA JnVGsN6IothiOBAuBI6oSgdk0aMd8Wt2yqC2rgAqL0CwoLbCEDFvQALjjCeOXQVgxQADpHePVA4X gg1SqpXi4yOzPKmHuPgm4pBdDOKAPC/gWgiMkBABqBTP6h4FJrWAkAoRcYMu6dUIAM4mgOAS0omq Uklk3E0LG1wrBgK+BqCgDoAA4hYB6jICuFTQrhNe4AAA1xwRFMxaQEgHQKAARwaYWYxGBZAMMEwH dpATggqcOAczqRACcdqA0BSQguhIV2Mgag4nfAqxmDRZBQB3rQESKMYAABmOKcg5IAAVAhAtO4AZ pQoRbn/H820KoRVQgMz00hIQbhFitAANkwrug+O9u69Vn6Ynw6FF9c0AAWRAinAAOorxcC4wHgRA uBmF3/an1RqnVWq9Wat1dq/WGsdZaz1prXW2t9cPbgAMAf4i9fAAF9sEACSh7gA18fSBjIY3YmZ+ +BQQ8B4LQCkFKTYFQKwjEqJUPFCgKF+K6ZERIiS3i5Fy7miJfo4nlCeE8IR3AE5KFnfgZgzG5wMg c15HhbRYgAA4Bypx4wkT2AXsx8qUh6j1RYJISQqpxC/rxesMIYXQTZWuAbixnlBS+htRguY3BuOL EeI8N9Ugeq7a8xLkLYgCcrjOGsKPD0hI9OQRp2svm5hsDZVHfoGJvE1E6J0WmndPK/DKE3bhTxyD kiKHQOgkwAceXoWFMAWQsmNAKAVQW+GniObhGsAAKAUTheuGoAAFwLgVAAM8Z8NhQCgPSkdkhygf LgeEmM00oyrjaG0OMABAkwdmdej1KQvRen/D4HwTIAALAWKeI0RobAAAjBGgahNyAADsHYO8AHCl Wk9bWbRXaOGlRHlgLEWMVQvBe4CDUGqdElLQlB04aI0RuFsEyRQl0sOLNKDkHItdPb+bhT2RoXzy Qo9zowfQmqZhaks3I7nnAU7fAmsiTXu4omnBpDSIwlpLzdg2M8xJ9aQtgjIuEERSTQI7ybLiIXC8 mRQj/NYQQav9VT1gMszJLod6ogUaKe2VMcGVmC6EEbEOKJqEmDs+kAoy6wI1zAfAhAjAlAmfIa4H CuUesFE+KHQssMODqqigSL8a6e+eycGR4GEGeeQDOEY0UG6HMHcW46uTc9MAAmCCS1NApBzB1B3B 5B7B9B/CBCDCFCHCJB6OUCWH+VSNA3IO25WNMjAJSFch0UDBwe4a8SkGuGuG8VwCmiEQeX8gYTAN HCLDJDLDNB+SkY2Vmn4AA2gWgnmKWwyfgaULqbghQNEF/DyAACDD5CqnknmH+DJEE6EMMdiOQE3A +AA0CZIAQa4e0diAAEsFUGEAAFGz6AAE+d4t8A8KOUE0pDPFBFDFFAmUENuHGdSEQFC+KBSBEqcD uC8ceVOYQfAVMHmtSFSFywYkOI4H+ACNMAxGAMGMJD9FHGLGNGPGRGTGVGXGZGbGcfCMAGIqOp6O SOUAAW8JAlOKoE8D1EU0C/CfEiySkDADAg+A8A8qceuMqJqWLGfHdHfHgNC/IF8tcDsDsgyn85G9 YBY7ofaOQqUsCCqCqD6QwGmeQARIQm84M4PD8lWEiH+GpIicQGcwYl8P+NCCOsYLIDKPwcKWTGuV nHjJFJHJJAiey72g4DqEsFsnkvMBdJeAAoGNkIsCRGJJLJvJxJzJ1J3J5J7J81kSoFQH+70N0LyP aHxKQNEIcLWEEEEDOABIRFLJ/KnKpKqfINMEcEc05KaE+AAHiHiv4eu+4oWyPHIDBJsR65wDYH+H nLaAA/gNEqG8YOqD0C43aDOCeNtEMslKtL7L9J4/UCODmZ8F2GYt6NDKaQaoMD9LRL/MdMfMhMjM lMnMo1kIEDaH+8WKO5+KmMIsCNCRwUEJEceJMQ+7AnCUDKlE/MrNZNbCFCyzI5wiS2CP+AzNsAAo 4CYdsE2E3MaR/LUH+7MqdM5GFM+R8Y6XqBacOCeB4IYCWByniBCA0uCTLFLNXNdOxOy1iRwd0Fun YD+E4QuHAHQ80iWJoeoSGOjN9O1PZPbPdPfPhPjGWNQEHOC7MOsekeGlvGqcm3WB4liCajC7MyOJ rJDPlQPQQfkaU2ybg5wIINCKKnCCLQnN3N6fSlcGCH+Ocr7MWiGr6/UeGL6O+FID6X8COB0tI5jQ TRXRYe6H2ZqGIGfC2CiD4LmHiHoRZPQeiWjQoMmCPPXRbSDSFSHSJSLSMe3IoGcH+m4J2iyWKjjK eHdSke8oiAbD+PaB6B6S5DlSPS7PgSkHU6HEEnq3InYrAJuSO3bM0bMSpSAfElGFEH+rAYkl2Usn macK680R+tgO+DmCw7mDkxsAAvHL5S9UNNYx4GLRlEUD8LedQWgNDJeToyS7S7VTdUPUxUzU1U3U 5JyFrU+H/SdIUeseuABIsI6I8SAL4L82CLGJkOAuPU7VlKqSlGwQkKmLaac8wMiO6aOEtV+netCB fWHUufYjGE0H+GLWUJwJyAAGTWensAOUEFQayJ4uIW5OvVnW1JGuOl+cWEGE+jYcucC61V6h27I4 iRjP2nMBXWLW3XfXhXjXlXnAjKCH+M20VNSnEbgO6O+2CIIBwBwZJS5XpYLGSOQM2+KgYJhV2NFI Qoeo+I4jcOqBzYrXcfsQIBKH+JyeQAkAcoeFUVsXqBgb0R1YNZOf0eywQJAF+GYQ2oy+KRodeDCV 0qksgSCAMR0ZrAO2GHyJAzEsCEoFcGMKQGSN0xSSBNsAzQA6MQeLvPNYvZRalanaparasfMB9ayH +GFa4hAAfVYF8LGN8IYJtavbMfWUEMeklDuHKHKHXC4Iw6oceoWde8qNEUFbaiKKy6C5+Kvbbbe6 0R/JoAAAVcKABHsjLYCBxaifxYzY3WaAiAbZAbsXqBiqq4JbPczKugosMk4XuHZLASAAsAiOqAyA nSsNDaQG9BeM+bae6i6O+FPdkAAFxdqjEjHcZc1d1d3d5d7UzayB9a3a6Aay4AA8III9YzxbLd9e YSAVSVm8InYPsOIKCMix2x42sgU2sKfQLK8Hi2KHMHMMMI8hWe0BTfOAADnfU+7JYJUFddyf1COH +2C+KAEH+JAFMD+X8CQvCSDebf+NFO4GgzkDM0TVMGwXoY1WyfXYePqPsABHOWTVEKiEPfhgBgvg xgzg1McDLg6H/N4E3VGiOiSSOW3YJg3d7bag4CsTyAAGMGMbKfrgaRQjnIcM+VSAAA3h1gs1Q6YD oH/WOAAkgKHRIX8CmbVKgNNAdhRbOvWFarYWwEGbgi0JuA/is0mR4HHi1iwe9hmRQkMpldhfYQOQ Rh5iZjPjRjTjVGPIcH+DfjeNEo+M6o4v/DHjXasVSNMM2dqSuEBVHh0QM4sSEgrC2fDcKs8CjkS1 IYe2yUXhtOFjM1VNTNWZqBcBG54FmEUQU388DddjvXougGgG2payydq9OYFGA55aU0y6pD3D4AAq Ut6G7lmvyHSiLlXYyKIKKd8BsBtkjk/mBmDmFmHB22sAqH+I8JuiyK/D4tCMQjKKLaWJrfLmJVmO +Ng4cJFj8iyRZlXP3fCHMACGlnGH+9mVg7USKNISZly7AURYmscB4B5l+1xcVfuW8AApwrgAkAaa OFmESQUB0wCcFmrW2Y0VmEuFgtcEJFUebA6SuX86obQ3XnnoJorotovoxAk2mCkH+8wg5a5EpJeq rN423l7H5eXozUynS+Mk2KS/MhUAA5CiTXMgYDRopGMOiGRGmK+CJp6XAugCqCCzwFKD8LXpvpTM oH2ACY8Fk/MDSEaFea6R4hCgU8IjYBpqxqPqRq3q5q7q8fmMQEwH+Q623iHZwaUSog+mCxu4vq/S ENNlmcWggkqOyQvpgPsZghwQ/R9q1GXdqFwH+OyLfsEAABEA0KeEADAJIC4CQtDr7rdJweze+wSF snYDmEsKuZyNABFs5kW7LPuPWC/sfshtJtLtNtONDnyH+MugdSYAABYBYb0KSNk367QxPtRO0NMN weRkTG6GysLi5R3PRLFtHGZr+H+n86dCZhuNADqCy7mEEDK4CAQwHtxNcx4GOvqCMDkWoYM/EM9h 88U8XcPHtuLutvPvRvTmFg6DLTk/xLg4sOQ+0qiNYJ/iXvVMcSkiyYk9MJYgYEbiEHkv5TXTS343 7VIEZvNGcJMD2H/K+MiLqMFOQB3OUnkEQQUL6oe0nCGrCVmGOGkr6FQF6Gg76CnP+BUBGqdJBvwe 4HgYiQOEyPSEoFalgNDXNwLLJLekzwVxZx7x9x/d63mGYH/yEQq6CNg6ChCL8lAZC96X9eJBE2bC AUE8wkkJUzelrC4CARkA7xUYzyAR+5mFUjYkUIhlmpaNDlznfnRx5JFwYH/qsAAGtznwCKGBIA2u DEyd6B0BYWSZvzafqueLwE8jYESFM4cHmi0NWDc6MDGCecm4HOtyAVMZyJuC8EG4YFcGGTTAENEB 30+yRO5pB0BzB1L1N1PZPrCH+F11YABYjVQJu8kQMgAkRtrCKaUQQNUlWNdfJx0P23Wv+i7NVyAN NWUV85xwA9mQ2/VeJStV+gyqLtfth1JJHGjwdK+naPLCUNEC2CKbXiKxOezZ21yug8QPSEKFE4ce GXhSsGKEsPoBEyNmnQNtOikR4ETA0UuUyYz3GJqoihHpkP4P7duE12p1R4P4R4TW0P6GOH/lsiKJ EQjnU3cO/bk9sjLCcM9gW1kkgSYkUgy2zqiR/NC5IToKyP28kA4M9mprcUE3mbnrmABU+lhphP2C N5uAB5uMbWUvxfd4NJ0I0FVmRVTfUPeHR6PYcvWEaDSCUb2CcS4AU5Y1UVMc2NADWEa32FAFwP+c 3fLUk1EuDTruYNED9sUkSC+3aAOuhNd0EE1xojgEYMUBQA+KOFGD2d6zRI/k81mH6VMF6GUT8C50 wwaK+R/kEjgjjNwo5s+qcBh8d5/4V8j8l8nUMiOF5CThxkS5e2INF4zV+OZg65emQ1WSlKQRZHsN Un80UNDX1XYABlSt0msNEryIaDqVuNRPzGvNciyNAky6CQekQBaBaqqn8LvYreVy+1nIWYkFgFgz ffUMFltT0R9wISO5aQpSyB78hL613p2p+Tq4ONFZyNMDGS3piDdN0dixN36fma44OSYPY4Ys2SAK adf7FhfaJKJwR9n0EIARBoJgAmDqUAAHAsEQAAH8/obEYlE4pFYtF4xGY1G45HYqAQCAH+/n+AEQ pV+AEiq2KAHS73pEwgDASADISxoADaVB2AA6FweAJDIY9RY1IAA+Xy/AAqV80QAj1WxAA1G86AA/ H7EIsDq8AEhYQAFbIACbZ6JRrVa7Zbbdb7hcblc7pdbtd7xeb1e75fb9f8BgcFg8JhcNh8RicVi8 Zb2bj3+0skADhlQA8cxEwmE6CZjMTAAfT6YQACQSB4jJb/D4a12u3wAfD4mwAsFhVIkAt0ABnvQA ieAAHfwwAbOMAHPyZkEAaAFMpj6ACGQxuAAMBrTje1auyADyeUwAEcjlUAH0+n3EweDwYADmcytx TYUwAEQjzcTIX3+wApFIXQAEWRZTgA1xwo2BUEgAS0GAAXEHgAVEJO67cKwsixtwyf5jQ4AB2w+0 LRAAesSIuAYBJCGgUA6AA0ieHAACsIYWtKA4DIaf7VIspB8Hy9JWGAaYAEmVpjAAZRrnGjYFyYAB KSeAEEgUAAryq7JtSwf56S2AAmS8ABzTCiYCROAAnB2FIAFEPgrgABYFNQh0dQuxR9NYYJnG6AAy kUVwAHCdB3rotIGgWBAABYEQLgAGITA1NwDgKAAXhIDYAJnQ5/H6kpwHSdwAGabRygAaxvnVP50n glx3HmordAEAAT1kABDVq4TiDFXMKTpXle19X9gWDYVh2JYtjWPZFk2VZdmWYKVnn/XIxAAV1qgA U9sAAe9tou0zUByHIVxaNKECSJMYSYmscIvHKGnQdB2gAVZVpSTpOlqADJT0jQMX6AA74AAAeYGA Aa4MAJg4TLUuXsTsHQge2IonJlDkuS46AAKoqiGAAEAQAdmr4kMtnuAA/D8TgAFAUBb1vVq5gJMi fA6C2ChrNIJAkByEg4CgABIEgOAAr0py2fAAG4bhyAAZ5nm2AEMyUb5vqwzCYo9j1DrOJoACPrwA HhsIADpsld5Ds66lDtR/w/eJxbeABNbkAGInsooCgJWARA0CWOgNSUcpKtJ+JIABvHNT57x8ospb HsgABDyMowVKoryvLMtpi55TSGSZJqSpSLjGJYavENol6GBV1JFtC2KRxT0kIUJe7iWRkgAdh47s iQB97jONAAcnhAAZ3i7piVjgb5QACx5suy+h6ICj6ezdb63r+x7Pte37nu+97/wfD8VmFp8rIsns NVPGRysn4piPQTQ/IgyAHe1h3nfW2fIAGwbEDlrBZAEAAqoCAAAZAcAAHoFPVIigIRY/x8QRRCdE iwBW8AAVyEkqIjw3mlNOal8ZH32j9AAG8N4kAACcE4LQ8w+n3kRJASEMsMwADQhsqAx4AB+w7WQf Yhhsg+H1PsQ41gZIjQMhDEkiI1omD/HXE9WKsw7RTTUKIURhCyAVAAG6LgAD1lBXADkAAFoyAAA/ GeJBFxZxridFAcEbwACEjlEQrhFU4KSDgFYHjJgvscRsAR7ghxRjAbiLR244RzqCTmRE66NwzyPA ACKSR0jpgAApJdbS3A9SbAAD2TzDxcAAYSMEAA85TGAay11r4a5WMqZWACKYdlLgQAgAAEEt40xK l1LuXkvZfS/mBMGYUw5iLJHDMcf5ojog2mYQUTB4TXDXh1Dwv8l2fBjmxCWEyYExA0m9LkjKHBjD /GTOVW6gjgCJdA/si0lyghqDUFEAAew9hfOsAaQC63WkhVrFcRQikCNWIuq8AAdaDAAAPQkAARqG MCYGAERtER/xWivQYOoABPUZlEwmacJC/gbpAlRKtDo9iypNLCKgKqVTgmLMEbtLx/lKf3OkAAu6 bAAFjTkAAt6eHIOU71kDgZLSYCBUV5jzgiVJAAICpgAAS1PpYXR/o2B/t1eO3YL9WQAUvX2RlFBI QPFAhKFUHpNgmE5AYApQ5IpFmAKIeiEhVh0u1GQhEXyQh4j0ZKRpnLfTjBsqOFglQkRIgAEzYeqJ FhU2LH/DuEk5XbzRp8OcAC7ysRPHWUIpE1oognAACu0CkwXgvTME4JzPAOWJpbau1lrbXWvthbG2 Vs7aLDOSOcf4w7dNxbnYSwtVkHyhTCOYAFBKgAAAzckAALrmAAM8GaVQRwABouoACZgNrVFxHHds f6JB6gAGreFxzGGpmwI0/YAAJgTIsNkF534QgAQWny6wwpITzj6AAK8V4wgACCEEKBUg1n/kduS/ QUuB03JNX6BiM0aC3xrFmP8zA8QADIwsAAbOGXgvDHTh0AA7sQAAZjICLNnbP2huuAAHeK2ftAuz bW2gy8ZD/p4y2279XfVCs5UUIAAAg4/xeX94ozqqsSNMTUMOSSqjUGpHQopCz2hFBoCMAAXgjk5C EDPKiZH7lvRRKUer+xhjRNgK1IIABbDIGwS4d936hEeBjnE8R4wAGbAniJmIAKVAqyDjDP2f9AaB 0FoPQmhdDaHLneEauRW7XBm5cS4zvsC3LuaEvS2fS+1TH/DFEaJQu6fvBeIjxSCxgVb7QwnKuTQA +B8C7HDIJ9FuHkPK74vRejOKaKkXgABeC81wh/ChHqCYpEfsWTLJUmALAADfZmmNEbP2gWyN44B/ oMEs78KqtFbC225OttAStwX9v9B4mowtzLjDTs7aO692bt3du/eG8d5bz3Xh0dI/2Th+m1B1sjGN uC2bRKlLxoDvh5p3T2IG6t6MhICAgAAgUDgkFg0HhEJhULhkNh0PiERiUTikOZcXf6GjQAQsdACR kAAUsjAD0k0VlESBUrABIlwAOcxAAPmgAfE3AAJnQAFc9AMpoFBoVDolFo1HpFJpVLplNp1PqFRq VTqlVq1XrFZrVbrldr1fsFhsVjskpa1nf8rBU2nCJtwAVVxAD1ullBl3ABOvQAON9AFuRIAPODAA zw0/suJxWLxmNx1XWmRf72ygAyK0ABszQAf2dADd0AAZWjAD900NAWpAAk1mr1pV2AAFuzABS2wA I25AAw3mIx+/4HB4XD4nF43H5HJ5XL5nN53P6HR5y+6j/YvXACx7QAT3dADw8AAaHjADb82czwB9 UJBHtAA2+AAHHzAAH+wAOH5ABW/gAC7/gAHUBN86UCwNA8EOC0ZlH+zp/M+0MFtK06GNSATXBJDA ACVDkCQTD8QRDEURxJEsTRPFEUxVFcWRarhpRgf7wHg8TyPMbb0Qe9UPII9oEPe+L5hw+r7v+C8e RdJKxoCAAAAPAQAAAwAAAAECPwAAAQEAAwAAAAEBGwAAAQIAAwAAAAQAAPJWAQMAAwAAAAEABQAA AQYAAwAAAAEAAgAAAREABAAAAAYAAPJeARIAAwAAAAEAAQAAARUAAwAAAAEABAAAARYAAwAAAAEA OAAAARcABAAAAAYAAPJ2ARwAAwAAAAEAAQAAAT0AAwAAAAEAAgAAAVIAAwAAAAEAAQAAAVMAAwAA AAQAAPKOh3MABwAAERgAAPKWAAAAAAAIAAgACAAIAAAACAAAGdYAAERkAAB3wwAAm94AAPAbAAAZ zgAAKo4AADNfAAAkGwAAVD0AAAGAAAEAAQABAAEAABEYYXBwbAIAAABtbnRyUkdCIFhZWiAH1wAK AB4ACAAhAB5hY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGzb bt9XHU+yPvBaWZzTHhpuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5yWFlaAAABLAAA ABRnWFlaAAABQAAAABRiWFlaAAABVAAAABR3dHB0AAABaAAAABRjaGFkAAABfAAAACxyVFJDAAAB qAAAAA5nVFJDAAABuAAAAA5iVFJDAAAByAAAAA52Y2d0AAAB2AAABhJuZGluAAAH7AAABj5kZXNj AAAOLAAAAGRkc2NtAAAOkAAAAi5tbW9kAAAQwAAAAChjcHJ0AAAQ6AAAAC1YWVogAAAAAAAAYAAA ADXEAAAHKlhZWiAAAAAAAABvkQAAs2MAABjyWFlaIAAAAAAAACdEAAAW8wAAswlYWVogAAAAAAAA 81IAAQAAAAEWz3NmMzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsY3Vy dgAAAAAAAAABAc0AAGN1cnYAAAAAAAAAAQHNAABjdXJ2AAAAAAAAAAEBzQAAdmNndAAAAAAAAAAA AAMBAAACAAAAKQCQASABugJ2A1AERQVhBpQH3QlBCroMOQ3BD1cQ6BJ2E/4VeRbmGEoZmxrkHBUd Nh5aH3kgmCG4Itkj/yUiJkYnaiiQKbsq5SwQLUMuci+lMNsyDzNJNIU1xDcAOEU5gzq/O+s9ET46 P1pAe0GgQsVD5kUKRi5HUUhxSZJKtkvYTPtOHE86UFlRfVKcU7tU2lX6Vx1YRFlvWqJb1F0FXjRf ZGCRYcFi8mQiZVVmj2fEaP1qO2t/bL5uBW9PcJ1x7nNDdJV18HdAeGJ5bHpye3l8g32Gfot/ioCM gYeCfYN4hGiFVYZChymIDYjsiceKoYt1jEqNGo3njrOPgJBWkS2SBJLbk7KUiJVeljKXB5fdmLOZ iZphmzicD5znncGenJ94oFWhNKIUovWj1aS4pYymVqcjp/KowKmNqlyrK6v4rMetmK5orzqwCrDa sayyfbNOtCC08rXFtpS3Y7gzuQO50LqQu028CLzEvYK+QL7/v77AfME9wgDCwsOFxEzFE8XbxqXH ccg9yQvJ28qty4DMU80lzfTOvs+I0FHRGdHi0q7Td9Q/1QrV1dag12zYOdkH2dXapNt03ETdFd3p 3rrfj+Bj4TbiDeLq48LkleVl5jHm++fJ6JTpY+o26w3r6OzR7cbuxu/Y8P/yQvOZ9Qr2pPhc+kb8 Zf6S//8AAABBAOQBcQIXAtMDtwSwBccG9wg9CZULBgx1DfQPfREAEoIT/hVuFs8YKhl4Grcb5h0G HigfSCBkIYEioSPFJOQmBicoKEYpbyqTK7gs4y4OLzcwZDGOMr4z8DUkNlM3iji8Oes7CDwdPTU+ SD9YQG5Bg0KWQ6pEvUXPRuFH8kkGShhLKUw6TUlOV09qUHdRhFKSU6FUsVXGVuJYAlkjWkNbYVyB XZ9evl/fYP9iIWNKZG9ll2bDZ/RpImpVa41sxm4Db0NwfnHEcvx0FXUcdh93I3gneSh6KHsnfCZ9 In4afxOACYD8ge6C3oPNhLiFn4aKh22IU4k2iheK94vTjKuNhY5bjzOQDJDmkcCSmpNylFCVLZYM luyXzJiumY+adZtbnEOdK54WnwKf7qDaocaioqNtpD2lEKXjprWnjKhgqTWqDarlq76smq1yrkuv Ja//sNmxsLKKs2O0OLUMteC2tLeIuF65M7oGuti7rLx/vVO+Jb73v8rAncFuwkDDFMPnxLnFjcZh xzXICsjfybXKjctkzD/NJM4TzwPP8tDd0cjStNOc1IPVatZS1znYH9kH2e/a2NvC3K/dm96L333g b+Fl4lvjUuRL5UbmROdB6D/pQ+pK61LsXO1q7nrvj/Co8cDy2vP39Rr2PPdf+IP5q/rS+/f9Hv4/ /0H//wAAABsAXgDDATYBrgI+AuQDmgRjBT4GKgccCBkJGgoiCyQMLA0rDiQPEg/7ENoRrhJ2EzgT +RS1FXIWMBbvF68YbhkuGfAasxt2HDsdAR3MHpYfYSAvIPshzCKfI3IkRSUeJfMmwSeEKD4o+im0 Km4rKyvoLKYtZi4mLucvqDBqMTEx9TK6M4A0RjULNdQ2mzdhOCg48Dm4On87RjwQPNo9pD5uPzdA AUDMQZdCY0MwRABEzkWdRm9HREgUSOhJvUqUS2tMRE0bTfROyU+VUFxRI1HsUrZTglRRVR5V8FbC V5ZYb1lGWiFa/1vfXMBdoV6DX2lgTGE1YhtjAWPoZMplqGaGZ2FoQGkfaf9q4GvBbKFthm5rb09w N3EecgZy7nPXdMJ1rHaYd4R4cXlfekl7MXwBfMR9g35FfwN/wIB/gTiB8oKsg2eEIoTdhZiGU4cP h82IjIlKiguKzouQjFKNF43cjqGPWpATkMuRhJJBkwCTwZSElUmWEpbfl66Yf5lZmjObEJvwnNSd up6jn4+gfaFvomGjTqQypRCl6qbFp6Gofqlfqj+rIKwDrOmtzq6zr56wh7FwsluzRbQwtRu2Brbw t9y4xbmuup67wLzkvgG/GcAzwVPCecOoxOLGKsd/yOzKcMwHzb/PpNG00/fWedla3J7gk+VO66T1 Sv//AABuZGluAAAAAAAABjYAAJkCAABWyAAAVQQAAJGwAAAnkQAAFWAAAFANAABUOQACCj0AAfrh AAEmZgADAQAAAgAAABMALABFAF8AeACRAKsAxQDfAPkBFAEwAUwBagGHAaYBxgHnAgoCLgJUAnwC pwLTAwMDNQNqA6UD5AQkBGcErATzBTsFhQXPBhwGaga6BwwHXQewCAUIWwiwCQgJYQm6ChQKcQrN CyoLhwvmDEcMpg0JDWwN1Q5EDrUPJg+cEBQQixEEEX8R/RJ6EvoTexP/FIUVChWRFhsWpRcyF8IY UxjiGXYaCxqiGzob0xxsHQQdnB4xHscfYB/6IJchNCHUInQjFCO2JFok/SWdJkIm5yeLKC4ozyl1 KhkquyteLAAsoi1ELeYuiy8sL84wejFEMh0y+TPXNLM1mDZ7N2c4UTlDOj07Mzw2PT8+Sj9gQHtB okLMRAJFOUZ+R8hJEkpRS5BM1E4ZT2JQrVH+U09UoVX3V0pYo1n9W1VcrV4GX19gt2IPY2xkw2Y3 Z8FpQmrIbFNt2m9pcPhyhXQVdaV3PHjRemp8A32gfzuA4YKJhDKF4IexiY+Lc41SjzORFJL7lNqW vZiemnicV54woAih36O0pYanVqkpqwes8q7jsNiy0rTEtsK4v7q5vLi+tcCywq/ErcaqyKnKocyj zpzQntKd1IrWh9iS2qzc0t7v4RnjM+VC50fpMOr/7LvuW+/h8UvypvPw9Sn2Svdi+G75aPpX+zb8 EPze/aT+l///AAAADAAjADwAVABuAIcAoQC7ANYA8QEMASkBRgFkAYIBogHDAeUCCQIuAlUCfwKr AtkDCQM9A3QDsAPwBDEEdAS6BQIFSwWVBeAGLwZ+Bs8HIwd1B8oIIgh5CNEJKwmHCeMKQgqhCwAL YQvCDCcMigzwDVgNww44DrAPKA+kECMQoREhEaQSKBKuEzYTwBRMFNoVaBX5FowXIRe5GFMY6xmJ GigayRtrHA4csR1SHfEekB8xH9QgeSEfIccicCMaI8UkciUeJcgmdickJ9IofSkqKdoqhyszK+As jC05LeUuli9BL/AwrTGBMl4zPjQfNQE16TbRN744qzmgOpg7kDyRPZM+mz+lQLVBzkLkRAVFJEZM R3dIpknjSx5MYk2jTuZQK1FxUr1UAVVKVpFX2lkiWm5btFz8XkRfjGDTYhljZWSsZhJnmWkUapBs EW2Mbw5wjnIMc4x1CXaPeBR5m3sjfLR+QH/TgXCDEISyhlWH94mgi0+M/I6tkGCSGpPRlYyXTpkM msyck55WoByh5KOspXSnOqkFqsKsY64Cr6exUrMCtK+2abglueG7n71kvyTA6MKqxG7GK8fvyajL Y80dztLQi9JA0/fVptdX2Qzaudxg3gXfreFP4u3kiuYg57LpSurf7HDt+++I8RbypfQw9bj3R/jW +mT7/f2O//8AAAAdAEQAagCRALgA3wEIATIBXgGLAbwB7gIkAl4CngLiAywDfwPcBD4EpgUSBYEF 8wZqBuMHXwfeCGAI4QlnCe4KeQsDC48MIAyvDUMN4Q6SD0UP/hC4EXQSMxL0E7cUfhVDFg0W2Beo GHoZTBolGv8b2xy6HZ8egh9oIFEhPiItIx0kESUFJfgm8SfpKN8p3SrXK9Qs0S3PLtIv0zDkMgQz JzRINWs2izevOM458jsOPC89TT5pP4VAokHCQt1D/kUaRj1HYEiFSbhK7UwpTWFOmk/VURBSUVOM VMlWCVdEWIVZxlsIXEldjF7QYBVhWmKgY+5lQmbRaHJqD2u8bWZvH3DZcpR0UnYUd9l5nHtcfSJ+ 3oChgmSEJIXmh8eJsIubjXuPWJEwkwaUzpaVmFaaB5u6nWefDqCyolKj76WIpx6otKpZrBWt3q+o sXSzPbUAtsm4j7pQvBK92L+UwVfDGMTaxp7IZcooy/TNu8+L0V7TItSU1gnXidkT2p7cJN2j3xvg i+Hx40zkneXj5xjoQOli6nvrg+yF7XLuXe838A/w1/Gf8lfzDvO79Fj09vWL9hf2o/co95z4D/iD +PH5Uvm0+hb6ePrK+xP7XPul++78N/x2/Kb81f0F/TT9ZP2T/cP98/4i/k/+ev6l/tD++/8n/1L/ ff+o/9T//wAAZGVzYwAAAAAAAAAKQ29sb3IgTENEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMA AAAAAAAAEAAAAAxpdElUAAAAFAAAANBmckZSAAAAQgAAAORuYk5PAAAAEgAAASZlc0VTAAAAEgAA AThmaUZJAAAAEAAAAUpwdFBUAAAAGAAAAVp6aFRXAAAADgAAAXJqYUpQAAAADgAAAYBubE5MAAAA FgAAAY5kZURFAAAAEAAAAaRydVJVAAAAJAAAAbRrb0tSAAAADAAAAdhlblVTAAAAEgAAAeRzdlNF AAAAEAAAAfZkYURLAAAAHAAAAgZ6aENOAAAADAAAAiIATABDAEQAIABjAG8AbABvAHIAaQDJAGMA cgBhAG4AIADgACAAYwByAGkAcwB0AGEAdQB4ACAAbABpAHEAdQBpAGQAZQBzACAAYwBvAHUAbABl AHUAcgBGAGEAcgBnAGUALQBMAEMARABMAEMARAAgAGMAbwBsAG8AcgBWAOQAcgBpAC0ATABDAEQA TABDAEQAIABjAG8AbABvAHIAaQBkAG9faYJybbJmdphveTpWaDCrMOkw/AAgAEwAQwBEAEsAbABl AHUAcgBlAG4ALQBMAEMARABGAGEAcgBiAC0ATABDAEQEJgQyBDUEQgQ9BD4EOQAgBBYEGgAtBDQE OARBBD8EOwQ1BDnO7LfsACAATABDAEQAQwBvAGwAbwByACAATABDAEQARgDkAHIAZwAtAEwAQwBE AEwAQwBEAC0AZgBhAHIAdgBlAHMAawDmAHIAbV9pgnIAIABMAEMARAAAbW1vZAAAAAAAAAYQAACc ZwAAAADBtMUAAAAAAAAAAAAAAAAAAAAAAHRleHQAAAAAQ29weXJpZ2h0IEFwcGxlIENvbXB1dGVy LCBJbmMuLCAyMDA1AAAAAA== --Apple-Mail-19--639659218 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Note that the assisting peer and indirect peer can be (hence the box around the two) provided by the same third party (but this has never been a requirement) The point is that the Assisting peer really is just there for the full resolution of SED. Once this is done the actual signaling and possibly media are handed over to the indirect peer (if needed) Now for some specific comments... On page 4 - Location server - this definition fits more for a "lookup Server". Lookup resolves an "owner", Location resolves a SED. On Page 4 - I still see many "?" in the text - probably needs to be quotation marks? In the definition of 4.1 (page 6) The LUF should be defined as a mapping of identifiers (ususally e.164 numbers - NOT necessarily a SIP username) and associated responsible domain In the definition of 4.2 - isn't the result of this query just the SED? 5.1.1 (page 8) - Between step 2 and 3 missing the location function where lookup information is converted to SED information 5.1.2 (Page 10) the text for step 2 is correct ("This look-up traverses the administrative boundary between the originating and the assisting domain") but the diagram shows this as the "transit domain" 5.1.2 step 3 - "The result will be the address of the TRANSIT SBE" not assisting... 5.1.2.3 Please refer to the figure above. This is where I sense the largest amount of confusion. The box that is labeled "Assisted SSP" is in reality the box I have above containing both Assisted Peer and Indirect Peer. While this may seem semantic it is crucial to get right as these two functions may be provided by different entities and are mutually exclusive. D. --Apple-Mail-19--639659218 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --Apple-Mail-19--639659218-- From speermint-bounces@ietf.org Mon Dec 03 15:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHnq-0005jV-Vf; Mon, 03 Dec 2007 15:22:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHnp-0005j4-Q9 for speermint@ietf.org; Mon, 03 Dec 2007 15:22:05 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzHnp-0005Fl-7b for speermint@ietf.org; Mon, 03 Dec 2007 15:22:05 -0500 Received: from [130.129.19.166] (dhcp-13a6.ietf70.org [130.129.19.166]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1IzHno0kcw-0003MZ; Mon, 03 Dec 2007 21:22:04 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <910C9905-1131-4C54-9805-3F685866C267@xconnect.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: speermint@ietf.org From: David Schwartz Date: Mon, 3 Dec 2007 12:20:45 -0800 X-Mailer: Apple Mail (2.752.3) X-Provags-ID: V01U2FsdGVkX19L3nd/K6Wnx5NaZqbu+Rt/XMAjfls8KVo5ALV hLC7h5QSTsdQvFUtzD1stph1xvHo1/zilM8RgCkwwA3qAy/Wm7 cQg1zoa7cAxY/riUe4+ng== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Speermint] Some quick comments on Use Cases 04 - sorry but I seem to have some issues with my email today :( X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org (This got cut off from my previous email...) Note that the assisting peer and indirect peer can be (hence the box around the two) provided by the same third party (but this has never been a requirement) The point is that the Assisting peer really is just there for the full resolution of SED. Once this is done the actual signaling and possibly media are handed over to the indirect peer (if needed) Now for some specific comments... On page 4 - Location server - this definition fits more for a "lookup Server". Lookup resolves an "owner", Location resolves a SED. On Page 4 - I still see many "?" in the text - probably needs to be quotation marks? In the definition of 4.1 (page 6) The LUF should be defined as a mapping of identifiers (ususally e.164 numbers - NOT necessarily a SIP username) and associated responsible domain In the definition of 4.2 - isn't the result of this query just the SED? 5.1.1 (page 8) - Between step 2 and 3 missing the location function where lookup information is converted to SED information 5.1.2 (Page 10) the text for step 2 is correct ("This look-up traverses the administrative boundary between the originating and the assisting domain") but the diagram shows this as the "transit domain" 5.1.2 step 3 - "The result will be the address of the TRANSIT SBE" not assisting... 5.1.2.3 Please refer to the figure above. This is where I sense the largest amount of confusion. The box that is labeled "Assisted SSP" is in reality the box I have above containing both Assisted Peer and Indirect Peer. While this may seem semantic it is crucial to get right as these two functions may be provided by different entities and are mutually exclusive. D. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 17:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJNj-00085w-7c; Mon, 03 Dec 2007 17:03:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJNi-00085r-3b for speermint@ietf.org; Mon, 03 Dec 2007 17:03:14 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJNh-0000tG-PL for speermint@ietf.org; Mon, 03 Dec 2007 17:03:14 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JSH00356ULCUS@siemenscomms.co.uk> for speermint@ietf.org; Mon, 03 Dec 2007 22:03:12 +0000 (GMT) Date: Mon, 03 Dec 2007 22:03:10 +0000 From: "Elwell, John" To: speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04913F9@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comment on requirements-03 Thread-Index: Acg1+EqcXDt0AaWZTGeA+bG+W5znBA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Speermint] Comment on requirements-03 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org During this afternoon's SPEERMINT session, open issues were posted concerning a couple of comments that I made some weeks ago. Just to clarify those comments: It states in 3.1: "advertisement and management of ingress and egress for session signaling and media". This issue of advertising is then elaborated further in the document. I can understand the need to advertise the ingress for signalling - that is a fundamental part of peering.=20 Why does an SSP need to advertise its signalling egress? Why does an SSP need to advertise its media ingress and egress (other than what it indicates in SDP offer/answer)? John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 20:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMzn-0005Xh-1d; Mon, 03 Dec 2007 20:54:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMzl-0005XU-Ng for speermint@ietf.org; Mon, 03 Dec 2007 20:54:45 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzMzl-0007Si-CG for speermint@ietf.org; Mon, 03 Dec 2007 20:54:45 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JSI00H1G5B8N5@siemenscomms.co.uk> for speermint@ietf.org; Tue, 04 Dec 2007 01:54:44 +0000 (GMT) Date: Tue, 04 Dec 2007 01:54:44 +0000 From: "Elwell, John" In-reply-to: <9AAEDF491EF7CA48AB587781B8F5D7C695C43E@srvxchg3.cablelabs.com> To: Jean-Francois Mule Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04913FE@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comments on Requirements-03 Thread-Index: AcgsZjfSV1bztBsHTWmO5MhpimN6KwJOIxSAABs/M3A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: A <0D5F89FAC29E2C41B98A6A762007F5D0441600@GBNTHT12009MSX.gb002.siemens.net> <9AAEDF491EF7CA48AB587781B8F5D7C695C43E@srvxchg3.cablelabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org Subject: [Speermint] RE: Comments on Requirements-03 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois, See below. > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: 03 December 2007 11:29 > To: Elwell, John > Cc: speermint@ietf.org > Subject: RE: Comments on Requirements-03 >=20 > John, >=20 > Thx for the comments. See inline. >=20 > Jean-Francois. >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Wednesday, November 21, 2007 10:45 AM > > To: speermint@ietf.org; Jean-Francois Mule > > Subject: Comments on Requirements-03 > >=20 > > Jean-Francois, > >=20 > > I am now a lot happier about the way the requirements in=20 > section 3 are > > formulated (in terms of "protocol mechanisms must...". Thanks. > >=20 > > I haven't done a complete review, but I happened to notice the > > following: > >=20 > > 1. "Requirement #1: protocol mechanisms must exist for SSPs to > > communicate the egress and ingress points of its service > > domain." > > Why do ingress points need to be advertised? > >=20 [JRE] My mistake. I meant why do egress points need to be advertised. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 20:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN1k-0006Tb-8z; Mon, 03 Dec 2007 20:56:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzN1i-0006TM-L8 for speermint@ietf.org; Mon, 03 Dec 2007 20:56:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzN1i-0005QO-50 for speermint@ietf.org; Mon, 03 Dec 2007 20:56:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2007 20:56:46 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB41ujug009632; Mon, 3 Dec 2007 20:56:45 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB41uOBg004510; Tue, 4 Dec 2007 01:56:41 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 20:56:29 -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 Subject: RE: [Speermint] Comment on requirements-03 Date: Mon, 3 Dec 2007 20:56:50 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E303FF6BBB@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04913F9@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Comment on requirements-03 Thread-Index: Acg1+EqcXDt0AaWZTGeA+bG+W5znBAAIGQug References: <0D5F89FAC29E2C41B98A6A762007F5D04913F9@GBNTHT12009MSX.gb002.siemens.net> From: "Michael Hammer (mhammer)" To: "Elwell, John" , X-OriginalArrivalTime: 04 Dec 2007 01:56:29.0351 (UTC) FILETIME=[E2E01370:01C83618] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1306; t=1196733405; x=1197597405; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20(mhammer)=22=20 |Subject:=20RE=3A=20[Speermint]=20Comment=20on=20requirements-03 |Sender:=20 |To:=20=22Elwell, =20John=22=20, =20; bh=bxb1y4TdLWwy4rDjSD0pHNxswvlv/nDtTPP1FwQZ7WU=; b=IEH0lrU3hEqhTei3bzI7ajlr2YU3yT+YJ3KqGzXWIOROrJXoKqo8CywXvs8KAdRrR4akMPdb /kNkLvKq9w5Q3aeoTd9g0iDlANm2wUBo3KgDeGmnjZvE6TeWDfedAyEF; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, Was that perhaps an oblique reference to the need to put an address in the SDP of a Session Border Controller in the outgoing SIP message? I am not sure we need to redefine how SIP and SDP works. Mike =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, December 03, 2007 5:03 PM > To: speermint@ietf.org > Subject: [Speermint] Comment on requirements-03 >=20 > During this afternoon's SPEERMINT session, open issues were=20 > posted concerning a couple of comments that I made some weeks=20 > ago. Just to clarify those comments: >=20 > It states in 3.1: > "advertisement and management of ingress and egress > for session signaling and media". > This issue of advertising is then elaborated further in the document. >=20 > I can understand the need to advertise the ingress for=20 > signalling - that is a fundamental part of peering.=20 >=20 > Why does an SSP need to advertise its signalling egress? >=20 > Why does an SSP need to advertise its media ingress and=20 > egress (other than what it indicates in SDP offer/answer)? >=20 > John >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 03 21:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNYQ-0006kU-Rk; Mon, 03 Dec 2007 21:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNYQ-0006kK-0x for speermint@ietf.org; Mon, 03 Dec 2007 21:30:34 -0500 Received: from mmail.voxeo.com ([66.193.54.208] helo=voxeo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzNYP-00009M-Kx for speermint@ietf.org; Mon, 03 Dec 2007 21:30:34 -0500 Received: from [130.129.86.77] (account rj [130.129.86.77] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.12) with ESMTPSA id 25148133 for speermint@ietf.org; Tue, 04 Dec 2007 02:30:34 +0000 Message-Id: From: RJ Auburn To: speermint@ietf.org Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 3 Dec 2007 21:30:31 -0500 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Speermint] newbie question on draft-ietf-speermint-srv-naptr-use X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092780014==" Errors-To: speermint-bounces@ietf.org --===============0092780014== Content-Type: multipart/alternative; boundary=Apple-Mail-14--615100673 --Apple-Mail-14--615100673 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, As a newbie to speermint can someone give me a quick outline of what srv-naptr-use[1] specifies above and beyond RFC 3263? Looking over the spec it was not clear what it exactly specified beyond describing the use of 3263 in a peering environment. Thanks in advance for your patience with someone who is still trying to get fully up to speed. Thanks, RJ [1] http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-02.txt [2] http://www.ietf.org/rfc/rfc3263.txt --Apple-Mail-14--615100673 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Folks,

As a newbie to speermint = can someone give me a quick outline of what srv-naptr-use[1] = specifies above and beyond RFC 3263? Looking over the spec it was = not clear what it exactly specified beyond describing the use of 3263 in = a peering environment. 

Thanks in advance for = your patience with someone who is still trying to get fully up = to speed. 

Thanks,

=
= RJ


= --Apple-Mail-14--615100673-- --===============0092780014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0092780014==-- From speermint-bounces@ietf.org Mon Dec 03 21:32:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNa0-0000rz-LM; Mon, 03 Dec 2007 21:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzNZz-0000rp-5q for speermint@ietf.org; Mon, 03 Dec 2007 21:32:11 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzNZx-0000IP-Jh for speermint@ietf.org; Mon, 03 Dec 2007 21:32:11 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JSI00J0U6JXDO@siemenscomms.co.uk> for speermint@ietf.org; Tue, 04 Dec 2007 02:21:33 +0000 (GMT) Date: Tue, 04 Dec 2007 02:21:31 +0000 From: "Elwell, John" Subject: RE: [Speermint] Comment on requirements-03 In-reply-to: A <072C5B76F7CEAB488172C6F64B30B5E303FF6BBB@xmb-rtp-20b.amer.cisco.com> To: "Michael Hammer (mhammer)" , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0491400@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] Comment on requirements-03 Thread-Index: Acg1+EqcXDt0AaWZTGeA+bG+W5znBAAIGQugAADYNIA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D04913F9@GBNTHT12009MSX.gb002.siemens.net> A <072C5B76F7CEAB488172C6F64B30B5E303FF6BBB@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, Certainly not. I was just pointing out that SDP will indicate where media terminates - whether that be an SBC or the endpoint. I fail to see the need for any other advertisement. John > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: 04 December 2007 01:57 > To: Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] Comment on requirements-03 >=20 > John, >=20 > Was that perhaps an oblique reference to the need to put an address in > the SDP of a Session Border Controller in the outgoing SIP message? >=20 > I am not sure we need to redefine how SIP and SDP works. >=20 > Mike > =20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Sent: Monday, December 03, 2007 5:03 PM > > To: speermint@ietf.org > > Subject: [Speermint] Comment on requirements-03 > >=20 > > During this afternoon's SPEERMINT session, open issues were=20 > > posted concerning a couple of comments that I made some weeks=20 > > ago. Just to clarify those comments: > >=20 > > It states in 3.1: > > "advertisement and management of ingress and egress > > for session signaling and media". > > This issue of advertising is then elaborated further in the=20 > document. > >=20 > > I can understand the need to advertise the ingress for=20 > > signalling - that is a fundamental part of peering.=20 > >=20 > > Why does an SSP need to advertise its signalling egress? > >=20 > > Why does an SSP need to advertise its media ingress and=20 > > egress (other than what it indicates in SDP offer/answer)? > >=20 > > John > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 03:22:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzT2z-0001wF-UG; Tue, 04 Dec 2007 03:22:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzT2y-0001ge-3o for speermint@ietf.org; Tue, 04 Dec 2007 03:22:28 -0500 Received: from relay1.merlotrelay.com ([69.183.238.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzT2x-0000oG-M8 for speermint@ietf.org; Tue, 04 Dec 2007 03:22:28 -0500 Received: from [192.168.249.198] ([216.18.3.1]) by merlotrelay.com with MailEnable ESMTP; Tue, 04 Dec 2007 03:20:37 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: speermint@ietf.org From: David Schwartz Date: Tue, 4 Dec 2007 00:22:21 -0800 X-Mailer: Apple Mail (2.752.3) X-ME-Bayesian: 0.000000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Speermint] Some general comments... X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Folks Following yesterdays session a bunch of us sat down to try and close probably the assisted/indirect ambiguity. In the discussions it became apparent that underpinning this ambiguity is the general question of scope in SPEERMINT. If we look at the WG page we see the following... "The SPEERMINT work plan is related to and distinct from the work plans of the ENUM and SIPPING working groups. While the the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions." The terminology draft follows this line and reads (on Page 4)... " As illustrated in Figure 1, the ENUM Working Group is primarily concerned with the acquisition of SED while the SPEERMINT Working Group is focused on the use of such SED in routing session signaling requests" What emerges is that "the structure and lookup of data" [WG-PAGE] or "the acquisition of SED" [TERM] are out of scope but the "use of the resulting URI data" [WG-PAGE] or "The use of such SED" [TERM] are in scope. What exactly does "the use of the resulting URI data" mean? Don't we all agree that SED constitutes a routable SIP URI? isn't that just plain SIP at this point? You have a routable URI - you use it. you follow 3261 and send it on its merry way. To me, SPEERMINT is all about GETTING the routable URI - yes - the acquisition of SED. Not which protocol I use - that is for ENUM and SIP but the process, architecture, semantics, data models, associated policy, discovery, etc. What am I missing? D. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 04:42:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzUHx-0002ae-9L; Tue, 04 Dec 2007 04:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzUHv-0002Tp-C9 for speermint@ietf.org; Tue, 04 Dec 2007 04:41:59 -0500 Received: from pro22.abac.com ([66.226.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzUHt-0001Oz-4X for speermint@ietf.org; Tue, 04 Dec 2007 04:41:59 -0500 Received: from Jeremyb2 (bzq-79-180-59-51.red.bezeqint.net [79.180.59.51]) (authenticated bits=0) by pro22.abac.com (8.14.1/8.14.1) with ESMTP id lB49fp2j092925; Tue, 4 Dec 2007 01:41:53 -0800 (PST) (envelope-from jeremyb@digitalshtick.com) From: "Jeremy Barkan \(DigitalShtick\)" To: "'David Schwartz'" , References: Subject: RE: [Speermint] Some general comments... Date: Tue, 4 Dec 2007 11:41:40 +0200 Organization: DigitalShtick Message-ID: <003d01c83659$e11db970$6e01a8c0@Jeremyb2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg2TwVX0Cqhhd9VQIyk8NapVOjscgACr08w X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Forwarding on behalf of David Schwartz From: David Schwartz Date: December 4, 2007 1:05:44 AM PST (CA) To: speermint@ietf.org Subject: Assisted/Transit Hi In our post session meeting there was alot of discussion about the persistent ambiguity in the documents regarding this divide. Expanding on the orthogonality of the assisted peering function it became apparent that the assistance comprises the resolution step (i.e. the lookup function and the location function) or in other words the process of taking a potentially non routable identifier (e.164 OR AOR) and converting it (possibly applying some policy) to a routable URI. This "resolution" step when performed remotely gains the title "assisted". At this point some of the participants felt that if this is so than the term "peering" as associated with "assisted" is misleading for there is no peering per-say that traverses the assisted peer as in the case of transit or direct peers. Some alternatives were proposed with the main options being... 1. just include LUF and LF and in the architecture draft introduce a term (e.g. Resolution Function) that aggregates the two 2. Include a "Resolution Function" in the terminology draft to reduce ambiguity 3. Leave Assisted with the additional clarification that it encompasses only the LUF and LF We are planning on sitting again on Wednesday afternoon (Vancouver time) to continue discussion on these points so please provide any feedback by then. Thanks, D. -----Original Message----- From: David Schwartz [mailto:dschwartz@xconnect.net] Sent: Tuesday, December 04, 2007 10:22 AM To: speermint@ietf.org Subject: [Speermint] Some general comments... Hi Folks Following yesterdays session a bunch of us sat down to try and close probably the assisted/indirect ambiguity. In the discussions it became apparent that underpinning this ambiguity is the general question of scope in SPEERMINT. If we look at the WG page we see the following... "The SPEERMINT work plan is related to and distinct from the work plans of the ENUM and SIPPING working groups. While the the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions." The terminology draft follows this line and reads (on Page 4)... " As illustrated in Figure 1, the ENUM Working Group is primarily concerned with the acquisition of SED while the SPEERMINT Working Group is focused on the use of such SED in routing session signaling requests" What emerges is that "the structure and lookup of data" [WG-PAGE] or "the acquisition of SED" [TERM] are out of scope but the "use of the resulting URI data" [WG-PAGE] or "The use of such SED" [TERM] are in scope. What exactly does "the use of the resulting URI data" mean? Don't we all agree that SED constitutes a routable SIP URI? isn't that just plain SIP at this point? You have a routable URI - you use it. you follow 3261 and send it on its merry way. To me, SPEERMINT is all about GETTING the routable URI - yes - the acquisition of SED. Not which protocol I use - that is for ENUM and SIP but the process, architecture, semantics, data models, associated policy, discovery, etc. What am I missing? D. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 07:04:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzWVw-0008RR-9t; Tue, 04 Dec 2007 07:04:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzWVu-0008NU-Tf for speermint@ietf.org; Tue, 04 Dec 2007 07:04:34 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzWVs-0000qU-N8 for speermint@ietf.org; Tue, 04 Dec 2007 07:04:34 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1IzWVp-00011x-00; Tue, 04 Dec 2007 13:04:29 +0100 Date: Tue, 4 Dec 2007 13:04:29 +0100 From: Otmar Lendl To: David Schwartz Subject: Re: [Speermint] Some general comments... Message-ID: <20071204120429.GA3877@nic.at> Mail-Followup-To: Otmar Lendl , David Schwartz , speermint@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/12/04 09:12, David Schwartz wrote: > > Following yesterdays session a bunch of us sat down to try and close > probably the assisted/indirect ambiguity. That's what the IETF meetings are for. [reordered] > > What am I missing? The latest update to the terminology draft: > The terminology draft follows this line and reads (on Page 4)... " As > illustrated in Figure 1, the ENUM Working Group is primarily > concerned with the acquisition of SED while the SPEERMINT Working > Group is focused on the use of such SED in routing session signaling > requests" This changed in the last revision based on various feedback. The version Daryl sent to the reviewers contains: As illustrated in Figure 1, the ENUM Working Group is primarily concerned with identifying a SIP URI that corresponds to a given E.164 number, while the SPEERMINT Working Group is concerned with using that SIP URI to acquire the SED and on the use of such SED in routing session signaling requests. Importantly, the SIP URI can be derived from ENUM (i.e., an E.164 DNS entry) or via any other mechanism available to the user. Which make IMHO a lot more sense. ================================== Generally speaking, one of the problems here is the fact that "SIP URI" is an overloaded term. I've been bitching about this often enough in my comments on the list and in one of my drafts. (e.g. http://www.enum.at/ietf/draft-lendl-speermint-background-00.html#URI ) We really, *really* have to distinguish between a SIP Address of Record (AoR) which is the nice address you print on your business card and the trivially routable SIP URI. In the perfect end-to-end world, RFC 3263 can be used to directly map the AoR to the next hop SIP proxy. In the speermint context, this just isn't true. I'd even venture to say that this is the main reason for the existance of speermint. > If we look at the WG page we see the following... "The SPEERMINT work > plan is related to and distinct from the work plans of the ENUM and > SIPPING working groups. While the the ENUM Working Group is primarily > concerned with the structure and lookup of data for the translation > of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the > use of the resulting URI data, as well as non-ENUM-derived URI data, > for use in signaling and routing of real-time sessions." IMHO, the input into the speermint algorithm is always an AoR. The AoR is a "name". It defines who you want to reach, e.g. "sip:david@example.com". It's the same string regardless whom you give your business card to. Same for public ENUM: You don't know who will query your public DNS, so you can't tailor your answer to the querier. Thus the (public) ENUM step must return an AoR, and can't answer with a SIP URI which indicates a specific ingress point. (unless that's your one and only ingress point) The "URIs" quoted above are thus all AoRs. Maybe we should use different terms for the various kinds of SIP URIs. Daryl? Are you game for some more revisions? We're still not at -58. > Don't we all agree that SED constitutes a routable SIP URI? isn't > that just plain SIP at this point? You have a routable URI - you use > it. you follow 3261 and send it on its merry way. Agreed. I think with the update to the terminology draft it all makes a lot more sense. > To me, SPEERMINT is all about GETTING the routable URI - yes - the > acquisition of SED. Not which protocol I use - that is for ENUM and > SIP but the process, architecture, semantics, data models, associated > policy, discovery, etc. The trouble relying with ENUM for SED acquisition is that it's based on telephone numbers, whereas speermint also needs to cope with non-number based calling. Thus if we base all the tricky egress-ingress selection, peer-discovery, transit selection and capacity planning on ENUM (and thus numbers), then we fail to solve the problem for SIP-AoR based calling. Have a nice and productive week in Vancouver! /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 09:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzYpP-00037R-DK; Tue, 04 Dec 2007 09:32:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzYpO-000320-71 for speermint@ietf.org; Tue, 04 Dec 2007 09:32:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzYpN-0003MA-ML for speermint@ietf.org; Tue, 04 Dec 2007 09:32:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Dec 2007 09:32:49 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB4EWnWL003518; Tue, 4 Dec 2007 09:32:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB4EUG1K008087; Tue, 4 Dec 2007 14:32:49 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 09:32:40 -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 Subject: RE: [Speermint] Some general comments... Date: Tue, 4 Dec 2007 09:33:02 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E303FF6C59@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg2TwecZW0grJ8/Su64MYat4IRqKAAMexJA References: From: "Michael Hammer (mhammer)" To: "David Schwartz" , X-OriginalArrivalTime: 04 Dec 2007 14:32:40.0447 (UTC) FILETIME=[8627E8F0:01C83682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3151; t=1196778769; x=1197642769; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20(mhammer)=22=20 |Subject:=20RE=3A=20[Speermint]=20Some=20general=20comments... |Sender:=20 |To:=20=22David=20Schwartz=22=20, =20; bh=2yGA4jW4B0CJKivmHyIn/5Y056AlNroopDdUiOn2ig4=; b=keux9FX7g0zj/raaMZ8GH5Ep8dLJVHinWKdL2IHhl02nFQusYJW3BPalgc/53Ieppqe0zLmB 88KA3Fe2zAJHJCaT8P8kNQynXIiJmvV+HXEnXGmcPBECZkkhHdWrZJuS; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, At a high level, the answer to your question is whether the "call routing" is done via redirecting a SIP request hop by hop through many SP networks and their proxies to the terminating network and terminating end-user, or whether it is done by redirecting ENUM queries through a sequence of registries until the originating VoIP SP serving the caller can connect as directly as possible to the terminating VoIP SP serving the called user. In short, route through SP's/proxies or route through databases. I would contend that the latter is much more efficient and the reason for SPEERMINT. Minimize the middlemen. The use of registries also allows the application of some control over who learns what ingress to go through, as well as some load balancing and perhaps congestion control and perhaps some SPIT control. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:dschwartz@xconnect.net]=20 > Sent: Tuesday, December 04, 2007 3:22 AM > To: speermint@ietf.org > Subject: [Speermint] Some general comments... >=20 > Hi Folks >=20 > Following yesterdays session a bunch of us sat down to try=20 > and close probably the assisted/indirect ambiguity. In the=20 > discussions it became apparent that underpinning this=20 > ambiguity is the general question of scope in SPEERMINT. >=20 > If we look at the WG page we see the following... "The=20 > SPEERMINT work plan is related to and distinct from the work=20 > plans of the ENUM and SIPPING working groups. While the the=20 > ENUM Working Group is primarily concerned with the structure=20 > and lookup of data for the translation of E.164 numbers into=20 > URIs (RFC3761), SPEERMINT is concerned with the use of the=20 > resulting URI data, as well as non-ENUM-derived URI data, for=20 > use in signaling and routing of real-time sessions." >=20 > The terminology draft follows this line and reads (on Page=20 > 4)... " As illustrated in Figure 1, the ENUM Working Group is=20 > primarily concerned with the acquisition of SED while the=20 > SPEERMINT Working Group is focused on the use of such SED in=20 > routing session signaling requests" >=20 > What emerges is that "the structure and lookup of data"=20 > [WG-PAGE] or "the acquisition of SED" [TERM] are out of scope=20 > but the "use of the resulting URI data" [WG-PAGE] or "The use=20 > of such SED" [TERM] are in scope. What exactly does "the use=20 > of the resulting URI data" mean? =20 > Don't we all agree that SED constitutes a routable SIP URI?=20 > isn't that just plain SIP at this point? You have a routable=20 > URI - you use it. you follow 3261 and send it on its merry way. >=20 > To me, SPEERMINT is all about GETTING the routable URI - yes=20 > - the acquisition of SED. Not which protocol I use - that is=20 > for ENUM and SIP but the process, architecture, semantics,=20 > data models, associated policy, discovery, etc. >=20 > What am I missing? >=20 > D. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 10:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZlN-0002E8-65; Tue, 04 Dec 2007 10:32:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZlL-0002Dv-L9 for speermint@ietf.org; Tue, 04 Dec 2007 10:32:43 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzZlK-0002mo-OO for speermint@ietf.org; Tue, 04 Dec 2007 10:32:43 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1IzZlH-00014e-00; Tue, 04 Dec 2007 16:32:39 +0100 Date: Tue, 4 Dec 2007 16:32:39 +0100 From: Otmar Lendl To: Jean-Francois Mule Subject: Re: [Speermint] new version of draft-ietf-speermint-requirements Message-ID: <20071204153239.GC3877@nic.at> Mail-Followup-To: Otmar Lendl , Jean-Francois Mule , speermint@ietf.org References: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com> <20071120173032.GA22290@nic.at> <9AAEDF491EF7CA48AB587781B8F5D7C695C43D@srvxchg3.cablelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C695C43D@srvxchg3.cablelabs.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/12/03 12:12, Jean-Francois Mule wrote: > > I like the "SIP Route" you mentioned in Req.#5, and perhaps you > > should reference it here again, as the next SIP hop information > > and the request URI to use are the central components of the SED. > > I would prefer we keep using SED as the SIP Route is just a sub-set of > SED. Fine with me. > > >3.3.2. URI Reachability > > > > > > > > For example, an originating service provider must be able to > > > determine whether a SIP URI is open for direct interconnection > > > without requiring an SBE to initiate a SIP request. > > > > Hm? How can there be a direct interconnection without a SIP request? > That belongs to the solution space, may be it can be done, may be not > but it is a desirable requirement. Forget about my comment, I misread that sentence in the draft. Your text is fine. > > >4.5.2. Signaling Security and TLS Considerations > > > > > > 5. SIP and SBE servers involved in the session establishment > > over > > > TLS must verify and validate the client certificates: the > > client > > > certificate must contain a DNS or URI choice type in the > > > subjectAltName which corresponds to the domain asserted in the > > > host portion of the URI contained in the From header. It is > > also > > > recommended that VSPs/ASPs convey the domain identity in the > > > certificates using both a canonical name of the SIP server(s) > > and > > > the SIP URI for the domain as described in section 4 of > > > [I-D.gurbani-sip-domain-certs]. > > > > I'm not up-to-date familiar with the SIP / TLS standards, I just want > > to make sure that customer-owned domains in SIP URIs do not cause > > troubles here. > > Any txt to be added? Rereading this section, I'm not sure whether we're not once again mixing requirements for speermint with requirements / BCP for providers. Moving this detailed TLS discussion to the architecture draft might be a good idea. For the requirements draft, I think we need something much more basic along the lines of Requirement #X: The SIP signalling between peering partners needs to be secured, this includes * Mutual Authentication (e.g. through TLS certs) * Confidentiality * Integrity Requirement #X+1: The authentication scheme needs to cope with SSPs that run the SIP service for thousands of customer-owned domains. (In other words, it's not feasible that the TLS of the SBE contains all the domains its customers use.) Requirement #X+2: The authentication scheme needs to cope with transit, i.e. that one of the parties owns neither the domain in the From:, nor in the To: header. Requirement #X+3. The selection of a transit SSP must be secure. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 10:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZub-000082-Hr; Tue, 04 Dec 2007 10:42:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZua-0008V6-Eg for speermint@ietf.org; Tue, 04 Dec 2007 10:42:16 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzZuZ-0003Xh-Qk for speermint@ietf.org; Tue, 04 Dec 2007 10:42:16 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 413B328000303; Tue, 4 Dec 2007 16:42:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEz8-aChMwx8; Tue, 4 Dec 2007 16:42:15 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2709C28000302; Tue, 4 Dec 2007 16:42:00 +0100 (CET) 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 Subject: RE: [Speermint] new version of draft-ietf-speermint-requirements Date: Tue, 4 Dec 2007 16:41:58 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF391CA6@mx1.office> In-Reply-To: <20071204153239.GC3877@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] new version of draft-ietf-speermint-requirements Thread-Index: Acg2ivhEhhL+PWI+QwS2ZI++YipBNQAAEkng References: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com><20071120173032.GA22290@nic.at><9AAEDF491EF7CA48AB587781B8F5D7C695C43D@srvxchg3.cablelabs.com> <20071204153239.GC3877@nic.at> From: "Saverio Niccolini" To: "Otmar Lendl" , "Jean-Francois Mule" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dear Otmar and all, =20 > Rereading this section, I'm not sure whether we're not once=20 > again mixing requirements for speermint with requirements /=20 > BCP for providers. Moving this detailed TLS discussion to the=20 > architecture draft might be a good idea. I think we need to define the bounds and decide what goes into Reqirements/Architecture/BCPs Yesterday we discussed that BCPs for security (you are now talking about security requirements) should go into a separate BCP draft while all the requirements that can references as standard work should go into the requirements Now it seems you are suggesting to detail some BCPs in the architecture=20 draft. Should not the architecture draft describe architecture and (maybe) some examples, but not turn to be a BCP-type of document? I would like to have a clarification on this and opinions from the group. Cheers, Saverio >=20 > For the requirements draft, I think we need something much=20 > more basic along the lines of >=20 > Requirement #X: The SIP signalling between peering partners=20 > needs to be secured, this includes > * Mutual Authentication (e.g. through TLS certs) > * Confidentiality > * Integrity >=20 > Requirement #X+1: The authentication scheme needs to cope=20 > with SSPs that run the SIP service for thousands of=20 > customer-owned domains. >=20 > (In other words, it's not feasible that the TLS of the SBE=20 > contains all the domains its customers use.) >=20 > Requirement #X+2: The authentication scheme needs to cope=20 > with transit, i.e. that one of the parties owns neither the=20 > domain in the From:, nor in the To: header. >=20 > Requirement #X+3. The selection of a transit SSP must be secure. >=20 > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: -=20 > 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft=20 > m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division=09 Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 11:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izakp-0008Ch-A1; Tue, 04 Dec 2007 11:36:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izakn-00083H-Vl for speermint@ietf.org; Tue, 04 Dec 2007 11:36:14 -0500 Received: from cmsout01.mbox.net ([165.212.64.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izaki-0008Kx-G9 for speermint@ietf.org; Tue, 04 Dec 2007 11:36:08 -0500 Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by cmsout01.mbox.net (Postfix) with ESMTP id 6FACF5117; Tue, 4 Dec 2007 16:36:02 +0000 (GMT) Received: from cmsapps05.cms.usa.net [165.212.11.128] by cmsout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID041LLDqKD5857X01; Tue, 04 Dec 2007 16:36:03 -0000 X-USANET-Source: 165.212.11.128 IN richard@stastny.com cmsapps05.cms.usa.net X-USANET-MsgId: XID041LLDqKD5857X01 Received: from richard-stastnys-computer.local [62.47.140.58] by cmsapps05.cms.usa.net (ESMTPA/stastny@usa.net) via mtad (C8.MAIN.3.40I) with ESMTPA id 635LLDqKa0084M28; Tue, 04 Dec 2007 16:36:00 -0000 X-USANET-Auth: 62.47.140.58 AUTH stastny@usa.net richard-stastnys-computer.local Message-ID: <475581E4.3050901@stastny.com> Date: Tue, 04 Dec 2007 17:35:48 +0100 From: Richard Stastny User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Otmar Lendl , David Schwartz , speermint@ietf.org Subject: Re: [Speermint] Some general comments... References: <20071204120429.GA3877@nic.at> In-Reply-To: <20071204120429.GA3877@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Z-USANET-MsgId: XID635LLDqKa0084X28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar Lendl wrote: > > The trouble relying with ENUM for SED acquisition is that it's based on > telephone numbers, whereas speermint also needs to cope with non-number > based calling. Thus if we base all the tricky egress-ingress selection, > peer-discovery, transit selection and capacity planning on ENUM (and > thus numbers), then we fail to solve the problem for SIP-AoR based calling. > > Amen ENUM is for resolving E.164 numbers to AoRs RFC3263 and/or SPEERMINT is for resolving AoRs to ingress points One could use private ENUM to resolve to ingress points directly, but even GSMA is currently not going down this path, because: RFC3263 and/or SPEERMINT must be able to work with AoRs directly also This is what I said one year ago Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 04 13:01:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc5Z-0001gR-3d; Tue, 04 Dec 2007 13:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc5X-0001fR-ED for speermint@ietf.org; Tue, 04 Dec 2007 13:01:43 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izc5X-0004Qj-5w for speermint@ietf.org; Tue, 04 Dec 2007 13:01:43 -0500 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JSJ00GGGE2UQG@firewall.verizonbusiness.com> for speermint@ietf.org; Tue, 04 Dec 2007 18:01:42 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([127.0.0.1]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JSJ00GWEE2TK7@dgismtp03.mcilink.com> for speermint@ietf.org; Tue, 04 Dec 2007 18:01:42 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JSJ00FJAE2PRL@dgismtp03.mcilink.com> for speermint@ietf.org; Tue, 04 Dec 2007 18:01:41 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.2]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 04 Dec 2007 18:01:40 +0000 Date: Tue, 04 Dec 2007 18:01:40 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Some general comments... In-reply-to: To: speermint@ietf.org Message-id: <092B2658AAB56A4D80836399A4C4703101FE8DE3@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Speermint] Some general comments... Thread-index: Acg2Twp/771Q0Nd4QaGb0BP1YVcd+gATPyOQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-OriginalArrivalTime: 04 Dec 2007 18:01:40.0856 (UTC) FILETIME=[B8D27780:01C8369F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, Personally I think the problem is the notion that we're constrained to a BCP. Anything non-trivial that this group might do would go beyond a BCP as I understand that term. Setting that aside for the moment, I would agree that we care about as you say, "getting" the data (SED). I would add that we care also about the semantics of the data - what does it represent? Perhaps that's the same thing as you mean by referring to data models. Tim > To me, SPEERMINT is all about GETTING the routable URI - yes - the =20 > acquisition of SED. Not which protocol I use - that is for ENUM and =20 > SIP but the process, architecture, semantics, data models,=20 > associated =20 > policy, discovery, etc. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Dec 05 14:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzVP-00070G-GP; Wed, 05 Dec 2007 14:01:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzVM-0006yM-SK for speermint@ietf.org; Wed, 05 Dec 2007 14:01:56 -0500 Received: from mail164.messagelabs.com ([216.82.253.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzzVL-0007mq-So for speermint@ietf.org; Wed, 05 Dec 2007 14:01:56 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-2.tower-164.messagelabs.com!1196881314!8585044!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.107] Received: (qmail 17179 invoked from network); 5 Dec 2007 19:01:54 -0000 Received: from unknown.level3.net (HELO f10cc8-10.level3.com) (209.245.18.107) by server-2.tower-164.messagelabs.com with SMTP; 5 Dec 2007 19:01:54 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10cc8-10.level3.com (Postfix) with ESMTP id 0A9F033A6; Wed, 5 Dec 2007 19:01:54 +0000 (GMT) Subject: Re: [Speermint] Some general comments... From: Daryl Malas To: Otmar Lendl In-Reply-To: <20071204120429.GA3877@nic.at> References: <20071204120429.GA3877@nic.at> Content-Type: text/plain Date: Wed, 05 Dec 2007 12:12:50 -0700 Message-Id: <1196881970.7806.11.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Comment in-line... On Tue, 2007-12-04 at 13:04 +0100, Otmar Lendl wrote: > On 2007/12/04 09:12, David Schwartz wrote: > > > > Following yesterdays session a bunch of us sat down to try and close > > probably the assisted/indirect ambiguity. > > That's what the IETF meetings are for. > > [reordered] > > > > > What am I missing? > > The latest update to the terminology draft: > > > The terminology draft follows this line and reads (on Page 4)... " As > > illustrated in Figure 1, the ENUM Working Group is primarily > > concerned with the acquisition of SED while the SPEERMINT Working > > Group is focused on the use of such SED in routing session signaling > > requests" > > This changed in the last revision based on various feedback. The > version Daryl sent to the reviewers contains: > > As illustrated in Figure 1, the ENUM Working Group is primarily > concerned with identifying a SIP URI that corresponds to a given > E.164 number, while the SPEERMINT Working Group is concerned with > using that SIP URI to acquire the SED and on the use of such SED in > routing session signaling requests. Importantly, the SIP URI can > be derived from ENUM (i.e., an E.164 DNS entry) or via any other > mechanism available to the user. > > Which make IMHO a lot more sense. > > ================================== > > Generally speaking, one of the problems here is the fact that "SIP > URI" is an overloaded term. I've been bitching about this often > enough in my comments on the list and in one of my drafts. (e.g. > http://www.enum.at/ietf/draft-lendl-speermint-background-00.html#URI ) > > We really, *really* have to distinguish between a SIP Address of Record > (AoR) which is the nice address you print on your business card and the > trivially routable SIP URI. > > In the perfect end-to-end world, RFC 3263 can be used to directly map > the AoR to the next hop SIP proxy. > > In the speermint context, this just isn't true. I'd even venture to say > that this is the main reason for the existance of speermint. > > > If we look at the WG page we see the following... "The SPEERMINT work > > plan is related to and distinct from the work plans of the ENUM and > > SIPPING working groups. While the the ENUM Working Group is primarily > > concerned with the structure and lookup of data for the translation > > of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the > > use of the resulting URI data, as well as non-ENUM-derived URI data, > > for use in signaling and routing of real-time sessions." > > IMHO, the input into the speermint algorithm is always an AoR. > > The AoR is a "name". It defines who you want to reach, e.g. > "sip:david@example.com". It's the same string regardless whom you give > your business card to. Same for public ENUM: You don't know who will > query your public DNS, so you can't tailor your answer to the querier. > Thus the (public) ENUM step must return an AoR, and can't answer with > a SIP URI which indicates a specific ingress point. (unless that's your > one and only ingress point) > > The "URIs" quoted above are thus all AoRs. Maybe we should use different > terms for the various kinds of SIP URIs. > > Daryl? Are you game for some more revisions? We're still not at -58. Grrr....I'm not sure I believe it makes that much of a difference. I think the more important thing is that it reads clearly (meaning clarity of context...not grammatical bliss ;-)). > > > Don't we all agree that SED constitutes a routable SIP URI? isn't > > that just plain SIP at this point? You have a routable URI - you use > > it. you follow 3261 and send it on its merry way. > > Agreed. I think with the update to the terminology draft it all > makes a lot more sense. > > > To me, SPEERMINT is all about GETTING the routable URI - yes - the > > acquisition of SED. Not which protocol I use - that is for ENUM and > > SIP but the process, architecture, semantics, data models, associated > > policy, discovery, etc. > > The trouble relying with ENUM for SED acquisition is that it's based on > telephone numbers, whereas speermint also needs to cope with non-number > based calling. Thus if we base all the tricky egress-ingress selection, > peer-discovery, transit selection and capacity planning on ENUM (and > thus numbers), then we fail to solve the problem for SIP-AoR based calling. > > Have a nice and productive week in Vancouver! > > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Dec 05 16:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01f4-00013a-25; Wed, 05 Dec 2007 16:20:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01f1-00012q-0i; Wed, 05 Dec 2007 16:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J01f0-0000Ni-Kk; Wed, 05 Dec 2007 16:20:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 480D4175D7; Wed, 5 Dec 2007 21:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J01ez-0004dk-Qm; Wed, 05 Dec 2007 16:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Dec 2007 16:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-terminology-14.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Terminology Author(s) : D. Malas, D. Meyer Filename : draft-ietf-speermint-terminology-14.txt Pages : 13 Date : 2007-12-05 This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-terminology-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-terminology-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-05161416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-terminology-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-terminology-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-05161416.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Dec 05 16:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01ir-0004Fm-TK; Wed, 05 Dec 2007 16:24:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01iq-0004F9-Gs for speermint@ietf.org; Wed, 05 Dec 2007 16:24:00 -0500 Received: from mail29.messagelabs.com ([216.82.249.147]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J01ip-0004eu-Cc for speermint@ietf.org; Wed, 05 Dec 2007 16:24:00 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-10.tower-29.messagelabs.com!1196889838!678714!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 24379 invoked from network); 5 Dec 2007 21:23:58 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-10.tower-29.messagelabs.com with SMTP; 5 Dec 2007 21:23:58 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 60B384444 for ; Wed, 5 Dec 2007 21:23:58 +0000 (GMT) Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-terminology-14.txt From: Daryl Malas To: speermint@ietf.org In-Reply-To: References: Content-Type: text/plain Date: Wed, 05 Dec 2007 14:34:54 -0700 Message-Id: <1196890495.7806.14.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org FYI...this is the latest revision I put together prior to the IETF conference. Although it does not have updates discussed on Monday, I believe it will help conversations occurring this week. --Daryl On Wed, 2007-12-05 at 16:20 -0500, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. > > > Title : SPEERMINT Terminology > Author(s) : D. Malas, D. Meyer > Filename : draft-ietf-speermint-terminology-14.txt > Pages : 13 > Date : 2007-12-05 > > This document defines the terminology that is to be used in > describing Session PEERing for Multimedia INTerconnect (SPEERMINT). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-14.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-speermint-terminology-14.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-speermint-terminology-14.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Dec 06 18:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ptj-0005bM-Sr; Thu, 06 Dec 2007 18:12:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Pti-0005bD-Pq for speermint@ietf.org; Thu, 06 Dec 2007 18:12:50 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Pth-00018Q-Tf for speermint@ietf.org; Thu, 06 Dec 2007 18:12:50 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JSN0096WHST7H@siemenscomms.co.uk> for speermint@ietf.org; Thu, 06 Dec 2007 23:12:29 +0000 (GMT) Date: Thu, 06 Dec 2007 23:12:29 +0000 From: "Elwell, John" Subject: RE: [Speermint] Some general comments... In-reply-to: <1196881970.7806.11.camel@montag.eng.level3.com> To: Daryl Malas , Otmar Lendl Message-id: <0D5F89FAC29E2C41B98A6A762007F5D049192C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg3cVbNVPyuyrTqRnaGUcKI+jG9tQA68L7w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20071204120429.GA3877@nic.at> <1196881970.7806.11.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We must not make any assumption about a SIP URI being an AoR. In many cases it will be - in many cases it won't be. In a mid-dialog request it will be a contact URI. In an INVITE request that arises from a REFER request it is likely to be a contact URI. John=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: 05 December 2007 19:13 > To: Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Some general comments... >=20 > Comment in-line... >=20 > On Tue, 2007-12-04 at 13:04 +0100, Otmar Lendl wrote: > > On 2007/12/04 09:12, David Schwartz wrote: > > >=20 > > > Following yesterdays session a bunch of us sat down to=20 > try and close =20 > > > probably the assisted/indirect ambiguity.=20 > >=20 > > That's what the IETF meetings are for. > >=20 > > [reordered] > >=20 > > >=20 > > > What am I missing? > >=20 > > The latest update to the terminology draft: > >=20 > > > The terminology draft follows this line and reads (on=20 > Page 4)... " As =20 > > > illustrated in Figure 1, the ENUM Working Group is primarily =20 > > > concerned with the acquisition of SED while the SPEERMINT=20 > Working =20 > > > Group is focused on the use of such SED in routing=20 > session signaling =20 > > > requests" > >=20 > > This changed in the last revision based on various feedback. The=20 > > version Daryl sent to the reviewers contains: > >=20 > > As illustrated in Figure 1, the ENUM Working Group is primarily > > concerned with identifying a SIP URI that corresponds to a given > > E.164 number, while the SPEERMINT Working Group is concerned with > > using that SIP URI to acquire the SED and on the use of=20 > such SED in > > routing session signaling requests. Importantly, the SIP URI can > > be derived from ENUM (i.e., an E.164 DNS entry) or via any other > > mechanism available to the user. > >=20 > > Which make IMHO a lot more sense. > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Generally speaking, one of the problems here is the fact that "SIP > > URI" is an overloaded term. I've been bitching about this often > > enough in my comments on the list and in one of my drafts. (e.g. > >=20 > http://www.enum.at/ietf/draft-lendl-speermint-background-00.html#URI ) > >=20 > > We really, *really* have to distinguish between a SIP=20 > Address of Record > > (AoR) which is the nice address you print on your business=20 > card and the > > trivially routable SIP URI. > >=20 > > In the perfect end-to-end world, RFC 3263 can be used to=20 > directly map > > the AoR to the next hop SIP proxy. > >=20 > > In the speermint context, this just isn't true. I'd even=20 > venture to say > > that this is the main reason for the existance of speermint. > >=20 > > > If we look at the WG page we see the following... "The=20 > SPEERMINT work =20 > > > plan is related to and distinct from the work plans of=20 > the ENUM and =20 > > > SIPPING working groups. While the the ENUM Working Group=20 > is primarily =20 > > > concerned with the structure and lookup of data for the=20 > translation =20 > > > of E.164 numbers into URIs (RFC3761), SPEERMINT is=20 > concerned with the =20 > > > use of the resulting URI data, as well as=20 > non-ENUM-derived URI data, =20 > > > for use in signaling and routing of real-time sessions." > >=20 > > IMHO, the input into the speermint algorithm is always an AoR. > >=20 > > The AoR is a "name". It defines who you want to reach, e.g. > > "sip:david@example.com". It's the same string regardless=20 > whom you give > > your business card to. Same for public ENUM: You don't know who will > > query your public DNS, so you can't tailor your answer to=20 > the querier. > > Thus the (public) ENUM step must return an AoR, and can't=20 > answer with > > a SIP URI which indicates a specific ingress point. (unless=20 > that's your > > one and only ingress point) > >=20 > > The "URIs" quoted above are thus all AoRs. Maybe we should=20 > use different > > terms for the various kinds of SIP URIs.=20 > >=20 > > Daryl? Are you game for some more revisions? We're still not at -58. >=20 > Grrr....I'm not sure I believe it makes that much of a difference. I > think the more important thing is that it reads clearly=20 > (meaning clarity > of context...not grammatical bliss ;-)). > >=20 > > > Don't we all agree that SED constitutes a routable SIP=20 > URI? isn't =20 > > > that just plain SIP at this point? You have a routable=20 > URI - you use =20 > > > it. you follow 3261 and send it on its merry way. > >=20 > > Agreed. I think with the update to the terminology draft it all > > makes a lot more sense. > >=20 > > > To me, SPEERMINT is all about GETTING the routable URI -=20 > yes - the =20 > > > acquisition of SED. Not which protocol I use - that is=20 > for ENUM and =20 > > > SIP but the process, architecture, semantics, data=20 > models, associated =20 > > > policy, discovery, etc. > >=20 > > The trouble relying with ENUM for SED acquisition is that=20 > it's based on > > telephone numbers, whereas speermint also needs to cope=20 > with non-number > > based calling. Thus if we base all the tricky=20 > egress-ingress selection, > > peer-discovery, transit selection and capacity planning on ENUM (and > > thus numbers), then we fail to solve the problem for=20 > SIP-AoR based calling. > >=20 > > Have a nice and productive week in Vancouver! > >=20 > > /ol > > --=20 > > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 11 05:22:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22GB-0007yB-V0; Tue, 11 Dec 2007 05:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22GA-0007y1-GK for speermint@ietf.org; Tue, 11 Dec 2007 05:22:42 -0500 Received: from exprod7og101.obsmtp.com ([64.18.2.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J22G8-0004mr-E4 for speermint@ietf.org; Tue, 11 Dec 2007 05:22:42 -0500 Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 11 Dec 2007 02:22:12 PST Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 02:18:50 -0800 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 Subject: RE: [Speermint] Some general comments... Date: Tue, 11 Dec 2007 05:18:47 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> In-Reply-To: <1196881970.7806.11.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg3cVglFr7/YHv/QraoZX2iSh1rdwEbazLg From: "Reinaldo Penno" To: "Daryl Malas" , "Otmar Lendl" X-OriginalArrivalTime: 11 Dec 2007 10:18:50.0383 (UTC) FILETIME=[3938D1F0:01C83BDF] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It seems the discussion died down. This is important to allow us poor editors to update the drafts. Are we having a LUF and LF function in the terminology draft? Should I include them in the architecture? Are we having a resolution function which is composed of both? .... Thanks, Reinaldo=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Wednesday, December 05, 2007 11:13 AM > To: Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Some general comments... >=20 > Comment in-line... >=20 > On Tue, 2007-12-04 at 13:04 +0100, Otmar Lendl wrote: > > On 2007/12/04 09:12, David Schwartz wrote: > > >=20 > > > Following yesterdays session a bunch of us sat down to=20 > try and close=20 > > > probably the assisted/indirect ambiguity. > >=20 > > That's what the IETF meetings are for. > >=20 > > [reordered] > >=20 > > >=20 > > > What am I missing? > >=20 > > The latest update to the terminology draft: > >=20 > > > The terminology draft follows this line and reads (on=20 > Page 4)... "=20 > > > As illustrated in Figure 1, the ENUM Working Group is primarily=20 > > > concerned with the acquisition of SED while the SPEERMINT Working=20 > > > Group is focused on the use of such SED in routing=20 > session signaling=20 > > > requests" > >=20 > > This changed in the last revision based on various feedback. The=20 > > version Daryl sent to the reviewers contains: > >=20 > > As illustrated in Figure 1, the ENUM Working Group is primarily > > concerned with identifying a SIP URI that corresponds to a given > > E.164 number, while the SPEERMINT Working Group is concerned with > > using that SIP URI to acquire the SED and on the use of=20 > such SED in > > routing session signaling requests. Importantly, the SIP URI can > > be derived from ENUM (i.e., an E.164 DNS entry) or via any other > > mechanism available to the user. > >=20 > > Which make IMHO a lot more sense. > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Generally speaking, one of the problems here is the fact that "SIP=20 > > URI" is an overloaded term. I've been bitching about this=20 > often enough=20 > > in my comments on the list and in one of my drafts. (e.g. > >=20 > http://www.enum.at/ietf/draft-lendl-speermint-background-00.html#URI ) > >=20 > > We really, *really* have to distinguish between a SIP Address of=20 > > Record > > (AoR) which is the nice address you print on your business card and=20 > > the trivially routable SIP URI. > >=20 > > In the perfect end-to-end world, RFC 3263 can be used to=20 > directly map=20 > > the AoR to the next hop SIP proxy. > >=20 > > In the speermint context, this just isn't true. I'd even venture to=20 > > say that this is the main reason for the existance of speermint. > >=20 > > > If we look at the WG page we see the following... "The SPEERMINT=20 > > > work plan is related to and distinct from the work plans=20 > of the ENUM=20 > > > and SIPPING working groups. While the the ENUM Working Group is=20 > > > primarily concerned with the structure and lookup of data for the=20 > > > translation of E.164 numbers into URIs (RFC3761), SPEERMINT is=20 > > > concerned with the use of the resulting URI data, as well as=20 > > > non-ENUM-derived URI data, for use in signaling and=20 > routing of real-time sessions." > >=20 > > IMHO, the input into the speermint algorithm is always an AoR. > >=20 > > The AoR is a "name". It defines who you want to reach, e.g. > > "sip:david@example.com". It's the same string regardless=20 > whom you give=20 > > your business card to. Same for public ENUM: You don't know=20 > who will=20 > > query your public DNS, so you can't tailor your answer to=20 > the querier. > > Thus the (public) ENUM step must return an AoR, and can't=20 > answer with=20 > > a SIP URI which indicates a specific ingress point. (unless that's=20 > > your one and only ingress point) > >=20 > > The "URIs" quoted above are thus all AoRs. Maybe we should use=20 > > different terms for the various kinds of SIP URIs. > >=20 > > Daryl? Are you game for some more revisions? We're still not at -58. >=20 > Grrr....I'm not sure I believe it makes that much of a=20 > difference. I think the more important thing is that it=20 > reads clearly (meaning clarity of context...not grammatical=20 > bliss ;-)). > >=20 > > > Don't we all agree that SED constitutes a routable SIP URI? isn't=20 > > > that just plain SIP at this point? You have a routable=20 > URI - you use=20 > > > it. you follow 3261 and send it on its merry way. > >=20 > > Agreed. I think with the update to the terminology draft it=20 > all makes=20 > > a lot more sense. > >=20 > > > To me, SPEERMINT is all about GETTING the routable URI -=20 > yes - the=20 > > > acquisition of SED. Not which protocol I use - that is=20 > for ENUM and=20 > > > SIP but the process, architecture, semantics, data models,=20 > > > associated policy, discovery, etc. > >=20 > > The trouble relying with ENUM for SED acquisition is that=20 > it's based=20 > > on telephone numbers, whereas speermint also needs to cope with=20 > > non-number based calling. Thus if we base all the tricky=20 > > egress-ingress selection, peer-discovery, transit selection and=20 > > capacity planning on ENUM (and thus numbers), then we fail=20 > to solve the problem for SIP-AoR based calling. > >=20 > > Have a nice and productive week in Vancouver! > >=20 > > /ol > > -- > > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 //=20 > > nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H //=20 > > http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 11 05:48:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22em-0004JV-NJ; Tue, 11 Dec 2007 05:48:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22el-0004HB-AD for speermint@ietf.org; Tue, 11 Dec 2007 05:48:07 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J22ek-00025n-Ao for speermint@ietf.org; Tue, 11 Dec 2007 05:48:07 -0500 Received: from [172.16.4.104] (barak.cellcom.co.il [212.150.188.226]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1J22eQ3Sqz-0004LQ; Tue, 11 Dec 2007 11:48:03 +0100 References: <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> Message-Id: <96293650-D89B-4847-9699-CB7A2C934C14@xconnect.net> From: David Schwartz To: Reinaldo Penno In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Subject: Re: [Speermint] Some general comments... Content-Transfer-Encoding: 7bit Date: Tue, 11 Dec 2007 12:47:29 +0200 X-Provags-ID: V01U2FsdGVkX18EYVoGmzvXfrHqaJOM2aONnDAd3oesHGylhBA NfaCZMvwflQ81fARTXeiOzyQpuKxoELDOqFJxTjfdqPfN91KRl HbQkJvZ4t792So7U8ahJg== X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Otmar Lendl , "speermint@ietf.org" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes The only term removed was "assisted peering" D. On Dec 11, 2007, at 12:18 PM, "Reinaldo Penno" wrote: > It seems the discussion died down. This is important to allow us poor > editors to update the drafts. Are we having a LUF and LF function in > the > terminology draft? Should I include them in the architecture? Are we > having a resolution function which is composed of both? .... > > Thanks, > > Reinaldo > >> -----Original Message----- >> From: Daryl Malas [mailto:daryl@level3.net] >> Sent: Wednesday, December 05, 2007 11:13 AM >> To: Otmar Lendl >> Cc: speermint@ietf.org >> Subject: Re: [Speermint] Some general comments... >> >> Comment in-line... >> >> On Tue, 2007-12-04 at 13:04 +0100, Otmar Lendl wrote: >>> On 2007/12/04 09:12, David Schwartz wrote: >>>> >>>> Following yesterdays session a bunch of us sat down to >> try and close >>>> probably the assisted/indirect ambiguity. >>> >>> That's what the IETF meetings are for. >>> >>> [reordered] >>> >>>> >>>> What am I missing? >>> >>> The latest update to the terminology draft: >>> >>>> The terminology draft follows this line and reads (on >> Page 4)... " >>>> As illustrated in Figure 1, the ENUM Working Group is primarily >>>> concerned with the acquisition of SED while the SPEERMINT Working >>>> Group is focused on the use of such SED in routing >> session signaling >>>> requests" >>> >>> This changed in the last revision based on various feedback. The >>> version Daryl sent to the reviewers contains: >>> >>> As illustrated in Figure 1, the ENUM Working Group is primarily >>> concerned with identifying a SIP URI that corresponds to a given >>> E.164 number, while the SPEERMINT Working Group is concerned with >>> using that SIP URI to acquire the SED and on the use of >> such SED in >>> routing session signaling requests. Importantly, the SIP URI can >>> be derived from ENUM (i.e., an E.164 DNS entry) or via any other >>> mechanism available to the user. >>> >>> Which make IMHO a lot more sense. >>> >>> ================================== >>> >>> Generally speaking, one of the problems here is the fact that "SIP >>> URI" is an overloaded term. I've been bitching about this >> often enough >>> in my comments on the list and in one of my drafts. (e.g. >>> >> http://www.enum.at/ietf/draft-lendl-speermint- >> background-00.html#URI ) >>> >>> We really, *really* have to distinguish between a SIP Address of >>> Record >>> (AoR) which is the nice address you print on your business card and >>> the trivially routable SIP URI. >>> >>> In the perfect end-to-end world, RFC 3263 can be used to >> directly map >>> the AoR to the next hop SIP proxy. >>> >>> In the speermint context, this just isn't true. I'd even venture to >>> say that this is the main reason for the existance of speermint. >>> >>>> If we look at the WG page we see the following... "The SPEERMINT >>>> work plan is related to and distinct from the work plans >> of the ENUM >>>> and SIPPING working groups. While the the ENUM Working Group is >>>> primarily concerned with the structure and lookup of data for the >>>> translation of E.164 numbers into URIs (RFC3761), SPEERMINT is >>>> concerned with the use of the resulting URI data, as well as >>>> non-ENUM-derived URI data, for use in signaling and >> routing of real-time sessions." >>> >>> IMHO, the input into the speermint algorithm is always an AoR. >>> >>> The AoR is a "name". It defines who you want to reach, e.g. >>> "sip:david@example.com". It's the same string regardless >> whom you give >>> your business card to. Same for public ENUM: You don't know >> who will >>> query your public DNS, so you can't tailor your answer to >> the querier. >>> Thus the (public) ENUM step must return an AoR, and can't >> answer with >>> a SIP URI which indicates a specific ingress point. (unless that's >>> your one and only ingress point) >>> >>> The "URIs" quoted above are thus all AoRs. Maybe we should use >>> different terms for the various kinds of SIP URIs. >>> >>> Daryl? Are you game for some more revisions? We're still not at -58. >> >> Grrr....I'm not sure I believe it makes that much of a >> difference. I think the more important thing is that it >> reads clearly (meaning clarity of context...not grammatical >> bliss ;-)). >>> >>>> Don't we all agree that SED constitutes a routable SIP URI? isn't >>>> that just plain SIP at this point? You have a routable >> URI - you use >>>> it. you follow 3261 and send it on its merry way. >>> >>> Agreed. I think with the update to the terminology draft it >> all makes >>> a lot more sense. >>> >>>> To me, SPEERMINT is all about GETTING the routable URI - >> yes - the >>>> acquisition of SED. Not which protocol I use - that is >> for ENUM and >>>> SIP but the process, architecture, semantics, data models, >>>> associated policy, discovery, etc. >>> >>> The trouble relying with ENUM for SED acquisition is that >> it's based >>> on telephone numbers, whereas speermint also needs to cope with >>> non-number based calling. Thus if we base all the tricky >>> egress-ingress selection, peer-discovery, transit selection and >>> capacity planning on ENUM (and thus numbers), then we fail >> to solve the problem for SIP-AoR based calling. >>> >>> Have a nice and productive week in Vancouver! >>> >>> /ol >>> -- >>> // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // >>> nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // >>> http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 11 13:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ADN-0005xw-8t; Tue, 11 Dec 2007 13:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ADL-0005ll-8M for speermint@ietf.org; Tue, 11 Dec 2007 13:52:19 -0500 Received: from mail47.messagelabs.com ([216.82.240.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2ADJ-0007QY-2T for speermint@ietf.org; Tue, 11 Dec 2007 13:52:19 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-18.tower-47.messagelabs.com!1197399134!37350709!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.107] Received: (qmail 9039 invoked from network); 11 Dec 2007 18:52:14 -0000 Received: from unknown.level3.net (HELO f10cc8-10.level3.com) (209.245.18.107) by server-18.tower-47.messagelabs.com with SMTP; 11 Dec 2007 18:52:14 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10cc8-10.level3.com (Postfix) with ESMTP id 1A4E433A9; Tue, 11 Dec 2007 18:52:14 +0000 (GMT) Subject: Re: [Speermint] Some general comments... From: Daryl Malas To: David Schwartz In-Reply-To: <96293650-D89B-4847-9699-CB7A2C934C14@xconnect.net> References: <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> <96293650-D89B-4847-9699-CB7A2C934C14@xconnect.net> Content-Type: text/plain Date: Tue, 11 Dec 2007 12:03:33 -0700 Message-Id: <1197399813.7806.19.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: "speermint@ietf.org" , Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I concur. On Tue, 2007-12-11 at 12:47 +0200, David Schwartz wrote: > Yes > > The only term removed was "assisted peering" > > D. > > On Dec 11, 2007, at 12:18 PM, "Reinaldo Penno" > wrote: > > > It seems the discussion died down. This is important to allow us poor > > editors to update the drafts. Are we having a LUF and LF function in > > the > > terminology draft? Should I include them in the architecture? Are we > > having a resolution function which is composed of both? .... > > > > Thanks, > > > > Reinaldo > > > >> -----Original Message----- > >> From: Daryl Malas [mailto:daryl@level3.net] > >> Sent: Wednesday, December 05, 2007 11:13 AM > >> To: Otmar Lendl > >> Cc: speermint@ietf.org > >> Subject: Re: [Speermint] Some general comments... > >> > >> Comment in-line... > >> > >> On Tue, 2007-12-04 at 13:04 +0100, Otmar Lendl wrote: > >>> On 2007/12/04 09:12, David Schwartz wrote: > >>>> > >>>> Following yesterdays session a bunch of us sat down to > >> try and close > >>>> probably the assisted/indirect ambiguity. > >>> > >>> That's what the IETF meetings are for. > >>> > >>> [reordered] > >>> > >>>> > >>>> What am I missing? > >>> > >>> The latest update to the terminology draft: > >>> > >>>> The terminology draft follows this line and reads (on > >> Page 4)... " > >>>> As illustrated in Figure 1, the ENUM Working Group is primarily > >>>> concerned with the acquisition of SED while the SPEERMINT Working > >>>> Group is focused on the use of such SED in routing > >> session signaling > >>>> requests" > >>> > >>> This changed in the last revision based on various feedback. The > >>> version Daryl sent to the reviewers contains: > >>> > >>> As illustrated in Figure 1, the ENUM Working Group is primarily > >>> concerned with identifying a SIP URI that corresponds to a given > >>> E.164 number, while the SPEERMINT Working Group is concerned with > >>> using that SIP URI to acquire the SED and on the use of > >> such SED in > >>> routing session signaling requests. Importantly, the SIP URI can > >>> be derived from ENUM (i.e., an E.164 DNS entry) or via any other > >>> mechanism available to the user. > >>> > >>> Which make IMHO a lot more sense. > >>> > >>> ================================== > >>> > >>> Generally speaking, one of the problems here is the fact that "SIP > >>> URI" is an overloaded term. I've been bitching about this > >> often enough > >>> in my comments on the list and in one of my drafts. (e.g. > >>> > >> http://www.enum.at/ietf/draft-lendl-speermint- > >> background-00.html#URI ) > >>> > >>> We really, *really* have to distinguish between a SIP Address of > >>> Record > >>> (AoR) which is the nice address you print on your business card and > >>> the trivially routable SIP URI. > >>> > >>> In the perfect end-to-end world, RFC 3263 can be used to > >> directly map > >>> the AoR to the next hop SIP proxy. > >>> > >>> In the speermint context, this just isn't true. I'd even venture to > >>> say that this is the main reason for the existance of speermint. > >>> > >>>> If we look at the WG page we see the following... "The SPEERMINT > >>>> work plan is related to and distinct from the work plans > >> of the ENUM > >>>> and SIPPING working groups. While the the ENUM Working Group is > >>>> primarily concerned with the structure and lookup of data for the > >>>> translation of E.164 numbers into URIs (RFC3761), SPEERMINT is > >>>> concerned with the use of the resulting URI data, as well as > >>>> non-ENUM-derived URI data, for use in signaling and > >> routing of real-time sessions." > >>> > >>> IMHO, the input into the speermint algorithm is always an AoR. > >>> > >>> The AoR is a "name". It defines who you want to reach, e.g. > >>> "sip:david@example.com". It's the same string regardless > >> whom you give > >>> your business card to. Same for public ENUM: You don't know > >> who will > >>> query your public DNS, so you can't tailor your answer to > >> the querier. > >>> Thus the (public) ENUM step must return an AoR, and can't > >> answer with > >>> a SIP URI which indicates a specific ingress point. (unless that's > >>> your one and only ingress point) > >>> > >>> The "URIs" quoted above are thus all AoRs. Maybe we should use > >>> different terms for the various kinds of SIP URIs. > >>> > >>> Daryl? Are you game for some more revisions? We're still not at -58. > >> > >> Grrr....I'm not sure I believe it makes that much of a > >> difference. I think the more important thing is that it > >> reads clearly (meaning clarity of context...not grammatical > >> bliss ;-)). > >>> > >>>> Don't we all agree that SED constitutes a routable SIP URI? isn't > >>>> that just plain SIP at this point? You have a routable > >> URI - you use > >>>> it. you follow 3261 and send it on its merry way. > >>> > >>> Agreed. I think with the update to the terminology draft it > >> all makes > >>> a lot more sense. > >>> > >>>> To me, SPEERMINT is all about GETTING the routable URI - > >> yes - the > >>>> acquisition of SED. Not which protocol I use - that is > >> for ENUM and > >>>> SIP but the process, architecture, semantics, data models, > >>>> associated policy, discovery, etc. > >>> > >>> The trouble relying with ENUM for SED acquisition is that > >> it's based > >>> on telephone numbers, whereas speermint also needs to cope with > >>> non-number based calling. Thus if we base all the tricky > >>> egress-ingress selection, peer-discovery, transit selection and > >>> capacity planning on ENUM (and thus numbers), then we fail > >> to solve the problem for SIP-AoR based calling. > >>> > >>> Have a nice and productive week in Vancouver! > >>> > >>> /ol > >>> -- > >>> // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > >>> nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // > >>> http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > >>> > >>> _______________________________________________ > >>> Speermint mailing list > >>> Speermint@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speermint > >> > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >> > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 07:46:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39vy-0006o0-AR; Fri, 14 Dec 2007 07:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39vx-0006jY-9c for speermint@ietf.org; Fri, 14 Dec 2007 07:46:29 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J39vv-000460-I3 for speermint@ietf.org; Fri, 14 Dec 2007 07:46:29 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J39vu-0004DH-00 for ; Fri, 14 Dec 2007 13:46:26 +0100 Date: Fri, 14 Dec 2007 13:46:26 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Some general comments... Message-ID: <20071214124626.GA16101@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <092B2658AAB56A4D80836399A4C4703101FE8DE3@ASHEVS002.mcilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <092B2658AAB56A4D80836399A4C4703101FE8DE3@ASHEVS002.mcilink.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/12/04 19:12, "Dwight, Timothy M (Tim)" wrote: > David, > > Personally I think the problem is the notion that we're constrained to a > BCP. Anything non-trivial that this group might do would go beyond a > BCP as I understand that term. That's my understanding as well. The current IETF protocol set makes certain assumptions regarding the overall interconnection/peering/connectivity layout which are not true in the carrier VoIP interconnection space. Current implementations use these protocols within private walled gardens where those assumptions more or less hold. That kind of works out for calls which stay inside these gardens. Any BCP speermint can come up with will thus only work within such walled gardens. In order to solve the overall VoIP interconnection / call routing problem, we'd need to look beyond individual peering islands. That, while IMHO very much needed, is definitely no longer a simple BCP issue. I consider it foolish to spend so much time on optimizing the intra-federation peering mechanics while the overall call routing architecture is completely undefined. This is tending and beautifying walled gardens before you even know what the layout of the arches and paths connecting your gardens will look like. Perhaps lovely in the short term, but a waste of time and a recipe for long term inefficiencies. I thus think we're on the road to irrelevance unless we change our charter. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 07:51:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3A0o-0004Lk-0C; Fri, 14 Dec 2007 07:51:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3A0m-0004LR-SL for speermint@ietf.org; Fri, 14 Dec 2007 07:51:28 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3A0m-0004t2-0a for speermint@ietf.org; Fri, 14 Dec 2007 07:51:28 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J3A0k-0004DR-00 for ; Fri, 14 Dec 2007 13:51:26 +0100 Date: Fri, 14 Dec 2007 13:51:26 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Some general comments... Message-ID: <20071214125126.GB16101@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <1196881970.7806.11.camel@montag.eng.level3.com> <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280BEEA100@proton.jnpr.net> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/12/11 11:12, Reinaldo Penno wrote: > It seems the discussion died down. This is important to allow us poor > editors to update the drafts. Are we having a LUF and LF function in the > terminology draft? Should I include them in the architecture? Are we > having a resolution function which is composed of both? .... Well, _you're_ doing the architecture. It should be your design which defines whether we need these two terms or not. There is no point in adding boxes to your architecture document just because we have defined some terms. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 10:04:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C5E-0000yi-58; Fri, 14 Dec 2007 10:04:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C5C-0000yX-Ap for speermint@ietf.org; Fri, 14 Dec 2007 10:04:10 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3C5B-0008Gx-Nb for speermint@ietf.org; Fri, 14 Dec 2007 10:04:10 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J3C58-0004Ec-00; Fri, 14 Dec 2007 16:04:06 +0100 Date: Fri, 14 Dec 2007 16:04:06 +0100 From: Otmar Lendl To: Pat MeLampy Subject: Re: [Speermint] Review of draft-ietf-speermint-architecture-04 Message-ID: <20071214150406.GA16211@nic.at> Mail-Followup-To: Otmar Lendl , Pat MeLampy , "speermint@ietf.org" References: <20071128132835.GA29883@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "speermint@ietf.org" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/11/28 23:11, Pat MeLampy wrote: > > Already there is a great ongoing debate about how to provision all of > the databases and ENUM servers used in these steps above. I wanted > to suggest that this entire scheme needs to be discussed in greater > detail as this working group moves forward. Consider the following... > Pat, this is good reminder of the scaling issues any solution needs to consider. Even more valuable would be a concrete list of requirements that follow from your example, similar to those already collected in draft-ietf-speermint-requirements-03. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 16:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HkH-0000Ai-Qo; Fri, 14 Dec 2007 16:06:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HkF-0000AW-UI for speermint@ietf.org; Fri, 14 Dec 2007 16:06:55 -0500 Received: from mail164.messagelabs.com ([216.82.253.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3HkF-0002H9-Eh for speermint@ietf.org; Fri, 14 Dec 2007 16:06:55 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-12.tower-164.messagelabs.com!1197666414!17743179!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 26470 invoked from network); 14 Dec 2007 21:06:54 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-12.tower-164.messagelabs.com with SMTP; 14 Dec 2007 21:06:54 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 101B64441 for ; Fri, 14 Dec 2007 21:06:54 +0000 (GMT) Subject: [Speermint] LUF vs. LF From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Fri, 14 Dec 2007 14:18:25 -0700 Message-Id: <1197667105.7806.29.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The topic of the two terms Look-up Function (LUF) and Location Function (LF) has come up a number of times during and post-Vancouver. I would like to present my opinion of these terms and their definitions. Look-up Function - This term defines the mechanism for looking up information to determine the next hop path for sending a SIP request to a peer. Examples of this mechanism is ENUM, DNS (host or domain resolution to an IP address), SIP Proxy (acting as a Redirect server). This function is purely the determination of the appropriate mechanism for the internal or assisted (and/or Federation) databases of record for peering. Location Function - This term defines the method for deriving the information. Although this truely takes place within the protocol mechanism, the term indicates an additional function in the peering process. This also encompasses defining the fact the associated method may use a local or assisted entity for providing the database of record for peering. I personally believe we could combine these two terms into a single "Location Function", but some have argued the granularity provides clarity. Please comment, as I believe, this is the last remaining sticky point in the terminology draft. Thanks...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 16:24:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3I1E-0007dv-P9; Fri, 14 Dec 2007 16:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3I1D-0007aD-37 for speermint@ietf.org; Fri, 14 Dec 2007 16:24:27 -0500 Received: from mail43.messagelabs.com ([216.82.249.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J3I1C-0001RB-Jv for speermint@ietf.org; Fri, 14 Dec 2007 16:24:27 -0500 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-18.tower-43.messagelabs.com!1197667465!19873335!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 26331 invoked from network); 14 Dec 2007 21:24:25 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-18.tower-43.messagelabs.com with SMTP; 14 Dec 2007 21:24:25 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id 646BC4443; Fri, 14 Dec 2007 21:24:25 +0000 (GMT) Subject: Re: [Speermint] Some general comments... From: Daryl Malas To: Otmar Lendl In-Reply-To: <20071214124626.GA16101@nic.at> References: <092B2658AAB56A4D80836399A4C4703101FE8DE3@ASHEVS002.mcilink.com> <20071214124626.GA16101@nic.at> Content-Type: text/plain Date: Fri, 14 Dec 2007 14:35:56 -0700 Message-Id: <1197668156.7806.43.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org IMO, I think it is necessary to describe both architectures within SPEERMINT. One architecture, which can be adopted as a walled garden scenario. This will allow an implementable and realistic version for today's peering scenarios. A second architecture, which assumes an open version that the content (telephoney, video, etc.) industry can, potentially, move towards over time. I simply do not believe it will occur in the next 10 years, but it will likely become more open over time. If we define the basic requirements and architecture to achieve both, I think we succeed in SPEERMINT. Keep this in mind, some early proposals made some assumptions of an "open" architecture (e.g. policy exchange, etc), and the WG chairs (and AD's, I believe) suggested we focus on a more realistic (currently) version of peering and then write drafts over time to better define attributes of the open architecture. IMO, too often, we have a tendency to want to "boil the ocean", instead of developing something to create building blocks for the industry today and tomorrow. Tomorrow may seem a little ambiguous today; but, over time, it will become clearer as the adoption of peering evolves and requirements become more and more obvious. --Daryl On Fri, 2007-12-14 at 13:46 +0100, Otmar Lendl wrote: > On 2007/12/04 19:12, "Dwight, Timothy M (Tim)" wrote: > > David, > > > > Personally I think the problem is the notion that we're constrained to a > > BCP. Anything non-trivial that this group might do would go beyond a > > BCP as I understand that term. > > That's my understanding as well. > > The current IETF protocol set makes certain assumptions regarding the > overall interconnection/peering/connectivity layout which are not > true in the carrier VoIP interconnection space. > > Current implementations use these protocols within private walled > gardens where those assumptions more or less hold. That kind of works > out for calls which stay inside these gardens. Any BCP speermint can > come up with will thus only work within such walled gardens. > > In order to solve the overall VoIP interconnection / call routing > problem, we'd need to look beyond individual peering islands. > > That, while IMHO very much needed, is definitely no longer a simple BCP issue. > > I consider it foolish to spend so much time on optimizing the > intra-federation peering mechanics while the overall call routing > architecture is completely undefined. > > This is tending and beautifying walled gardens before you even know > what the layout of the arches and paths connecting your gardens will > look like. Perhaps lovely in the short term, but a waste of time and > a recipe for long term inefficiencies. > > I thus think we're on the road to irrelevance unless we change our charter. > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 14 17:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Id3-0001C7-Cr; Fri, 14 Dec 2007 17:03:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Id2-0001C1-Hm for speermint@ietf.org; Fri, 14 Dec 2007 17:03:32 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Id2-0002Oz-5D for speermint@ietf.org; Fri, 14 Dec 2007 17:03:32 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 17:03:31 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 17:03:31 -0500 From: Hadriel Kaplan To: "Michael Hammer (mhammer)" , David Schwartz , "speermint@ietf.org" Date: Fri, 14 Dec 2007 16:58:46 -0500 Subject: RE: [Speermint] Some general comments... Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg2TwecZW0grJ8/Su64MYat4IRqKAAMexJAAgYoOMA= Message-ID: References: <072C5B76F7CEAB488172C6F64B30B5E303FF6C59@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E303FF6C59@xmb-rtp-20b.amer.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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael - when you say "redirecting" a SIP or ENUM request, do you mean pro= xying/forwarding, or do you literally mean a SIP 3xx redirection (or iterat= ive ENUM) model? The latter won't work, for a variety of reasons. But I assume you mean the= former: whether call routing should be done by SIP proxying or recursive E= NUM. A recursive ENUM model won't cover all, IMO. Within a registry feder= ation it will be useful, because each SSP may well have direct SIP connecti= on to each other (ie, a full mesh), and thus a recursive ENUM query can tel= l the originating SSP the right ingress SBE for the terminating SSP. The p= roblem, of course, is not all SSPs have connectivity to all SSPs, and ENUM = has no topological view of the relationships and equipment that exist in be= tween. In other words even if we can figure out how to get SSP2's subscriber data = to be "seen" by SSP1, so that SSP1 can do an ENUM dip and get back SSP2's s= ubscriber AoR or ingress point, it has nothing to do with whether SSP1 can = actually reach SSP2 at a SIP layer, or what transit SSPs (and SBEs) it has = to traverse to do so. I guess we'll see whether that particular aspect wil= l be covered by PEPPERMINT. :) -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, December 04, 2007 9:33 AM > To: David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Some general comments... > > David, > > At a high level, the answer to your question is whether the "call > routing" is done via redirecting a SIP request hop by hop through many > SP networks and their proxies to the terminating network and terminating > end-user, or whether it is done by redirecting ENUM queries through a > sequence of registries until the originating VoIP SP serving the caller > can connect as directly as possible to the terminating VoIP SP serving > the called user. > > In short, route through SP's/proxies or route through databases. I > would contend that the latter is much more efficient and the reason for > SPEERMINT. Minimize the middlemen. > > The use of registries also allows the application of some control over > who learns what ingress to go through, as well as some load balancing > and perhaps congestion control and perhaps some SPIT control. > > Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 02:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4AN5-0007Oc-V5; Mon, 17 Dec 2007 02:26:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4AN4-0007OV-Ht for speermint@ietf.org; Mon, 17 Dec 2007 02:26:38 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4AN4-0006SL-39 for speermint@ietf.org; Mon, 17 Dec 2007 02:26:38 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JT600B2CNCDYO@siemenscomms.co.uk> for speermint@ietf.org; Mon, 17 Dec 2007 07:26:37 +0000 (GMT) Date: Mon, 17 Dec 2007 07:26:36 +0000 From: "Elwell, John" Subject: RE: [Speermint] LUF vs. LF In-reply-to: <1197667105.7806.29.camel@montag.eng.level3.com> To: Daryl Malas , speermint@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D8F3E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] LUF vs. LF Thread-Index: Acg+lUk/xHdpmXkzTEiQWQA0DW4BkAB5wtDg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1197667105.7806.29.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, Thanks for raising this on the list, because it was I who expressed concerns to you on this subject. I think it is extremely unlikely that an average reader would understand, from the present definitions of LF and LUF, the meanings you have described below. Therefore something has to be done. My preference would be just to define LF. Use of the term LUF in other drafts is very marginal. The use cases draft talks about "LF and LUF" in several places, but does not make a distinction - I think it could just refer to LF. The architecture draft does not mention "LUF". Therefore I don't see a compelling reason to have a definition of LUF. John =20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: 14 December 2007 21:18 > To: speermint@ietf.org > Subject: [Speermint] LUF vs. LF >=20 > The topic of the two terms Look-up Function (LUF) and=20 > Location Function > (LF) has come up a number of times during and post-Vancouver. I would > like to present my opinion of these terms and their definitions. >=20 > Look-up Function - >=20 > This term defines the mechanism for looking up information to=20 > determine > the next hop path for sending a SIP request to a peer. =20 > Examples of this > mechanism is ENUM, DNS (host or domain resolution to an IP=20 > address), SIP > Proxy (acting as a Redirect server). This function is purely the > determination of the appropriate mechanism for the internal=20 > or assisted > (and/or Federation) databases of record for peering. >=20 > Location Function - >=20 > This term defines the method for deriving the information. Although > this truely takes place within the protocol mechanism, the term > indicates an additional function in the peering process. This also > encompasses defining the fact the associated method may use a local or > assisted entity for providing the database of record for peering. >=20 > I personally believe we could combine these two terms into a single > "Location Function", but some have argued the granularity provides > clarity. >=20 > Please comment, as I believe, this is the last remaining=20 > sticky point in > the terminology draft. >=20 > Thanks...--Daryl >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 03:48:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4BeY-0003k3-Hu; Mon, 17 Dec 2007 03:48:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4BeX-0003jy-D2 for speermint@ietf.org; Mon, 17 Dec 2007 03:48:45 -0500 Received: from moutng.kundenserver.de ([212.227.126.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4BeW-0007vH-KY for speermint@ietf.org; Mon, 17 Dec 2007 03:48:45 -0500 Received: from [172.16.100.90] (bzq-25-94-33.static.bezeqint.net [212.25.94.33]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1J4BeV19Ay-0005uA; Mon, 17 Dec 2007 09:48:44 +0100 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04D8F3E@GBNTHT12009MSX.gb002.siemens.net> References: <1197667105.7806.29.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D04D8F3E@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Schwartz Subject: Re: [Speermint] LUF vs. LF Date: Mon, 17 Dec 2007 10:48:41 +0200 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Provags-ID: V01U2FsdGVkX18uVktEfpdIz5giXJj8XZhcUb/W15sQj2m55Gi ZwiLLDiY+qcBXVZSASufTImFY2Fr5UQTbJ1R3UtVfob0U6Ng5t Pj+j41OCR+wCtFe2nWL7g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi John. If indeed LUF is scarcely used in other drafts than I would say the problem is there and not with maintaining this definition in the terminology draft. I need to re-read the use case draft since the draft I wrote which was incorporated into the consolidated use-case draft clearly had such a function and this needs to be recaptured. The definitions as they appear in .14 are as follows: 4.3.1. Look-Up Function The Look-Up Function (LUF) provides a mechanism for querying an internal and/or external database, which maintains a list of peered host domains. 4.3.2. Location Function The Location Function (LF) develops SED by discovering the Signaling Function (SF), and SF's reachable host (IP Address and port). What is unclear about this? Why do we keep circling the wagons on this? D. On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: > Daryl, > > Thanks for raising this on the list, because it was I who expressed > concerns to you on this subject. > > I think it is extremely unlikely that an average reader would > understand, from the present definitions of LF and LUF, the > meanings you > have described below. Therefore something has to be done. > > My preference would be just to define LF. Use of the term LUF in other > drafts is very marginal. The use cases draft talks about "LF and > LUF" in > several places, but does not make a distinction - I think it could > just > refer to LF. The architecture draft does not mention "LUF". > Therefore I > don't see a compelling reason to have a definition of LUF. > > John > > >> -----Original Message----- >> From: Daryl Malas [mailto:daryl@level3.net] >> Sent: 14 December 2007 21:18 >> To: speermint@ietf.org >> Subject: [Speermint] LUF vs. LF >> >> The topic of the two terms Look-up Function (LUF) and >> Location Function >> (LF) has come up a number of times during and post-Vancouver. I >> would >> like to present my opinion of these terms and their definitions. >> >> Look-up Function - >> >> This term defines the mechanism for looking up information to >> determine >> the next hop path for sending a SIP request to a peer. >> Examples of this >> mechanism is ENUM, DNS (host or domain resolution to an IP >> address), SIP >> Proxy (acting as a Redirect server). This function is purely the >> determination of the appropriate mechanism for the internal >> or assisted >> (and/or Federation) databases of record for peering. >> >> Location Function - >> >> This term defines the method for deriving the information. Although >> this truely takes place within the protocol mechanism, the term >> indicates an additional function in the peering process. This also >> encompasses defining the fact the associated method may use a >> local or >> assisted entity for providing the database of record for peering. >> >> I personally believe we could combine these two terms into a single >> "Location Function", but some have argued the granularity provides >> clarity. >> >> Please comment, as I believe, this is the last remaining >> sticky point in >> the terminology draft. >> >> Thanks...--Daryl >> >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 04:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CGC-0003Nv-Es; Mon, 17 Dec 2007 04:27:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CGA-0003Nq-Nq for speermint@ietf.org; Mon, 17 Dec 2007 04:27:38 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4CG9-0000X7-Sx for speermint@ietf.org; Mon, 17 Dec 2007 04:27:38 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JT600J2ASY12K@siemenscomms.co.uk> for speermint@ietf.org; Mon, 17 Dec 2007 09:27:37 +0000 (GMT) Date: Mon, 17 Dec 2007 09:27:36 +0000 From: "Elwell, John" Subject: RE: [Speermint] LUF vs. LF In-reply-to: To: David Schwartz Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] LUF vs. LF Thread-Index: AchAi0EswUeShPUsRlCCIn5f8A9xBwAAaorw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1197667105.7806.29.camel@montag.eng.level3.com> <0D5F89FAC29E2C41B98A6A762007F5D04D8F3E@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, There are several things that are unclear - see below. If other people on this list come forward and say that the definitions are perfectly clear, then I guess I will have to back down. But to me it seems there are just a few of us, talking at cross purposes, and this gives me an uneasy feeling about the maturity of the drafts. John=20 > -----Original Message----- > From: David Schwartz [mailto:dschwartz@xconnect.net]=20 > Sent: 17 December 2007 08:49 > To: Elwell, John > Cc: Daryl Malas; speermint@ietf.org > Subject: Re: [Speermint] LUF vs. LF >=20 > Hi John. >=20 > If indeed LUF is scarcely used in other drafts than I would say the =20 > problem is there and not with maintaining this definition in the =20 > terminology draft. I need to re-read the use case draft since the =20 > draft I wrote which was incorporated into the consolidated use-case =20 > draft clearly had such a function and this needs to be recaptured. >=20 > The definitions as they appear in .14 are as follows: >=20 > 4.3.1. Look-Up Function >=20 > The Look-Up Function (LUF) provides a mechanism for querying an > internal and/or external database, which maintains a list=20 > of peered > host domains. [JRE] What is the input to the query, and what is the output from the query? Without this information the definition is far too vague. Is the input to the query a domain, and it looks to see if that domain is in the list and answers yes/no and perhaps also responds with other information about that domain? Or is the input a SIP URI or some other form of target address and the output the domain that can be used to reach that target? I believe it is the latter, but the definition certainly does not tell me that. >=20 > 4.3.2. Location Function >=20 > The Location Function (LF) develops SED by discovering=20 > the Signaling > Function (SF), and SF's reachable host (IP Address and port). [JRE] What is the input to the discovery process? Also, what is the relationship between LUF and LF. I thought at first that the LUF was performed first, and the output from the LUF would be the input (or one of the inputs) to the LF. Daryl tells me I am wrong - that the LUF is part of the LF, or more precisely, the LUF is a mechanism that the LF uses. >=20 > What is unclear about this? Why do we keep circling the=20 > wagons on this? >=20 > D. >=20 >=20 >=20 >=20 > On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: >=20 > > Daryl, > > > > Thanks for raising this on the list, because it was I who expressed > > concerns to you on this subject. > > > > I think it is extremely unlikely that an average reader would > > understand, from the present definitions of LF and LUF, the =20 > > meanings you > > have described below. Therefore something has to be done. > > > > My preference would be just to define LF. Use of the term=20 > LUF in other > > drafts is very marginal. The use cases draft talks about "LF and =20 > > LUF" in > > several places, but does not make a distinction - I think it could =20 > > just > > refer to LF. The architecture draft does not mention "LUF". =20 > > Therefore I > > don't see a compelling reason to have a definition of LUF. > > > > John > > > > > >> -----Original Message----- > >> From: Daryl Malas [mailto:daryl@level3.net] > >> Sent: 14 December 2007 21:18 > >> To: speermint@ietf.org > >> Subject: [Speermint] LUF vs. LF > >> > >> The topic of the two terms Look-up Function (LUF) and > >> Location Function > >> (LF) has come up a number of times during and post-Vancouver. I =20 > >> would > >> like to present my opinion of these terms and their definitions. > >> > >> Look-up Function - > >> > >> This term defines the mechanism for looking up information to > >> determine > >> the next hop path for sending a SIP request to a peer. > >> Examples of this > >> mechanism is ENUM, DNS (host or domain resolution to an IP > >> address), SIP > >> Proxy (acting as a Redirect server). This function is purely the > >> determination of the appropriate mechanism for the internal > >> or assisted > >> (and/or Federation) databases of record for peering. > >> > >> Location Function - > >> > >> This term defines the method for deriving the information.=20 > Although > >> this truely takes place within the protocol mechanism, the term > >> indicates an additional function in the peering process. This also > >> encompasses defining the fact the associated method may use a =20 > >> local or > >> assisted entity for providing the database of record for peering. > >> > >> I personally believe we could combine these two terms into a single > >> "Location Function", but some have argued the granularity provides > >> clarity. > >> > >> Please comment, as I believe, this is the last remaining > >> sticky point in > >> the terminology draft. > >> > >> Thanks...--Daryl > >> > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >> > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email=20 > Security System. > > For more information please visit http://www.messagelabs.com/email > >=20 > ______________________________________________________________________ >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 04:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ca4-0005JX-ST; Mon, 17 Dec 2007 04:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ca3-0005J9-GR for speermint@ietf.org; Mon, 17 Dec 2007 04:48:11 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Ca1-0005hg-Mo for speermint@ietf.org; Mon, 17 Dec 2007 04:48:11 -0500 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.49941645; Mon, 17 Dec 2007 04:47:51 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 04:47:51 -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 Subject: RE: [Speermint] LUF vs. LF Date: Mon, 17 Dec 2007 04:45:53 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] LUF vs. LF Thread-Index: AchAi0EswUeShPUsRlCCIn5f8A9xBwAAaorwAAC8O7A= From: "Lee, Yiu" To: "Elwell, John" , "David Schwartz" X-OriginalArrivalTime: 17 Dec 2007 09:47:51.0860 (UTC) FILETIME=[E3EF3740:01C84091] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, I think LUF was defined to allow some Assisted SSP to provide only registry service. My understanding is many SSP can form a federation where a common registry can translate some input (not defined) to a routable AOR. The LUF only returns an AOR. The LF will take the AOR and determine the target proxy to route the session to. Even thought most people don't see the difference, but in fact these are two different procedures. I agree that most people don't see the difference. If we consolidate these two terms into one function, how do you suggest the text to describe the new LF? Thanks, Yiu -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Monday, December 17, 2007 4:28 AM To: David Schwartz Cc: speermint@ietf.org Subject: RE: [Speermint] LUF vs. LF David, There are several things that are unclear - see below. If other people on this list come forward and say that the definitions are perfectly clear, then I guess I will have to back down. But to me it seems there are just a few of us, talking at cross purposes, and this gives me an uneasy feeling about the maturity of the drafts. John=20 > -----Original Message----- > From: David Schwartz [mailto:dschwartz@xconnect.net] > Sent: 17 December 2007 08:49 > To: Elwell, John > Cc: Daryl Malas; speermint@ietf.org > Subject: Re: [Speermint] LUF vs. LF >=20 > Hi John. >=20 > If indeed LUF is scarcely used in other drafts than I would say the=20 > problem is there and not with maintaining this definition in the=20 > terminology draft. I need to re-read the use case draft since the=20 > draft I wrote which was incorporated into the consolidated use-case=20 > draft clearly had such a function and this needs to be recaptured. >=20 > The definitions as they appear in .14 are as follows: >=20 > 4.3.1. Look-Up Function >=20 > The Look-Up Function (LUF) provides a mechanism for querying an > internal and/or external database, which maintains a list of=20 > peered > host domains. [JRE] What is the input to the query, and what is the output from the query? Without this information the definition is far too vague. Is the input to the query a domain, and it looks to see if that domain is in the list and answers yes/no and perhaps also responds with other information about that domain? Or is the input a SIP URI or some other form of target address and the output the domain that can be used to reach that target? I believe it is the latter, but the definition certainly does not tell me that. >=20 > 4.3.2. Location Function >=20 > The Location Function (LF) develops SED by discovering the=20 > Signaling > Function (SF), and SF's reachable host (IP Address and port). [JRE] What is the input to the discovery process? Also, what is the relationship between LUF and LF. I thought at first that the LUF was performed first, and the output from the LUF would be the input (or one of the inputs) to the LF. Daryl tells me I am wrong - that the LUF is part of the LF, or more precisely, the LUF is a mechanism that the LF uses. >=20 > What is unclear about this? Why do we keep circling the wagons on=20 > this? >=20 > D. >=20 >=20 >=20 >=20 > On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: >=20 > > Daryl, > > > > Thanks for raising this on the list, because it was I who expressed=20 > > concerns to you on this subject. > > > > I think it is extremely unlikely that an average reader would=20 > > understand, from the present definitions of LF and LUF, the meanings > > you have described below. Therefore something has to be done. > > > > My preference would be just to define LF. Use of the term > LUF in other > > drafts is very marginal. The use cases draft talks about "LF and=20 > > LUF" in several places, but does not make a distinction - I think it > > could just refer to LF. The architecture draft does not mention=20 > > "LUF". > > Therefore I > > don't see a compelling reason to have a definition of LUF. > > > > John > > > > > >> -----Original Message----- > >> From: Daryl Malas [mailto:daryl@level3.net] > >> Sent: 14 December 2007 21:18 > >> To: speermint@ietf.org > >> Subject: [Speermint] LUF vs. LF > >> > >> The topic of the two terms Look-up Function (LUF) and Location=20 > >> Function > >> (LF) has come up a number of times during and post-Vancouver. I=20 > >> would like to present my opinion of these terms and their=20 > >> definitions. > >> > >> Look-up Function - > >> > >> This term defines the mechanism for looking up information to=20 > >> determine the next hop path for sending a SIP request to a peer. > >> Examples of this > >> mechanism is ENUM, DNS (host or domain resolution to an IP=20 > >> address), SIP Proxy (acting as a Redirect server). This function=20 > >> is purely the determination of the appropriate mechanism for the=20 > >> internal or assisted (and/or Federation) databases of record for=20 > >> peering. > >> > >> Location Function - > >> > >> This term defines the method for deriving the information.=20 > Although > >> this truely takes place within the protocol mechanism, the term=20 > >> indicates an additional function in the peering process. This also > >> encompasses defining the fact the associated method may use a local > >> or assisted entity for providing the database of record for=20 > >> peering. > >> > >> I personally believe we could combine these two terms into a single > >> "Location Function", but some have argued the granularity provides=20 > >> clarity. > >> > >> Please comment, as I believe, this is the last remaining sticky=20 > >> point in the terminology draft. > >> > >> Thanks...--Daryl > >> > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >> > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit http://www.messagelabs.com/email > >=20 > ______________________________________________________________________ >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 08:51:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GN2-0001k5-M8; Mon, 17 Dec 2007 08:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GN1-0001jz-3G for speermint@ietf.org; Mon, 17 Dec 2007 08:50:59 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GMy-0003G1-Nw for speermint@ietf.org; Mon, 17 Dec 2007 08:50:59 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JT700B4F54WRB@siemenscomms.co.uk> for speermint@ietf.org; Mon, 17 Dec 2007 13:50:56 +0000 (GMT) Date: Mon, 17 Dec 2007 13:50:55 +0000 From: "Elwell, John" Subject: RE: [Speermint] LUF vs. LF In-reply-to: A <45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> To: "Lee, Yiu" , David Schwartz Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D900F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] LUF vs. LF Thread-Index: AchAi0EswUeShPUsRlCCIn5f8A9xBwAAaorwAAC8O7AACO7PEA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net> A <45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yiu, In fact my initial understanding was in line with your understanding below. However, in trying to clarify if further in that direction, I encountered a different opinion. John=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com]=20 > Sent: 17 December 2007 09:46 > To: Elwell, John; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > John, >=20 > I think LUF was defined to allow some Assisted SSP to provide only > registry service. My understanding is many SSP can form a federation > where a common registry can translate some input (not defined) to a > routable AOR. The LUF only returns an AOR. The LF will take=20 > the AOR and > determine the target proxy to route the session to. Even thought most > people don't see the difference, but in fact these are two different > procedures. I agree that most people don't see the difference. If we > consolidate these two terms into one function, how do you suggest the > text to describe the new LF? >=20 > Thanks, > Yiu >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, December 17, 2007 4:28 AM > To: David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > David, >=20 > There are several things that are unclear - see below. If other people > on this list come forward and say that the definitions are perfectly > clear, then I guess I will have to back down. But to me it seems there > are just a few of us, talking at cross purposes, and this gives me an > uneasy feeling about the maturity of the drafts. >=20 > John=20 >=20 > > -----Original Message----- > > From: David Schwartz [mailto:dschwartz@xconnect.net] > > Sent: 17 December 2007 08:49 > > To: Elwell, John > > Cc: Daryl Malas; speermint@ietf.org > > Subject: Re: [Speermint] LUF vs. LF > >=20 > > Hi John. > >=20 > > If indeed LUF is scarcely used in other drafts than I would say the=20 > > problem is there and not with maintaining this definition in the=20 > > terminology draft. I need to re-read the use case draft since the=20 > > draft I wrote which was incorporated into the consolidated use-case=20 > > draft clearly had such a function and this needs to be recaptured. > >=20 > > The definitions as they appear in .14 are as follows: > >=20 > > 4.3.1. Look-Up Function > >=20 > > The Look-Up Function (LUF) provides a mechanism for querying an > > internal and/or external database, which maintains a list of=20 > > peered > > host domains. > [JRE] What is the input to the query, and what is the output from the > query? Without this information the definition is far too=20 > vague. Is the > input to the query a domain, and it looks to see if that domain is in > the list and answers yes/no and perhaps also responds with other > information about that domain? Or is the input a SIP URI or some other > form of target address and the output the domain that can be used to > reach that target? I believe it is the latter, but the definition > certainly does not tell me that. >=20 > >=20 > > 4.3.2. Location Function > >=20 > > The Location Function (LF) develops SED by discovering the=20 > > Signaling > > Function (SF), and SF's reachable host (IP Address and port). > [JRE] What is the input to the discovery process? > Also, what is the relationship between LUF and LF. I thought at first > that the LUF was performed first, and the output from the LUF would be > the input (or one of the inputs) to the LF. Daryl tells me I=20 > am wrong - > that the LUF is part of the LF, or more precisely, the LUF is a > mechanism that the LF uses. >=20 > >=20 > > What is unclear about this? Why do we keep circling the wagons on=20 > > this? > >=20 > > D. > >=20 > >=20 > >=20 > >=20 > > On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: > >=20 > > > Daryl, > > > > > > Thanks for raising this on the list, because it was I who=20 > expressed=20 > > > concerns to you on this subject. > > > > > > I think it is extremely unlikely that an average reader would=20 > > > understand, from the present definitions of LF and LUF,=20 > the meanings >=20 > > > you have described below. Therefore something has to be done. > > > > > > My preference would be just to define LF. Use of the term > > LUF in other > > > drafts is very marginal. The use cases draft talks about "LF and=20 > > > LUF" in several places, but does not make a distinction -=20 > I think it >=20 > > > could just refer to LF. The architecture draft does not mention=20 > > > "LUF". > > > Therefore I > > > don't see a compelling reason to have a definition of LUF. > > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: Daryl Malas [mailto:daryl@level3.net] > > >> Sent: 14 December 2007 21:18 > > >> To: speermint@ietf.org > > >> Subject: [Speermint] LUF vs. LF > > >> > > >> The topic of the two terms Look-up Function (LUF) and Location=20 > > >> Function > > >> (LF) has come up a number of times during and post-Vancouver. I=20 > > >> would like to present my opinion of these terms and their=20 > > >> definitions. > > >> > > >> Look-up Function - > > >> > > >> This term defines the mechanism for looking up information to=20 > > >> determine the next hop path for sending a SIP request to a peer. > > >> Examples of this > > >> mechanism is ENUM, DNS (host or domain resolution to an IP=20 > > >> address), SIP Proxy (acting as a Redirect server). This=20 > function=20 > > >> is purely the determination of the appropriate mechanism for the=20 > > >> internal or assisted (and/or Federation) databases of record for=20 > > >> peering. > > >> > > >> Location Function - > > >> > > >> This term defines the method for deriving the information.=20 > > Although > > >> this truely takes place within the protocol mechanism, the term=20 > > >> indicates an additional function in the peering process.=20 > This also >=20 > > >> encompasses defining the fact the associated method may=20 > use a local >=20 > > >> or assisted entity for providing the database of record for=20 > > >> peering. > > >> > > >> I personally believe we could combine these two terms=20 > into a single >=20 > > >> "Location Function", but some have argued the=20 > granularity provides=20 > > >> clarity. > > >> > > >> Please comment, as I believe, this is the last remaining sticky=20 > > >> point in the terminology draft. > > >> > > >> Thanks...--Daryl > > >> > > >> > > >> _______________________________________________ > > >> Speermint mailing list > > >> Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > >> > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > >=20 > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > >=20 > ______________________________________________________________________ > >=20 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 10:15:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Hgm-0005Tj-Vi; Mon, 17 Dec 2007 10:15:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Hgl-0005Sb-LP for speermint@ietf.org; Mon, 17 Dec 2007 10:15:27 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Hgk-0005UD-HO for speermint@ietf.org; Mon, 17 Dec 2007 10:15:27 -0500 X-IronPort-AV: E=Sophos;i="4.24,177,1196658000"; d="scan'208";a="86261872" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 17 Dec 2007 10:15:26 -0500 X-IronPort-AV: E=Sophos;i="4.24,177,1196658000"; d="scan'208";a="141841743" Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.140]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Dec 2007 10:15:27 -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 Subject: RE: [Speermint] LUF vs. LF Date: Mon, 17 Dec 2007 10:14:59 -0500 Message-ID: <3036F4A94122BD4AAAAB441FE88845288EC6E4@300815ANEX3.global.avaya.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04D900F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] LUF vs. LF Thread-Index: AchAi0EswUeShPUsRlCCIn5f8A9xBwAAaorwAAC8O7AACO7PEAAChLNg References: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net>A<45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> <0D5F89FAC29E2C41B98A6A762007F5D04D900F@GBNTHT12009MSX.gb002.siemens.net> From: "Rodrig, Benny (Benny)" To: "Elwell, John" , "Lee, Yiu" , "David Schwartz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org John, My understanding of this was that the LUF could get e.g. an E164 number and return a domain name and then the LF follows taking the domain name as input and returning how to route to it (i.e. SED). In many cases they would be combined, but I suppose there could be cases where you go to one mechanism (e.g. 'assisting') with a number to find it belongs to example.com and then you go to another mechanism (e.g. internal) to find how to route to example.com. I don't know if this is really what David meant. Under this interpretation, if you're starting with e.g. joe@example.com you don't really need the LUF, or you can say it is trivial. You go straight to LF. Benny =20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: Monday, December 17, 2007 8:51 AM To: Lee, Yiu; David Schwartz Cc: speermint@ietf.org Subject: RE: [Speermint] LUF vs. LF Yiu, In fact my initial understanding was in line with your understanding below. However, in trying to clarify if further in that direction, I encountered a different opinion. John=20 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > Sent: 17 December 2007 09:46 > To: Elwell, John; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > John, >=20 > I think LUF was defined to allow some Assisted SSP to provide only=20 > registry service. My understanding is many SSP can form a federation=20 > where a common registry can translate some input (not defined) to a=20 > routable AOR. The LUF only returns an AOR. The LF will take the AOR=20 > and determine the target proxy to route the session to. Even thought=20 > most people don't see the difference, but in fact these are two=20 > different procedures. I agree that most people don't see the=20 > difference. If we consolidate these two terms into one function, how=20 > do you suggest the text to describe the new LF? >=20 > Thanks, > Yiu >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, December 17, 2007 4:28 AM > To: David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > David, >=20 > There are several things that are unclear - see below. If other people > on this list come forward and say that the definitions are perfectly=20 > clear, then I guess I will have to back down. But to me it seems there > are just a few of us, talking at cross purposes, and this gives me an=20 > uneasy feeling about the maturity of the drafts. >=20 > John >=20 > > -----Original Message----- > > From: David Schwartz [mailto:dschwartz@xconnect.net] > > Sent: 17 December 2007 08:49 > > To: Elwell, John > > Cc: Daryl Malas; speermint@ietf.org > > Subject: Re: [Speermint] LUF vs. LF > >=20 > > Hi John. > >=20 > > If indeed LUF is scarcely used in other drafts than I would say the=20 > > problem is there and not with maintaining this definition in the=20 > > terminology draft. I need to re-read the use case draft since the=20 > > draft I wrote which was incorporated into the consolidated use-case=20 > > draft clearly had such a function and this needs to be recaptured. > >=20 > > The definitions as they appear in .14 are as follows: > >=20 > > 4.3.1. Look-Up Function > >=20 > > The Look-Up Function (LUF) provides a mechanism for querying an > > internal and/or external database, which maintains a list of=20 > > peered > > host domains. > [JRE] What is the input to the query, and what is the output from the=20 > query? Without this information the definition is far too vague. Is=20 > the input to the query a domain, and it looks to see if that domain is > in the list and answers yes/no and perhaps also responds with other=20 > information about that domain? Or is the input a SIP URI or some other > form of target address and the output the domain that can be used to=20 > reach that target? I believe it is the latter, but the definition=20 > certainly does not tell me that. >=20 > >=20 > > 4.3.2. Location Function > >=20 > > The Location Function (LF) develops SED by discovering the=20 > > Signaling > > Function (SF), and SF's reachable host (IP Address and port). > [JRE] What is the input to the discovery process? > Also, what is the relationship between LUF and LF. I thought at first=20 > that the LUF was performed first, and the output from the LUF would be > the input (or one of the inputs) to the LF. Daryl tells me I am wrong=20 > - that the LUF is part of the LF, or more precisely, the LUF is a=20 > mechanism that the LF uses. >=20 > >=20 > > What is unclear about this? Why do we keep circling the wagons on=20 > > this? > >=20 > > D. > >=20 > >=20 > >=20 > >=20 > > On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: > >=20 > > > Daryl, > > > > > > Thanks for raising this on the list, because it was I who > expressed > > > concerns to you on this subject. > > > > > > I think it is extremely unlikely that an average reader would=20 > > > understand, from the present definitions of LF and LUF, > the meanings >=20 > > > you have described below. Therefore something has to be done. > > > > > > My preference would be just to define LF. Use of the term > > LUF in other > > > drafts is very marginal. The use cases draft talks about "LF and=20 > > > LUF" in several places, but does not make a distinction - > I think it >=20 > > > could just refer to LF. The architecture draft does not mention=20 > > > "LUF". > > > Therefore I > > > don't see a compelling reason to have a definition of LUF. > > > > > > John > > > > > > > > >> -----Original Message----- > > >> From: Daryl Malas [mailto:daryl@level3.net] > > >> Sent: 14 December 2007 21:18 > > >> To: speermint@ietf.org > > >> Subject: [Speermint] LUF vs. LF > > >> > > >> The topic of the two terms Look-up Function (LUF) and Location=20 > > >> Function > > >> (LF) has come up a number of times during and post-Vancouver. I=20 > > >> would like to present my opinion of these terms and their=20 > > >> definitions. > > >> > > >> Look-up Function - > > >> > > >> This term defines the mechanism for looking up information to=20 > > >> determine the next hop path for sending a SIP request to a peer. > > >> Examples of this > > >> mechanism is ENUM, DNS (host or domain resolution to an IP=20 > > >> address), SIP Proxy (acting as a Redirect server). This > function > > >> is purely the determination of the appropriate mechanism for the=20 > > >> internal or assisted (and/or Federation) databases of record for=20 > > >> peering. > > >> > > >> Location Function - > > >> > > >> This term defines the method for deriving the information.=20 > > Although > > >> this truely takes place within the protocol mechanism, the term=20 > > >> indicates an additional function in the peering process. > This also >=20 > > >> encompasses defining the fact the associated method may > use a local >=20 > > >> or assisted entity for providing the database of record for=20 > > >> peering. > > >> > > >> I personally believe we could combine these two terms > into a single >=20 > > >> "Location Function", but some have argued the > granularity provides > > >> clarity. > > >> > > >> Please comment, as I believe, this is the last remaining sticky=20 > > >> point in the terminology draft. > > >> > > >> Thanks...--Daryl > > >> > > >> > > >> _______________________________________________ > > >> Speermint mailing list > > >> Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > >> > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > >=20 > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > >=20 > ______________________________________________________________________ > >=20 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 11:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IcN-00005A-KY; Mon, 17 Dec 2007 11:14:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IcL-0008EX-1e for speermint@ietf.org; Mon, 17 Dec 2007 11:14:57 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4IcJ-00048U-SR for speermint@ietf.org; Mon, 17 Dec 2007 11:14:56 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JT700K7JBSUDZ@siemenscomms.co.uk> for speermint@ietf.org; Mon, 17 Dec 2007 16:14:55 +0000 (GMT) Date: Mon, 17 Dec 2007 16:14:53 +0000 From: "Elwell, John" Subject: RE: [Speermint] LUF vs. LF In-reply-to: A <3036F4A94122BD4AAAAB441FE88845288EC6E4@300815ANEX3.global.avaya.com> To: "Rodrig, Benny (Benny)" , "Lee, Yiu" , David Schwartz Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D9068@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Speermint] LUF vs. LF Thread-Index: AchAi0EswUeShPUsRlCCIn5f8A9xBwAAaorwAAC8O7AACO7PEAAChLNgAAKNtnA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net> A <45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> <0D5F89FAC29E2C41B98A6A762007F5D04D900F@GBNTHT12009MSX.gb002.siemens.net> A <3036F4A94122BD4AAAAB441FE88845288EC6E4@300815ANEX3.global.avaya.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Benny, Quite so, but the definitions don't make this clear and I am not sure everyone agrees. John=20 > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]=20 > Sent: 17 December 2007 15:15 > To: Elwell, John; Lee, Yiu; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > John, >=20 > My understanding of this was that the LUF could get e.g. an=20 > E164 number > and return a domain name and then the LF follows taking the=20 > domain name > as input and returning how to route to it (i.e. SED). In many=20 > cases they > would be combined, but I suppose there could be cases where you go to > one mechanism (e.g. 'assisting') with a number to find it belongs to > example.com and then you go to another mechanism (e.g.=20 > internal) to find > how to route to example.com. I don't know if this is really what David > meant. Under this interpretation, if you're starting with e.g. > joe@example.com you don't really need the LUF, or you can say it is > trivial. You go straight to LF. >=20 > Benny > =20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, December 17, 2007 8:51 AM > To: Lee, Yiu; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] LUF vs. LF >=20 > Yiu, >=20 > In fact my initial understanding was in line with your understanding > below. However, in trying to clarify if further in that direction, I > encountered a different opinion. >=20 > John=20 >=20 > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > > Sent: 17 December 2007 09:46 > > To: Elwell, John; David Schwartz > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] LUF vs. LF > >=20 > > John, > >=20 > > I think LUF was defined to allow some Assisted SSP to provide only=20 > > registry service. My understanding is many SSP can form a=20 > federation=20 > > where a common registry can translate some input (not defined) to a=20 > > routable AOR. The LUF only returns an AOR. The LF will take the AOR=20 > > and determine the target proxy to route the session to.=20 > Even thought=20 > > most people don't see the difference, but in fact these are two=20 > > different procedures. I agree that most people don't see the=20 > > difference. If we consolidate these two terms into one=20 > function, how=20 > > do you suggest the text to describe the new LF? > >=20 > > Thanks, > > Yiu > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: Monday, December 17, 2007 4:28 AM > > To: David Schwartz > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] LUF vs. LF > >=20 > > David, > >=20 > > There are several things that are unclear - see below. If=20 > other people >=20 > > on this list come forward and say that the definitions are=20 > perfectly=20 > > clear, then I guess I will have to back down. But to me it=20 > seems there >=20 > > are just a few of us, talking at cross purposes, and this=20 > gives me an=20 > > uneasy feeling about the maturity of the drafts. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: David Schwartz [mailto:dschwartz@xconnect.net] > > > Sent: 17 December 2007 08:49 > > > To: Elwell, John > > > Cc: Daryl Malas; speermint@ietf.org > > > Subject: Re: [Speermint] LUF vs. LF > > >=20 > > > Hi John. > > >=20 > > > If indeed LUF is scarcely used in other drafts than I=20 > would say the=20 > > > problem is there and not with maintaining this definition in the=20 > > > terminology draft. I need to re-read the use case draft since the=20 > > > draft I wrote which was incorporated into the=20 > consolidated use-case=20 > > > draft clearly had such a function and this needs to be recaptured. > > >=20 > > > The definitions as they appear in .14 are as follows: > > >=20 > > > 4.3.1. Look-Up Function > > >=20 > > > The Look-Up Function (LUF) provides a mechanism for=20 > querying an > > > internal and/or external database, which maintains a list of=20 > > > peered > > > host domains. > > [JRE] What is the input to the query, and what is the=20 > output from the=20 > > query? Without this information the definition is far too vague. Is=20 > > the input to the query a domain, and it looks to see if=20 > that domain is >=20 > > in the list and answers yes/no and perhaps also responds with other=20 > > information about that domain? Or is the input a SIP URI or=20 > some other >=20 > > form of target address and the output the domain that can=20 > be used to=20 > > reach that target? I believe it is the latter, but the definition=20 > > certainly does not tell me that. > >=20 > > >=20 > > > 4.3.2. Location Function > > >=20 > > > The Location Function (LF) develops SED by discovering the=20 > > > Signaling > > > Function (SF), and SF's reachable host (IP Address and port). > > [JRE] What is the input to the discovery process? > > Also, what is the relationship between LUF and LF. I=20 > thought at first=20 > > that the LUF was performed first, and the output from the=20 > LUF would be >=20 > > the input (or one of the inputs) to the LF. Daryl tells me=20 > I am wrong=20 > > - that the LUF is part of the LF, or more precisely, the LUF is a=20 > > mechanism that the LF uses. > >=20 > > >=20 > > > What is unclear about this? Why do we keep circling the wagons on=20 > > > this? > > >=20 > > > D. > > >=20 > > >=20 > > >=20 > > >=20 > > > On Dec 17, 2007, at 9:26 AM, Elwell, John wrote: > > >=20 > > > > Daryl, > > > > > > > > Thanks for raising this on the list, because it was I who > > expressed > > > > concerns to you on this subject. > > > > > > > > I think it is extremely unlikely that an average reader would=20 > > > > understand, from the present definitions of LF and LUF, > > the meanings > >=20 > > > > you have described below. Therefore something has to be done. > > > > > > > > My preference would be just to define LF. Use of the term > > > LUF in other > > > > drafts is very marginal. The use cases draft talks=20 > about "LF and=20 > > > > LUF" in several places, but does not make a distinction - > > I think it > >=20 > > > > could just refer to LF. The architecture draft does not mention=20 > > > > "LUF". > > > > Therefore I > > > > don't see a compelling reason to have a definition of LUF. > > > > > > > > John > > > > > > > > > > > >> -----Original Message----- > > > >> From: Daryl Malas [mailto:daryl@level3.net] > > > >> Sent: 14 December 2007 21:18 > > > >> To: speermint@ietf.org > > > >> Subject: [Speermint] LUF vs. LF > > > >> > > > >> The topic of the two terms Look-up Function (LUF) and Location=20 > > > >> Function > > > >> (LF) has come up a number of times during and=20 > post-Vancouver. I=20 > > > >> would like to present my opinion of these terms and their=20 > > > >> definitions. > > > >> > > > >> Look-up Function - > > > >> > > > >> This term defines the mechanism for looking up information to=20 > > > >> determine the next hop path for sending a SIP request=20 > to a peer. > > > >> Examples of this > > > >> mechanism is ENUM, DNS (host or domain resolution to an IP=20 > > > >> address), SIP Proxy (acting as a Redirect server). This > > function > > > >> is purely the determination of the appropriate=20 > mechanism for the=20 > > > >> internal or assisted (and/or Federation) databases of=20 > record for=20 > > > >> peering. > > > >> > > > >> Location Function - > > > >> > > > >> This term defines the method for deriving the information.=20 > > > Although > > > >> this truely takes place within the protocol mechanism,=20 > the term=20 > > > >> indicates an additional function in the peering process. > > This also > >=20 > > > >> encompasses defining the fact the associated method may > > use a local > >=20 > > > >> or assisted entity for providing the database of record for=20 > > > >> peering. > > > >> > > > >> I personally believe we could combine these two terms > > into a single > >=20 > > > >> "Location Function", but some have argued the > > granularity provides > > > >> clarity. > > > >> > > > >> Please comment, as I believe, this is the last=20 > remaining sticky=20 > > > >> point in the terminology draft. > > > >> > > > >> Thanks...--Daryl > > > >> > > > >> > > > >> _______________________________________________ > > > >> Speermint mailing list > > > >> Speermint@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/speermint > > > >> > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email > > > Security System. > > > > For more information please visit=20 > http://www.messagelabs.com/email > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 12:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Jlj-0001mR-0h; Mon, 17 Dec 2007 12:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Jli-0001mH-JN for speermint@ietf.org; Mon, 17 Dec 2007 12:28:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Jli-0000dZ-4u for speermint@ietf.org; Mon, 17 Dec 2007 12:28:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2007 12:28:42 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBHHSfiY016966; Mon, 17 Dec 2007 12:28:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBHHSBZU006897; Mon, 17 Dec 2007 17:28:37 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 12:28:28 -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 Subject: RE: [Speermint] Some general comments... Date: Mon, 17 Dec 2007 12:28:52 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30412505E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg2TwecZW0grJ8/Su64MYat4IRqKAAMexJAAgYoOMAAjcoc8A== References: <072C5B76F7CEAB488172C6F64B30B5E303FF6C59@xmb-rtp-20b.amer.cisco.com> From: "Michael Hammer (mhammer)" To: "Hadriel Kaplan" , "David Schwartz" , X-OriginalArrivalTime: 17 Dec 2007 17:28:28.0208 (UTC) FILETIME=[3C7B4300:01C840D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3225; t=1197912521; x=1198776521; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20(mhammer)=22=20 |Subject:=20RE=3A=20[Speermint]=20Some=20general=20comments ... |Sender:=20 |To:=20=22Hadriel=20Kaplan=22=20,=0 A=20=20=20=20=20=20=20=20=22David=20Schwartz=22=20,=20; bh=S4Oir3M6jAQ4m+J4xGDgPrS0uOI3pOSgKjFg4Bs6h0M=; b=zAo9+i3rWRGBUrT3St6X1qU9DtFr0b0p0/hg+sd6bn76neougBJ8pWeVyr SzZRVn4biAVHrZyNBTg2NkNwY/iL5SeryjIbQtsIFyr0inWofDNyu0cDU62u 6f9ld6t+6D; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hadriel, If the topological and relationship information is not available within ENUM and DNS, it is not because it can not be done, but because we haven't gotten busy and defined those parameters to be there yet. Of course, it requires the data to be provisioned with the right values in a registry that is visible. But, that is more a business problem than a technical one. Mike =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Friday, December 14, 2007 4:59 PM > To: Michael Hammer (mhammer); David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Some general comments... >=20 > Michael - when you say "redirecting" a SIP or ENUM request,=20 > do you mean proxying/forwarding, or do you literally mean a=20 > SIP 3xx redirection (or iterative ENUM) model? >=20 > The latter won't work, for a variety of reasons. But I=20 > assume you mean the former: whether call routing should be=20 > done by SIP proxying or recursive ENUM. A recursive ENUM=20 > model won't cover all, IMO. Within a registry federation it=20 > will be useful, because each SSP may well have direct SIP=20 > connection to each other (ie, a full mesh), and thus a=20 > recursive ENUM query can tell the originating SSP the right=20 > ingress SBE for the terminating SSP. The problem, of course,=20 > is not all SSPs have connectivity to all SSPs, and ENUM has=20 > no topological view of the relationships and equipment that=20 > exist in between. >=20 > In other words even if we can figure out how to get SSP2's=20 > subscriber data to be "seen" by SSP1, so that SSP1 can do an=20 > ENUM dip and get back SSP2's subscriber AoR or ingress point,=20 > it has nothing to do with whether SSP1 can actually reach=20 > SSP2 at a SIP layer, or what transit SSPs (and SBEs) it has=20 > to traverse to do so. I guess we'll see whether that=20 > particular aspect will be covered by PEPPERMINT. :) >=20 > -hadriel >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, December 04, 2007 9:33 AM > > To: David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Some general comments... > > > > David, > > > > At a high level, the answer to your question is whether the "call=20 > > routing" is done via redirecting a SIP request hop by hop=20 > through many=20 > > SP networks and their proxies to the terminating network and=20 > > terminating end-user, or whether it is done by redirecting ENUM=20 > > queries through a sequence of registries until the=20 > originating VoIP SP=20 > > serving the caller can connect as directly as possible to the=20 > > terminating VoIP SP serving the called user. > > > > In short, route through SP's/proxies or route through databases. I=20 > > would contend that the latter is much more efficient and the reason=20 > > for SPEERMINT. Minimize the middlemen. > > > > The use of registries also allows the application of some=20 > control over=20 > > who learns what ingress to go through, as well as some load=20 > balancing=20 > > and perhaps congestion control and perhaps some SPIT control. > > > > Mike >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 15:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MZz-0007US-2R; Mon, 17 Dec 2007 15:28:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MZx-0007UL-1d for speermint@ietf.org; Mon, 17 Dec 2007 15:28:45 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4MZw-0007Dq-FN for speermint@ietf.org; Mon, 17 Dec 2007 15:28:44 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J4MZv-00054d-00 for ; Mon, 17 Dec 2007 21:28:43 +0100 Date: Mon, 17 Dec 2007 21:28:43 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] LUF vs. LF Message-ID: <20071217202842.GA19501@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <0D5F89FAC29E2C41B98A6A762007F5D04D8F6D@GBNTHT12009MSX.gb002.siemens.net> <45AEC6EF95942140888406588E1A66020367E116@PACDCEXCMB04.cable.comcast.com> <0D5F89FAC29E2C41B98A6A762007F5D04D900F@GBNTHT12009MSX.gb002.siemens.net> <3036F4A94122BD4AAAAB441FE88845288EC6E4@300815ANEX3.global.avaya.com> <0D5F89FAC29E2C41B98A6A762007F5D04D9068@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D04D9068@GBNTHT12009MSX.gb002.siemens.net> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/12/17 17:12, "Elwell, John" wrote: > Benny, > > Quite so, but the definitions don't make this clear and I am not sure > everyone agrees. John, that's my impression as well. IMHO we just need to pepper the terminology draft with a few examples and it should be clearer whether we're all interpreting the definitions the same way. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Dec 17 15:55:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Mzi-00041H-SG; Mon, 17 Dec 2007 15:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Mzh-000406-5J for speermint@ietf.org; Mon, 17 Dec 2007 15:55:21 -0500 Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Mzf-0000TX-Dm for speermint@ietf.org; Mon, 17 Dec 2007 15:55:21 -0500 Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Dec 2007 12:54:48 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 12:55:04 -0800 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 Subject: RE: [Speermint] Some general comments... Date: Mon, 17 Dec 2007 15:55:06 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280C0509C6@proton.jnpr.net> In-Reply-To: <20071214125126.GB16101@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Some general comments... Thread-Index: Acg+UBfxF2jI5O3xTwGMKkBq/ngsHgCno9bA From: "Reinaldo Penno" To: "Otmar Lendl" , X-OriginalArrivalTime: 17 Dec 2007 20:55:04.0758 (UTC) FILETIME=[1966AD60:01C840EF] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Actually, I'm not doing the architecture as you imply, the IETF is. I'm one of the co-author and editor but follow IETF guidelines on putting the document together. If you think something is not right with the document, please point out and/or suggest text so we can get consensus. Your previous comments to the doc were put before the WG in the last meeting in case you do not know. Thanks, Reinaldo > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Friday, December 14, 2007 4:51 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Some general comments... >=20 > On 2007/12/11 11:12, Reinaldo Penno wrote: > > It seems the discussion died down. This is important to=20 > allow us poor=20 > > editors to update the drafts. Are we having a LUF and LF=20 > function in=20 > > the terminology draft? Should I include them in the=20 > architecture? Are=20 > > we having a resolution function which is composed of both? .... >=20 > Well, _you're_ doing the architecture. It should be your=20 > design which defines whether we need these two terms or not.=20 > There is no point in adding boxes to your architecture=20 > document just because we have defined some terms. >=20 > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: -=20 > 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft=20 > m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 18 13:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h7i-0001b7-UL; Tue, 18 Dec 2007 13:24:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h7h-0001aj-PS for speermint@ietf.org; Tue, 18 Dec 2007 13:24:57 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4h7g-0007Nz-9g for speermint@ietf.org; Tue, 18 Dec 2007 13:24:57 -0500 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.40347190; Tue, 18 Dec 2007 13:24:14 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 13:24:14 -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: Tue, 18 Dec 2007 13:24:13 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020307DEF4@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Off-Topic: 71st IETF - Registration Thread-Index: AchBjxWoqEuuLjF9TG2ubb5oUjjvfwAE8Wzg From: "Livingood, Jason" To: X-OriginalArrivalTime: 18 Dec 2007 18:24:14.0228 (UTC) FILETIME=[31472540:01C841A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Speermint] Off-Topic: 71st IETF - Registration X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Since not everyone is on the announce list, please note that IETF 71 registration is now open. Please take note of the hotel info if you will travel to the city ahead of the IETF meeting.* Regards Jason=20 Your Friendly WG Co-Chair and Sponsor of IETF 71 :-) * Reservations Alert - Reserve Early!! If you are considering arriving on the Saturday before IETF 71 (March 8, 2008), please be aware that the Philadelphia Flower Show is taking place next door at the Philadelphia Convention Center. This is a very popular show which attracts over 250,000 people each year. It is run by the Pennsylvania Horticultural Society, and is the largest indoor flower show in the world. That show ends on the Sunday that IETF 71 begins, so most people will be checking out the same day that most IETF people will be checking in. Thus, if you plan to arrive early, contact the hotel ASAP to make your reservation and understand that the Saturday rate may be higher (or unavailable) due to high demand.=20 -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org]=20 Sent: Tuesday, December 18, 2007 10:59 AM To: IETF Announcement list Cc: wgchairs@ietf.org Subject: 71st IETF - Registration=20 71st IETF Meeting Philadelphia, PA, USA March 9-14, 2008 Registration is now open for the 71st IETF Meeting! You can register on line at:=20 http://www.ietf.org/meetings/71-IETF.html REGISTRATION INFORMATION: Early-Bird Registration - USD 635.00 If you register and pay for your attendance to the IETF-71 before 17:00 ET-US (22:00 UTC/GMT), Friday, 29 February 2008, you will pay the early-bird price of USD 635.00.=20 =20 After Early-Bird cutoff - USD 785.00 =20 You can still register and pay online at USD 785.00 until 17:00 ET-US (22:00 UTC/GMT), Friday, March 7 2008. Full-time Student Registrations - USD 150.00 Full-time students with proper ID are eligible to receive a special USD 150.00 student rate. Student rate is not subject to any late-fees. Students will also be able to register on-site at the special student rate. Failure to provide valid student ID on-site will revoke the special student status.=20 CANCELLATION: The cut-off for registration cancellation is Monday, 3 March at 17:00 ET-US (22:00 UTC/GMT). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. ON-SITE REGISTRATION: You can register onsite at the meeting in Philadelphia, PA, USA starting Sunday, 9 March at 12:00 noon (local time - ET). The IETF meetings start Monday morning and run through Friday lunchtime, with late scheduling changes. Most training session take place on Sunday afternoon 9 March. Participants should plan their travel accordingly. The IETF Secretariat _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Dec 18 13:25:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h7r-00020S-5J; Tue, 18 Dec 2007 13:25:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h7p-0001vw-Cd for speermint@ietf.org; Tue, 18 Dec 2007 13:25:05 -0500 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4h7o-0006Gj-V1 for speermint@ietf.org; Tue, 18 Dec 2007 13:25:05 -0500 Received: from ([10.52.116.30]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.14907063; Tue, 18 Dec 2007 13:24:42 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 13:24:42 -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: Tue, 18 Dec 2007 13:24:42 -0500 Message-ID: <45AEC6EF95942140888406588E1A66020307DEF5@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Off-Topic: IETF 71 Microsite Thread-Index: AchBjxWoqEuuLjF9TG2ubb5oUjjvfwAE2gyAAAAdN2A= From: "Livingood, Jason" To: X-OriginalArrivalTime: 18 Dec 2007 18:24:42.0490 (UTC) FILETIME=[421F95A0:01C841A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Speermint] Off-Topic: IETF 71 Microsite X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Since not everyone is on the announce list, please take note of the microsite below. Regards Jason=20 Your Friendly WG Co-Chair and Sponsor of IETF 71 :-)=20 -----Original Message----- From: Livingood, Jason=20 Sent: Tuesday, December 18, 2007 1:21 PM To: IETF Announcement list Cc: wgchairs@ietf.org Subject: IETF 71 Microsite=20 FYI - We have setup a small website regarding IETF 71 at http://ietf71.comcast.net for attendees This site includes additional hotel recommendations, information about traveling to the city, the social event, and will include important information about such topics as where to get a good drink or where to eat. :-) You can get updates via RSS feed too. Regards Jason Livingood Comcast=20 > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] > Sent: Tuesday, December 18, 2007 10:59 AM > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: 71st IETF - Registration >=20 > 71st IETF Meeting > Philadelphia, PA, USA > March 9-14, 2008 >=20 > Registration is now open for the 71st IETF Meeting! >=20 > You can register on line at:=20 > http://www.ietf.org/meetings/71-IETF.html >=20 > REGISTRATION INFORMATION: > Early-Bird Registration - USD 635.00 >=20 > If you register and pay for your attendance to the IETF-71 before=20 > 17:00 ET-US (22:00 UTC/GMT), Friday, 29 February 2008, you will pay=20 > the early-bird price of USD 635.00. > =20 > After Early-Bird cutoff - USD 785.00 > =20 > You can still register and pay online at USD 785.00 until 17:00 ET-US=20 > (22:00 UTC/GMT), Friday, March 7 2008. >=20 > Full-time Student Registrations - USD 150.00 >=20 > Full-time students with proper ID are eligible to receive a special=20 > USD 150.00 student rate. Student rate is not subject to any late-fees. > Students will also be able to register on-site at the special student=20 > rate. Failure to provide valid student ID on-site will revoke the=20 > special student status. >=20 > CANCELLATION: >=20 > The cut-off for registration cancellation is Monday, 3 March at 17:00=20 > ET-US (22:00 UTC/GMT). Cancellations are subject to a 10% (ten=20 > percent) cancellation fee if requested by that date and time. >=20 > ON-SITE REGISTRATION: >=20 > You can register onsite at the meeting in Philadelphia, PA, USA=20 > starting Sunday, 9 March at 12:00 noon (local time - ET). >=20 > The IETF meetings start Monday morning and run through Friday=20 > lunchtime, with late scheduling changes. Most training session take=20 > place on Sunday afternoon 9 March. Participants should plan their=20 > travel accordingly. >=20 > The IETF Secretariat >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Dec 21 09:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5j4G-0005A2-B4; Fri, 21 Dec 2007 09:41:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5j4E-00059w-Tp for speermint@ietf.org; Fri, 21 Dec 2007 09:41:38 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5j4D-0000VT-9A for speermint@ietf.org; Fri, 21 Dec 2007 09:41:38 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id B790C9946 for ; Fri, 21 Dec 2007 09:41:34 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Dec 2007 09:41:34 -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: Fri, 21 Dec 2007 09:41:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Best wishes to everyone this holiday season Thread-Index: AchD35ToZqq/mKMDTP6v7V/Xw7lFIQ== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 21 Dec 2007 14:41:34.0656 (UTC) FILETIME=[95977C00:01C843DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Speermint] Best wishes to everyone this holiday season X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I hope everyone enjoys the holidays, and all the best to you and your families. I shared this parting gift with folks at work, and decided to share with my fellow ietf-ers...for those of you that are xkcd.com fans, the author (Randall Munroe) spoke at Google a couple weeks ago, and here's the footage - http://youtube.com/watch?v=3DzJOS0sV2a24 . For those of you that _aren't_ fans, checkout http://xkcd.com and become one!=20 Hope to see everyone in the city of brotherly love this coming March. Adam Uzelac Director, Converged Network Arch and Planning Global Crossing 585-563-4359 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint