From enum-bounces@ietf.org Mon Aug 01 06:49:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXrA-00027O-IF; Mon, 01 Aug 2005 06:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzXr9-00027A-Dj for enum@megatron.ietf.org; Mon, 01 Aug 2005 06:49:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29540 for ; Mon, 1 Aug 2005 06:49:12 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzYNP-00028j-5F for enum@ietf.org; Mon, 01 Aug 2005 07:22:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id F14966CEDC; Mon, 1 Aug 2005 11:45:34 +0100 (BST) In-Reply-To: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C1D1@erol.Westbrooke.bango.net> References: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C1D1@erol.Westbrooke.bango.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BF9750A-6ACA-4888-B80C-D7EFA4DE8F8E@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Date: Mon, 1 Aug 2005 11:48:40 +0100 To: Tim Moss X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.8 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, Ray Anderson , Richard Shockey Subject: [Enum] Re: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi There Tim, Ray, Please read the draft and the earlier mails from the ML-archive. I don't know how I can spell it out with more clarity than I already have. There still seem to be folk who think that this is a ->client<- machine capability specification. Such an interpretation is Incorrect. If someone wants to do such a thing, then they can, of course, work on their own Enumservice spec, but this is not it. The Enumservice proposal in 'draft-ra-shen-enum-mobileweb-01' allows the content provider to specify the forms in which content is provided, and for these specifications to be associated with a telephone number (via ENUM). Thus, for example, a service provider might provide a "personal web page" for their customer, and the forms in which this content is available could be published in the equivalent ENUM zone. It does not specify the capabilities of a client machine - I would be fascinated with an analysis of the message exchanges needed between different nodes to use such data. Device capability/content form negotiation is indeed an option that (no doubt) the W3C and the Mobi JV members will develop/complete in the future. However, ->this<- Enumservice specification is NOT intended to do that. In earlier mails I have already mentioned the "bootstrap problem" that exists in the real world, in that once a client has started to request content using (say) WAP, then switching to another available form is an expensive shift - it takes bandwidth and time. If you believe that this can be avoided using non-proprietary means (and that will work with existing devices) then please spell it out. In the interim, the 'mobileweb' Enumservice allows the client to know what is available - as you mention, without negotiation only the client can know what is its capability, and so is in a position to select between the different available options using whatever browsers it has to hand. This Enumservice means that the client doesn't need to guess. all the best, Lawrence On 31 Jul 2005, at 23:16, Tim Moss wrote: > I very much agree with Ray here. > > It would definitely be a good idea to discuss this proposal with the > World Wide Web Consortium (W3C) Mobile Web Initiative (MWI) as they > are > putting significant resource into this area, in particular there are > three W3C working groups that should be contacted. > > These are the Device Independence Working Group (DIWG), the MWI Best > Practices Working Group (BPWG) and the Device Description Working > Group > (DDWG). > > I don't believe that ENUM is necessarily the right place for storing > general device capabilities. A single phone number could be used by > multiple devices (e.g. if the internet connection is initiated over > Bluetooth to a mobile device) with varying capabilities, or the same > device may have multiple 'browser' clients installed on it e.g. WML > browser, IMODE browser, video player etc. > > However, ENUM could be a good place for a user to describe their > particular preferences with respect to how they would like content > to be > presented to them, and potentially override any automatic content > adaptation that may otherwise occur. > > This should definitely be worked out in detail with the MWI though > rather than splintering off into two (or more) different solutions for > achieving the same result. > > > Tim Moss > CTO > Bango > > e: tim@bango.com > m: +44 78 8779 4032 > t: +44 12 2347 2823 > w: http://www.bango.com > > > Mobile Content World 2005 > ****************************************************************** > "Come and see us on stand 14 at MCW 2005 > Olympia Conference Centre, London, UK > 13th - 15th September 2005" > www.mobilecontentworld.biz > > > >> -----Original Message----- >> From: Ray Anderson [mailto:ray@bango.net] >> Sent: 25 July 2005 11:42 >> To: lconroy; Richard Shockey >> Cc: 'enum@ietf.org' ENUM; Tim Moss >> Subject: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt >> >> >> Here are my top level comments: >> >> The idea here seems to be to provide "clues" about the >> services available at an ENUM addressible site so that a >> device or user that could make use of those clues could >> provide a better service to the end user. >> >> The aims are good, but acfetr careful consideration I believe >> that this proposal is wrong in its approach, and also wrong >> as an ENUMservice. I recommend the authors get involved in >> the Mobile Web Initiative. >> http://www.w3.org/2005/MWI/ >> >> (1) Wrong Approach >> >> The W3C is currently engaged on a Mobile Web Initiative which >> is working hard to ensure that web sites can give an improved >> experience to mobile users. Currently most web sites are >> optimized to big screen users >> with a "PC environment (keyboard, distraction level etc.). >> There are many >> parts to this, not least of which >> is that the web site can use information presented by the end >> user device (HTTP_ACCEPT among others) to determine how best >> to deliver a good experience to users. In addition, the site >> can redirect to alternative services that might help, if teh >> device has certain characteristics. >> >> Therefore, the idea of tagging a site with different URL's >> that are selected between by the client device or the user >> should not be necessary, and in fact is more limited because >> the hosting site should be able to evolve and adapt its >> capabilities much faster than the client device. >> >> There are many reasons why one URL for content promotion / >> bookmarking / passing on is a good thing. Thats probably why >> the .MOBI TLD met with so much derision, and was rejected by >> W3C, 3GPP, and content providers. >> >> >> (2) Wrong as an ENUM service >> >> If the ENUM service approach (not withstanding the above) >> was to be useful, then surely it should be available across >> all domains, not just those in e164.arpa, for example in >> www.neustar.biz so that devices accessing those domains can >> also provide more appropriate URL's depending on the support >> for WAP, ME, iMode, xHTML, VoiceXML, Flash, etc. In that >> case, the extra "clues" should become a general DNS facility, >> otherwise only sites accessed by enum URL's could provide the >> ease of use. >> >> In that case I assume there is some other working group that >> should look at the proposal. >> >> >> >> >> At 13:09 23/07/2005, lconroy wrote: >> >>> Hi Folks, >>> In case no-one noticed, the mobileweb draft has been updated >>> to "draft-ra-shin-enum-mobileweb-01.txt". >>> >>> This draft is covered in section 3.3 of the Agenda. >>> I would suggest that folk look at the new version BEFORE the ENUM >>> meeting - the changes are editorial rather than technical, >>> >> but given how some >> >>> people seem to have interpreted the -00 version so far, >>> >> perhaps this one >> >>> will clarify things and avoid unnecessary flights of fancy. >>> >>> I would also advise folk to look at the "modest proposal" draft, but >>> as it seems vanishingly unlikely that there will be time to >>> >> cover that in >> >>> the meeting, questions/comments to the list would be appreciated. >>> >>> all the best, >>> Lawrence >>> >> >> > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 02 06:29:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu1L-0006Tf-9G; Tue, 02 Aug 2005 06:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu1H-0006QV-4e; Tue, 02 Aug 2005 06:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06113; Tue, 2 Aug 2005 06:29:08 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuXg-0007ch-0S; Tue, 02 Aug 2005 07:02:44 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j72ASoPj030021; Tue, 2 Aug 2005 03:28:50 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j72ASoxb030020; Tue, 2 Aug 2005 03:28:50 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 2 Aug 2005 03:28:50 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20050802102850.GA29990@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] voipeer BOF scheduling update X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0844248221==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0844248221== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, Due to numerous scheduling issues, the voipeer BOF has been rescheduled. We will be meeting at 1400 on Wednesday in room 342. I realize this isn't perfect, but there is very little we can do about this at this point (I'll just point out that Marcia has been doing her best to accommodate us).=20 Thanks for your patience on this, and track me down if you have questions or comments. Dave --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC70riORgD1qCZ2KcRArIjAJ9PgrFV2pDUJiYsZQNFNUnb+KsaHACfaD+n h0Qb0IZS4zTt/CGUNHMCO9M= =ZoZj -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- --===============0844248221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0844248221==-- From enum-bounces@ietf.org Tue Aug 02 09:24:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwkY-0000pk-1v; Tue, 02 Aug 2005 09:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwkW-0000nL-2K for enum@megatron.ietf.org; Tue, 02 Aug 2005 09:24:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18425 for ; Tue, 2 Aug 2005 09:24:02 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxGy-0007lu-Fq for enum@ietf.org; Tue, 02 Aug 2005 09:57:38 -0400 Received: from [86.255.29.4] (open-29-4.ietf63.ietf.org [86.255.29.4]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j72DORxc012631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2005 06:24:29 -0700 Message-ID: <42EF73DB.1030903@shockey.us> Date: Tue, 02 Aug 2005 09:23:39 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Enum] Presentations for Friday X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org If you plan on presenting on Friday please try and have your Powerpoints or PDF files ready by Thur PM. Email them to me so I can then have them loaded on my machine before the meeting starts in order to avoid the usual technical delays. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 03 10:22:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K8C-00077X-2Q; Wed, 03 Aug 2005 10:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K89-00070v-TP for enum@megatron.ietf.org; Wed, 03 Aug 2005 10:22:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21116 for ; Wed, 3 Aug 2005 10:21:57 -0400 (EDT) Received: from smtp.bango.net ([62.254.208.133] helo=erol.Westbrooke.bango.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Ken-0003l6-W0 for enum@ietf.org; Wed, 03 Aug 2005 10:55:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 3 Aug 2005 15:21:37 +0100 Message-ID: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C435@erol.Westbrooke.bango.net> Thread-Topic: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Thread-Index: AcWWhp9qpiLtF83+Q0O/iniX0gH2fwA/22rw From: "Tim Moss" To: "lconroy" X-Spam-Score: 0.8 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Ray Anderson , Richard Shockey Subject: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > From: lconroy [mailto:lconroy@insensate.co.uk]=20 >=20 > Hi There Tim, Ray, >=20 > Please read the draft and the earlier mails from the=20 > ML-archive. I don't know how I can spell it out with more=20 > clarity than I already have. > There still seem to be folk who think that this is a > ->client<- > machine capability specification. >=20 > Such an interpretation is Incorrect. Lawrence, Please accept this email as constructive criticism, as that is the intention. I did read the updated version of the draft and along with others understood it as being related to the client phone number. I joined this list after the main flurry of emails on this particular topic so only had the updated draft document as a starting point. I've since found and read the list archive, where you've explained much much more about the draft. Surely the fact that so many people misinterpreted it indicates that the draft itself is easily misunderstood. It really doesn't describe at all well how the service is likely to be used. If you'd included a few examples of its use like the one below then much confusion could have been avoided. > The Enumservice proposal in 'draft-ra-shen-enum-mobileweb-01'=20 > allows the content provider to specify the forms in which=20 > content is provided, and for these specifications to be=20 > associated with a telephone number (via ENUM). >From our experience dealing with many many mobile content providers this isn't a problem that needs to be solved. A content provider offering a service in more than one of WML,cHTML,HTML,xHTML will do so server-side from the same URL. The client just accesses the one single URL and is dynamically served up content appropriate for it. If the content provider can't do this themselves then Bango offers a services so that they can. > Thus, for example, a service provider might provide a "personal web=20 > page" for their customer, and the forms in which this content=20 > is available could be published in the equivalent ENUM zone. Other than the personal web page situation (and quite honestly even then) how much use will this get? How likely are users to associate a phone number with a content site? How do they discover these phone numbers in the first place? What does a content provider do if they have more mobile sites than they do phone numbers? If I'm looking for information about Microsoft I go to microsoft.com, for Vodafone to vodafone.com. If this approach fails then Google is pretty good. Surely entering a web address is easier and more likely to get a result than typing in a phone number (even if I knew which phone number to try). If I want to get to the German version of the Microsoft website, do I have to find their German phone number first? Its much quicker to change .com to .de If people want a personal web page are they really likely to want to publish it under their phone number? Imagine the number of nuisance calls they would get if anything on their homepage could be considered offensive, or even if they'd just spelt something wrong. Most people pick a domain name that relates either to the subject of their homepage, relates to their own name or is just plain fun. They then have the choice of including their phone number for all to see or not. > It does not specify the capabilities of a client machine - I=20 > would be fascinated with an analysis of the message exchanges=20 > needed between different nodes to use such data. The W3C Device Independence Working Group, Device Description Working Group and Mobile Web Initiative are currently working on exactly this. Since this issue is one that affects all websites, the above groups are in a much better position to deal with the issue, rather than limiting it to a small number of sites that can be forced rather uncomfortably into an ENUM scheme. > In earlier mails I have already mentioned the "bootstrap problem" that exists in the real world, This problem doesn't prevail in the real world either, not in our experience anyway. A mobile device will try to connect to the mobile operator's WAP,i-mode, or 'Internet' gateway based on "connection settings" configured on that device. The user types in a URL http://www.somesite.com and the browser connects via the gateway specified in the "connection settings" using the protocol appropriate for that gateway. > in that once a client has started to request content using (say) WAP, > then switching to=20 > another available form is an expensive shift - it takes=20 > bandwidth and time. If you believe that this can be avoided=20 > using non-proprietary means (and that will work with existing=20 > devices) then please spell it out. How much will actually be saved though - with this scheme the client presumably needs to first send an extra request to lookup in e164.arpa the information this ENUM service proposes to store. So how does it make this first request if it doesn't in general know how to connect to the internet? Even if it can make the lookup, this extra connection/request is likely to be just as expensive as the one you are trying to avoid, so there's no net gain. > In the interim, the 'mobileweb' Enumservice allows the client to know what is available=20 It only lets the client know what was available at the time of the last update to ENUM, and only what is available on that one specific URL, and it is only as accurate as the person who maintains the ENUM record wants it to be. =20 Assuming the destination document at the specified URL works ok on a mobile, it may link to many other sites that may not be mobile sites, or other pages on that same site may not display on mobile devices. Worse still, how do I know that the site will work on *my* particular phone, which may have one of a whole range of screen sizes and resolutions, it may or may not support the image formats used in the site, it may or may not accept a page with more than 4K of data in it etc. etc. The range of device compatibility problems go way beyond the simple WAP,ME,i-mode choice that this services tries to boil them down to. > - as you mention, without negotiation only the client can know what is its capability, and so is in a position to select between the different=20 > available options using whatever browsers it has to hand.=20 > This Enumservice means that the client doesn't need to guess. Again, in our experience the client doesn't actually need to guess. Based on the MIME types of the response received from the content server, which will be based on the types the browser indicates it can handle (HTTP_ACCEPT request header) the client knows whether the document is HTML,WML,cHTML,XHTML and can parse and render the content accordingly. Most mobile devices these days will cope admirably with content in any of these markup languages, whether they get displayed as the content author intended is a whole different kettle of fish. I can see that this service fits alongside the "web" and "ft" services that allow ENUM to store the fact that an http://xyz URL is a web site and that an ftp://xyz URL is an FTP site (you can kind of tell that from the URI scheme though), but its premise seems flawed as it appears to be trying to solve problems that don't exist, and doesn't address ones that do. Just because ENUM can store this information doesn't mean it should. If you're looking for the "killer app" for ENUM, then like ".mobi" in the DNS world, I really don't believe "mobileweb" isn't going to be it. > all the best, > Lawrence >=20 >=20 > On 31 Jul 2005, at 23:16, Tim Moss wrote: > > I very much agree with Ray here. > > > > It would definitely be a good idea to discuss this proposal=20 > with the=20 > > World Wide Web Consortium (W3C) Mobile Web Initiative (MWI) as they=20 > > are putting significant resource into this area, in=20 > particular there=20 > > are three W3C working groups that should be contacted. > > > > These are the Device Independence Working Group (DIWG), the=20 > MWI Best=20 > > Practices Working Group (BPWG) and the Device Description Working=20 > > Group (DDWG). > > > > I don't believe that ENUM is necessarily the right place=20 > for storing=20 > > general device capabilities. A single phone number could=20 > be used by=20 > > multiple devices (e.g. if the internet connection is initiated over=20 > > Bluetooth to a mobile device) with varying capabilities, or=20 > the same=20 > > device may have multiple 'browser' clients installed on it e.g. WML=20 > > browser, IMODE browser, video player etc. > > > > However, ENUM could be a good place for a user to describe their=20 > > particular preferences with respect to how they would like=20 > content to=20 > > be presented to them, and potentially override any=20 > automatic content=20 > > adaptation that may otherwise occur. > > > > This should definitely be worked out in detail with the MWI though=20 > > rather than splintering off into two (or more) different=20 > solutions for=20 > > achieving the same result. > > > > > > Tim Moss > > CTO > > Bango > > > > e: tim@bango.com > > m: +44 78 8779 4032 > > t: +44 12 2347 2823 > > w: http://www.bango.com > > > > > > Mobile Content World 2005 > > ****************************************************************** > > "Come and see us on stand 14 at MCW 2005 Olympia Conference Centre,=20 > > London, UK 13th - 15th September 2005" > > www.mobilecontentworld.biz > > > > > > > >> -----Original Message----- > >> From: Ray Anderson [mailto:ray@bango.net] > >> Sent: 25 July 2005 11:42 > >> To: lconroy; Richard Shockey > >> Cc: 'enum@ietf.org' ENUM; Tim Moss > >> Subject: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt > >> > >> > >> Here are my top level comments: > >> > >> The idea here seems to be to provide "clues" about the services=20 > >> available at an ENUM addressible site so that a device or=20 > user that=20 > >> could make use of those clues could provide a better=20 > service to the=20 > >> end user. > >> > >> The aims are good, but acfetr careful consideration I believe that=20 > >> this proposal is wrong in its approach, and also wrong as an=20 > >> ENUMservice. I recommend the authors get involved in the=20 > Mobile Web=20 > >> Initiative. > >> http://www.w3.org/2005/MWI/ > >> > >> (1) Wrong Approach > >> > >> The W3C is currently engaged on a Mobile Web Initiative which is=20 > >> working hard to ensure that web sites can give an improved=20 > experience=20 > >> to mobile users. Currently most web sites are optimized to big=20 > >> screen users with a "PC environment (keyboard, distraction level=20 > >> etc.). > >> There are many > >> parts to this, not least of which > >> is that the web site can use information presented by the end user=20 > >> device (HTTP_ACCEPT among others) to determine how best to=20 > deliver a=20 > >> good experience to users. In addition, the site can redirect to=20 > >> alternative services that might help, if teh device has certain=20 > >> characteristics. > >> > >> Therefore, the idea of tagging a site with different URL's=20 > that are=20 > >> selected between by the client device or the user should not be=20 > >> necessary, and in fact is more limited because the hosting site=20 > >> should be able to evolve and adapt its capabilities much=20 > faster than=20 > >> the client device. > >> > >> There are many reasons why one URL for content promotion /=20 > >> bookmarking / passing on is a good thing. Thats probably why the=20 > >> .MOBI TLD met with so much derision, and was rejected by=20 > W3C, 3GPP,=20 > >> and content providers. > >> > >> > >> (2) Wrong as an ENUM service > >> > >> If the ENUM service approach (not withstanding the above)=20 > was to be=20 > >> useful, then surely it should be available across all domains, not=20 > >> just those in e164.arpa, for example in www.neustar.biz so that=20 > >> devices accessing those domains can also provide more appropriate=20 > >> URL's depending on the support for WAP, ME, iMode, xHTML,=20 > VoiceXML,=20 > >> Flash, etc. In that case, the extra "clues" should become=20 > a general=20 > >> DNS facility, otherwise only sites accessed by enum URL's could=20 > >> provide the ease of use. > >> > >> In that case I assume there is some other working group=20 > that should=20 > >> look at the proposal. > >> > >> > >> > >> > >> At 13:09 23/07/2005, lconroy wrote: > >> > >>> Hi Folks, > >>> In case no-one noticed, the mobileweb draft has been updated to=20 > >>> "draft-ra-shin-enum-mobileweb-01.txt". > >>> > >>> This draft is covered in section 3.3 of the Agenda. > >>> I would suggest that folk look at the new version BEFORE the ENUM=20 > >>> meeting - the changes are editorial rather than technical, > >>> > >> but given how some > >> > >>> people seem to have interpreted the -00 version so far, > >>> > >> perhaps this one > >> > >>> will clarify things and avoid unnecessary flights of fancy. > >>> > >>> I would also advise folk to look at the "modest proposal"=20 > draft, but=20 > >>> as it seems vanishingly unlikely that there will be time to > >>> > >> cover that in > >> > >>> the meeting, questions/comments to the list would be appreciated. > >>> > >>> all the best, > >>> Lawrence > >>> > >> > >> > > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 03 10:57:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Kge-0002LQ-4N; Wed, 03 Aug 2005 10:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Kgd-0002LI-5B for enum@megatron.ietf.org; Wed, 03 Aug 2005 10:57:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23809 for ; Wed, 3 Aug 2005 10:57:36 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LDF-0005OS-BC for enum@ietf.org; Wed, 03 Aug 2005 11:31:26 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id EB4FD1A38D; Wed, 3 Aug 2005 16:57:09 +0200 (CEST) Date: Wed, 3 Aug 2005 16:57:09 +0200 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Message-ID: <20050803145709.GA13236@nic.at> References: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C435@erol.Westbrooke.bango.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C435@erol.Westbrooke.bango.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org (Just a minor point, I don't address the bulk of your argument.) On 2005/08/03 16:08, Tim Moss wrote: > > Surely entering a web address is easier and more likely to get a result > than typing in a phone number (even if I knew which phone number to > try). On a simple phone with a 3x4 numerical keypad a number (especially your typical 1800-CALLNOW type vanity number) is be a lot simpler to input than a web address. That does not hold on a full blown user interface with an alphanumeric keyboard. On such a platform, URLs win. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 03 11:05:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KoW-0006nr-2u; Wed, 03 Aug 2005 11:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KoU-0006m9-Hm for enum@megatron.ietf.org; Wed, 03 Aug 2005 11:05:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24261 for ; Wed, 3 Aug 2005 11:05:44 -0400 (EDT) Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0LLB-0005kM-Bc for enum@ietf.org; Wed, 03 Aug 2005 11:39:34 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j73F5cwk003395Wed, 3 Aug 2005 15:05:38 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1E0KoM-0001dd-00; Wed, 03 Aug 2005 16:05:38 +0100 Date: Wed, 3 Aug 2005 16:05:37 +0100 From: "Clive D.W. Feather" To: Tim Moss Subject: Re: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Message-ID: <20050803150537.GD71410@finch-staff-1.thus.net> References: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C435@erol.Westbrooke.bango.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C435@erol.Westbrooke.bango.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, Ray Anderson , lconroy , Richard Shockey X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Tim Moss said: > If people want a personal web page are they really likely to want to > publish it under their phone number? Imagine the number of nuisance > calls they would get if anything on their homepage could be considered > offensive, or even if they'd just spelt something wrong. Even if they do, why can't it just be stored at ? Accessed through a simple A record, of course, not a complex regex thingy. [A public service would be to set up a name server that maps anything.441223472823.some.domain to anything.3.2.8.2.7.4.3.2.2.1.4.4.e164.arpa for all possible values.] -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 03 12:33:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MAu-0003jN-O2; Wed, 03 Aug 2005 12:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0MAt-0003j7-1X for enum@megatron.ietf.org; Wed, 03 Aug 2005 12:32:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29232 for ; Wed, 3 Aug 2005 12:32:56 -0400 (EDT) Received: from smtp.bango.net ([62.254.208.133] helo=erol.Westbrooke.bango.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Mha-0000se-CV for enum@ietf.org; Wed, 03 Aug 2005 13:06:47 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Date: Wed, 3 Aug 2005 17:32:47 +0100 Message-ID: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C45D@erol.Westbrooke.bango.net> Thread-Topic: [Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt Thread-Index: AcWYO/ueLpw0KjuFSmuGxbPQG7eBtgAAUayw From: "Tim Moss" To: "Otmar Lendl" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Otmar, you are quite right - I didn't phrase that very well. I wasn't really talking literally about the process of entering the site address, more about how a user discovers and remembers what it is they have to type in. =20 However Bango believe your point is a very important one. In general the shorter the address a user has to type in, the fewer unusual symbols, and the more memorable it can be the better. Bango offer a service where a user can enter the "phone spelling" of a number as you use in your example, usually chosen to have some brand significance or some relation to the service being offered, or the number itself it that is more 'memorable' which it may be for some fairly short numbers. This easy access method works on the web as well as on mobile, but is far more useful on mobile devices for the reasons you state below. =20 =20 Tim Moss CTO Bango =20 e: tim@bango.com m: +44 78 8779 4032 t: +44 12 2347 2823 w: http://www.bango.com =20 =20 Mobile Content World 2005=20 ****************************************************************** "Come and see us on stand 14 at MCW 2005 Olympia Conference Centre, London, UK 13th - 15th September 2005" www.mobilecontentworld.biz=20 =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Otmar Lendl > Sent: 03 August 2005 15:57 > To: enum@ietf.org > Subject: Re: [Enum] RE: COMMENTS on=20 > draft-ra-shin-enum-mobileweb-01.txt >=20 >=20 > (Just a minor point, I don't address the bulk of your argument.) >=20 > On 2005/08/03 16:08, Tim Moss wrote: > >=20 > > Surely entering a web address is easier and more likely to get a=20 > > result than typing in a phone number (even if I knew which phone=20 > > number to try). >=20 > On a simple phone with a 3x4 numerical keypad a number=20 > (especially your typical 1800-CALLNOW type vanity number) is=20 > be a lot simpler to input than a web address. >=20 > That does not hold on a full blown user interface with an=20 > alphanumeric keyboard. On such a platform, URLs win. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 05:33:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c6K-0003Gq-4i; Thu, 04 Aug 2005 05:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0c6I-0003Gf-Ej; Thu, 04 Aug 2005 05:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16241; Thu, 4 Aug 2005 05:33:16 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cd6-0008KE-VX; Thu, 04 Aug 2005 06:07:16 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j749X6T3009197; Thu, 4 Aug 2005 02:33:06 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j749X6D0009196; Thu, 4 Aug 2005 02:33:06 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Aug 2005 02:33:06 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20050804093305.GA9189@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] voipeer BOF presentations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660850738==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0660850738== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides I'm still trying to collect a few of the presentations. Dave =09 --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC8eDRORgD1qCZ2KcRAtbdAJ4leeVWSTD0jXHxyhc27lu3OFb0SACgkeX5 5uiA8l/oTq3YclBpedk9QCM= =NNUU -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- --===============0660850738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0660850738==-- From enum-bounces@ietf.org Thu Aug 04 05:41:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cED-000550-Ju; Thu, 04 Aug 2005 05:41:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cEC-00054i-6U for enum@megatron.ietf.org; Thu, 04 Aug 2005 05:41:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16854 for ; Thu, 4 Aug 2005 05:41:25 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E0cl0-0000GP-1T for enum@ietf.org; Thu, 04 Aug 2005 06:15:26 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-126.messagelabs.com!1123148443!4828737!5 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 18296 invoked from network); 4 Aug 2005 09:41:12 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-11.tower-126.messagelabs.com with SMTP; 4 Aug 2005 09:41:12 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 42EFDDE10003E6CC; Thu, 4 Aug 2005 05:41:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: : [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt Date: Thu, 4 Aug 2005 05:41:09 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ACCBA30@ACCLUST02EVS1.ugd.att.com> Thread-Topic: : [Enum] I-D ACTION:draft-ietf-enum-iris-ereg-01.txt Thread-Index: AcWO5Fs2DXwa+C3eTCSUa3DBEW/F7QJ8yNcw From: "Pfautz, Penn L, NEO" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Maybe I'm just woozy this morning or missed some of the discussion but I have a couple of questions in advance of tomorrow's WG: 1. In section 3.2.3=20 a) why is the E.164 number shown with a "." between country code and the NSN? b)should I be thinking of the nameservers here as Tier 1 or Tier 2? c) I'm not sure about the relevance of carriers. In fact the types listed seem to leave out the only one that's potentially important - i.e. the number issuing carrier. (if that's intended to be "line", then I would suggest renaming. 2. in 3.2.4, is the host Tier 1 or Tier 2? If Tier 2 how is the IP address kept updated? Is there a latent requirement for Tier 2 to tell the Registrar? Thanks, Penn Pfautz AT&T _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 06:25:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cv6-0004ZJ-3r; Thu, 04 Aug 2005 06:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cv4-0004XZ-Ac; Thu, 04 Aug 2005 06:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21972; Thu, 4 Aug 2005 06:25:43 -0400 (EDT) Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dRu-0002nf-WC; Thu, 04 Aug 2005 06:59:44 -0400 Received: from prive-Rline3.com ([192.168.1.32] [192.168.1.32]) by Rline3.francetelecom.com with ESMTP; Thu, 4 Aug 2005 12:25:35 +0200 Received: from fedft02a.francetelecom.fr ([193.248.188.50] [193.248.188.50]) by Rline3.francetelecom.com with ESMTP; Thu, 4 Aug 2005 12:25:35 +0200 Received: from puexcc11.nanterre.francetelecom.fr by fedft02a.francetelecom.fr with ESMTP; Thu, 4 Aug 2005 12:25:35 +0200 Received: from mail pickup service by PUEXCC11.nanterre.francetelecom.fr with Microsoft SMTPSVC; Thu, 4 Aug 2005 12:20:31 +0200 Received: from fedft01a.francetelecom.fr ([193.248.188.10]) by PUEXCC11.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:43:06 +0200 Received: from [193.248.188.80] by fedft01a.francetelecom.fr with ESMTP for jeanclaude.samou@exchange2000.francetelecom.fr; Thu, 4 Aug 2005 11:43:06 +0200 Received: from prive-Rline1.com ([192.168.1.12] [192.168.1.12]) by Rline1.francetelecom.com with ESMTP; Thu, 4 Aug 2005 11:43:05 +0200 Received: from megatron.ietf.org ([132.151.6.71] [132.151.6.71]) by Rline1.francetelecom.com with ESMTP; Thu, 4 Aug 2005 11:43:02 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)by megatron.ietf.org with esmtp (Exim 4.32)id 1E0c6L-0003HF-BH; Thu, 04 Aug 2005 05:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)by megatron.ietf.org with esmtp (Exim 4.32)id 1E0c6I-0003Gf-Ej; Thu, 04 Aug 2005 05:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16241; Thu, 4 Aug 2005 05:33:16 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9])by ietf-mx.ietf.org with esmtp (Exim 4.43)id 1E0cd6-0008KE-VX; Thu, 04 Aug 2005 06:07:16 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j749X6T3009197; Thu, 4 Aug 2005 02:33:06 -0700 Received: (from dmm@localhost)by m106.maoz.com (8.13.4/8.12.11/Submit) id j749X6D0009196;Thu, 4 Aug 2005 02:33:06 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using-f Date: Thu, 4 Aug 2005 02:33:06 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-Id: <20050804093305.GA9189@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Content-Type: multipart/mixed; boundary="===============0593604965==" X-imss-version: 2.028 X-imss-result: Passed X-imss-scores: Clean:0.00000 C:100 M:100 S:100 R:100 X-imss-settings: Baseline:1 C:3 M:1 S:3 R:1 (0.0000 0.0000) X-OriginalArrivalTime: 04 Aug 2005 09:43:06.0597 (UTC) FILETIME=[EA95C950:01C598D8] X-Spam-Score: 2.6 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] [Sipping] voipeer BOF presentations X-BeenThere: enum@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0593604965== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides I'm still trying to collect a few of the presentations. Dave =09 --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC8eDRORgD1qCZ2KcRAtbdAJ4leeVWSTD0jXHxyhc27lu3OFb0SACgkeX5 5uiA8l/oTq3YclBpedk9QCM= =NNUU -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- --===============0593604965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0593604965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0593604965==-- From enum-bounces@ietf.org Thu Aug 04 08:43:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4W-0008PX-IX; Thu, 04 Aug 2005 08:43:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxJw-0006Vz-66; Tue, 02 Aug 2005 10:00:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20429; Tue, 2 Aug 2005 10:00:37 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzxqP-0000wb-Ql; Tue, 02 Aug 2005 10:34:15 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j72DvvHX023405; Tue, 2 Aug 2005 09:57:58 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j72DtoHX020580; Tue, 2 Aug 2005 09:56:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 16:56:36 +0300 Message-ID: Thread-Topic: [Sipping] voipeer BOF scheduling update Thread-Index: AcWXTYKR/pC9WPfPTv6YdaDaQ9Q4+gAHDv9g From: "Romascanu, Dan \(Dan\)" To: "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] RE: [Sipping] voipeer BOF scheduling update X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Gonzalo sent a different message on the sipping list only (9 to 10am in the morning). That's confusing. Can you guys decide and come with one authoritative announcement on all lists? Digitally signed and authenticated :-)=20 Thanks, Dan > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of David Meyer > Sent: Tuesday, August 02, 2005 1:29 PM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sipping@ietf.org > Subject: [Sipping] voipeer BOF scheduling update >=20 > Folks, >=20 > Due to numerous scheduling issues, the voipeer BOF has > been rescheduled. We will be meeting at 1400 on Wednesday > in room 342. I realize this isn't perfect, but there is > very little we can do about this at this point (I'll just > point out that Marcia has been doing her best to accommodate > us).=20 >=20 > Thanks for your patience on this, and track me down if > you have questions or comments. >=20 > Dave >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 08:43:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4X-0008QQ-3h; Thu, 04 Aug 2005 08:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzy3q-0000aF-7X; Tue, 02 Aug 2005 10:48:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25400; Tue, 2 Aug 2005 10:48:03 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzyaH-0003K6-3q; Tue, 02 Aug 2005 11:21:41 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 01145194479; Tue, 2 Aug 2005 16:47:40 +0200 (CEST) Received: from [86.255.29.210] ([86.255.29.210]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Aug 2005 16:53:13 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3d674b61ebb24f766d7137de15f72216@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Date: Tue, 2 Aug 2005 16:47:39 +0200 To: "Romascanu, Dan \(Dan\)" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 02 Aug 2005 14:53:13.0523 (UTC) FILETIME=[E859E030:01C59771] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: voipeer@lists.uoregon.edu, sipping@ietf.org, enum@ietf.org Subject: [Enum] Re: [Sipping] voipeer BOF scheduling update X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peer-to-peer SIP BOF is not the same as VOIPEER BOF. Hisham On Aug 2, 2005, at 3:56 PM, Romascanu, Dan ((Dan)) wrote: > Gonzalo sent a different message on the sipping list only (9 to 10am in > the morning). That's confusing. Can you guys decide and come with one > authoritative announcement on all lists? Digitally signed and > authenticated :-) > > Thanks, > > Dan > > >> -----Original Message----- >> From: sipping-bounces@ietf.org >> [mailto:sipping-bounces@ietf.org] On Behalf Of David Meyer >> Sent: Tuesday, August 02, 2005 1:29 PM >> To: voipeer@lists.uoregon.edu >> Cc: enum@ietf.org; sipping@ietf.org >> Subject: [Sipping] voipeer BOF scheduling update >> >> Folks, >> >> Due to numerous scheduling issues, the voipeer BOF has >> been rescheduled. We will be meeting at 1400 on Wednesday >> in room 342. I realize this isn't perfect, but there is >> very little we can do about this at this point (I'll just >> point out that Marcia has been doing her best to accommodate >> us). >> >> Thanks for your patience on this, and track me down if >> you have questions or comments. >> >> Dave >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 08:43:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4X-0008Qp-HF; Thu, 04 Aug 2005 08:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzybZ-0001mt-D1; Tue, 02 Aug 2005 11:22:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28341; Tue, 2 Aug 2005 11:22:54 -0400 (EDT) Received: from mail-kan.bigfish.com ([63.161.60.29] helo=mail29-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzz81-0005DY-Uj; Tue, 02 Aug 2005 11:56:33 -0400 Received: from mail29-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail29-kan-R.bigfish.com (Postfix) with ESMTP id EDD3FF1E75; Tue, 2 Aug 2005 15:22:44 +0000 (UTC) X-BigFish: VC Received: by mail29-kan (MessageSwitch) id 1122996164914025_16490; Tue, 2 Aug 2005 15:22:44 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail29-kan.bigfish.com (Postfix) with ESMTP id B9CCAF1E53; Tue, 2 Aug 2005 15:22:44 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id j72FMi9F021133; Tue, 2 Aug 2005 10:22:44 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j72FMhl23017; Tue, 2 Aug 2005 10:22:44 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 10:22:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 10:22:42 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E2F5F08@PLSWB08C.ad.sprint.com> Thread-Topic: [Sipping] voipeer BOF scheduling update Thread-Index: AcWXTYKR/pC9WPfPTv6YdaDaQ9Q4+gAHDv9gAALeZtA= From: "Khan, Sohel Q [NTK]" To: "Romascanu, Dan \(Dan\)" , "David Meyer" , X-OriginalArrivalTime: 02 Aug 2005 15:22:43.0838 (UTC) FILETIME=[078A81E0:01C59776] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] RE: [Sipping] voipeer BOF scheduling update X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I think there are three different meetings: 1. TISPAN Adhoc meeting: Tuesday, from 1815 to 1945 in room 352. (Gongalo leading) 2. P2P SIP Adhoc meeting: Wednesday from 0900 to 1000 in Bordeaux (Henning) 3. VoIP Peering BOF: Wednesday 1400-15:30 Room 342 (David Meyer) Thanks, Sohel -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, August 02, 2005 8:57 AM To: David Meyer; voipeer@lists.uoregon.edu Cc: enum@ietf.org; sipping@ietf.org Subject: RE: [Sipping] voipeer BOF scheduling update Gonzalo sent a different message on the sipping list only (9 to 10am in the morning). That's confusing. Can you guys decide and come with one authoritative announcement on all lists? Digitally signed and authenticated :-)=20 Thanks, Dan > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of David Meyer > Sent: Tuesday, August 02, 2005 1:29 PM > To: voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sipping@ietf.org > Subject: [Sipping] voipeer BOF scheduling update >=20 > Folks, >=20 > Due to numerous scheduling issues, the voipeer BOF has > been rescheduled. We will be meeting at 1400 on Wednesday > in room 342. I realize this isn't perfect, but there is > very little we can do about this at this point (I'll just > point out that Marcia has been doing her best to accommodate > us).=20 >=20 > Thanks for your patience on this, and track me down if > you have questions or comments. >=20 > Dave >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 08:43:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4X-0008RE-Vu; Thu, 04 Aug 2005 08:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzqR-00040F-4l; Tue, 02 Aug 2005 12:42:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04014; Tue, 2 Aug 2005 12:42:19 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Mu-0000eh-Vc; Tue, 02 Aug 2005 13:15:59 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j72GdbHX018847; Tue, 2 Aug 2005 12:39:37 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j72GcHHX017000; Tue, 2 Aug 2005 12:39:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2005 19:38:39 +0300 Message-ID: Thread-Topic: [Sipping] voipeer BOF scheduling update Thread-Index: AcWXTYKR/pC9WPfPTv6YdaDaQ9Q4+gAHDv9gAALeZtAAAs4UYA== From: "Romascanu, Dan \(Dan\)" To: "Khan, Sohel Q [NTK]" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] RE: [Sipping] voipeer BOF scheduling update X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Thanks - this clarifies. =20 > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of Khan, Sohel Q [NTK] > Sent: Tuesday, August 02, 2005 6:23 PM > To: Romascanu, Dan (Dan); David Meyer; voipeer@lists.uoregon.edu > Cc: enum@ietf.org; sipping@ietf.org > Subject: RE: [Sipping] voipeer BOF scheduling update >=20 > I think there are three different meetings: >=20 > 1. TISPAN Adhoc meeting: Tuesday, from 1815 to 1945 in room 352. > (Gongalo leading) >=20 > 2. P2P SIP Adhoc meeting: Wednesday from 0900 to 1000 in Bordeaux > (Henning) >=20 > 3. VoIP Peering BOF: Wednesday 1400-15:30 Room 342 (David Meyer) >=20 > Thanks, >=20 > Sohel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 04 08:43:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4Y-0008Rd-Da; Thu, 04 Aug 2005 08:43:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cSI-0004G9-TF; Thu, 04 Aug 2005 05:56:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18254; Thu, 4 Aug 2005 05:55:59 -0400 (EDT) Received: from relay.vnet.co.uk ([195.38.85.106] helo=trinitevisp.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0cz5-00018v-Kf; Thu, 04 Aug 2005 06:30:00 -0400 Received: from trinitevisp.co.uk [195.38.85.142] by VMAILW2K46-3A.trinitevisp.co.uk with ESMTP; Thu, 4 Aug 2005 10:56:39 Received: from MedionDesk [84.12.52.197] by VMAILW2K37.trinitevisp.co.uk with ESMTP; Thu, 4 Aug 2005 10:55:47 From: "John Horrocks" To: "David Meyer" , Subject: RE: [Enum] voipeer BOF presentations Date: Thu, 4 Aug 2005 10:54:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00AA_01C598E2.E7F9DD30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050804093305.GA9189@1-4-5.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b96fc7f2e5771a48506e2d7077f96fa0 X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: enum@ietf.org, sipping@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01C598E2.E7F9DD30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi David I would have liked to attend and present the ECC TRIS work but cannot make it. Please feel free to circulate and put on your web page the attached draft report and to draw attention to the ECC Consultation (see http://www.ero.dk/consultation) The draft new ECC Report 74 on Access to emergency calls based on voice over IP Download Report 74 The draft new ECC Report 75 on a Model for Interconnection in IP-based networks Download Report 75 Comments to the above reports from ECC PT2 are invited from CEPT administrations and any other interested parties not later than 9 September 2005 and should be forwarded to the European Radiocommunications Office preferably by e-mail to Mr Jukka Rakkolainen, ERO: rakkolainen@ero.dk Best wishes John Horrocks +44 1483 797807 john@horrocks.co.uk Skype: "johnhorrocks" -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]On Behalf Of David Meyer Sent: 04 August 2005 10:33 To: voipeer@lists.uoregon.edu Cc: enum@ietf.org; sipping@ietf.org Subject: [Enum] voipeer BOF presentations http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides I'm still trying to collect a few of the presentations. Dave ------=_NextPart_000_00AA_01C598E2.E7F9DD30 Content-Type: application/msword; name="Report 75 IP interconnection.doc" Content-Disposition: attachment; filename="Report 75 IP interconnection.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAogAAAAAAAAAA EAAApAAAAAEAAAD+////AAAAAKAAAAChAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEACyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAkD4AAA4AYmpiauAA4AAAAAAAAAAAAAAAAAAAAAAA AAAJBBYA0mQAAIJqAQCCagEAvTgAAAAAAABOAQAAAAAAAAAAAAAAAAAAhAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAEgIAAAAAAAASAgAAEgI AAAAAAAASAgAAAAAAACYCAAAAAAAAJgIAAAAAAAAmAgAAEQAAAAAAAAAAAAAALwJAAAAAAAA6BkA AAAAAADoGQAAAAAAAOgZAACAAAAAaBoAADQAAACcGgAAVAAAALwJAAAAAAAAqUMAANoBAAD8GgAA EgEAAA4cAABMAAAAWhwAAAAAAABaHAAAAAAAAFocAAAAAAAAXCkAAI4BAADqKgAAdAAAAF4rAAA8 AAAAKEMAAAIAAAAqQwAAAAAAACpDAAAAAAAAKkMAAAAAAAAqQwAAAAAAACpDAAAAAAAAKkMAACQA AACDRQAAIAIAAKNHAABsAQAATkMAABUAAAAAAAAAAAAAAAAAAAAAAAAAmAgAAAAAAACaKwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAKKAAAIgAAACwoAAAwAQAAmisAAAAAAACaKwAAAAAAAE5DAAAAAAAA qC8AAAAAAABICAAAAAAAAEgIAAAAAAAAWhwAAAAAAAAAAAAAAAAAAFocAACwCwAAY0MAABYAAACo LwAAAAAAAKgvAAAAAAAAqC8AAAAAAACaKwAAbAEAAEgIAAA4AAAAWhwAAAAAAACYCAAAAAAAAFoc AAAAAAAAKEMAAAAAAAAAAAAAAAAAAKgvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmisAAAAAAAAoQwAAAAAAAKgvAAAyAQAAqC8AAAAAAADaMAAA 4gAAAIxBAACkAAAAgAgAABgAAACYCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7EIAAAAAAABaHAAAAAAAAPAaAAAMAAAA8JLAUsCH xQG8CQAALBAAAOgZAAAAAAAABi0AAOIAAAAwQgAAFgAAAAAAAAAAAAAA7EIAADwAAAB5QwAAMAAA AKlDAAAAAAAARkIAAKYAAAAPSQAAAAAAAOgtAADAAQAAD0kAAAAAAADsQgAAAAAAAKgvAAAAAAAA 3AgAAIIAAABeCQAAXgAAAEgIAAAAAAAASAgAAAAAAABICAAAAAAAAEgIAAAAAAAAAgDZAAAACAEN AQ0NDQ0NDQ0NDQ0NQSBNT0RFTCBGT1IgSU5URVJDT05ORUNUSU9OIElOIElQLUJBU0VEIE5FVFdP UktTDQ1NYXkgMjAwNQ0MDUVYRUNVVElWRSBTVU1NQVJZDQ1UaGUgUmVwb3J0IGlzIHByZXNlbnRl ZCBmb3IgcHVibGljIGNvbnN1bHRhdGlvbjsgaXQgcHJlc2VudHMgYSBtb2RlbCBmb3IgaW50ZXJj b25uZWN0aW9uIGluIElQLWJhc2VkIG5ldHdvcmtzIHdoZXJlIHRoZXJlIGlzIHNlcGFyYXRpb24g b2Ygc2VydmljZSBwcm92aXNpb24gYW5kIGNvbm5lY3Rpdml0eS4gVGhlIG1vZGVsIGlzIHByZXNl bnRlZCBmb3IgZGlzY3Vzc2lvbiBhbmQgZG9lcyBub3QgcmVwcmVzZW50IGEgcG9saWN5IHZpZXcg b2YgQ0VQVCBvciBpdHMgbWVtYmVycy4NDVRoZSBtb2RlbCBpcyBiYXNlZCBvbiB0aGUgcHJvdmlz aW9uIG9mIGEgaGlnaCBxdWFsaXR5IGNvbm5lY3Rpdml0eSBwbGF0Zm9ybSB0aGF0IGNhbiBiZSB1 c2VkIGZvciBuZXcgYW5kIHRoaXJkIHBhcnR5IHNlcnZpY2VzIHdoZXJlIGludGVyY29ubmVjdGlv biBjaGFyZ2VzIGFyZSBiYXNlZCBvbiBjYXBhY2l0eSByYXRoZXIgdGhhbiB1c2FnZS4gUmV0YWls IGFuZCBhY2Nlc3MgY2hhcmdlcyBjYW4gYmUgYmFzZWQgb24gZWl0aGVyIHVzYWdlIG9yIGNhcGFj aXR5LiBRdWFsaXR5IGNhbiBiZSBoYW5kbGVkIG9uIGEgY2xhc3MgcmF0aGVyIHRoYW4gYSBzZXJ2 aWNlIGJhc2lzIGFuZCBjYW4gYmUgaW5jbHVkZWQgaW4gdGhlIGNoYXJnaW5nIGZvciBhY2Nlc3Mu DQ1UaGUgbmV3IG1vZGVsIGRpZmZlcnMgZnJvbSB0aGUgY3VycmVudCBwbGFucyBmb3IgdGhlIE5H TiBiZWluZyBkaXNjdXNzZWQgaW4gRVRTSSBhbmQgSVRVLVQgYnV0IGlzIHNpbWlsYXIgdG8gdGhl IG1haW4gYXNwZWN0cyBvZiB0aGUgYXBwcm9hY2ggdXNlZCBieSB0aGUgbW9iaWxlIG9wZXJhdG9y cyBmb3IgdGhlIEdSWCwgd2hpY2ggbWF5IGFsc28gYmVjb21lIHRoZSBiYXNpcyBmb3IgdGhlIHBy b3Zpc2lvbiBvZiB0aGUgSVAgTXVsdGltZWRpYSBTdWJzeXN0ZW0sIGFuZCBpdCBpcyBhbHNvIHVz ZWQgZm9yIHNlcnZpY2VzIG9uIHRoZSBJbnRlcm5ldC4NDVRoZSByZWFzb25zIGZvciBwcmVzZW50 aW5nIHRoaXMgbW9kZWwgYXJlOg1BIG1vZGVsIGlzIG5lZWRlZCB0aGF0IGlzIGNvbXBhdGlibGUg d2l0aCB0aGUgZWFzeSBpbnRyb2R1Y3Rpb24gb2YgbmV3IGFuZCB0aGlyZCBwYXJ0eSBzZXJ2aWNl cw1UaGUgY29zdCBiYXNpcyBvZiB0aGUgbmV0d29ya3MgaGFzIGNoYW5nZWQgYW5kIHRoZSBiYWNr Ym9uZSBuZXR3b3JrIGlzIG5vdyByZWxhdGl2ZWx5IGluZXhwZW5zaXZlDVRoZSByZXRhaWwgbWFy a2V0IGlzIG1vdmluZyBhd2F5IGZvcm0gY2FsbCBjaGFyZ2VzIGFuZCB0b3dhcmRzIGZsYXQgcmF0 ZSBjaGFyZ2VzIGFuZCB0aGUgcmV0YWlsIGFuZCBpbnRlcmNvbm5lY3Rpb24gY2hhcmdlcyBuZWVk IHRvIGJlIG1hdGNoZWQgYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byByZWR1Y2UgYXJiaXRyYWdl IHJpc2tzLg0NDQ0NDQ0NDQwNSU5ERVggVEFCTEUNDQ0TIFRPQyBcbyAiMS0zIiAUMQlJTlRST0RV Q1RJT04JEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3MzYgXGggARQ0FQ0yCURFRklOSVRJT05TCRMgUEFH RVJFRiBfVG9jMTA4ODM0NzM3IFxoIAEUNBUNMwlSZWFzb25zIGZvciBtb3ZpbmcgdG8gYSBuZXcg bW9kZWwJEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3MzggXGggARQ0FQ0zLjEJU3VwcG9ydCBvZiBuZXcg c2VydmljZXMJEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3MzkgXGggARQ0FQ0zLjIJQ2hhbmdlcyB0byBj b3N0IHN0cnVjdHVyZXMJEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3NDAgXGggARQ0FQ0zLjMJU2ltcGxp ZmljYXRpb24JEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3NDEgXGggARQ1FQ0zLjQJQ2hhbmdlcyB0byB0 aGUgcmV0YWlsIG1hcmtldAkTIFBBR0VSRUYgX1RvYzEwODgzNDc0MiBcaCABFDYVDTQJVGhlIFBy b3Bvc2VkIGludGVyY29ubmVjdGlvbiBjb25jZXB0IGZvciBOR04JEyBQQUdFUkVGIF9Ub2MxMDg4 MzQ3NDMgXGggARQ3FQ01CUNoYXJnaW5nCRMgUEFHRVJFRiBfVG9jMTA4ODM0NzQ0IFxoIAEUNxUN NS4xCUNvbm5lY3Rpdml0eSBjaGFyZ2VzCRMgUEFHRVJFRiBfVG9jMTA4ODM0NzQ1IFxoIAEUNxUN NS4yCVNlcnZpY2UgY2hhcmdlcwkTIFBBR0VSRUYgX1RvYzEwODgzNDc0NiBcaCABFDcVDTUuMwlD b25uZWN0aW9uIHRvIHRoZSBQU1ROCRMgUEFHRVJFRiBfVG9jMTA4ODM0NzQ3IFxoIAEUOBUNNS40 CVN1bW1hcnkJEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3NDggXGggARQ4FQ02CUNvbmNsdXNpb24gYW5k IG5leHQgc3RlcHMJEyBQQUdFUkVGIF9Ub2MxMDg4MzQ3NDkgXGggARQ5FQ0VDQ0NDA1BIG1vZGVs IGZvciBpbnRlcmNvbm5lY3Rpb24gaW4gSVAtYmFzZWQgbmV0d29ya3MNSU5UUk9EVUNUSU9ODVRl bGVjb21tdW5pY2F0aW9ucyBvcGVyYXRvcnMgYXJlIHN0YXJ0aW5nIHRvIGltcGxlbWVudCBJUC1i YXNlZCBuZXR3b3JrcyBhcyBhIHJlcGxhY2VtZW50IGZvciBvciBhZGRpdGlvbiB0byBjaXJjdWl0 IHN3aXRjaGVkIG5ldHdvcmtzIGJvdGggZm9yIHRoZSBwcm92aXNpb24gb2YgdGVsZXBob255IGFu ZCBpdHMgcmVsYXRlZCBzZXJ2aWNlcyBzdWNoIGFzIGZheCBhbmQgYWxzbyBmb3IgdGhlIHByb3Zp c2lvbiBvZiBuZXcgc2VydmljZXMsIGluY2x1ZGluZyB0aGUgb3Bwb3J0dW5pdHkgZm9yIGFsbG93 aW5nIHRoaXJkIHBhcnQgcHJvdmlzaW9uIG9mIHNlcnZpY2VzLiBUaGVzZSBuZXcgbmV0d29ya3Mg YXJlIGNvbW1vbmx5IGNhbGxlZCBOZXh0IEdlbmVyYXRpb24gTmV0d29ya3MuDQ1UaGUgY2hhbmdl IHRvIElQLWJhc2VkIG5ldHdvcmtzIG9mZmVycyBhbiBvcHBvcnR1bml0eSB0byBpbnRyb2R1Y2Ug bmV3IGNvbW1lcmNpYWwgbW9kZWxzIGZvciBpbnRlcmNvbm5lY3Rpb24gdGhhdCBhcmUgYmV0dGVy IHN1aXRlZCB0byB0aGUgZGV2ZWxvcG1lbnQgb2YgZnV0dXJlIHNlcnZpY2VzIHRoYW4gdGhlIGN1 cnJlbnQgdGltZSBhbmQgZGlzdGFuY2UgKHVzYWdlKSBiYXNlZCBtb2RlbC4gRnVydGhlcm1vcmUg dGhlIGluaGVyZW50IGFiaWxpdHkgZm9yIElQLWJhc2VkIG5ldHdvcmtzIHRvIHNlcGFyYXRlIHNl cnZpY2VzIGFuZCBjb25uZWN0aXZpdHkgcHJvdmlkZXMgYSBtb3JlIGVmZmVjdGl2ZSBtZXRob2Qg b2YgcHJvbW90aW5nIHNlcnZpY2UgY29tcGV0aXRpb24gdGhhbiBmYWNpbGl0aWVzIHN1Y2ggYXMg Y2FycmllciBzZWxlY3Rpb24gYW5kIHByZS1zZWxlY3Rpb24uDQ1JbiB0ZXJtcyBvZiB0aGUgbWFy a2V0LCB0aGUgdHJhZGl0aW9uYWwgdGVsZWNvbW11bmljYXRpb25zIG9wZXJhdG9ycyBhcmUgaGF2 aW5nIHRvIGNvbXBldGUgaW5jcmVhc2luZ2x5IHdpdGggdGhlIHByb3Zpc2lvbiBvZiBzZXJ2aWNl cyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQgYW5kIHRoZSBhZG9wdGlvbiBvZiBhIG5ldyBtb2Rl bCBzaG91bGQgb2ZmZXIgc2ltcGxpZmljYXRpb25zIGFuZCBjb3N0IHNhdmluZ3MgdGhhdCB3aWxs IGhlbHAgdGhlbSBhcyB0aGUgbWFya2V0IGNoYW5nZXMuDQ1UaGUgbW9kZWwgcHJlc2VudGVkIGhl cmUgaXMgYSBwcm9wb3NhbCBmb3IgZGlzY3Vzc2lvbiBhbmQgZG9lcyBub3QgcmVwcmVzZW50IGEg cG9saWN5IG9mIHRoZSBFQ0MuDURFRklOSVRJT05TDUdSWCBiYWNrYm9uZTogVGhlIEdQUlMgUm9h bWluZyBlWGNoYW5nZSwgd2hpY2ggaXMgYW4gaW50ZXJuYXRpb25hbCBzaGFyZWQgdHJhbnNpdCBv ciBiYWNrYm9uZSBuZXR3b3JrIHRoYXQgaXMgcnVuIGJ5IHRoZSBHU00gQXNzb2NpYXRpb24gZm9y IHRoZSBzdXBwb3J0IG9mIEdQUlMgcm9hbWluZyB0cmFmZmljIGFuZCB3aGljaCBtYXkgYmUgZXh0 ZW5kZWQgZm9yIHRoZSBzdXBwb3J0IG9mIElNUy4gVGhlIEdSWCBoYXMgYSBmb3JtIGFuZCBzdHJ1 Y3R1cmUgdGhhdCBpcyBzaW1pbGFyIHRvIHRoYXQgb2YgdGhlIHB1YmxpYyBJbnRlcm5ldCBhbmQg aXQgdXNlcyBwdWJsaWMgSVAgYWRkcmVzc2VzIGJ1dCBpcyBub3QgY29ubmVjdGVkIHRvIHRoZSBw dWJsaWMgSW50ZXJuZXQuDQ1OZXh0IEdlbmVyYXRpb24gTmV0d29ya3MgKE5HTik6IEEgZ2VuZXJh bCB0ZXJtIHVzZWQgZm9yIG5ldHdvcmtzIHdpdGggYSBwYWNrZXQtYmFzZWQgYXJjaGl0ZWN0dXJl IHRoYXQgd2lsbCByZXBsYWNlIHRoZSBJU0ROL0dTTTIrIGdlbmVyYXRpb24gb2YgbmV0d29ya3Mu IEluIHRoaXMgcmVwb3J0IHRoZSB0ZXJtIGlzIHVzZWQgZm9yIG5ldHdvcmtzIHJ1biBhbmQgY29u dHJvbGxlZCBieSB0aGUgdGVsY29zIGluIGNvbnRyYXN0IHRvIHRoZSBwdWJsaWMgSW50ZXJuZXQu DQ1JUCBNdWx0aW1lZGlhIHN1YnN5c3RlbSAoSU1TKTogVGhlIElQLWJhc2VkIG5ldHdvcmsgcGxh bm5lZCBmb3IgdGhlIHN1cHBvcnQgb2YgYm90aCB2b2ljZSBhbmQgZGF0YSBzZXJ2aWNlcyB3aXRo aW4gdGhlIHRoaXJkIGdlbmVyYXRpb24gbW9iaWxlIG5ldHdvcmtzIGJhc2VkIG9uIHRoZSAzR1BQ IHN0YW5kYXJkcy4NUmVhc29ucyBmb3IgbW92aW5nIHRvIGEgbmV3IG1vZGVsDVN1cHBvcnQgb2Yg bmV3IHNlcnZpY2VzDUlmIE5HTnMgYXJlIHRvIHN1cHBvcnQgbmV3IHNlcnZpY2VzIGFuZCB0aGly ZCBwYXJ0eSBzZXJ2aWNlcyB0aGVuIHRoZXkgbmVlZCB0byBzdXBwb3J0IHRoZXNlIHNlcnZpY2Vz IG92ZXIgbmV0d29yayBib3VuZGFyaWVzLiBUaGUgZXhpc3RpbmcgdXNhZ2UgYmFzZWQgY2hhcmdp bmcgZm9yIGludGVyY29ubmVjdGlvbiB3b3VsZCBtZWFuIHRoYXQgdGhlcmUgd291bGQgbmVlZCB0 byBiZSBpbnRlcmNvbm5lY3Rpb24gYWdyZWVtZW50cyBhbmQgY2hhcmdpbmcgYXJyYW5nZW1lbnRz IGF0IGVhY2ggaW50ZXJjb25uZWN0aW9uIHBvaW50IGZvciBlYWNoIHNlcnZpY2UgY2FycmllZCBv dmVyIHRoYXQgcG9pbnQgYW5kIHRoZSBwcmFjdGljYWwgcHJvYmxlbXMgb2YgZXN0YWJsaXNoaW5n IHN1Y2ggYXJyYW5nZW1lbnRzIGZvciBtYW55IGRpZmZlcmVudCBuZXcgc2VydmljZXMgd291bGQg YmUgZm9ybWlkYWJsZS4gVGhlc2UgcHJhY3RpY2FsIHByb2JsZW1zIHdvdWxkIGNvbnN0aXR1dGUg YSBodWdlIGJhcnJpZXIgdG8gdGhlIHJvbGwtb3V0IG9mIG5ldyBzZXJ2aWNlcyBhbmQgaW5ub3Zh dG9ycyB3b3VsZCBnaXZlIHNlcnZpY2UgaW5ub3ZhdG9ycyBhIHN0cm9uZyBpbmNlbnRpdmUgdG8g dXNlIHRoZSBJbnRlcm5ldCBpbnN0ZWFkIG9mIHRoZSBOR05zLiBUaGUgbmV3IG1vZGVsIHRoZXJl Zm9yZSBuZWVkcyB0byBzZXBhcmF0ZSBzZXJ2aWNlIHByb3Zpc2lvbiBhbmQgY29ubmVjdGl2aXR5 IGluIHRoZSBzYW1lIHdheSBhcyB0aGUgSW50ZXJuZXQgZG9lcy4gVGhpcyBtZWFucyB0aGVyZWZv cmUgdGhhdCB3ZSBuZWVkIHRvIGNvbnNpZGVyIHNlcGFyYXRlbHk6DUludGVyY29ubmVjdGlvbiAo aW50ZXJvcGVyYWJpbGl0eSkgYXQgdGhlIHNlcnZpY2UgbGV2ZWwgDUludGVyY29ubmVjdGlvbiBh dCB0aGUgY29ubmVjdGl2aXR5IGxldmVsLg1DaGFuZ2VzIHRvIGNvc3Qgc3RydWN0dXJlcw1EZXZl bG9wbWVudHMgaW4gdGVjaG5vbG9neSBhbmQgaHVnZSBlY29ub21pZXMgb2Ygc2NhbGUgZnJvbSB0 aGUgY3VzdG9tZXIgcHJlbWlzZXMgbWFya2V0IGhhdmUgcmVzdWx0ZWQgaW4gdGhlIGNvc3RzIG9m IGNvcmUgb3IgYmFja2JvbmUgbmV0d29ya3MgZHJvcHBpbmcgc3Vic3RhbnRpYWxseS4gVGhlIGV4 aXN0aW5nIHJlZ3VsYXRvcnkgYW5kIGNvbW1lcmNpYWwgbW9kZWxzIGFyZSBidWlsdCBvbiB0aGUg YXNzdW1wdGlvbiBvZiBhbiBleHBlbnNpdmUgY29yZSBvciBiYWNrYm9uZSBuZXR3b3JrIGhlbmNl IHRoZSBmb2N1cyBvbiBjb21wZXRpdGlvbiBpbiBsb25nIGRpc3RhbmNlIGFuZCBpbnRlcm5hdGlv bmFsIGNhbGxzIHRocm91Z2ggY2FycmllciBzZWxlY3Rpb24gYW5kIHRoZSBkZXZlbG9wbWVudCBv ZiBzZXJ2aWNlcyBzdWNoIGFzIGZyZWVwaG9uZS4gRmlndXJlIDEgc2hvd3MgdGhlIGV4aXN0aW5n IGNvc3QgbW9kZWwgaW4gc2ltcGxpZmllZCBmb3JtLiBJbiBwcmFjdGljZSB0aGUgYmFja2JvbmUg bWF5IGJlIGNvbXBvc2VkIG9mIHNldmVyYWwgc2VwYXJhdGUgaW50ZXJjb25uZWN0ZWQgdHJhbnNp dCBuZXR3b3Jrcy4NDQ0BDQ1GaWd1cmUgMTogRXhpc3RpbmcgY29zdCBtb2RlbA0NDUZpZ3VyZSAy IHNob3dzIHRoZSBuZXcgY29zdCBtb2RlbC4NDQENRmlndXJlIDI6IE5ldyBjb3N0IG1vZGVsDQ1U aGUgbmV3IGNvc3QgbW9kZWwgaGFzIGFwcGxpZWQgdG8gbW9iaWxlIG5ldHdvcmtzIGZvciBzb21l IHRpbWUgYmVjYXVzZSBvZiB0aGUgaGlnaCBjb3N0cyBvZiByYWRpbyBhY2Nlc3MgYW5kIHRoZSBt b2JpbGUgb3BlcmF0b3JzIGFyZSBhZG9wdGluZyBhIGNoYXJnaW5nIG1vZGVsIHNpbWlsYXIgdG8g dGhhdCBwcm9wb3NlZCBoZXJlIGZvciBzZXJ2aWNlcyBvbiBHUFJTLiBUaGUgbmV3IGNvc3QgbW9k ZWwgc3VnZ2VzdHMgdGhhdCBjaGFyZ2luZyBzaG91bGQgY2hhbmdlIHRvIGNhcGFjaXR5IGluc3Rl YWQgb2YgdXNhZ2UgZm9yIHRoZSBiYXNpYyBjb25uZWN0aXZpdHkuICBUaGlzIGNoYXJnaW5nIG1v ZGVsIGhhcyBiZWVuIHVzZWQgaW4gdGhlIEludGVybmV0IGZvciBtYW55IHllYXJzLiBGdXJ0aGVy bW9yZSBhIGNoYW5nZSB0byBhIG5ldyBtb2RlbCBtYXkgaGVscCB0byBwcm9tb3RlIGNvbXBldGl0 aW9uIGJldHdlZW4gZGlmZmVyZW50IHRlY2hub2xvZ2llcy4NU2ltcGxpZmljYXRpb24NVGhlIHJl ZHVjdGlvbiBpbiBjb3N0cyBtZWFucyB0aGF0IGEgY29tcGxleCBpbnRlcmNvbm5lY3Rpb24gY2hh cmdpbmcgbW9kZWwgaXMgbm8gbG9uZ2VyIGp1c3RpZmllZCBhbmQgdGhhdCBhIHNpbXBsZXIgYXBw cm9hY2ggc2hvdWxkIGJlIHNvdWdodC4NDVNpbXBsaWZpY2F0aW9uIGNvbWVzIGZyb20gYSBjb21i aW5hdGlvbiBvZiB0d28gY2hhbmdlczoNU2VwYXJhdGlvbiBvZiBzZXJ2aWNlcyBhbmQgY29ubmVj dGl2aXR5DUFkb3B0aW9uIG9mIHBlZXJpbmcgKHNlbmRlciBrZWVwcyBhbGwpIGJldHdlZW4gcHJv dmlkZXJzIG9mIHRoZSBzYW1lIHNlcnZpY2UNDUEgbW9kZWwgdGhhdCBzZXBhcmF0ZXMgc2Vydmlj ZXMgYW5kIGNvbm5lY3Rpdml0eSByZWR1Y2VzIHRoZSBudW1iZXIgb2YgaW50ZXJjb25uZWN0aW9u IGFncmVlbWVudHMgbmVlZGVkIGJlY2F1c2U6DXRoZSBpbnRlcmNvbm5lY3Rpb24gYWdyZWVtZW50 cyBmb3IgY29ubmVjdGl2aXR5IG5vIGxvbmdlciBuZWVkIHRvIHJlZmxlY3QgdGhlIGNoYXJnZXMg Zm9yIGRpZmZlcmVudCBzZXJ2aWNlcyBhbmQgDXRoZSBvcGVyYXRvcnMgd2hvIGFyZSBwcm92aWRp bmcgY29ubmVjdGl2aXR5IG5vIGxvbmdlciBuZWVkIHRvIGtub3cgYWJvdXQgdGhlIHNlcnZpY2Vz IGNhcnJpZWQgb3ZlciB0aGUgaW50ZXJjb25uZWN0aW9uIHBvaW50cy4NDVRoaXMgaXMgYSBkcmFt YXRpYyBzaW1wbGlmaWNhdGlvbi4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBleGFtcGxlLiBJZiB0 aGVyZSBhcmUgdGhyZWUgaW50ZXJjb25uZWN0ZWQgbmV0d29ya3MsIHR3byBsb2NhbCwgQSBhbmQg QiwgYW5kIGEgdHJhbnNpdCBuZXR3b3JrLCBULCBiZXR3ZWVuIHRoZW0gYW5kIHRoZXJlIGFyZSBO IHNlcnZpY2UgcHJvdmlkZXJzIG9uIEEgYW5kIE0gb24gQiBlYWNoIHByb3ZpZGluZyBvbmUgdW5p cXVlIHNlcnZpY2UgYW5kIHdhbnRpbmcgY29ubmVjdGl2aXR5IHRvIGFsbCBzdWJzY3JpYmVycyBv biBBIGFuZCBCLiBUaGlzIGlzIHNob3duIGluIGZpZ3VyZSAzLiBUaGUgY29uc2VxdWVuY2UgaXMg dGhhdCB0aGUgaW50ZXJjb25uZWN0aW9uIGFncmVlbWVudHMgYmV0d2VlbiBBIGFuZCBULCBhbmQg YmV0d2VlbiBUIGFuZCBCIG5lZWQgdG8gY292ZXIgZXhwbGljaXRseSBNK04gZGlmZmVyZW50IHNl cnZpY2VzLg0NAQ1GaWd1cmUgMzogVW5pcXVlIHNlcnZpY2VzDQ1JZiB0aGUgc2VydmljZXMgYXJl IHN0YW5kYXJkaXNlZCBhbmQgY29tbW9uIHRvIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBzbyB0aGF0 IGVhY2ggcHJvdmlkZXMgc2F5IFMgc2VydmljZXMgd2l0aCBzdGFuZGFyZGlzZWQgdGFyaWZmcyBh cyBoYXBwZW5zIGZvciB0ZWxlcGhvbnkgdGhlbiB0aGUgc2l0dWF0aW9uIGlzIGFzIHNob3duIGlu IEZpZ3VyZSA0Lg0NAQ1GaWd1cmUgNDogU3RhbmRhcmRpc2VkIHNlcnZpY2VzDQ1UaGlzIHByb3Zp ZGVzIHNvbWUgc2ltcGxpZmljYXRpb24sIGJ1dCB0aGUgd29yayBpbiBFVFNJIGFuZCBJVFUtVCBp cyBub3Qgc3RhbmRhcmRpc2luZyBzZXJ2aWNlcyBhbmQgc28gdGhpcyBzaW1wbGlmaWNhdGlvbiBp cyBub3QgYW50aWNpcGF0ZWQuDQ1XaXRoIHRoZSBtb2RlbCBwcm9wb3NlZCB3aGljaCBzZXBhcmF0 ZXMgdGhlIGxheWVycyBhbmQgaW50cm9kdWNlcyBwZWVyaW5nIGZvciBzZXJ2aWNlcyAoYXMgaXMg dGhlIGNhc2UgZm9yIGVtYWlsKSwgdGhlIHNpdHVhdGlvbiBpcyBzaW1wbGlmaWVkIGFzIHNob3du IGluIEZpZ3VyZSA1Lg0NAQ1GaWd1cmUgNTogTmV3IG1vZGVsDQ1UaGUgbmV3IG1vZGVsIGFsc28g cmVkdWNlcyB0aGUgY29zdHMgb2YgaW50ZXJjb25uZWN0aW9uIGNoYXJnaW5nIGJlY2F1c2UgaXQg cmVtb3ZlcyB0aGUgbmVlZCBmb3IgdGhlIG9wZXJhdG9ycyB3aG8gcHJvdmlkZSBjb25uZWN0aXZp dHkgdG8gbG9nIHNlcnZpY2UgdXNhZ2UsIGFsdGhvdWdoIGluIHByYWN0aWNlIHRoaXMgbWF5IG5v dCBiZSByZW1vdmVkIGNvbXBsZXRlbHkgYmVjYXVzZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGZvciBk YXRhIHJldGVudGlvbiBmb3IgbGF3IGVuZm9yY2VtZW50Lg1DaGFuZ2VzIHRvIHRoZSByZXRhaWwg bWFya2V0DVRoZSBleGlzdGluZyByZXRhaWwgbWFya2V0IGlzIGNoYW5naW5nIHdpdGggY2FsbCBw cmljZXMgZHJvcHBpbmcgYW5kIG1hbnkgb3BlcmF0b3JzIHN0YXJ0aW5nIHRvIG9mZmVyIGZsYXQg cmF0ZSB0YXJpZmZzIHdoZXJlIHVubGltaXRlZCBjYWxsIHZvbHVtZXMgYXJlIG9mZmVyZWQgZm9y IGEgZml4ZWQgc3Vic2NyaXB0aW9uLiBUaGlzIGdlbmVyYXRlcyB0aGUgcmlzayBvZiBhcmJpdHJh Z2UgYW5kIHRoZSBvcGVyYXRvcnMgd291bGQgYmVuZWZpdCBmcm9tIGhhdmluZyBpbnRlcmNvbm5l Y3Rpb24gYXJyYW5nZW1lbnRzIHRoYXQgYmV0dGVyIG1hdGNoIHRoZSBzdHJ1Y3R1cmUgb2YgdGhl IHJldGFpbCBjaGFyZ2VzLiBUaGlzIGNoYW5nZSBpcyBjYXVzaW5nIG1hbnkgY29tbWVudGF0b3Jz IHRvIHNheSB0aGF0IHRoZSBkYXlzIG9mIGNhbGwgY2hhcmdlcyBhcmUgZGlzYXBwZWFyaW5nLiAN DVRoZXJlIGlzIGhvd2V2ZXIgYSBzbWFsbCBudW1iZXIgb2YgaGlnaCBwcmljZSBjYWxscyByZW1h aW5pbmcgaW5jbHVkaW5nIGNhbGxzIHRvIHNvbWUgY291bnRyaWVzLCBjYWxscyB0byBtb2JpbGVz IGFuZCBjYWxscyB0byBwcmVtaXVtIHJhdGUgc2VydmljZXMuIFRoZSBtb2RlbCBuZWVkcyB0byBh Y2NvbW1vZGF0ZSBzdWNoIGNhbGxzLg0NVGhlIGNoYW5nZXMgcHJvcG9zZWQgaW4gdGhpcyBSZXBv cnQsIGhvd2V2ZXIsIGFwcGx5IHRvIGFsbCBzZXJ2aWNlcyBhbmQgbm90IGp1c3QgdG8gY2FsbHMu DVRoZSBQcm9wb3NlZCBpbnRlcmNvbm5lY3Rpb24gY29uY2VwdCBmb3IgTkdODVRoZSBOR04gaXMg c3RpbGwgYXQgYW4gZWFybHkgc3RhZ2Ugb2YgZGV2ZWxvcG1lbnQgZXNwZWNpYWxseSBpbiByZWxh dGlvbiB0byB0aGUgaW50ZXJjb25uZWN0aW9uIGFycmFuZ2VtZW50cy4gQWx0aG91Z2ggdGhlIHdv cmsgaW4gRVRTSSBhbmQgSVRVLVQgaXMgY3VycmVudGx5IHRlbmRpbmcgdG8gYXNzdW1lIHRoZSBj b250aW51YXRpb24gb2YgdGhlICJQU1ROIG1vZGVsIiB3aXRoIHVzYWdlIGJhc2VkIGNoYXJnZXMs IHRoZSBtb2JpbGUgb3BlcmF0b3JzIGFyZSBzdHVkeWluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhl aXIgR1JYIGJhY2tib25lIGZvciB0aGUgc3VwcG9ydCBvZiBzZXJ2aWNlcyBvbiB0aGUgSVAgTXVs dGltZWRpYSBTdWJzeXN0ZW0sIHdoaWNoIGlzIHRoZWlyIGVxdWl2YWxlbnQgb2YgdGhlIGZpeGVk IE5HTi4NDVRoZSBjb25jZXB0IHByb3Bvc2VkIGZvciBkaXNjdXNzaW9uIGhlcmUgaXMgdGhhdCB0 aGUgTkdOIHNob3VsZCBjb25zaXN0IG9mIGEgaGlnaCBxdWFsaXR5IGludGVyY29ubmVjdGVkIGJh Y2tib25lIG5ldHdvcmsgcHJvdmlkaW5nIGNvbm5lY3Rpdml0eSB3aXRoIGEgc2VwYXJhdGlvbiBv ZiBjb25uZWN0aXZpdHkgYW5kIHNlcnZpY2UgcHJvdmlzaW9uLiBUaGlzIGFycmFuZ2VtZW50IHdv dWxkIGFsbG93IGVhc3kgcHJvdmlzaW9uIG9mIG5ldyBhbmQgdGhpcmQgcGFydHkgc2VydmljZXMg YW5kIHdvdWxkIGFsc28gYWxsb3cgY2xhc3MtYmFzZWQgcmF0aGVyIHRoYW4gc2VydmljZSBiYXNl ZCBtZWFzdXJlcyB0byBpbXByb3ZlIHF1YWxpdHkgc3VjaCBhcyBwcmlvcml0aXNhdGlvbiBpbiBy b3V0ZXIgcXVldWVzLg0NQXQgdGhlIGNvbm5lY3Rpdml0eSBsZXZlbCB0aGVyZSB3b3VsZCBiZSBz ZXBhcmF0aW9uIGJldHdlZW4gdGhlIGFjY2VzcyBzeXN0ZW1zIGFuZCB0aGUgYmFja2JvbmUuDQ1U aGlzIG1vZGVsIGZvciB0aGUgTkdOIHdvdWxkIGNyZWF0ZSBhIG11bHRpLW9wZXJhdG9yIGJhY2ti b25lIHBsYXRmb3JtIHdoZXJlIHRoZSBuZXcgY2hhcmdpbmcgYXJyYW5nZW1lbnRzIHdvdWxkIGFw cGx5LiBUaGlzIHBsYXRmb3JtIHdvdWxkIG5lZWQgdG8gYmUgY29ubmVjdGVkIHRvIHRoZSBleGlz dGluZyBQU1ROIHdpdGggaXRzIHVzYWdlIGJhc2VkIGNoYXJnaW5nIHZpYSBnYXRld2F5cyB3aGlj aCB3b3VsZCBoYW5kbGUgdGhlIHNwZWNpYWwgY2hhcmdpbmcgYXJyYW5nZW1lbnRzIG5lZWRlZCBm b3IgdGhlIFBTVE4uIEluIHRoaXMgd2F5IHRoZSBuZXcgbW9kZWwgY291bGQgZXhwYW5kIGdyYWR1 YWxseSBhcyBuZXcgb3BlcmF0b3JzIGpvaW4gYW5kIG1pZ3JhdGUgc3Vic2NyaWJlcnMgZnJvbSB0 aGUgb2xkIG1vZGVsIHRvIHRoZSBuZXcuIEluIHByYWN0aWNlIHRoZSB0d28gbW9kZWxzIHdvdWxk IGNvLWV4aXN0IGZvciBhIG51bWJlciBvZiB5ZWFycy4gVGhpcyBzbG93IG1pZ3JhdGlvbiBmcm9t IG9sZCB0byBuZXcgd291bGQgYWxsb3cgb3BlcmF0b3JzIHRvIG1pbmltaXplIHRoZWlyIGNvc3Rz IGFuZCBtYXhpbWl6ZSB0aGUgcmV0dXJucyBmcm9tIG9sZGVyIHRlY2hub2xvZ3kgd2hpY2ggY291 bGQgY29udGludWUgdG8gYmUgdXNlZCBmb3Igc3Vic2NyaWJlcnMgd2hvIG9ubHkgbmVlZCB0aGUg UFNUTi4gSXQgd291bGQgYWxzbyBhbGxvdyBuZXcgc2VydmljZXMgdG8gYmUgcHJvdmlkZWQgYXMg YW4gb3ZlcmxheS4NQ2hhcmdpbmcNU3Vic2NyaWJlcnMgd291bGQgcGF5IHNlcGFyYXRlbHkgZm9y IGNvbm5lY3Rpdml0eSBhbmQgc2VydmljZXMsIGFsdGhvdWdoIGEgc2luZ2xlIG9yZ2FuaXNhdGlv biBjb3VsZCBwcm92aWRlIGJvdGguDUNvbm5lY3Rpdml0eSBjaGFyZ2VzDVN1YnNjcmliZXJzIHdv dWxkIHBheSBmb3IgY29ubmVjdGl2aXR5IGJ5IHBheWluZyBmb3IgYWNjZXNzLiBUaGUgcmV0YWls IGNoYXJnZXMgZm9yIGFjY2VzcyBjb3VsZCBiZSB1c2FnZSBiYXNlZCBvciBmbGF0IHJhdGUgYnV0 IHRoZSB1c2FnZSBlbGVtZW50IHdvdWxkIHRha2UgYWNjb3VudCBvbmx5IG9mIHRoZSB2b2x1bWUg b2YgYml0cyBvciBwYWNrZXRzIGFuZCBub3QgdGhlIG5hdHVyZSBvZiB0aGUgc2VydmljZSBwcm92 aWRlZC4gV2hlcmUgYWNjZXNzIGlzIHBhaWQgb24gYSB1c2FnZSBiYXNpcyB0aGUgc3Vic2NyaWJl ciB3b3VsZCBuZWVkIHRvIHBheSBmb3IgaW5jb21pbmcgYXMgd2VsbCBhcyBvdXRnb2luZyBjb21t dW5pY2F0aW9ucy4gVGhpcyBpcyB3aGF0IGhhcHBlbnMgYXQgcHJlc2VudCB3aXRoIEdQUlMuIElu IHByYWN0aWNlIG9uZSB3b3VsZCBleHBlY3QgdGhhdCB1c2FnZSBiYXNlZCBjaGFyZ2VzIGZvciBh Y2Nlc3Mgd291bGQgYmUgdXNlZCBvbmx5IHdoZXJlIHRoZSBhY2Nlc3Mgc3lzdGVtcyBoYXZlIHJl bGF0aXZlbHkgaGlnaCBjb3N0cyBzdWNoIGFzIG1vYmlsZSByYWRpby4gIEFsc28gdXNlZCBmb3Ig c29tZSBicm9hZGJhbmQgZml4ZWQgYWNjZXNzIHRlY2hub2xvZ2llcy4NDUFjY2VzcyBwYXltZW50 cyBtYXkgYmUgcXVhbGl0eSByZWxhdGVkIG9uIGEgY2xhc3MgcmF0aGVyIHRoYW4gYSBzZXJ2aWNl IGJhc2lzLiBUaGlzIHdvdWxkIG1hdGNoIHRoZSBxdWFsaXR5IGlzc3VlcyB3ZWxsIGJlY2F1c2Ug dGhlIG1haW4gcXVhbGl0eSBwcm9ibGVtcyBhcmUgYmVsaWV2ZWQgdG8gbGllIGluIHRoZSBhY2Nl c3Mgc3lzdGVtcy4NDVRoZSBhY2Nlc3MgcHJvdmlkZXIgd291bGQgcGF5IHRoZSBiYWNrYm9uZSBu ZXR3b3JrIHByb3ZpZGVyIG9uIGEgY2FwYWNpdHkgYmFzaXMgZm9yIGNvbm5lY3Rpb24gdG8gdGhl IGJhY2tib25lLg0NQmFja2JvbmUgb3BlcmF0b3JzIHdvdWxkIG5vcm1hbGx5IGludGVyY29ubmVj dCB1c2luZyBwZWVyaW5nLg1TZXJ2aWNlIGNoYXJnZXMNU3Vic2NyaWJlcnMgY291bGQgcGF5IGZv ciBzZXJ2aWNlcyBvbiBhIHVzYWdlIG9yIGZsYXQgcmF0ZSBiYXNpcyBidXQgaW4gcHJhY3RpY2Ug cGF5bWVudCBmb3IgbW9zdCBsb3dlciBjb3N0IHNlcnZpY2VzIHdvdWxkIHByb2JhYmx5IGJlIGZs YXQgcmF0ZS4NDVNlcnZpY2UgcHJvdmlkZXJzIHdvdWxkIG5vdCBiZSBjb25zdHJhaW5lZCBieSB0 aGUgY29ubmVjdGl2aXR5IHByb3ZpZGVycyBidXQgd291bGQgbm9ybWFsbHkgYmFzZSBpbnRlcmNv bm5lY3Rpb24gY2hhcmdpbmcgb24gYSBzZW5kZXIga2VlcHMgYWxsIGJhc2lzIGFzIHRoaXMgbWVh bnMgdGhhdCBzZXJ2aWNlcyBjYW4gYmUgaW50ZXJjb25uZWN0ZWQgd2l0aG91dCBuZWVkaW5nIGNv bW1lcmNpYWwgYWdyZWVtZW50cyBhbmQgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSBlbWFpbCBo YXMgZ3Jvd24gc28gcmFwaWRseS4gRW1haWwgYWxyZWFkeSB1c2VzIHRoaXMgbW9kZWwuDUNvbm5l Y3Rpb24gdG8gdGhlIFBTVE4NQ29ubmVjdGlvbiB0byB0aGUgUFNUTiB3b3VsZCBiZSB2aWEgZ2F0 ZXdheXMgd2hpY2ggd291bGQgYmUgcnVuIGJ5IHNlcnZpY2UgcHJvdmlkZXJzIGZvciB0aGVpciBv d24gc3Vic2NyaWJlcnMgb3IgY291bGQgYmUgcnVuIGluZGVwZW5kZW50bHkgYXMgYSAic2Vydmlj ZSIgdG8gb3RoZXIgc2VydmljZSBwcm92aWRlcnMgKGllIHRoZXJlIGNvdWxkIGJlIGEgZmV3IGdh dGV3YXkgcHJvdmlkZXJzIGluIGVhY2ggY291bnRyeSB3aG8gd291bGQgc2VydmUgbWFueSBzZXJ2 aWNlIHByb3ZpZGVycyBhbGwgYXJvdW5kIHRoZSB3b3JsZCBmb3IgY29ubmVjdGlvbnMgd2l0aCB0 aGUgUFNUTiBpbiB0aGF0IGNvdW50cnkuDVN1bW1hcnkNRmlndXJlIDYgc2hvd3MgdGhlIG1vZGVs IGFuZCB0aGUgcmV0YWlsIGFuZCBpbnRlcmNvbm5lY3Rpb24gY2hhcmdpbmcgZm9yIGNhbGxzIGFu ZCBzZXJ2aWNlcyB3aXRoaW4gdGhlIG5ldyBtb2RlbC4gU2F5IGNlbnRyYWwgdHJhbnNpdCBtb2Rl bCBjb3VsZCBoYXZlIGNhcGFjaXR5IGNoYXJnZXMuICBTYXkgU1AgY291bGQgYmUgY29ubmVjdGVk IHRvIG1pZGRsZSB0cmFuc2l0IG9wZXJhdG9yIHZpYSBhIGRpZmZlcmVudCBhY2Nlc3MgbmV0d29y ay4gICAgQWRkIGFjY2VzcyBzdWJzY3JpcHRpb24gZm9yIFRlcm1pbmFsIEIuDQ0BDQ1GaWd1cmUg NjogQ2hhcmdpbmcgd2l0aGluIHRoZSBuZXcgbW9kZWwNDUZpZ3VyZSA3IHNob3dzIHRoZSBtb2Rl bCBhbmQgdGhlIHJldGFpbCBhbmQgaW50ZXJjb25uZWN0aW9uIGNoYXJnaW5nIGZvciBjYWxscyBh bmQgc2VydmljZXMgZXh0ZW5kZWQgdmlhIGdhdGV3YXkgb3V0IHRvIHRoZSBvbGQgbW9kZWwuDQ0B DQ1GaWd1cmUgNzogQ2hhcmdpbmcgZm9yIHNlcnZpY2VzIGNvbm5lY3RlZCB0byB0aGUgb2xkIG1v ZGVsDQwNQ29uY2x1c2lvbiBhbmQgbmV4dCBzdGVwcw1UaGUgaWRlYXMgcHJlc2VudGVkIGhlcmUg bmVlZCBicm9hZCBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgaW5kdXN0cnkuIFVuZm9ydHVuYXRlbHkg dGhlIHN0YW5kYXJkcyBib2RpZXMgbm9ybWFsbHkgY29uc2lkZXIgb25seSB0ZWNobmljYWwgaXNz dWVzIGFuZCB0aGUgZml4ZWQgb3BlcmF0b3JzIG5lZWQgYSBib2R5IHNpbWlsYXIgdG8gdGhlIEdT TSBBc3NvY2lhdGlvbiB3aXRoaW4gd2hpY2ggdGhlIGNhbiBkaXNjdXNzIGlzc3VlcyBzdWNoIGFz IHRoaXMgdGhhdCBpbnZvbHZlIGJvdGggdGVjaG5pY2FsIGFuZCBjb21tZXJjaWFsL29wZXJhdGlv bmFsIGFzcGVjdHMuDQ1JdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBuZWNlc3NhcmlseSBoZWF2eSBp bnZvbHZlbWVudCBvZiByZWd1bGF0b3JzIGluIGludGVyY29ubmVjdGlvbiBmb3IgdGhlIFBTVE4g aGF2ZSBiZSBoYXZpbmcgdGhlIHVuaW50ZW5kZWQgZWZmZWN0IG9mIHN1cHByZXNzaW5nIG1vcmUg cmFkaWNhbCB0aGlua2luZyBhYm91dCBhIG5ldyBtb2RlbCBhbmQgdGhlcmVmb3JlIEdvdmVybm1l bnRzIGFuZCByZWd1bGF0b3JzIG1heSBuZWVkIHRvIHRha2UgYW4gaW5pdGlhdGl2ZSB0byBzaW11 bGF0ZSBzdWNoIGRpc2N1c3Npb25zLg0NVGhlIG92ZXJhbGwgaW50ZW50aW9uIGlzIHRoYXQgYSBt aWdyYXRpb24gdG8gYSBuZXcgYW5kIGJldHRlciBtb2RlbCB3b3VsZCBub3QgYmUgaW1wb3NlZCBi dXQgd291bGQgYmUgbWFya2V0IGxlZCBvbiB2b2x1bnRhcnkgYmFzaXMuDQ0DDQ0EDQ0DDQ0EDQ0I RUNDIFJFUE9SVCBYWFgNDQhEUkFGVCBFQ0MgUkVQT1JUIDc1DQ0NDQhFUkMgUkVQT1JUDQ1Db3B5 cmlnaHQgMjAwMCB0aGUgRXVyb3BlYW4gQ29uZmVyZW5jZSBvZiBQb3N0YWwgYW5kIFRlbGVjb21t dW5pY2F0aW9ucyBBZG1pbmlzdHJhdGlvbnMgKENFUFQpDQ0IRFJBRlQgRUNDIFJFUE9SVCA3NQ1Q YWdlIBMgUEFHRSAUMhUNDQ0IDQ0IDQ0IRFJBRlQgRUNDIFJFUE9SVCA3NQ1QYWdlIBMgUEFHRSAU OBUNDQ0IRFJBRlQgRUNDIFJFUE9SVCA3NQ1QYWdlIBMgUEFHRSAUORUNDQ0NDQhFUkMgUkVQT1JU DQ0NDQ0NCEVDQyBSRVBPUlQNUGFnZSATIFBBR0UgFDEVDQ0NRWxlY3Ryb25pYyBDb21tdW5pY2F0 aW9ucyBDb21taXR0ZWUgKEVDQykgDXdpdGhpbiB0aGUgRXVyb3BlYW4gQ29uZmVyZW5jZSBvZiBQ b3N0YWwgYW5kIFRlbGVjb21tdW5pY2F0aW9ucyBBZG1pbmlzdHJhdGlvbnMgKENFUFQpDQ0NDQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAAAIEAAADBAAABAQAAAUEAAAIBAAACQQAAAoE AAALBAAADwQAAEEEAABKBAAAXgQAALcEAADZCQAA3AkAAO0JAADuCQAA/AkAAP0JAAD+CQAA/wkA AAwKAAANCgAAJwoAACgKAAApCgAAKgoAACsKAAAsCgAALQoAAC4KAAA6CgAAOwoAAFUKAABWCgAA VwoAAFgKAABZCgAAWgoAAPPq5dzl1OXOxs68rc7lAOXOos6inI+chJx2hJyEj5yPnIScaISchI8A AAAAGgIIgQNquEAAAAYIAVUIAW1IAARuSAAEdQgBABoCCIEDajtAAAAGCAFVCAFtSAAEbkgABHUI AQAUA2oAAAAAVQgBbUgABG5IAAR1CAEAGTUIgTsIgUNKGABhShgAbUgABG5IAAR1CAELbUgABG5I AAR1CAEUA2oAAAAANQiBVQgBbUgJCHNICQgAHDBKIABDShgAT0oAAFFKAABhShgAbUgJCHNICQgA EzUIgUNKGABhShgAbUgJCHNICQgPNQiBQ0ocAG1ICQhzSAkICzUIgW1ICQhzSAkIDjUIgTYIgW1I CQhzSAkIABEDaqQGAABVCAFtSAkIc0gJCAhtSAkIc0gJCAARA2oAAAAAVQgBbUgJCHNICQgYA2oA AAAAVQgBbUgABG5IAARzSAkIdQgBKAAEAAADBAAABQQAAAYEAAAHBAAACAQAAAkEAAAKBAAACwQA AAwEAAANBAAADgQAAA8EAABABAAA9gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADpAAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAKIA AAAAAAAAAAAAAADGAAAAAAAAAAAAAAAAxgAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAADGAAAAAAAA AAAAAAAAdAAAAAAAAAAAAAAAAAAAAAAAAAAuAAADJAENxk0AGQAAEAUgCjAPQBRQGWAecCOAKJAt oDKwN8A80EHgRvBLAFEQViBbMGBAZVBqYG9wdLB2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACok AWEkASQAAAMkAg3GNQAR7vq+/XkELgb+CM4Lng5uET4UDhfeGa4cfh9OIh4l7ie+KgAAAAAAAAAA AAAAAAAAAAAAE6T0ASokAWEkAiEAAA3GNQAR7vq+/XkELgb+CM4Lng5uET4UDhfeGa4cfh9OIh4l 7ie+KgAAAAAAAAAAAAAAAAAAAAAAE6T0ASokAQABDwAABAAAAyQBYSQBAAcPAA+EIRwTpCwBXoQh HAkAABiEFAUZhDcBGyagL4SNAAANAAQAAL08AAALPgAAjz4AAP39/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEBAABAQNABAAAQQQAAEoEAABLBAAATAQAAF4EAABfBAAAcQUAAHIFAADp BgAA6gYAACYIAAAnCAAAUggAALIIAAAUCQAA1QkAANYJAADXCQAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAACvAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAA AAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgA AAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAJ4AAAAAAAAAAAAAAACeAAAAAAAA AAAAAAAAngAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAAAAAAAAAACgAAAyQD CiYAC0YFABOkeABhJAMABAAAAyQDYSQDAAEAACIAAAMkAQ3GNQAR7vq+/XkELgb+CM4Lng5uET4U DhfeGa4cfh9OIh4l7ie+KgAAAAAAAAAAAAAAAAAAAAAAKiQBYSQBLgAAAyQBDcZNABkAABAFIAow D0AUUBlgHnAjgCiQLaAysDfAPNBB4EbwSwBREFYgWzBgQGVQamBvcHSwdgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqJAFhJAEAEtcJAADYCQAA2QkAANoJAADbCQAA3AkAAN0JAADeCQAA3wkAAOsJ AADsCQAA7QkAACwKAABaCgAAngoAANoKAAAZCwAATAsAAI0LAADcCwAABwwAAEAMAAB0DAAArwwA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA1gAAAAAAAAAA AAAAANYAAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAADP AAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAyAAAAAAA AAAAAAAAAM8AAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAyAAAAAAAAAAAAAAAAMgAAAAAAAAAAAAA AADIAAAAAAAAAAAAAAAAAAAAAAAHEwANxggAAiADuCYACgcSAA3GCAACkAG4JgAKAAQAAAMkAWEk ASIAAAMkAQ3GNQAR7vq+/XkELgb+CM4Lng5uET4UDhfeGa4cfh9OIh4l7ie+KgAAAAAAAAAAAAAA AAAAAAAAKiQBYSQBAAEAAAAXWgoAAFsKAABcCgAAfgoAAH8KAACZCgAAmgoAAJsKAACcCgAAnQoA AJ4KAAChCgAAogoAALkKAAC6CgAAuwoAANUKAADWCgAA1woAANgKAADZCgAA2goAAN0KAADeCgAA +AoAAPkKAAD6CgAAFAsAABULAAAWCwAAFwsAABgLAAAZCwAAHAsAAB0LAAArCwAALAsAAC0LAABH CwAASAsAAEkLAABKCwAASwsAAEwLAABPCwAAUAsAAGwLAABtCwAAbgsAAIgLAACJCwAAigsAAIsL AACMCwAA+ez54fnT4fnh7Mu/y/nh+bHh+eG/y7/L+eH5o+H54b/Lv8v54fmV4fnhv8u/y/nh+Yfh +eEAGgIIgQNqKUMAAAYIAVUIAW1IAARuSAAEdQgBABoCCIEDaqxCAAAGCAFVCAFtSAAEbkgABHUI AQAaAgiBA2ovQgAABggBVQgBbUgABG5IAAR1CAEAGgIIgQNqskEAAAYIAVUIAW1IAARuSAAEdQgB ABY6CIFDShgAYUoYAG1IAARuSAAEdQgBAA9tSAAEbkgABHNICQh1CAEaAgiBA2o1QQAABggBVQgB bUgABG5IAAR1CAEAFANqAAAAAFUIAW1IAARuSAAEdQgBABk1CIE7CIFDShgAYUoYAG1IAARuSAAE dQgBC21IAARuSAAEdQgBADWMCwAAjQsAAI4LAACPCwAAvAsAAL0LAADXCwAA2AsAANkLAADaCwAA 2wsAANwLAADdCwAA3gsAAOcLAADoCwAAAgwAAAMMAAAEDAAABQwAAAYMAAAHDAAACgwAAAsMAAAf DAAAIAwAACEMAAA7DAAAPAwAAD0MAAA+DAAAPwwAAEAMAABDDAAARAwAAFMMAABUDAAAVQwAAG8M AABwDAAAcQwAAHIMAABzDAAAdAwAAHcMAAB4DAAAjgwAAI8MAACQDAAAqgwAAKsMAACsDAAArQwA AK4MAAD07uHu1u7I1u7W4e7h7tbuutbu1uGy9LLu1u6k1u7W9LL0su7W7pbW7tb0svSy7tbuiNbu 1gAAABoCCIEDappFAAAGCAFVCAFtSAAEbkgABHUIAQAaAgiBA2odRQAABggBVQgBbUgABG5IAAR1 CAEAGgIIgQNqoEQAAAYIAVUIAW1IAARuSAAEdQgBAA9tSAAEbkgABHNICQh1CAEaAgiBA2ojRAAA BggBVQgBbUgABG5IAAR1CAEAGgIIgQNqpkMAAAYIAVUIAW1IAARuSAAEdQgBABQDagAAAABVCAFt SAAEbkgABHUIAQAZNQiBOwiBQ0oYAGFKGABtSAAEbkgABHUIAQttSAAEbkgABHUIARY6CIFDShgA YUoYAG1IAARuSAAEdQgBNa4MAACvDAAAsgwAALMMAAC6DAAAuwwAALwMAADWDAAA1wwAANgMAADZ DAAA2gwAANsMAADcDAAA3QwAAPcMAAD4DAAAEg0AABMNAAAUDQAAFQ0AABYNAAAXDQAAGA0AABwN AAAdDQAATg0AAFsNAAAdEgAAKRIAADsSAACoEwAAbRUAAI8VAACrGwAArBsAAK4bAADMGwAA8hsA APMbAAD0GwAADRwAAI0iAACOIgAAjyIAAKkiAAB0IwAAdSMAAPTs9Ozm2+bN2+bb9ObA5tvmstvm 28CnoZyhAJwAnACcAJyTnKGcipyhnIGcoZx4ABEDavpVAABVCAFtSAkIc0gJCBEDaolRAABVCAFt SAkIc0gJCBEDattMAABVCAFtSAkIc0gJCBEDahFHAABVCAFtSAkIc0gJCAhtSAkIc0gJCAALNQiB bUgJCHNICQgUA2oAAAAANQiBVQgBbUgJCHNICQgAGgIIgQNqlEYAAAYIAVUIAW1IAARuSAAEdQgB ABk1CIE7CIFDShgAYUoYAG1IAARuSAAEdQgBGgIIgQNqF0YAAAYIAVUIAW1IAARuSAAEdQgBABQD agAAAABVCAFtSAAEbkgABHUIAQALbUgABG5IAAR1CAEPbUgABG5IAARzSAkIdQgBFjoIgUNKGABh ShgAbUgABG5IAAR1CAEvrwwAANsMAAAXDQAAGQ0AABoNAAAbDQAAHA0AAB0NAABODQAAWw0AAOEO AADiDgAAoBAAAKEQAAC6EQAAuxEAAB0SAAApEgAAqRMAAKoTAAC3FAAAuBQAAPgAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAA AAAAAAAAAAAAAOoAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAALUAAAAAAAAA AAAAAADqAAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAAALUAAAAAAAAAAAAAAAC1AAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAAALUAAAAA AAAAAAAAAAC1AAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAAAAAABAAAAyQDYSQDAAEBAC4AAAMkAQ3G TQAZAAAQBSAKMA9AFFAZYB5wI4AokC2gMrA3wDzQQeBG8EsAURBWIFswYEBlUGpgb3B0sHYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKiQBYSQBAAEAAAAEAAADJAFhJAEHEgANxggAApABuCYACgcT AA3GCAACIAO4JgAKABW4FAAAbRUAAI8VAACnFQAA4BgAABkZAABEGQAAXxkAAKkbAACqGwAAqxsA AK0bAACuGwAAzBsAAM0bAADOGwAA8RsAAPIbAAD0GwAADRwAAA4cAAD7HQAACh4AAJoeAACbHgAA 0x4AAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADr AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAOQAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAyQBYSQBAAEAAAgAAAMkAwomAAtGBgBhJAMAASIAAAQBAAMkA2Ek AwAEAAADJANhJAMAGdMeAAD7HgAASB8AAEkfAAC7HwAALSAAAK0gAACuIAAAjCIAAI0iAACPIgAA qSIAAKoiAABzIwAAdCMAAHYjAACWIwAAlyMAACYkAAAnJAAAzCQAAM0kAADPJAAA4yQAAOQkAAD+ JQAAGyYAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAA AAAAAADjAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAADlAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADhAAAAAAAAAAAA AAAAAAAAAAABIgAAAQAAAAQAAAMkAWEkAQgAAAMkAwomAAtGBwBhJAMABAAAAyQDYSQDCAAAAyQD CiYAC0YIAGEkAwAadSMAAHYjAACWIwAAzSQAAM4kAADPJAAA4yQAAPooAAAnKQAAsy8AALwvAAC+ OAAAvzgAAME4AADpOAAAcjkAAHM5AAB1OQAAsDkAALI5AADMOQAAvTwAAL48AADAPAAAwTwAAMM8 AADEPAAAxjwAAMc8AADJPAAAyjwAANk8AADaPAAA2zwAAO88AADwPAAA8TwAAPI8AADzPAAA/jwA AF89AABgPQAAdD0AAHk9AAB6PQAAgD0AAIE9AACCPQAAgz0AAIQ9AACFPQAAhj0AAIc9AACJPQAA ij0AAIw9AAD79fvs+/X7APsA++P79fva+/X7APvVANUA1QDVAMrIAMrAvbkAyrMApJ69l5SXjJe9 yADKAMoAAA8wShEAbUgABG5IAAR1CAEEMEoRAAANA2oAAAAAMEoRAFUIAQs1CIFDShAAYUoQABwD agAAAABDShAAVQgBYUoQAG1IAARuSAAEdQgBAAs1CIFtSAYEc0gGBAc1CIFDShAABENKEAAADjUI gUNKFABcCIFhShQAAAM1CIEUA2oAAAAAVQgBbUgABG5IAAR1CAEACQNqAAAAAFUIAREDanFmAABV CAFtSAkIc0gJCBEDah5fAABVCAFtSAkIc0gJCBEDaoZaAABVCAFtSAkIc0gJCAs1CIFtSAkIc0gJ CAhtSAkIc0gJCDcbJgAA3CcAAN0nAACeKAAAnygAAPooAAAnKQAAxyoAAMgqAABeLAAAXywAAMAs AADBLAAAsy8AALwvAAAvMAAARDAAALYyAAC3MgAAfDMAAH0zAADtMwAA7jMAACw0AAA8NAAAzzQA ANA0AAAXNgAALjYAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAABIgAAAQEAAAEAAAAE AAADJANhJAMAHC42AACLNwAAkzcAAL04AAC+OAAAwDgAAME4AADpOAAA6jgAAHE5AAByOQAAdDkA AHU5AACwOQAAsjkAAMw5AAAPOwAAEDsAADY8AAA3PAAAvDwAAL08AAC/PAAAwDwAAMI8AADDPAAA xTwAAMY8AAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD2AAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAAQAAAMkAWEkAQABAAAAASIAAAQA AAMkA2EkAwAbxjwAAMg8AADJPAAA2TwAANo8AADvPAAA8DwAAPE8AADyPAAA/jwAAP88AABePQAA Xz0AAHQ9AACEPQAAhT0AAIY9AACIPQAAiT0AAIs9AACMPQAAoT0AALE9AACyPQAAsz0AAMg9AADY PQAA2T0AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAABBAAAyQBYSQBAAQPAAMkAmEkAgAEAAADJAJh JAIAAQAAABuMPQAAjT0AAKE9AACmPQAApz0AAK09AACuPQAArz0AALA9AACxPQAAsj0AALM9AAC0 PQAAyD0AAM09AADOPQAA1D0AANU9AADWPQAA1z0AANg9AADZPQAA3D0AAN09AADoPQAA7T0AAO49 AAD5PQAA/j0AAP89AAAFPgAABj4AAAc+AAAIPgAACT4AAI8+AACQPgAA9fPw5+Ln2Ofw8wDJw/C8 ubyxvPCtAPWnAPWnuby5vLG8ogCdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhtSAkIc0gJCAAIbUgGBHNIBgQA CzUIgW1IBgRzSAYEBzUIgUNKEAAPMEoRAG1IAARuSAAEdQgBBDBKEQAADQNqAAAAADBKEQBVCAEL NQiBQ0oQAGFKEAAcA2oAAAAAQ0oQAFUIAWFKEABtSAAEbkgABHUIAQATMEoRAGFKEABtSAAEbkgA BHUIAQgwShEAYUoQAAARA2oAAAAAMEoRAFUIAWFKEAAEQ0oQAAADNQiBFANqAAAAAFUIAW1IAARu SAAEdQgBJNk9AADaPQAA2z0AANw9AADoPQAA6T0AAOo9AADrPQAA7D0AAO09AAD5PQAACT4AAAo+ AAALPgAANj4AAI0+AACOPgAAjz4AAJA+AAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADiAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAMkAWEkAQAJAAAPhNACEYTQAl6E0AJghNACAAQQAAMkAWEkAQAEDwADJAJhJAIAARAA AAEAAAASNgAJMAQSMAAmUAkAHFABAB+wgy4gsMhBIbBuBCKwUwMjkIoFJJCKBSWwAAAXsMQCGLDE AgyQxAI2AAkwAxIwACZQCQAcUAEAH7CDLiCwyEEhsG4EIrBTAyOQigUkkIoFJbAAABewxAIYsMQC DJDEAi8ACTAEJlAJAB+wgy4gsMhBIbBuBCKwUwMjkIoFJJCKBSWwAAAXsMQCGLDEAgyQxAIvAAkw AyZQCQAfsIMuILDIQSGwbgQisFMDI5CKBSSQigUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACkBgAARABkALYArwAAAAIAAAAAAAAAAQAAAAAAqgpBCkABNgEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAACBAAAAAoAAEMAC/AYAAAABEECAAAAgQER AAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAAAACAYgAH8BQGAAAGBuiD/fZZxZjLcDKefZR3v+r/APAF AAABAAAARAAAAAAAYQIAbh7w6AUAAOiD/fZZxZjLcDKefZR3v+r/iVBORw0KGgoAAAANSUhEUgAA ALYAAACvAQMAAABq57YUAAAABGdBTUEAALGIlZj0pgAAAAZQTFRFAAAA////pdmf3QAAAAlwSFlz AAAOxAAADsQBlSsOGwAABWdJREFUeJyl181qJDcQB3C1Bds5LKMc9zBYA/sCe/RhGO2jLOQFFkJg Asatjg97zAsE8ipyHDK37Cto8SHHyOxFB9HKv0r96XRDIF4We34zo5FKVSWNyKs/SfwPv2z4pw2v 1z1teNxwv+Fuw8W6dxseNzxsuNtw8XrVO3Fc9ShuV91X6/Fx9boLvepJNKsexHr8vVx3q1a9E4bc CbX0KGh/kxCiWXiQ5B6uFu4UOVjIhWN4/C2qToi5d4L/xuCRXjF6lJjKLW+M1TMPKtLYGtEI9cy9 ceTZCpnkzN0dT4XnX83c8jA8f21nLj27pTd5M3pXY/hvxCt6sgqTJ8UDCEEfc9ajx2vROBXog4/i qEYPR4mlJaFpfdf16P6sciczFqVyVHJy+qwqO6wPUb0f/cFjN2z+kh1+y3ZyR29qnjJR60a/f2D/ mmlo5yen1wXTe2gGr+lxNF87mqL/aEZHhpiknzvVYa7nwbtdjW1iT8KEGz1z7JV6TrRh8Ti56tSv XfEc96r3tFdJ5+JYMAVodEMeDfluch0beChOgSt+Q55Hv+89Fq/JqZzaF+57f9hwN/i74ocy/sx5 njtxZpfYpeIfy7pGN6N3ivyW1yvDzIUujoSQQQ/O8dTkiKeMvQe4Y1dUGDKq4fVItxy1OBVPo1e8 7/KO91ei8JfO+eAlUrJ3wflzX/KEnh4cYXD5nvPNSqRqH4cDUqNFjlAKVhKp2sfzHZZbRaEoAnLm N1QXHjWncWqgNprejwKnhc0tit3vZn6iuqsffULlnSTKo+z7G4NaPKk2Uj3ewfWQJ6jrpH9JhlqQ zGH0iBo9HK80DgFEIarBEf/4/ijxPLXjWA95S/Fx++pnnJ043tLcn52o6OQkl2P+F6eTNlDzGOso 5yd3BzcLR3yrJ5urR3RDbkXF5X121RMagR/8tq/fIKrf3ubfP8C5Ax7ZW4Sh+un7/OdB6GyLd6L/ ufoxfz4MD44i8e8frLj6vnhluT/w6yt06Ku3+Y/vEJ+hn5Tm3gmJ+Tw5MfYT7pzwR5vlo22y96Wf 2OLNk2vk5TP1k+KuPzy+2EOJz+A6e46nLfEMN6XPIDcCtdhg3yD+lAXFgX7YL9TN5Ap5gR4caX89 9nFf+g/2h4+LZPYJ+VIPnsjFlD+jI49O4rrPN4T+dXHkkT/jv2qRn2jep13f3yosEWWLM0NiIf56 1/e3NrsPaA8yCOVMjrvBbXbvsXScjQ1Cn14N7hpHu2mzp/rqrmZOdYpTgetRvOodq+K6bTz3bfvC A5zi6ureg+YbVzihb9D7Bo8apzj6Cxz5byZXWI4wONzOOqDPD+Mnduo/ZxPnXmNfroujR8TBu96p H+KuGYd14fQlR99DJvwXb0PxGn5ZuOH++Sks3ZGbyfXoyJ9cHOPvB/dn3elt1y8dJx886U+R17Uf zkecfOyX4jej79XMw+jpmjyaCxo8/NwMjn7CjtPkMtYLAqp4H5sLGvzfuDSMXpd8uJR9n859vjL4 fOE8aWf3Acd59RfnVfswekv3jBafWeXFfcN5ymc8Q3k7u59Q/qcaMcX7opruOeGG6oVyCjU7u/+E o2gEalShjuzsvoSjSwjq2XF5v0p0Qzvg33F5H+vK/S1wK6I5D/c6HqA8qeb3PdvQQcKd08zvh44a BHeuanGfDHwA8zBxfv+MvP1iL7hNTY40RIHy1daamcNQ3ORduViP92ca+x088nRm93DMn1baf3ka 7/M0f3K7vIfjDTjmDN/rF86rMGXCK+7lulu16sPwL30Y/qX7at1tve4UvhU/9t9GXvq346Ol919G /u31husNNxue173a8HrD9YabDW/W/Tmv+9cNn/2kfwBD3VfIS8sygAAAAABJRU5ErkJggpc5AABE AGQAAAAAAAAAAgAAAAAAAAABAAAAAAABAAEA6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADwAE8DwAAACyBArwCAAAAAEEAAAACgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/ AQAACAAAABDwBAAAAAAAAIAyAAfwBzkAAAMEJV8DtCZSD42jtouBYeVsg/8A4zgAAAEAAADoBgAA AABhAmAhG/DbOAAAJV8DtCZSD42jtouBYeVsg/xnAAAAAAAAAAAAAAEAAAABAAAA0AIAANACAACp OAAAAP54nK3aBZhWR7oo6lprxd3d3d3dPUQnE+jGCd3QjbtLExy6cRqHH4fG07ikg4QkSEI8IS4E iRuZTLjv+veZfc997t7n7JnMzvNOd///WlVfffVVrVrJjsL+ISS7rwxhr9B8rxDSnz6I9gt7+3lg nH6S/nZQHIXoP7/7P13zH7/9kfyR/L/fptfvE0VhXz9/98m2zD8+vTgKaQThtzi9OoQ9e/aEM/7X N9F/3neAe85KkqhNdEhoHR0RWkbHhhbRiaF5dFpoFp0dmkbnh8bRJaFRdEVoGF0bGkQ3hcLoNu4O BdH9oX5UKdSLngj50V/JDXlRTeqGulF9GoVnoua0DnWiDnSlR6gd9aGEIYxgDBnmsMw1693zhnY+ 0ebX+vhNv/tEjaIjoqbRKVGL6IKodXRN1D66I+ocPRx1iypHvaI6Uf+ocTQoahcNj7pHY6IB0cRo ZDQ9mhzNjeZEC6Ol0YpoTbQ22hRtiN6J3og+jbZGO6PPo5+jr6M9/ne/eE90eLx/fHx8RHxGfFJ8 QXx2fHl8aXy9f26L74zvjSv55+n4ybh2nBM3iGvEreO6cVFcEBfHTeIRcYt4Utw2nht3jJfFXeMX 4+7x63Gv+KO4b7zTFb/GA+O9ksHxYcnQ+KRkeHx+UhpfnYyI70hGxpXIoQZ1qEdDmtGK9q7rQnd6 u6+YwdooZXQyLJ6gzSnMSIbEc/TxHIuTQfGKZGD8QjIgXpeUxK8kxfGrSf/4jaRf/G7SJ/4g6R1/ mvSKv0x6xjuT7vF3ybPx10mHeHvSMf486Rx/nHSJ30+6xm8nRfEW321yzUtJj3it659333L3L9LO fGYnfePp2p2s/fGM0tdwfQ6iv/5786xYOtOeVmJrSkPqUYca5FCJO7jGdRe472RtHK7NvfWxO+4d fx33iD+Jn43fjLvEL8n1SjlfELeMp8ZN49FxQ1mu54o6cfu4ulmpHOfFT8S58cPx4+bvPvN4i9m8 Kr7C7F4Ynx6fGR8bnxgfEh8Z7x0fGP8exfGP0e5oR/St6vgyek+FvO6fV6KXVM4q9VOujmaqpwnR jGhYNCnqF42LukYjolbRkKgwKolqRn2jp6Ke0YNq8la1eVXUITovahud5IrDo+bR3up3t/W0y3r6 WE2/bh29yDJraQ4ZxjCCIZT4ri896EpH97ShubXYmALt5FFLm1VDk6gyT1qzj1q7D1rD91jLd1jT N3N9aBVdFdpEl4W20YWhXXRuaB+dETpEp4SO0fGhc3R06BIdFtJ94D92jfCf//ePXSP+z10m3Uv+ scsk2Z/f2m3+6z3ov9txDg+HhMPDkeGwcFw4NJzkr9M5OxwcLggHhUu4MhwYruOmcEC4nXtE9gCP hP3Ckzytx6rUom7YJxTQmOa0sVt2pCs96EsJQxjBGPFk/Fzs2o3u/1S7v+rrYOM/Q2zXyseD8lJD fppHZ4ae9sFR0aVhTnRNWC2fb9n/tkcPh79HT4XD4urhzLheuDpuFu6LO4Qqcc9QEA8OHeJxoX88 M4yNF4c58dqwKn49vBp/Ej6Kvw3fxnvCnviQ6JDklOjk5JLowuSW6LqkUnRPUj16PGkcVU+6RPWT QVHLZFLUJVkY9UnWR0OS96KxydfR1CSK5yZHWePnWos3xi8mlazPWtZ2y/g96/KjZIw1PD/+KlkX 70rej79Nvot/SPZJfkpOTH5JLkt+Te5Odic5yW9JDT/rUI+GNKUV7enMs67tTX8GMdz9oxjP5OTn ZDqztbuARcmPyXIqkh+StbycfJ9s5vXku+Sd5NvkAz5Jvkm+TL5OdiS7/LXLb58l25PP/fNF8rFv 3uftZFuyJfkq2cRLvl3D8+5YluzUx85kvvtmMd3dkxjHKO0OYxD9tdyLZ+lMO1qJoSkNqEcdqpPD PVzumpPcu692v493JFvjbcl6OXzOPjgu3mrveTtpbR+sE29IHrOf3hyvSi6Q/2PNw17xtOS7aHzy YTQ82RD1T5ZG3ZJpUdtkWNQo6R7VSVpETyd1ooeSJ6JbkzujK5Iro7OTM6Njk6Oi/ZK9o9/in8P2 eFt4L343vBy/EpbGK8OMeF4YEU8OveORoXVcHPLibuEvcdtwV9w4XBHnhVPjquHg+C/hN/X3pTp8 PbolPO/ZXBZdHkZY292jc+wBp4dq0cnhATV8dXRMOD06Mhykrn+x1j6xzjZYZ4vIMJYRDGEAfenh miI60oYWNHZvIXnUsm6rUZknreNHeTAcEe7lDqv65nBUuJ6rwtHhMi4Mx4RzwrH2kmPDyVb88f45 Kpzg7nQf+Mf+8t/tKOH4V/8PO0rfkO4od4W3xHV0dGg4luM5kZPtaadyOmca/1mc45xzrnyczwXR UeEia/1iObrE2efS6LhwmZxdHp0QrnAOujI6KVwlj1dHp3JauEZer7FvXhudxdmcE66LzuN8LuAi LuYSLvP95VzBVe67mmu0c602r+cG7d+on5v0d7N+b9H/reK4TTy3hwvt3RdEd4rzLvHeLe67xX+P /eke47nXuO41vvuM8z7jvc+47zP+++Thvmwu/j1ZfVNrHWlPG1rRgubmuimN7csNaRCcCKkf7gr5 4U5Vcodd+fZQJ9wWaodbVcwtoaa6qGE/rx5u5AYVdL0d/FquCbnhaq4KOeEKLueyUMVzoEq4mIu4 gPN9fh7ncLbrz+IMTtfGado7lZO1fZJ+TtTfCfo9Xv/HiePY8IwqzFON+WqvniotoFDFNlSFjWmq HpvRglYy2IZ2dCTNaJqLf1etdjdX3c1Zd3PX3Rx2N5c9zGkPc9tTrfY0173MeS9z31sN9FELfdRq X+31UyP91UqxmilROwPU0EC1NEhNDVFfQxmm1oYzQu2NZBRj1ORYxjGBDBOZzBTfT2UaM9w3kzLt zNbmHOZqf55+5utvgX7L9b9QHIvEs1itLhbfEnEuFe8ycS8X/3K1usJ4VhjXSuNbaZwrjXeVca8y /lXysCqbi39Xra4yV6vU6ipzt8ocrjSXK9XqSnO7whyvMNfL1epyc79MrS5VC0vUxGK1uliNLFIr C9VMudpZoIbmq6V5zFVXc9TYbMrU20xmqMFpTGWK2pzMRDJMYJzPxzKGUa4fyQiGa2OY9oYyRNuD 9DNQfwP0660oFIujv1rtJ66+4uujVvuIt7da7SX+XsbR03h6qtUextfDOLsbb3e12t34u2czmubi 31Wrf5irP8zZH+ZujzncYy73mNM95jZEZ3JWFEXncG4UR+dHiTe0vaKLnHcv5hLvbpdG+0aXRftF l0f7R1dEB0ZXRgc5HR8cXR0dwqHe5g7niOja6EiO4pjouuhYjuMETuQkTuFU35/GGZzpvrM4Rzvn avM8ztf+Bfq5SH8X6/cS/V/qfy/z1+XRhb65wBXpVekd6Z1ncYZWTtdi2vrJpD0e/7+iOJq3QuqP f1utXuc8f13Unja0ooW115ymNLb+Glp/DSiw/upbf/nkWYN1rcE61mBta7CWNVhTDzXsDdWtwerW YLVwnveBcznHO/lZnBnlWIs54TROjaqEUziJEzmB43x+LMdwlOuP5AgO18ah2juEg7V9kH4O1N/+ +t1P//uKY5/ombC3uPYW315RvZCIN44KQyT+yDiC8YSoWdijVveo1T1qdY9a/UOt/pGtrjQXfy6r 92TfKk6PXrC/DLEXenOProgvi67kqvjy6Or4iuia+MroWq6LPX3jq6MbuJGb4muim7klvja6ldu4 Pb4uuoM7uSu+Prqbe7iX+7g/viF6gAd5iIepxCM8yuM8yVM87foq5GirKtW1X5Na+qyj/2fEkyeu fDHWF2uBmAvF3yC+JGoYXxw1ii+MGscXRE3i86Om8blRs/gczoqax2dyetQiPo1TOZkTOYHjOY5j OYajXXsUR3KE+1OHc5g2U4dq/xD9HMxB+kwdqP/UAWLZX0yp/cS3X3RMvCycGC8Np8VLwlneb86P PQfihc6n5eGa+LlwQzw/3OIce0c8x9zMCg94D6oUTw+PxVPDk862T8eZkBOPD9XiMaGGc27teHh4 Jh7irDsw1HfmLYj7hgbeoxrGz4bGcZfQxHtVU2fgpnHL0CxuQgO/51HTd7mueSo0ih9z/UOhML5X G3eG/PhWbd6g7Wv0cWXIjS8NleOLnKXPF8c54eH4zHB/fJpz9Snh1vgkMZ/gHc75Lz4mXBAfbVxH hlPiI8Jx8eHhiPiwcCB7xYeGP5wrf+Z9ylnAPOYwyzlzJtOZ6qw5hUnOmxlnzQmMd94c67w5xnlz tPPmKOfNEc6bI5w3S503hztvDnPeHOq8OdR5c4jz5hDnzcHOm4OdNwc5bw7y7j7IeXOQ8+Yg5/1B zpuDnDcHOW8Oct4c7Lw52HlziPPmEOfNoc6bQ503hzlvDnfeLHXeHOG8OdJ5c5Tz5mjnzTHOm2Od N8c7b05w3pzorDmJKc6a05jurDmTWc6Xc5jHAsrZxs/s5m/8Ed0fQnx/SNg7fiDsy/7xg/L3oPeW h8Kh8cPh8LhSODJ+JBwdPxqOMW/HxY+H4+Mn1NST4SRzeXL8V7mv7F2nihpzvvPOc0b2Pbsmtc3N M+RRL5wdF9CARv5uQjNauK4VbdzXzv0dtNNRe52121X7Rfrppj/nr7iH/nuKo5d4+oirr/j6ibOf ePuLu1j8JcZRYjwDjGuA8Q0wzoHGO9C4Bxr/wOy+k+4/f24n2ydKd7IuISe5I6qd3B4V0Cy5LWqX 3BJ1TW6Oeic3RAOS66LS5OpoXHJFNDm5JCpLLowWJOdGS5IzolXJydGa5Ljo5eTIaHNySPRGsl/0 bhJHHyS/h0+Tn8IXyTdhe7It7Eo+Dt8m74bvk9fCT8nL4efkhfBrsjTsTuYzI/yWZPwcySCf9/F9 kevau765+xq4/xntVNPe09p9LHyQPBDe9Vx7I7klbE6uDy8nV4Y1ySVhVXJ+WJKcFRYkp4Wy5MQw OTkujEuOCqXJ4WFAckjonRwUuib7h3bJfqFZsk8oSPYOtclJ9gpP+Pkgd/r8Rt9f6bqLXH+W+052 /zHaOVR7+2s31v7v8VnhZ6v72/iSsMOK/yK+Pnwc3xLej51iVOEWlbY5fjq8ElcL61XQWlWzOm4e no+dGFXECrO/PB7EyLDMDrU8nsF8ny/1/Quue9n1r7nvXfd/rJ1t2vtGuz9p/3f9xNHHdscv7KQ7 7LTf2oF/tiv/Hp8RxeZnf/N0qPk6xrydbP7OMo8Xmc8rzeuN5vdO8/yg+X6CdP7/b5X0P/s3bS/F B4r40FBhP1sRHxuWxieGhfGpYYH9b258bphlT5wRXxamxleFSTKWiW8O4+I7whj76EhrttQaHRb/ JQyxFgdbgwPjOmGAdVccNwz9rbV+cevQ19rqI4O9raPe1kwvWexlT+9lf+8lk73s+708B3rJZm/P it7xctdXuG+d+1/RzmvaeyuUxO9p/6MwKP5cf9v1+00YHv8YRsS/htHx38NYGR4f7xNN9Fya7Jk1 TZZnyvLs+KRonufgc56Li+LzomXxRdFKz9EXPFvXeua+FN8UbYxvjV6L74zejO+J3o3vjz6IH4o+ iR8xW4+brb9E38RPRz/EVaJf46pmrHoUJTWjfZI60QFJXbOWFx2V1IuOTwqiU5LC6MykYXRu0sjs NY6uSJpE1yZNo5uSZtHtSfPoHh5MWkSP8hQ51KAuBTT2fUvaub6z+551f2/tFGtviHZHaH9sUj/K 6G+qfsuSZ6J5Se1ooXiWJtWs8FwrvHK0Pnkq2pg8Gb2WPBa9mVSyyh+IPkzujT5N7oq+VEk7VNU3 yfXR9yptZ3Jp9FVyZfR5cm30sYrb6rt3VNkbrn3VPRvcuz55WLuPaP/xaJl2FyV/jebrZ3aSE01P qkaTkurReDGMSmpFw+RloLj6ia9Xkh91E2snMbeVnxY0Mob6PJM0MPYGctBALhpEj/EQ9/ruDm52 7XXuu9L9l2jnfO2dLd+naf9EYz5Wf0ckNaKDjXt/494rqRKF5Gnz85fol/gJ8/WYeatk/h6Mvozv iz41tx+a4/fM9VvmfItz12ZnrFecrdY7T61xlqpwhlrp7LTUmWmR81K5M9J8dTRHPZWpqxnxvuoq Vl9/hInxb2GC1T0u/s562KkGv7QmPlWPH6jLd9TnG2FovFmtvmxtrFW3z6vfZSy0RuZRxlQyjKHU d4Pp79pedHNfJ/e31U4L7TW23gq0nxdGxbX0V1XNPx3Gey5mPC8n2cWmxp7H8e1hpnU623qdZ90+ Z/0uso6XxudZ42fZqU4La5xpXnSeecVZZpMzTLoP/Hc7yv/+9/++h6T/5dIuFVdLzgnVknM5j/ND 1eQCLuJiLuFSLuMKruQqruYaruN6buBGbuIWbuU2bucO7uJu7uFe7ucBHtTnQzwcqlODWv6uQ13f 5VPfdYU0dE9jmtI8uS+0pDVtaU9H7XamiGfpQS+f96EfxQxw7yCGaG8Ypdofqa/R+h2bVPL0eiRM IJM8GiZ58k1OHg9TkyfCtOTJMCN5KsxM/upJ93SYlVQOc5KcMDfJDfOSqmF+Ut1TsEZ4LqkVypPa YaEn6KKkblic5HtC1gtLk4KwzJN1edIwrEgah5VJE5p5grYIzyctQ0XSmjbhhaRdWO1JvCbpSKew Nukc1iVdKQovJt3C+qR7eCnpQU9P4V7hFU/vDUnfsDHpR3HYlJR4Qg8IryYDw2vJ4LAlGcLQ8Hoy zNO7NLyZjAhvefK/nYwK7ySjPdXHhveSceH9ZHzYmkzwpM/4PeOzjO8yrsm4NuOejPsz2sloL6Pt jD4y+svoNyOGjFgy4sqIMSPWjJgz4s8YT8a4MsaXMdaMcWfkwBOYZSxlCYtYmDWRSUz2WWoKU+Vy GtOZ4fqZlDGL2dqYw1zmMZ8F2n6OchayiMUsYSnLWM4KVvI8L7CatbzIel7W1gY2sZnX9Pc6b4jj Ld4W27u8L96t5v5DNfARn6iHT9XF5+rjC3WyTb18FWYnO9TOTjW0Sy19o6a+DdOT79TYD2rtRzX3 s9r7JYxPflWPu9Xl39Tn7+r07+r1jzA02RMGJ8H+HEUlTn79nQH6Jnt5xuwd9Uz2ibon+9qv93Oa 3N/z54CoQ3KgZ9GBUZvkoKhVcrD9+xAnTu+DyWGeVYdHDZ0kC5OjPLuOsqcfHdXLOibKJ4+6ybH2 +dRxUR1qJ8dHtaiZnGDvPyGqnpwYVcs6KapKrhNqTtYpnMSJnMDxHMexHMPRHMkRHM5hHMohHMyB HMD+7Me+7MNeJMREBPY4Uf7B7/yN39gdqlCZp/krT/n8SZ7gcdc9yiM87L6HeID75fk+7uFu7tTu HdzGrdysr5u4geu5lmu4iiu5nMu4hIu5kAvcdx7ncg5na/cszuQMTtfvaZzKKeI5mZM4UZwniPt4 jlMPx3KM2jiao9TJkU78R3C4ujmMQ9XQocn34RAOVlMHqa0D1dgByddO0bvCvmpvn2R72Fsd7pV8 GRJ1GavPSJ0G9brH2eyP+MPw93irE+j74W9Owr95Du52dtsdvxl+jV8Pv8RbnMJfDT95Lv4Yb2RD +MHz8fv4pfBd/CLrnNDXhG/i1eFrZ8CvPTN3xatYGXbGK5zcl7MsbHfq3h4vCV/Fi1kUtnmmfhmX 85yT/QLmh889Yz+P54bP4jnh03h2+MQZ82PP3I/jmeEjp/cP4+lMCx94Bm+NpzihTw7vxZOYGN71 TH6P99nKh3zEx3zCZ3zOF3zJNrazg53s4hu+5Tu+5wd+4md+4Vd28zd+5+/8wR6iJDWB8XI7jjGM 9t0oRriulGEMdd8QBmljICUU00+7felNL3rQnWcpoiud6UQH2tOWNu5tRUuaa7cZTfTTmIb6LqRA LPXElmf+61JHLdRWEzXVRg01Ul2tVA37ebbtn1RRP5XV0tNq6q9q6y9q7Ek194Tae1wNPqYeved7 Zh7n+Xm85+iJnqcnea6ewqmesad73p7p2Xu25/G5zgDnOwtcmNxpfdwRLnU+uNw54UrnhaudG65N braubvJGeKO1doM1d3243RnjzuRa6/GacK9zx/3OIA86izycXG79XhYecz55wjnlL84sTyUXWu8X WPvnhdzsmeac/9+56H/2rr45+67+hZ3iRm7iZm7RU+pWbuN27uBO7uJu7uFe7uN+HuBBHuJhKvGI th7lMR43gsftRo+HSv5+mAd9d79r7uVu7nTP7dzKzdzI9VzL1VzJ5a67lIvdeyHna+dcztbuWWbr DLN2mtk7hZOdZE40m8eb2ePM8DFOMkeb7SPN+hFm/3BVcJhqONRp5hDVcbDTzEGq5UCnmQOS+hSo jAYqpCGNVUsTmqmcFrRURa1pSztV1YFOdKYr3XiWHvRyTR/60p9i95cwgIHaHMRghjBUX6lhDNd/ KSMYKZ7UKEaLcQxjxTuO8WJPTSDj74zvMq7LuC+jndQEbY9nrD7HMFocoxgpvhEMZ5gVMpQhDLZi BjKAEoqtpH70pQ+96UkPq6w7z1JEV7rQmY50cE172tGWNrSmlTZb0oLmNKOpflONaSSehjQQYwH1 xVyPfGPIM5661DG+2sZZy3hrUsPYq8tBNfNZ1bzmmt8c81zFfFc27097ojytBv6qFp7ypPmLuviL +njSE+gJtfKEFf242nnMin5MHT2qnh6xqh9RW5XUWCW19rCn3EPq7iH192C4iIvV/qVcZh1czpXW xFVcbX1cy3XWyvXcYN3cZP3czC3W0m3cbl3dwV3W2N3W2j08Zkd4POvGf/pt55Dsf5vZ21vC/TwQ OtAx6/5/cYeYmN0hNjvL1XSmq+VsV5s6znnPOO/VJc/ZL98ZsB71nQcLKHQ2bOCc2JBGzoyNaeL8 2JTmzpMtaEkrZ8zWtHHmbEs7Z9H2dHRu7kRnZ+gudHWeLnLmLnXmLnXmLnXmLvXuUOrcXercXerc XercXepdo9S1pe4pdX+ptkq1W6qPUv2V6r9ULKXiKhVjqVhLxV1qDKXGkhru99QwhvpuCIMZxEAG uCdVQjH96Udf+tCbnnSnG0V0oRMdaa+NtrShlT5a0Fy/TWksr43kt4FcF1Jf3us5Q+c5Q9d1hn7G O1pt5+haYYr5mKziJ6r2jGqfoNrHqfaxqn20ah+l0keo9FKVPoyhKn2wSh9IiUovpp9q70Mv1d6D Z+lGVzqr/o60p62/W9OSFjSjifsa0UA7hdTXbj55+qmm72r6rqbfatm/n/Te+6T33tQToSa1qJ31 uPfgx8MzWY95H35MG49p69FQj/oUZD2in0f094h35Ef0/Yj35EriqORduZKYKnlfriS+h8X5cGhF a9rQlvZ0pDNdKOJZetDLfX3oS3/tljCQQfodwjDxDBffCEaKebRxjDGucYw3xoyxTjTmyfI+xRxM NRfTzMkMczPTHKVr58/9O/W62X8TennUUg8tzHBzmumpqZ6a6KmxnhrZ+xrpraHeGqiQQpVSaKUW qJoC1VNfFdW3UuupqHoqK99KzVdl+VZpnqrLU315VmmeSsxTkXkqM88qzVOleao1T9XmWaF59vR8 lZyvovNVdj2rs54qr6/aC1R9gWdCoRXQwHOvodXQ0KpoZHU0tkqaWC1NrZpmVk9zq6ilFdWK1lZX G6usLe2suA5WXkc6WYVd6EqRVfks3elBT6u1N33oSz+KKfHdAAYyiCEMdf8whmuzlBGM1M8o/Y1m jP7HMk4s48U1QXwZJop1kpgni32KMUw1lhnGODOrBz3pRW/S7/rSj/4UU8IAK3cggxisMoYwlGHa Sw2nVPsjGKmvUfoczRj9j2WcWFLjxTVBfBlxZsSbEXdG/BnjyBhPxrgyxpcxzozxZow7Y/wZKz8j Fxk5ychNRo4ycpVR7Rl5y8hfRh4z8pmxGjJym5rg99R4xvkuNZYxrk2Ndt9oP0f5LDXadaPdN9r8 jDZPo81XaoxdZYz5G2Mex5jPMVbhGHM71hyPNddjrc6x5n2s+R+rDsaqh7HqYgyjGaVORjKCUvWf Gq5+hjFULQ1RU4MZpL4GqrMBlKi5ErVXrA77q8dUP7XZV532Va+pPuq3j3rubdfpbffpbSfqZUfq ZXfqZZfqZbdK9bR79bSL9QxVySXH3OeogRznnhx1n6P+c6yDHOshl6pUy+rq3q7aSBVpM9VN+6ki utKFzj7vREc60J527mlLG1rTipbaa0FzmtGUJvppTCMa0oBCCsRRn3rkk0ddnqEOtV1Ty/01tZuq oc8aYqkuB9XkopqcpKrKT1V5qipfufKWK4c5cpkjp1Xkt4o8V5HvyvJe2RxUNhepp83N0+boafP1 tLlLVf6TO2Hb7E54Y5Qj+lyjyDWaXKPKNbpco8w12lyjzjX6XFnIlY1cWcmVnVxZypWtXFnLlb1c WcyVzVxZzZXdXFnOle0cqlA5q7V3rdbhr1mtvHu18g6WahmezPrH361pQ1vauS7Vng50pBOdtdGF rhTRjWfpTg/99PSzp+t6aqOXtnt5i+rlJNjLqbC3t6fe3gX7eIPq4w2qb3goq583qX7hARV+P/ep +PtU/r3cYyXcY0XczV1Wx11WyZ1Wy51WzR1Wz+1W0e1W0+1W1m1W2G1W2m1W3G1W3m1W4K1Z4xjP BDJOrhkn2IyTbMYbWsapNuN0m3HKTU1gvL/H+26070b7fbTPRjsJjw7XaPcqruQKLucyfVzKJVzM RVygz/M5j3M5h7O1eRZncjqncSqn6PNkTuJETuA4jhXPsX4ew9GuO1obR2WN9SaQGsNobwapUYz0 ppAa4a2hlOEM8xaRGsoQBnuzGMRABnjTKKGY/vSjrzeQPvSmFz3pQXeepRtFrityfzee1WYP/fSk l757i6OPuPqKs5+Y+4u/2DiKjanEm8oA4xtonAONd5BxDzb+wfIwRD6GeFsZKj9D5WmofA2Tu2Fy OEwuh3lbGSa3w+R4mHwPk/dh8j/MPAwzH8PMyzBvLEPN0VBzNdScDTV3Q8zhEHM52HwPNu+Dzf8g dTBIfQxUNwPV0QD1VKK2itVZsXrrTz/1108d9qWPuuytPlO91GpPNduD7mr4WbXcjSJ13YXOdFLn HelAe3Xfjja0phUtaU4zmtKExjSkgXsKKaC+tvLJ035dntFfHWrruxY1xZKqIa7qVBNnqqqYU7nG kGMsqSrGVpmn/V7Z55V9X9m1ld1XRRtVtJfK0X6OvnL0m8oVR664UlWt46rWc6qatZ2qbp1Xt95T Naz9GvaAmvacVC17UK2Q7nN/bscszL7BLXB+yHOWyKce9Z0vUgXOG4U0oCGNaOwc0oSmNKM5LWhJ K1rTxnVtaUd7OmirI53orP0udNVnEd2cW1LPOrt0p4fzS6qnM0yql3NMqrezTKqP80wf55m+zjOp fs40/ZxpUv2da/o71/R3ril2ril2rilxrilxrilxrilxrilxrilxrilxPilxPilxNilxNilxNilx NilxNilxLilxLil2Lil2Lil2Lkn1dzbp72zS39mkn7NJqq/zSV/nkz7OJ32cT3o7n/RyLunpedbD s627Z9yzdPO8K/Lc60oXz8HOdKKj52IH2tOOtp6VbWhNK1rSguY0o6lrmtCYRjTURgMKKdB2ferp K1+fedQVwzPUEU8dcdWmlhhribWmmFM1xF/dOKobTzVjq2aMqarGW9W4c+UgVy5y5SSVIz858pQj XznyliN/OfJYRT6ryGsV+a0iz1Xku4q8V5H/HPOQYz5yzEuO+Unlmqtcc5Zr7qqax1Q1c1rN/FY3 z6ka5jxVUw2kaqmJVG01kqqjZlLPqKFU3Wwt/7lVUS27Ksqs5frWcgGFNKChdd2IxjShKc1oTgta 0orWtHF9W9rRXlsd6GiP6ERnutgzulJkf0x1s1c+a8/sbu/sYQ/taS/tZU9N9ba/9rbP9rHfpvra e/vag/vZi/vZk1P97c/97dP97df97dvF9u9i+3ix/bzYvl7sOVpsjy+21xfb84s9S4vt/8WeA8We B8Wepf09G/obe3/Pin6eGf08T1N9PUP6epb09Uzp49nS2zMm1cvzppfnTk96eAalunsepZ71bOrm GVVEV8+rLp5bnelER8+xVAfa0462nm9taE0rWtKC5jSjKU1oTCPXN6QBhRRosz719JNPHnX1m3pG HHWoLaba4qtFTfHWFHsNY6huPNWNq5rxVTXOqsaba+y5cpAjFzlykiM3VeSoilxVkbMqcldZDivL ZWU5rSy3leW4slxXlvPK8l/ZPFQxH1XMSxXzk2OucsxZjrnLNYepqua0qrlNVTPPqermvbr5r6EO aqqHWtRWG6k66iT1jLqpS546yqee2qqXrdd/9t8K/p79t4LtrcYCCq3OQqu00GottGoLrd5Cq7jQ ai60qgut7kKrvNBqL7TqC63+QrtAod0g1YCGNKIxTWjq+1Qz1zZzTzP3NtNGM20102YzbTfTRzN9 NdNnM303E0MzsbR0fyta04a2tKM9HehIJ213spOkOtOFrhQZT5E2irRVpM0ibRfpo0hfRfos0neR GIrEUiSmIrEVibFIe0XaLbLLFdntiux8RXbAIjthqitd6EwnOtKB9rSjLW1oTSta0oLmNKMpTWhM IxrSgEIKqE898vWZr+98MeSLJV9M+WLLF2O+WPPFnC/2fGPIN5Z8Y8o3tnxjzDfWfGPON/Z8OciX i1Q96mfn+r+qk/+qPu7I7oVj1XB9CtRxqlAtpxrQUE2nGvm9ke8aua6Rum+k/htZB6mGfk818HsD +1Kq0DoptF5SBdZOgTVUYC0VWFMF1laBNZYqtN4KrbtUA2sw1dB6bERjmlifqaY0ozktaEkrWrsm 1Ya2tHN/qr32Omi7oz5SnfTZSd+dxNBJLJ3E1ElsncTZSbypjuJPdTCWVHvaGWuqrXG3Nf628tBW Ptpa5//x83rfX+/a691znfuv09a1WZ3dk+ri/lRX7XXVfpG+ivRbpP8icXQTTzdxdRNfN3GmisRc JP4i40h1NaauxtfVmLuYs872r050tJelOtDe3pZqR1va2O9SrWlFS1rQnGY0pYnrGtOIhtpINaBQ 26kCfaXq6zdVTwz1xJLKF1e+GPPFmifmPPHnGUee8eQZV57x5RlnnvHmG3e+8afqyUWqfrbu/qe1 ekB2L0tCEO+euHH25z97b6E8FcpR+vNf+68iV2RXzDBnteGUOqOlRjDSGW0UoxnjnDaWcYxnAhkm MonJTHHdVKYxnRnaSM2kTNupWcwODbPmhAZZc0U/LxQk80P9rAWhXtZzIZ+8rPJQl2eokywMtamV tSjUpAbVqZYsDlXJJYcqVOZp/spTrvkLT/IEj2vjMR7V7iNU0tfD+n4oa763odQ8b0apuU5Jc5yO ZjPL0ytV5mk2kxlM94RLTWMqU5js6TeJiWSYwHifj2MsYxjNKPenRjJCu6UM109qmH6H6n+IWAYz SGypgWIdKOYBYh9gDCXGUmxMxcZWbIz9jbW/Mfc39n5y0E8u+slJP7npJ0f95KqfnPWTu/5y2F8u +8tpf/ktludi+U6VyH2JOUgNMCepgeZnoLlKDTJ3qcHmMTXEnKaGmuP/qKt/9in/j128hvZqZg0R V2qw2AaLbbC4BotrsJgGiyc1hKHiGiqm1DCGU8oIRjKK0WIdLc7UGHGOEedYxok1NZ4JZJjIJN+l Jrs2NcV9U7SRmqq91DSm+zs1g5mUMYvZvkvNEdscMc4V81yxzzWGucYy15jmGltqnrGm5rPA+FPP mZ9UubkqN2fl5q7cHJaby3JzmnrO/KYWmOvUfOaZ+9RcdTBXPaTmqY15amSeWpmnZuapndRcdZSa o6ZSs9VXahZlzGSGz6czze+pqWpxqrpMTVGjU9TqZCYxkQwTGM8436fGunas+1JjtJEazShGMoJS hjNMX6mh4hoqxiHiTQ0W+2BjSA0xniHGNcQYU4ONNzXI+AfKR2qA/KRK5KtE3krkr0QeUwPkdIDc pgbKdWpQtu7+td30luy+fLJWB2lxMEMYyjCG+zxVqudSUZSKplRUpaIrFWlquMiHMZQhDGaQzwdl R1OZKuSQS1WqZQ36k2+RA7OR36vuRqvDMWoyNVZ9jlWnqXGM9/cEMn5PTWQSk5ni8ynumeL+qdqZ xnS5TM1gpgzMFGlqhshnGMEMI5lpRDONbKYRzjTa1Aymm8fUNPM61RxPNdepKeY9NZlJ/k5NJMME n6XGM46xPhvr3rHaGKOt0YzSdmokI/SZGqn/keIYKZ6R4hopvtQIsY4Q94hsXv5chu/KZvg0O8g4 xttRUhPIMNFnqUl2l9RkO8dku8Zku8Zku0Zqkp1jkp0jNZEMExjPON+lxrouNcZ9Y9w/Rjupsdoc m+373zOKx/T8mAgeE8ljInpUhI+al0eoxMM8xINZk6371CR7QGoiGSb4LDWeca4b557UWPeP1U5q nDbHaTs1Xl/js33/uVF8nX3C/BRmi2KOiOaIcq7qmqfi5qm++Xa9+XbABXbDBXbI5+yqz9lhn3Na KHeSKE+WsowVYWGyigpeYA3rWO+7l3iFjWx276ts4Q1tvsnb+niX9/SZep+t4vhAPB/yER+LMfVJ mJV8ymehLOvzMDP5IsxIvmRbmJ71VZiWbA9Ts3aEKcnOMDnZFSZlfR0mkkm+CROSb8P45LswjrHJ 92FM8kMYzajkxzCSEfJSyvDk5zCMockv3sF+8V72q/ezX72n7fa+ttt7227vb795j/vN+9zfvNf9 zfvd37zn/e5973fvfX/3/vd374F/9z74h3fDP7wjpvZ4X9wTOtMpCVFHOtA+iaJ2WXHUlja0TpKo FS2z9opa0DzZO2pGU5ok+0SNs/aNGtGQBsl+USEFyf5RfeolB0T55CUHRnWzDmB/9mNf9mFv9iIh JiKwx9r6g7/zO3/jN3bzK7/wMz/xIz9Ygz9Yfz9aez9acz9Z2z85RfzsRPxzaEYL97SiDe1oT0c6 05VudHddT3rTx/39KNbeAAZqfzBDzd1wc1hqPkea11Hmd4y5Hmvex5v/CeogoyYmqo3JamWKmpmq dqappelqaob6mqnWytRcmfqbpRZnq8k5anOOGp2rVucmr6nJzWxkg1p9mfWsYy2rqWAVK12znKUs YTGLWEi5tlLPsYD5zNPPXOYwW9+zKBPHTGaIaTrTxDiVKeKdzCQmin9i9ucM63cmZcwiXc9/bme4 JPtfZY+OOmupsx46ZU1isllKTWFq6JA1zexN83O6z6a7Zpp7pqnuaWZymoqfpvKnms2pVsJUMzrV yphqVqeY1SlWzBQzO8XMTrGaJpvdyWZ3slU22QxPtuommeVJVuEkszzJypxkpieZ6YlW7ESzPdFs T7SSJ5rt1CQzPpkpZn0q06z81HQVMIOZlKmE1Cxmq4g5zFUV85jPAp6T4XIWsojFMr2EpSxjOStY 6bvUCvcsZ5m2lmp3iX4W63eRGBaJZ6HYylXlc2JdIOb5Yp9vDPOMZZ4xzTW2Oap5jrHONubZxj5b HmbJxyx5mSU/s+w0s+RrlrzNksNZcjlLXmfJ7yx5nmXlzJL32fI/2zzMNh9zzMsc8zPXSpsb2uqr Da313YqWYmkhpuZia0ZTcTYRb2OxNzaGRsbS0JgaGFuhMRYaa4FKL0iet7orPGFfYDVrrPh1vGj1 r+dlXmEDG9nMq7zG67zBm7zNO+57l/e0s5UP+FD7H+nnYz7V72di+JwvxPOluLaJ7yuxbhfzDrHv 9HOnv3f6fKfvUztcu8M9O9y/Qzvbtbld26mv9PeVvr+yY21zdtvm7Pals9uXzm5fOOukPndm+9zZ J/WZc1DqU2ejj52RNvqZ2uCMtMHnqY2u2+ie1Cb3pzZrb7N2U5vY6O/UBl7hZV5y3XpeZB1rWcNq 7aReoILnWcVKVvh+hXtXaHO52Jcbw3JjWWZMy4wttdQ4lxrzEmNfIgeL5WKRnCyUm3J5ek6+FjBf 7ubL4TzmqoU5zFYXs9RHGTOZoV6mM42pTGEyk5ionlIZtZVRYxm1lrEvZNRdRv1l1GG6l/zZnall dme6PrpUS5fq8VK9X5I1mSnh4qypTAsXkf68hEu5jMu5gitdcxVXcw3Xch3XZ00JN3AjN3Ezt2RN zv68NWsq05gebsuawcxwu2zdLmt3yN4dsninbN4lq3fJ7t0yfY+M3yvz95mB+83EA2bkQR4yOw9n LXXaW+q0t8xJb5lT3nIn+OVO8Mud4Fc4wa9wel/h1L7CiX2FE/sKJ/bUShWZWsXzVPACq1nj+zWu XeOe1Gr3p17Q1gvaTK1mDWt9to4XWc9LvOzaV9jARjaxWTuv8hpbeJ039PEmb/E27/Cuvt/jfbby AR/yEekq+sTPT1z3qfs/027qc32mvhDPF8b9pfF/KQ/b5OMreflKflLb5Wq7nKV2yOEOudwhpzvl dqcc75TrXXK+S+53mYNd5uNr0p87/b3D59t9/5Xrtrn+S/d9wefa+Exbn/KJdj/W/kd8qL8PeJ/3 9P8u7/A2b4rrDV5nC6+ymU1s4BXXvMxLvOj+daxljXZXU6Gf51mlz5X6XyGO5SwT11LxLRHnYvEu EvdC8Zerr3K19py6W6AO56vN+Wp1npqdq3bnquE5anqO2p6txmer9dlqfrb6n2UdzLIeZlkXs6yP WdbJLOtlVriQCzif8ziXczibszjT/WdwOqdp+1RO4WT9ncSJ+j+B48VyHMeK7RgxHi3Wo8R9pPiP yFocDjemw7KWhkON81DjPSRrRThYDg6Wi4OyVrKC5SxjKUtYzCLXpRZSznMs0EZqPvOYq+05zGaW /lJl+p/JDLGkpjNNfKmpTBFvarLYU5OMIzXRmCYaWypjnBnjzRh3xvgz8pCRj4y8ZOQnI08Z+crI W0b+MvKYkc+MvGbkNyPPGfnOyHtG/jPmIWM+0r3tv98p/2//PvzHeEr4gfTnv/ZvcP7xfltDxmrI XA0ZrCGTNWS0etYCz7oFnnsLPP9Sz1nJqQVW8wKrOTXfik7NYy5zmM0s36XKXFvmnjL3l2mrTJup Wdqfle37zz0remffb18Ie2ttL73vJZJEZIk6SdRMrIZi9RSrrVidxdZgbC3G1mVsjSbWamLd7mXP 28ta3ttet7f1vY+1vq81v5/1v7994AD72oH2hoPsEwfbLw6xdxxmDzncfnKEfeUoe8zR9ppj7TnH 239O8J5ykveVU7y3nOr95XTvMWdytveacznfe86FXOy951Iu50qu5lqu50Zu4TbucO1d3MN97n+A h7RXiUe0/5h+HueJrG/tp9/aV1Pf2GO/sd+mvjYzX5uV1C4zs8vM7DIzqa/9nvqG73z/vet/cP8P 2vtR+z/p52d9/qzvX8Twq1h+tUf9an/abW/abU/abT/6zX70m3H8Zjy/Gddvan23ut9tDew29l/l 4Fe5+EVOfpGbn62nn6ytH+XtB/n7Xh6/tTa/kdev5XeX9bxDvrfL+1fyv808fGFOPjc3n5qjT8zV x+bsQ/P3gbl8n3fN7Tsh8owK5nFP/Hr4I97Cq+Hv8SZVtTH8LX6Fl8Jv8fqwO17HmvBrvDr8Elfw fPg5XsVKVoSfspazzHpLLWWJ9ZdazKLwfbyQ8vBd1nMsCN/G85kXvonnMid8Hc9mFmX+LvNdmevK 3FemjTJtlumjTJ9lYigTT5m4ysRYJtYycZeJv8w4yoypzNjKjLHMWMuMucz4y/5jHfyTe8pB2Z1g r7DQCi63hhZmzf0X95WnsytyunehF1jtvWgNa70jpdbxIuu9N6Ve4mVe8S61gY1sYjOv8hpbeJ03 eNO1b/E27/Cutt7jfX1s5QN9fshH3sNSH3sX+4RPvY996n3sMz73Tva5d7IvvJOlvvRets172Tbv nl95N/vKu9l272bbvZvt8H66w/vZDu9nO72f7fR+ttN77E7vaLu8o+3yjrbLO+4u72i7vPfu8p62 03vaTu9pO72n7fRuvMO72g7vajucjbc7I293Vv7KmfkrZ+dtztDbnKW/dKb+wtn6c+fsz5zDP3Uu /4SPndE/dl7/iA+d3z9wjt/K+8717/Eu7/C2s/5bvMkbvM4WXuNVNrOJjWxw/Su8zEus117qRdbp Yy1r9LeaF/RfIY7nWSWu1EoxrhDrCjEvZ5n4lxnHUuNJLTG2Jca42FgXG/NiY18kB4vkYqGcLJSb hXK0UK4Wylm53JV7zy2Xx3L5LJfXcvktl+dy+S6X93L5X2geFpqPheZloflZZJ5Si83ZYnOXWmIe l5jPpeY1tcw8LzPfy837CjWwUi2s4nm1UZGt0T/3/HkgW+3pf/FczRpnt7Wssze+yHpecq57mVfY wEY2sZlXeY0tvM4bvMlbvO3ed3iX97T5Plv18QEf2nc/8kz42N77iefDp3xmD/7M8+Jz58Mv7MVf en5ssx9v8yz5yp78lefKdmfE7fbmHc6IO+zPO5wTd9qjdzon7vQc2mmv3umZtNN+vdPzaac9e6dn 1U7nmJ327p3ONTvt3zuMeYc9fIdzzw77+HbnoO328q8877bZz7d59n1pT//Sc/AL+/rnzlGf2ds/ dbb6hI/t8R97Zn7Eh/b6D9hqv3+f9+z57/IOb/OW5+ybvMHrbOE1XmUzm9jIBte+wsu8pJ31vMg6 ba9ljb5W84K+K8TwPKvEtFJsK8S4XKzLxJxaKv4lxrHEeBYb12LjW2Sci4x3kXEvNP6F8rBQPhbK S7n8lMtTuXyVy1u5/JXLY7l8lstrufyWy3O5fC+U94Xyv9A8LDQfi8zLIvOz2DwtNl9LzFtqqTlc ai6XmdPl5ja1wjyvNOepVeb/eSrUQuoFVmfr8J/d/8dl9/9KVlIFL7CaNay1ytZabWuturVW31qr cK3VuNaqXGt1rrVK1/Ei63mJl3mFDWxkE5t5ldfYwuu8wZu8xdu8w7u8x/tstQtstRtstStstTts tUuss1ustWustXustYustZustaustbustcustduk1rCaF6jweYXvK1xX4foK91W4v0I7Fdqr0G6F 9iv0U6G/Cv1W6L/C+CqMs8J4K4y7wvgr5KFCPirkJc3V89mc/U//f1nKs3mubL7Xso4XWW/uUy/x Mq/4bAMb2aQ+UpvVyqtq5jW185oa2qKWtqipLWprixrbota2qLktam+LGnxdLb6uJlNv8CZv8Tbv 8C7v8T5b1e9WdbxVPW8V31b1nXqf93iXd3ibt3iTN3idLbzGq2xmExvZwCu8zEus50XWsZY1rOYF KvRZoe8KMVSIpUJMFeKvMI4K46kwrgrjqzDOCuOtMO4K46+Qhwr5eEFeUqvlaLVcrcnm9187uzyQ naEztbyOF1nPS3pJvcwr/k5tYKMoUptEtElkm0S4SaSbRLxJ5JuMYJORbDKi1EbWsdZna3231jVr XbvWPWvdu1Yba7WVWqfdddk4/rvVnIT/7//9P+BAPVJ9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA S6kLAgAAAAgAAAAOAAAAXwBUAG8AYwAxADAAOAA4ADMANAA3ADMANgAAAH0AAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ 6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADEAMAA4ADgAMwA0ADcAMwA3AAAAfQAA AEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMAMQAwADgAOAAzADQA NwAzADgAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwAx ADAAOAA4ADMANAA3ADMAOQAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4A AABfAFQAbwBjADEAMAA4ADgAMwA0ADcANAAwAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEup CwIAAAAIAAAADgAAAF8AVABvAGMAMQAwADgAOAAzADQANwA0ADEAAAB9AAAARAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5 +brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwAxADAAOAA4ADMANAA3ADQAMgAAAH0AAABE AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADEAMAA4ADgAMwA0ADcA NAAzAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMAMQAw ADgAOAAzADQANwA0ADQAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAA XwBUAG8AYwAxADAAOAA4ADMANAA3ADQANQAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsC AAAACAAAAA4AAABfAFQAbwBjADEAMAA4ADgAMwA0ADcANAA2AAAAfQAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6 zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMAMQAwADgAOAAzADQANwA0ADcAAAB9AAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwAxADAAOAA4ADMANAA3ADQA OAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADEAMAA4 ADgAMwA0ADcANAA5AAAAygUAAEQAZAAAAAAAAAAKAAAAAAAAAAAAAAAAAHUwFA8fAx8DAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwMAAAALIECvAIAAAAAwQAAAAKAAAjAAvwDAAA AARBAwAAAP8BAAAIAAAAEPAEAAAAAgAAgDIAB/BGBQAAAwQNFrnoc9JykK9JHdm5eIwW/wAiBQAA AQAAAFVHAAAAAF0IYCEb8BoFAAANFrnoc9JykK9JHdm5eIwWKBQAAIABAACABAAA4hQAAIgKAAAo MngAKGclAOgEAAAA/nja7VhNbBtFFH6z/7tN7HXjltCCsgl2hdRQ0VbigIQVp1YjSpu6UAlUcsjG 3jYWjmvZriJ6MhIHVA70GgQinJCqIqWRkKDi4AuHoh5SKSCURmqKEAcOKAh6ASTzZna98XrZ1Had HhBrjXd25v2/b2bfDgEVgI9qADIcBnpFsB2QwjAIdbwAdKgSgKoA8GMU4D2kVB0KhVFw+PSEM/IM GxFgP5ydTKejUCN34AjO1eunAZnhFOQAPtMcao1RAXDwB++VyeNT2BmJMioB+gDNYI1eIrZdXFWo Etrr4xRpZoD2BNIP1Gabd6/jA/XglAxwBb04plBfAf5Gw+u3FygPtueQAifgTxyVbBWcPU4Y9X4h qZhCWr5KXF4q2OHl2H2zSUbjasi254mjmXhmicMlgnecdzTHlfdRc5U066Iyn8L7X0263Gv9t/kx Gu192q3V+wPwwye/z9/HZhgP5q9Fz9dtfoHFUKX8HO1FmSRbZrVuC/ralj4GI8lSzsxjtxbV1hfv BskUHT8bso8evd0km/YOkUGnxxHq7V5sR7Rf5JuEouKsVZrLFcy8kZyECUROCWJAezGIwzmHn7j8 nKf3bzkVAnIqteTUm0WhJWuSm6f28hLk++ONR+saWInYa2AtGrwGHh6vG9G0vBHpNl53kXslshPx 0nZ74jXeGq8YTO0Ifv778YCO4nFG3pSK4sPi0Z3sG/qmtBJqV3Z94XyAbJzxyb4T0sW03F0eH8gV 2ZDHxF7mUWd5vClfFqnFyUzGKpffxMw1ftvnLsjOVd2QF0M7YedaqHd2ivLnfc9L36u9tHOA2fmt pGsUCeNm5q2ZiwVryrFykv0mOtxRT6Jh19HkS0jyheyrH1zsNb/l4zwHaWFJLopLshddgltLKI4e iekhPr3XdVvvd5HO9C7pS7jbtK+3sZKWl5d9Unn3mVZuT0vDsAmrcIJsCBvES+lfTY+Sxz6Wx8vi Po7WiKfz2UNZtqd1g7N3tCcjNbXY1nqw66KrgXXRyB7tQHBdJDgxENv2c5D5+bJ2LbQLeydzBcso WYUK6krBELYE/o/ifworAdrvDLk6Tn2E6f4SA1HVguPzlVxT9Z7uaw2/Tog74ddLku3Xu3j/Rg1a GaJvZUxLNXVaWleasU2z5b6nPNz0zRrjeahK95RpaVFJ4r15TW1hXvStqf8j/bgi3Wrxx2Hb4p/C nVlcC9fUWrhTizfC95RaeFH5NNy+xVtfln57ePd5a789Tl4Rq8Ki4qXckt8LFI0wFKniG+pu7KVy 5YpZyFiGWcgaldycZZxB5CQYgiiiEuwpxRAWx5bdFlnt6H+W6f9AXFNoZZu1ilYhiyg2MmY+b2Rm zdIFq5xytKec/zizgmoecuxJINJt+7p5T7wuTci6OM33cnUOM78WxA95et5yzCyVclbJKFt5K1PJ XSxgXKnNo8z+UdefBIv1EPP0UaK6h2kfkl4QKJqOlyyrOIvl0HiK7Qh2JO1otvnN1HQWsh1iVwHr T9Ho7waxrScTxH8y8WsvTyYOsxi9KJ3rp5pftS5cypssNbmyMWOWrayB/cpsrjw85VSQMbwfZNXI JPvCmnC+tuwKszF+0KVsB4u8i0nbf53FvFGBEI4bee3tcsWagzr1FXD/GYYrpLF/CD8PQGsF4j9X a76853BUEM/G/wEp3TkdrgQAAEQAZAAAAAAAAAAKAAAAAAAAAAAAAAAAAHUwrA0fAx8DAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwMAAAALIECvAIAAAABAQAAAAKAAAjAAvwDAAA AARBBAAAAP8BAAAIAAAAEPAEAAAAAwAAgDIAB/AqBAAAAwTxbtHC0D2nDNf4kmxkJQ/h/wAGBAAA AQAAAB9NAAAAAF0IYCEb8P4DAADxbtHC0D2nDNf4kmxkJQ/hpBEAAJMBAACwCgAA9RQAACgQAAAo MngAMOohAMwDAAAA/nja7VhPSBRRGP/e/Fsd59+2mwomrbZGh+qg14hVDCvKBD2lkLqtIKmRCvZH UJAohEDwEB4qoUOnQKxTBAnZTQ+GSGSHxCg9GBvmpYLte29mp53dRnfV7RC+4c188977/rzf73tv 3i6BXAD+bQ6ABw4ALV6shyUdCiGGBcCAUQIwIQNs+AGOGEA12IgcNoLDtwKr5RBrEaAIGmrr6vww ReagHPtisQuAynAe2gGeyNZomY0C4OA777TJ45tutfjZKAEUwDBYpUXEmsdNyKOESgp3XWz1UUkg KtCYTd18aw50BsXY8UAA8Gl0rgC/MPDYzBjVwXoMRyAI8ANbJdMFZ7YTNrpI8Gq9QkB9TGxdatjS 5dgzmmAjXuK2zX5ieSaOXmJpieBs5y3PG+pD9DxKEn1Rm5Svnwm+7PLhW18IH40FcuP8kg/ePVrv W8IaCGz0NSltC6a+wDDMpfoclfzMkmlzMGYaemlaD0FpZXd7SweKAV2+P77oZlO05hm3XVExk2Cb SsdJoSVxhM42H2u5/EKdJTQrGiLdne1dLR2BylqowczphiBQKQhlcNHSJ7Y+55D+xqngwqmUxKmT RSGJNcnmKT1e3Ob+b/FIXgPLXnMNrPnd18DWeE37A+q6d7t4fUXtZW828Cre58CrKhmvIDRlJX/+ fzwgIzwue6aUIXErPLZne9qYUpa1dG3HxtpcbGNPiu1P2kc17Nkej2/UO56oUi/uJo8G43FYvSfS iCvD4UhPTyMyF782584tzi9GVHmmZSPONW0343yqRJWF3N2M02fFacg0E6pawldar3ZFmqwoa9lV k+GOegkD68cd9S4Oua2mnB/s3Ev8ypfxHISFQXVIHFSd2SXYZ4kcy4/E/JAUv68M0++KNzO/r41B 3G3S9xtfSZOTkylWefudntyKpRKIwjzcIhPyInGOTF1NO+FRYTyezdvP0TNibaRPaoJT0JYhcyHs OoHfwBWcYsBwy8MSY9XTrIfSWtfmuWnE9dyEZ7Fe93OTYGEkpo1DIcNhVb8p5qF0rr0rEuiOdPWi r2o4iPUk3o/ivRpPClTODJ9OycTnOT4juluGiSkZNiI16yNSv5aYI3RW9n7v0KZfqCDPw4Q0oI1I Ie0aPhNz80/uiCm5uXPG9pBOD+nkiMc1M+LT3s3Xzhlvsz6uZYOJ91o2mJjVzXn5jcyYiOrNelTP lAnDGNCiekib03ee83tIZwdp3o7A3N0N5im+uxOOK62/0dMb6YQFupMDeiyBYRLHVPjsg+Rfxan/ aSQW538g1BDP2n8DVzDt63EEAABEAGQAAAAAAAAACgAAAAAAAAAAAAAAAAB+LCQO6ALnAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DAAAACyBArwCAAAAAUEAAAACgAAIwAL8AwA AAAEQQUAAAD/AQAACAAAABDwBAAAAAQAAIAyAAfw7QMAAAMERX1VcB23NSFo1EU7ObPO8v8AyQMA AAEAAADNUQAAAABSCGAhG/DBAwAARX1VcB23NSFo1EU7ObPO8pgMAABwAgAAAAkAADwUAACoDgAA +FxuAOgSIwCPAwAAAP542sVWzU8TURCf3e622/1qS1fEYEJFICSiEYwJJoqF6EGQsgYOGD1IYIEm UpqW8PEvkJj4DxD0BpzUyMHEA17k4qEmxkjg0F4MxpiUqBc1qfPe7pa2tlJKja+ZffNm583+fvM+ Ogy4ARw3nQBOaAfSfCgtTg/UQQYbgBeiLJrQ7bIGsKJSlXoI1IO8PG5ZTlMLB/UwFNJ1DTaYt9CB 7zKZAcDJ0A9hfIqWt0i9AFj45siP6cCRx7Jo1IsDGRi0MGA2HkViwR1liSazK/wbH9E4RsGnC+UX a/tyKGdxIGD/A+HWmGbWtDPUu47bk1OupJhgzbkEcyY7l83OhbyYDtqnMUZ533glp/xPxIRqR60s CiJVEKlQKorXylyttYLvcdprCWAbw25LdnQe8vPDgM0818rRTDsZYpZRmhwcJF2bUtK1JSUEIpuS 6cEUZMVGlsYYgoXISREVQahYCFUT4aERKYhIQTQqkUoQ2ZnP/XI9Nyy/4KPSDleY6ZPY/8zZDdm2 szcXxO6CRwy+S/nhw/LXuRRKIPB9bkMbX8pl4Cbz6e7VaCQzZjRjBnppRg9CY3csPHIf1eeqeP3R dqmYfJZZsdhEO8fUWRpLM0NOXId4Qq7lyagbxi0vJuvF5mmlMrQuRaVdsTBDpVAcBlmjREZDMFwR slb5iy8oeX3VR/ZJ6vWRUQ9MVoRs131FIDdXNZE1UWSr7jXWT+7ZwKARmw2PGoFobHo2PGbE4pl5 aIV7oMMlCKGm468VM9sJt2GAajrqeoV8Lmrgnlf/BZ9nKuETKsJnsiQf/Yh8noopV9qdKGt9zFP7 MHtqmYJTizdBX+lTy1mnli87L800Lwui6NDy1nlkImYYU0ZkJn4XGqAPuqANpQHFfF6j4y4Yg6uo N6NWWWYkLe12eqq50jajoEfLW+l9RrcOYNR1BEY+dV3SFS9fTUbtlNGW0suT3dF/JhS4EZkxYqPT kYgxOhOejgTiJkdcq24g7BosBm2UC/kRZs0QoLrJeZ99ZUwfq8dqkkpUqj7TsLom/R+mhXVEJ/6t t2BRsIr9HeXvdQRfpI6YEHRlgcqiPIGyX0eI1MMBy8IDOSqcl3uwL15b8AdWO52qhRL7z5WgVJPK AhVEqRZFqSJKFVGq5aO0Udi7x7zZvBSVXY8wLNs4uBCfMaZgidxi5IunYJGx9wf30Q+F9cifdXxu y6/7SSAHtf8Gb21d+IwEAABEAGQAAAAAAAAACgAAAAAAAAAAAAAAAAB+LCQO2ALYAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DAAAACyBArwCAAAAAYEAAAACgAAIwAL8AwAAAAE QQYAAAD/AQAACAAAABDwBAAAAAUAAIAyAAfwCAQAAAMEUH8ltXti1Q8IroLEgAMsSP8A5AMAAAEA AAA+VgAAAABSCGAhG/DcAwAAUH8ltXti1Q8IroLEgAMsSHQNAABwAgAAAAkAADwUAACoDgAA+Fxu AOgSIwCqAwAAAP542sVXS2sTURQ+80om80rThD5sobG2pUgtUhAqaG1LkVaxDqSLii6s6bQN2CQk oY+/UBD6A4TqrnUlggvFRVWwG8EIovaxSDZSEaFF3dRCPPfOJE1iommMesOZe+6Zc89857tzz50w 4ADgHtsAbNAJpLlQ2mxOqIMUNoAqCLNoQrczHoBljarUQ6Qe5GatZTlGLTw0wMiwrntglXkNXXgv lboMOBkuQQCvkuUtUS8AFr5yuTE5HDkti4d68aAAgxYGzCagyCw4wizRFHZZeOkiGs+oeLWj7LNp Xx7lBA5E7PcQbrVpZk07Q73r+F0laU9IcdacSzCnMnPZzFzIicnRfgdjlPaMp0rSfV+Ka+mo5UVB pCoiFYtFqbKYq7FW8C1OeyEDbGLYTTkdXYBcfhhIZ55t5SnTNoaYFZQWjoeEfU1O2NfluEhkTTY9 mDxW0sh2MIZoIbJRRAUQqhZCzUR4aEQqIlIRjUakHERp5rOf3MCPKo+EsLzF5zPdiP33rLch07Z2 Z3uxO14t7b1JuuH90pfZJIrX+21WbZgYzM7AQebTt9dDI5kxwykz0BMzei8090UCYzdRTdZKvjub xWIKmcwKxSZaJ1NnaSxlhuy4LqleqRHIqA8mLC8m48XmaMUYeiiH5W0pn6FiKA6DrFkmoxEYLQtZ u/LZ1StXuSqP7KN8wUVG/TBVFrJtx1mRVK5KImuhyFYc91g3qbNenxGZCfgNbzgSmgmMG5FodA7a 4TrocBqGUdPx147MdsMVuEw1HXW9zHxOecAxp/2NfB5oJJ/hAvlMFc1H/8N87HLSvuqIl7Q+5q5d zOxaJm/XYiUQiu9a3tq1Qsm8tFJehiSJ8+Ss89hkxDCmjWAseg2a4CL0QAdKE4p5HaDjHhiHc6i3 olaMmVJQNFIUr6QNDgs2nA9FvD5v1EQSHaDPIhjMpx/g6ClrNVyaX9bVG0Il365Oin9dvS0cQc3n HQrGjIg/FAwa/lggFMzkQnJosvjqoCySH8mkldoHKpTjXe25K6E+kyufY0Dbl/91jvmnezcetm14 VK9gf1X99ekuFDjdJ0VdnaeyoEyiHJzuEvXgYEm8pYTFk0o/9oVPfOG33yDdmoUS+0/loNQS6jwV RKkVRKkhSg1RaqWjLPy+vJOS7kVHvKIV16ws9ZLk/P+VZUnacFa+shywaVbtKspm+luLYdlm33w0 ZkzDIKnQZN2OwgKTRsp/cEP+t9bP/1GyW+5/GhKIo/Yfmwtuo5gEAABEAGQAAAAAAAAACgAAAAAA AAAAAAAAAAB+LHMPyQLKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DAAAACy BArwCAAAAAcEAAAACgAAIwAL8AwAAAAEQQcAAAD/AQAACAAAABDwBAAAAAYAAIAyAAfwFAQAAAME sFu4DpoKkn7/8ZK5CtjH4f8A8AMAAAEAAADKWgAAAABSCGAhG/DoAwAAsFu4DpoKkn7/8ZK5CtjH 4aANAABwAgAAAAkAADwUAAAuDwAA+FxuAABSJgC2AwAAAP542s1XTUwTQRR+u91tt/vX1jb8BBMr ApJQiSExwUQRkIsmwhI5YDTRAgs0Cqxtw084eSUx4eYRPcLJmHgw8YAXuXiAhBgRTNrEGIwxgj8X f1LfzO6WtrYCFYjTvJ03r2/eft+beTMtA24Ax6ITwAl1QJoPpcbpgTJIYQPwgsGiCd3OBADqPVSl HgL1IF+WWpZj1MJBBXS1a1oA5pklaMDvUqkOwMlwCSL4FC1vkXoBsPDVkR3TgSOPZQlQLw5kYNDC gNl4FIkFt8ESTWbrnS98ROMYBZ8ulJ+s7cuhnMCBgP13hHvINLOmnaHeZdymnHQlxEXWnEswp9Jz 2fRcyIrpoP0GxtjZO57JSf9DcVG1oxYXBZEqiFQoFMVrZa7EWsGXOO25BLCKYVclOzoP2flhwGae aeVopp0MMcsoVQ4OEq4FKeFakRYFIguS6cHkZMVGtoExBAuRkyLKg1CxEKomwl0jUhCRgmhUIsUg sjOf+eYKrlt+whvSGpeb6cPY/8jYDem2tjnWjF3II35eTvrh1cyXsSRKMPht7HZp/2QmAzeZT3dv gEYyYxopM9BTM3ozVLZEI+FbqCZLReX+aqGYfJpZvthEq2fKLI2lmSEV1yCWyyU8GbVAv+XFpL3Y LK1Qhh5LhrQu5maoEIrdIKuUyKgLuotCVit/9DVLXt/eI3svXfSRUSsMFoVs3X1WICfXXiKroshm 3XOsn5yzwct6dDTSqweN6MhopE+PxlLjUAs3QIPT0I6ahp9azGwjXIEOqmmoa0XyORUA97i6H3we qYRPex4+gwX5aP/I54647Jp3v9nR+phVO52uWianavEk+FW4ajmravld5uWCWOow1znc26vHYsHw QFTXh/TheCx1DY5AU8aHjNogRPU+OId6NWrF5OWe2iNpygC/l+tcR/msKA94Yj8fNsK9kfhEsCcc 0/u2WHVSDiabavpss9i15fBrovwKsds5ouvqKkXUPhKM6v16VB/GzRcfCcbMfRjrpG8mbyV4Qln4 2qwVCFnZb9o237n3YSNeTzV4uc1if1X5+33I57kPBwRNmaAyJQ+gbN2HIvVwwIxwVzaEk3Ir9vnv SH7bW7tRtVBi/6EYlGpCmaCCKNW8KFVEqSJKdeco8+/dTnHJP+1+vQ9nVLkY8Bx8LR733PQlFEPa +1qMqHPS/1WLn9S30sHVop1nO+/mCe+lebd/lzEsW3l5IhbXh2CSnOZkxx6FKcbmwb3zQ+7vsj// z2S27P8/JJCD2n8D9IV8QlMHAABEAGQAAAAAAAAACgAAAAAAAAAAAAAAAABwNfwU1QLVAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DAAAACyBArwCAAAAAgEAAAACgAAIwAL8AwA AAAEQQgAAAD/AQAACAAAABDwBAAAAAcAAIAyAAfwzwYAAAMEF/4k0bigU32WzrI506aD0f8AqwYA AAEAAABiXwAAAABSCGAhG/CjBgAAF/4k0bigU32WzrI506aD0VQkAADAAAAAQAUAACAWAAClDQAA 0IyEAKANNABxBgAAAP542u1aTWwbVRCeXe//rmN7k7SpEsGmdZAIP0qb+lQhOdCqBbWp2zQSoqlk 12xbUzc1dqKqyEWBCglBhSJoDyBazCGX4kMvvUCQzIELFCmVQEKCAz3ACSGj0ktaNcx7uzb2xm52 HQdE212N9+37mZk3872380ZmQAbwDeoAImwGcoWQHhMC0ANLeAEEoYQ1UR7AWAcw5wcygvaQaA8W 39bbNZtoDQe9cGA0FuuCEnMdtmDb0tJe6MLnHkjhr2L3VmgvABb+8tXz9OFbwK7por040IDBGgas C9UBlY3yJVrSWFOKd5MSx6CCqLM1dp09hzK+P4UiFpHxJoXMFeAOKr507UMyhrQiYwmfi1grWCJY q56hvXu5fuW6b0gGpjqWMLbHsvRZruFRuSq8rXbGlszUtTL2KB7q6322ZF65jZLLdbIIzz583q6R Vb1+/vNUlHiyV4l9f6MTfvzk5qkbSIZx69Rw4MheazxHLSeT8SwpdVFOFs+ZJYvRvMU9ChtHsqlE GouXu5R3Cz8148nb86zwHh6+VsOblJ5meuwSy5DZIqRgi/KNPMgQVBwwsydSk4m0MTIKOxE5WQgD KYVhAF6yxzPV8WxdqZFPuSY+FRw+rfci5/CaUPWTO780m/u/aw/nGphH7J/DNTCAal6Ql6G9arFa TA74WCj5ZmWDm5XrbcJVZy3ZcgQqh3Fg2ml5jtquh9unjEgLksE5bVfh7tQ+jewmNAATNTc199pn pLgWl+OaW+2dcid0y2q3dG9Wi+uzcll3b7VlO5Zu71jdzXcsF+juRnR3toxuHF3W1wTdnXXoftaJ 7jBMrM1qv2/t0UznQ+KQ/DjvXuf6r0EjnYO2zkmeWHkkmTRzuYOoZeX2tis90wFwUQVIIt43+cHl 7tHvT+gFNdrRbPdobI0ftGwItP2BxtZYPnM31tCpNT7SzgWIjAPZxGQuNaWOovd22r57wqXnHpwZ N8LAd5KFgTEFXH9BEvqC5NUivHImNCQ/31aLVFbE2UArK+LBmq3T979jVKLh1MlmMic1/75W9nuo 2e8FisWwT4Q8H5Ty/Fap7COUxzKhggTCi1KzL3Blt28Wv9Rb8g/+KzHKR1k3lrRi6ELTGBrj8pPN Y2jO1ox37ZHN1CNf8K+xRPJ+cyqRShu56cO5ZDaVmUqdnDROZo3pXOKouQMiYCD10jsC2/CO4D2A b9uwpZfWkF+rJkL7RFrw6R3e8ukFoZlP+RV9CkKeDwtlH6E0lgnNCiDsEup9yrv2aeM1xts+/kyY kxb4GbHxGuNbPS/Nuj8vrexrhfr6hPClSLqMxcZhvKXI4FN1A3dTKUGb8JxtJ54foXOcVBdpDuC5 RCaRTE2dNpLHEtmjJuywMUlQ3A/DNo4Jhr0jtQ9V60OTXsVnRFsZqcNHlhog9QpXVM9RMpTtlIqq gXSMG9JaRWq9t+aE1/0L/HrZvbfuicjz7UTko9Rbrwj7ZGLdMXPyZTNrHDfNTM5IpNPjNCqw4tmw /YWwogQrrvXmr0OyFS2e9XuLFt/wF9S47DV2el8DLausRexUVNY6Wrx/ZuzEwB7OwkBO8oaBV6WC GuO8WuRNEbTD/FpY5GN+rTFw/8zYiYG838oGTXd4ywbN+ONapqP1bNCTKGA3fi8iJFpV3csdEmLK kFBQW5W7O2jJHQ96kxsLxpRY0L1cN8gicZIZWOCbn0VWg5VKfHOmw218syz6xPeL2DyNjdPSP5mi mZkZl5miHi4hhNgCH1sxL+yUXcS2CWR5FZ9vie79dIWJC1eYSuTZAj5wTF605E5LHvDBZKTVyC3a crtZb3KD7OrlzguWjwc82bkkZFijZbkEW/O2f73KLYN7uQ8x+xCz/zfMNo4n7oo9UkwcbVfe5IP2 502+Fd+meRMrk9U4b7Kdnjcj9qmzWd6kz2PepLHF3lM3rPtFKentjMCsE/VBdVFvcKJOt/NEfSdk nagv6Ks5Uc/qRTVNyVDClIoqIO3S23WivuT/VS5rQan9ce5x/wsSkREzzWxq8qgerUHKtpYQccn/ dUdZK2troeugv7263hU/746J5bZmnCvrdDD436xTJ8a1kJWzHui8V856pfzm+VBQOh/aKhmdhPJY JlSQgiFnztotxn1Vn1g7aZBqUNlJGZbdOHY6N2WegL1k1ySxdj+8w1Sszv3WCc4c0PL/4NRe9f/Z IYx8tP5vrWDQQbEHAABEAGQAAAAAAAAACgAAAAAAAAAAAAAAAABwNe0V1QLVAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DAAAACyBArwCAAAAAkEAAAACgAAIwAL8AwAAAAEQQkA AAD/AQAACAAAABDwBAAAAAgAAIAyAAfwLQcAAAMEVGaagi7IWi0XfDO0JHbaAP8ACQcAAAEAAAC1 ZgAAAABSCGAhG/ABBwAAVGaagi7IWi0XfDO0JHbaAHojAADAAAAA4AQAACAWAAClDQAA0IyEAOBh NgDPBgAAAP542u1aTWwTVxCeXe+u17vrxNk4aVAitCEJaqFFgdSXoiJHBUERBPMnoQKSjVmCVcdx 7VhpUA7pD2pVRZVVhFSqQt1DTs0hF04NUjhwaVEVpLaqKIdwaE8IuaJcAmo67+062Isd7zoO6g9r jfft2/dm5s1872fGZsAD4LrWBOCGrUAuLMJGoRHaYAkvAB/MYc0CB6C1Akx5gfSgLUTagsWnF8ya LlrDQTscGQiF/DDD3IJt+G5p6QD48b4fYvgtma0l2gqAhT9dpTxd+NRo1vhpKw4UYLCGAePikWR2 gZujJYW9IYZbSIljUEHU2ejbao4hj8+voIhFZNwlkbECPEbFl25eIn3IW2Qs4n0RawVDBGvUM7R1 O9cp3XL1eoBZ7ksYm31Zes8X8ShcBd7Ge8aUzJS8ZcxePJTWu0zJvPQIJedLZBGeHXh/VCRr+brz x2gQbx+p0qkf7zbDL189GL2LpGkPRz9vP7PD6M9Ry3lIf5aU/JSTwXNiyWA0a3APwob+VCwSx+Lt Fmld7tdKPHlznAXefX03i3iT0hamzSyxDBktQgq2Sd95NjEEFUf01FAsEYlr/QOwG5GTgm4gpW7o gbfM/sxyf7akVM6nXAWfChaflnqRs3hNWPaTPb9UGvuztYd1Dswi9idxDvSgmhc9T6F92WLFmOxx sTDnyno0LusptQm3PGrRlCNQOYwF01bLc9R2bdxBqV+cFzXOarsCd6v2cWR3QgHQUXNdsa99Ugwr YU9Ysau9Ve7jJsNqD1VnVgM168mrzq1mRdhJd6/nJd4+wkpnczmE+UyERXkyhv5oVE+njyOmCh9n qHq9AeCyDBBF+3R5wab3O70RNScHGyp5v7w1flJSTaAcaixvjadHbscaKrXGF8pkI5FxJBVJpGMj 8gDOtd3mTNtcxSL/vxFbMXAPVxYFh08ANSVWniOFFRqKVmiB6tPtcsM47xPH+VfFvIvQOJYJ5UQQ jomVZlFhfbY3m+7z191BPsjasaaxD+Yq7oO4t2Yq74OcqRlv2ytbqVe+5c+xRPIhfSQSi2vpzKl0 NBVLjsSGE9pwSsukI4P6LgiAhtROPwHYjp8AfnrwaTu+aac15NuoCdA2gRp8+pg3fHpRqORTvqpP QRjnu4W8i1Acy4SyAgh7hFKf8rZ9Wn6e8aaPvxGmxHl+wl1+nvG1nnnW2z/zVPe1RH09JFxzkyaH Q0fhqM01phTPX8vruAfSHNQJz+/WE8/r6RgT8iI9x78RSUaisZExLXo2khrUYZeJSYLiTugzcUww 7BypHahaB5r0Kt4DSnWk9p1ZKoPUGW5anqSkSTspTcsa0lmuV3GKVKuGJz3GHvmB184eyS/vGO95 c3LYUwnJlXaMzxRQUpJ9TKyI+6564r6w80xLa73XrmQ5rg6We3YjtmJpP2dgKS06O2+9I+bkEOfU Iu+7QTnFr4VFvuTXGgP/nRFbMTDuNWKhTIOzWGjCG1aSDbXHQi+jgH240gbIOU+2L7dXCEm9Qk6u Ve4+nyH3qM+Z3JAvJIV8tcu9h8+X0Q0ZlJURn2QYJiYmbGYY2riI0MTm+FDVDINV9jS+O4Esr+L9 vNv+mGeYsDDDFM4/Ndga+4y7DbkZ0YGtmaS4GrnTptwW1plcH7t6ubOC4eMeR3aeE5Ks5l4NtmZN /zqVmwf7cp9j9jlm/22YLb83/+VuE0PugXpF7xfqH71/7/6YRu9GTq189L6TRj0BM/apFL13OIze y1vsU3ld64I0p9bzNGPEdcflRXWt4zqSeSVx3UV1NXFdVp2W45Q0qZvStAxIe1TncV15K1/x/ubJ Kz6x/mfGt717RSIjpOupWGJQDRYhZXtNiLjivdGQV/LKWui6ybtaXVeOh+9K11t8Yl51Fg/r0smW eTHYbH/VSK4UD2+pZzysUMuNeX5uJr93HoifvpCEF+FYRWvZ4dlIeW6UzjWTuqHh03ocJpDnMQgh 79VHVu3cQYlRc3zSYSb7vPhh04wbGuuRl8DV+1I9V28DwXvF12hGfHdkRB+NjKmnMTbbjCvaIN53 1TTb7vOdDUE+J9Zjx0Lsba0n9gr55tviPyPfTOI7km8m8WzlfHO13xDuyCDckbsx3iQUxzKhrBBW rPlmznEWb1I1NJzyr0bDDj8IHf5uIasSimOZUFbI+Z1rWB51jNDassDNN63Brs9LdNd/MzGip6LD iYQeJUgxcUAQYaDDwIBWZe23I7eNyv2BT6oyPW3E48UnjSeItHfCKNipYDdjzvmo3QpzjmHZDYfH 0iP6EOwg84tk6zvhE6bgYe73ZrCuM0//U6X4Kv1nC2HkovV/A63O72EAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAnAAoAAQBpAA8AAwAAAAAAAAAAADAAAEDx/wIAMAAMAAYATgBvAHIAbQBhAGwAAAAC AAAAEABfSAEEbUgJBHNICQR0SAkEaAABQAEAAgBoAA0ACQBIAGUAYQBkAGkAbgBnACAAMQAAACoA AQAGJAEKJgALRgMAD4SvARGEUf4TpOABFKTwADEkAEAmAF6ErwFghFH+GgA1CIE7CIFLSBwAT0oD AFFKAwBtSAkIc0gJCKIAAkABAAIAogANAAkASABlAGEAZABpAG4AZwAgADIAAAB6AAIABiQBCiYB C0YDAA3GTQAZAAAQBSAKMA9AFFAZYB5wI4AokC2gMrA3wDzQQeBG8EsAURBWIFswYEBlUGpgb3B0 sHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4RCAhGEvv0TpHgAFKR4ACokAUAmAV6EQgJghL79 AwBcCIEAQgADAAEAAgBCAA0ACQBIAGUAYQBkAGkAbgBnACAAMwAAABcAAwAGJAEKJgILRgMAE6R4 ABSkeABAJgIABgA1CIE2CIE0AAQAAQACADQADQAJAEgAZQBhAGQAaQBuAGcAIAA0AAAADwAEAAYk AQomAwtGAwBAJgMAAAA4AAUAAQACADgADAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAAFAAFAAomBAtG AwATpPAAFKQ8AEAmBAAAOAAGAAEAAgA4AAwACQBIAGUAYQBkAGkAbgBnACAANgAAABQABgAKJgUL RgMAE6TwABSkPABAJgUAADgABwABAAIAOAAMAAkASABlAGEAZABpAG4AZwAgADcAAAAUAAcACiYG C0YDABOk8AAUpDwAQCYGAAA4AAgAAQACADgADAAJAEgAZQBhAGQAaQBuAGcAIAA4AAAAFAAIAAom BwtGAwATpPAAFKQ8AEAmBwAAOAAJAAEAAgA4AAwACQBIAGUAYQBkAGkAbgBnACAAOQAAABQACQAK JggLRgMAE6TwABSkPABAJggAADwAQUDy/6EAPAAMARYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEA ZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAABEAB9AAQDyAEQADAAOAEgAZQBhAGQAZQBy ACwAUABhAGcAZQAgAE4AbwAAAA0ADwANxggAAuAQwCEBAgAIAENKEABhShAALAAgQAEAAgEsAAwA BgBGAG8AbwB0AGUAcgAAAA0AEAANxggAAuAQwCEBAgAAADIAKUCiABEBMgAMAAsAUABhAGcAZQAg AE4AdQBtAGIAZQByAAAADABDShAAT0oAAFFKAAAsABNAAQACACwADQEFAFQATwBDACAAMQAAAAoA EgATpHgAFKR4AAYANQiBOwiBKgAUQAEAAgAqAA0BBQBUAE8AQwAgADIAAAAKABMAD4TIAF6EyAAD ADoIgQAqABUAAQACACoADQEFAFQATwBDACAAMwAAAAoAFAAPhJABXoSQAQMANgiBACoAFgABAAIA KgANAQUAVABPAEMAIAA0AAAACgAVAA+EWAJehFgCBABDShIAKgAXAAEAAgAqAA0BBQBUAE8AQwAg ADUAAAAKABYAD4QgA16EIAMEAENKEgAqABgAAQACACoADQEFAFQATwBDACAANgAAAAoAFwAPhOgD XoToAwQAQ0oSACoAGQABAAIAKgANAQUAVABPAEMAIAA3AAAACgAYAA+EsARehLAEBABDShIAKgAa AAEAAgAqAA0BBQBUAE8AQwAgADgAAAAKABkAD4R4BV6EeAUEAENKEgAqABsAAQACACoADQEFAFQA TwBDACAAOQAAAAoAGgAPhEAGXoRABgQAQ0oSADoA/g/xALIBOgAMAAYAUwB0AHkAbABlADUAAAAI ABsAAyQCYSQCEwA1CIFDShAAT0oAAFFKAABhShAAADoA/g/xAMIBOgANAAYAUwB0AHkAbABlADYA AAAIABwAAyQCYSQCEwA1CIFDShAAT0oAAFFKAABhShAAADQA/g8BANIBNAAMAAYAUwB0AHkAbABl ADcAAAACAB0AEwA1CIFPSgAAUUoAAG1ICQhzSAkIADQA/g8BAOIBNAANAAYAUwB0AHkAbABlADIA AAACAB4AEwA1CIFDShAAT0oAAFFKAABhShAAADIA/g8BAPIBMgAMAAYAUwB0AHkAbABlADEAAAAI AB8AAyQBYSQBCwA1CIFPSgAAUUoAAAAwAP5PogABAjAADAAFAFMAdAB5AGwAZQAAABYANQiBQ0oU AE9KAwBRSgMAXAiBYUoUAEIA/g8BABICQgAMAQ0AQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAMQAA AAIAIQAUAENKEABPSgQAUUoEAF5KBABhShAAYgD+TyEAIgJiAA0AGwBTAHQAeQBsAGUAIABIAGUA YQBkAGkAbgBnACAAMgAgACsAIABKAHUAcwB0AGkAZgBpAGUAZAAAAAwAIgADJAMTpPAAYSQDDgA1 CIFPSgMAUUoDAFwIgToAJ0CiADECOgAMBREAQwBvAG0AbQBlAG4AdAAgAFIAZQBmAGUAcgBlAG4A YwBlAAAACABDShAAYUoQACwAHgABAEICLAAMBQwAQwBvAG0AbQBlAG4AdAAgAFQAZQB4AHQAAAAC ACQAAAA6AP4PQQJCAjoADAUQAEMAbwBtAG0AZQBuAHQAIABTAHUAYgBqAGUAYwB0ADEAAAACACUA BgA1CIFcCIFAAP4PAQBiAkAADAUMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgAmABQAQ0oQ AE9KBABRSgQAXkoEAGFKEAAAAAAAgwAAAJA6AAABAAAAAAAAAAAA/////wIEAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACDAAAAhgAAAAAAAAAAAP//AAAAAAAAAABLAAAA3gUAABwJAACQ OgAABQAAZAAAAAD/////BQA4ZAAAAAD/////BQBwZAAAAAD/////BQChZAAAAAD/////CQAAAARA //8BABgrowAAAAAAADD//wIAGCujAAAAAAAEQP//AwAYK6MAAAAAAAAw//8EABgrowAAAAAABDD/ /wUAGCujAAAAAAAAMP//BgAYK6MAAAAAAAQw//8HABgrowAAAAAAADD//wgAGCujAAAAAAAEMP// CQAYK6MAAAAAAAAAAABLAAAA3gUAABwJAACqFwAAjR4AANwjAAAXMgAAsTUAAJA6AAAAAAAAAAAB AAAAAAACAAAAAAADAAEAAAAEAAIAAAAFAAEAAAAGAHQBAAAHAAEAAAAIAAAAAAAAAAAAAwAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAQAAAAEEAAABKAAAASwAA AEwAAABeAAAAXwAAAHEBAAByAQAA6QIAAOoCAAAmBAAAJwQAAFIEAACyBAAAFAUAANUFAADWBQAA 1wUAANgFAADZBQAA2gUAANsFAADcBQAA3QUAAN4FAADfBQAA6wUAAOwFAADtBQAALAYAAFoGAACe BgAA2gYAABkHAABMBwAAjQcAANwHAAAHCAAAQAgAAHQIAACvCAAA2wgAABcJAAAZCQAAGgkAABsJ AAAcCQAAHQkAAE4JAABbCQAA4QoAAOIKAACgDAAAoQwAALoNAAC7DQAAHQ4AACkOAACpDwAAqg8A ALcQAAC4EAAAbREAAI8RAACnEQAA4BQAABkVAABEFQAAXxUAAKkXAACqFwAAqxcAAK0XAACuFwAA zBcAAM0XAADOFwAA8RcAAPIXAAD0FwAADRgAAA4YAAD7GQAAChoAAJoaAACbGgAA0xoAAPsaAABI GwAASRsAALsbAAAtHAAArRwAAK4cAACMHgAAjR4AAI8eAACpHgAAqh4AAHMfAAB0HwAAdh8AAJYf AACXHwAAJiAAACcgAADMIAAAzSAAAM8gAADjIAAA5CAAAP4hAAAbIgAA3CMAAN0jAACeJAAAnyQA APokAAAnJQAAxyYAAMgmAABeKAAAXygAAMAoAADBKAAAsysAALwrAAAvLAAARCwAALYuAAC3LgAA fC8AAH0vAADtLwAA7i8AACwwAAA8MAAAzzAAANAwAAAXMgAALjIAAIszAACTMwAAvTQAAL40AADA NAAAwTQAAOk0AADqNAAAcTUAAHI1AAB0NQAAdTUAALA1AACyNQAAzDUAAA83AAAQNwAANjgAADc4 AAC8OAAAvTgAAIw5AAChOQAAsTkAALI5AACzOQAAyDkAANg5AADZOQAA2jkAANs5AADrOQAA7DkA AJE6AACYAAAAADAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAABgADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAUgADAAAAAAAAAAgAAAAICYAAUgADABAAAAAAAAgAAAAICYAAUg ADACAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAABgADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAEjAAAAAAAAAAgAAAAICYAAAAEjAAAAAAAAAAgAAAAICY AAAAEjAAAAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAA EzAAAAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAAEjAAAAAAAAAAgAAAAICYAAAAEjAA AAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAAEzAAAAAA AAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICYAAAAEjAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAABgADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAIAIAAMgATAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgE4JAACYAAAAADAAAAAAAAAAgE4JAACYAAAAADAAAAAAAAAAgE4JAACYAAAA ADAAAAAAAAAAgE4JAACYAAAAADAAAAAAAAAAgE4JAACYAAAAADAAAAAAAAAAgE4JAACYAAAAADAA AAAAAAAAgE4JAAAIAAMgATABAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgB0OAACYAAAAADAAAAAA AAAAgB0OAACYAAAAADAAAAAAAAAAgB0OAACYAAAAADAAAAAAAAAAgB0OAACYAAAAADAAAAAAAAAA gB0OAAAIAAMgATACAAAAAAAAgAAAAIAYAQMgIjAAAAAAbREAAG0RAACYAAAAADAAAAAAAAAAgI8R AACYAAYgADAAAAAAAAAAgI8RAACYAAYgADABAAAAAAAAgI8RAAAYAQMgIjABAAAAbREAAG0RAACY AAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAA ADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAA AAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAA AAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAAgEQVAACYAAAAADAAAAAAAAAA gEQVAACYAAAAADAAAAAAAAAAgEQVAAAYAQMgIjACAAAAbREAAG0RAACYAAAAADAAAAAAAAAAgPsZ AACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAggADAAAAAAAAAAgPsZAACY AAggADABAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAcg ADAAAAAAAAAAgPsZAACYAAcgADABAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAA AAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAA AAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAA gPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZ AACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACY AAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAACYAAAA ADAAAAAAAAAAgPsZAACYAAAAADAAAAAAAAAAgPsZAAAYAQMgIjADAAAAbREAAG0RAACYAAAAADAA AAAAAAAAgP4hAACYAAAAADAAAAAAAAAAgP4hAACYAAAAADAAAAAAAAAAgP4hAACYAAAAADAAAAAA AAAAgP4hAACYAAAAADAAAAAAAAAAgP4hAAAIAAMgATADAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gPokAACYAAAAADAAAAAAAAAAgPokAACYAAAAADAAAAAAAAAAgPokAACYAAAAADAAAAAAAAAAgPok AACYAAAAADAAAAAAAAAAgPokAACYAAAAADAAAAAAAAAAgPokAACYAAAAADAAAAAAAAAAgPokAAAI AAMgATAEAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgLMrAAAYAQMgIjAAAAAAsysAALMrAACYAAAA ADAAAAAAAAAAgC8sAACYAAAAADAAAAAAAAAAgC8sAACYAAAAADAAAAAAAAAAgC8sAACYAAAAADAA AAAAAAAAgC8sAACYAAAAADAAAAAAAAAAgC8sAACYAAAAADAAAAAAAAAAgC8sAACYAAAAADAAAAAA AAAAgC8sAAAYAQMgIjABAAAAsysAALMrAACYAAAAADAAAAAAAAAAgCwwAACYAAAAADAAAAAAAAAA gCwwAACYAAAAADAAAAAAAAAAgCwwAAAYAQMgIjACAAAAsysAALMrAACYAAAAADAAAAAAAAAAgBcy AAAYAQMgIjADAAAAsysAALMrAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACY AAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAA ADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAA AAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAAAAAAgIszAACYAAAAADAAAAAA AAAAgIszAAAIAAMgATAFAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICaAAAAAAAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAAAAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAAAAA AAAAAAAAgAAAAICYAAAAEDAAAAAAAAAAgAAAAICaAAAAAAAAAAAAAAAAgAAAAICYAAAAEDAAAAAA AAAAgAAAAICaAAAAAAAAAAAAAAAAgAAAAIAAAAAAAwAAAAYAAAAGAAAACQAAAAwAAAAMAAAAHQAA ADUAAAA1AAAANQAAAEIAAACiAAAAyQAAAMwAAADMAAAAzAAAAM8AAADPAAAA9gAAAB0BAAAdAQAA HwEAACwBAAAuAQAALgEAAC4BAAAuAQAAMAEAAE0BAABNAQAAUAEAAAAEAABaCgAAjAsAAK4MAAB1 IwAAjD0AAJA+AAAhAAAAJgAAACcAAAAoAAAALAAAADAAAAAABAAAQAQAANcJAACvDAAAuBQAANMe AAAbJgAALjYAAMY8AADZPQAAkD4AACIAAAAkAAAAJQAAACkAAAAqAAAAKwAAAC0AAAAuAAAALwAA ADEAAAAABAAAjz4AACMAAADtBQAA/AUAAAwGAAAoBgAAKgYAADoGAABWBgAAWAYAAH4GAACaBgAA nAYAALoGAADWBgAA2AYAAPkGAAAVBwAAFwcAACwHAABIBwAASgcAAG0HAACJBwAAiwcAALwHAADY BwAA2gcAAOcHAAADCAAABQgAACAIAAA8CAAAPggAAFQIAABwCAAAcggAAI8IAACrCAAArQgAALsI AADXCAAA2QgAAPcIAAATCQAAFQkAABcJAACQOgAAEw2U/xMlFP+VwBMlFP+VwBMlFP+VwBMlFP+V wBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMlFP+VwBMl FP+VwJWMvAAAAMMAAADFAAAA6QAAAPAAAADyAAAAEAEAABcBAAAZAQAAQQEAAEgBAABKAQAAUAEA ABMhlP+VgBMhFP+VgBMhlP+VgBMhtP+VgA8AAPBAAAAAAAAG8CAAAAACDAAAAwAAAA8AAAACAAAA AQAAAAMAAAACAAAADQAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSgoAACAACPAIAAAA CwAAAAwIAAAPAAPwMgoAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA CAAABQAAAA8ABPD4AAAAgggK8AgAAAABCAAAAAoAALMAC/CiAAAABAAAADsBwMAMAAAAwwAAAAEA xcAgAAAA/wAAQIDAgQHAwMAAggEAgAAAvwEQABAA/wEAAAgAgMM0AAAAvwMgACAARABSAEEARgBU AAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABQAG8AdwBlAHIAUABsAHUAcwBXAGEA dABlAHIATQBhAHIAawBPAGIAagBlAGMAdAAxAAAAUwAi8R4AAACPAwIAAACQAwAAAACRAwIAAACS AwAAAAC/AwAAAIAAABDwBAAAAAIAAAAAABHwBAAAAAEAAAAPAATw+AAAAIIICvAIAAAAAggAAAAK AACzAAvwogAAAAQAAAA7AcDADAAAAMMAAAABAMXAIAAAAP8AAECAwIEBwMDAAIIBAIAAAL8BEAAQ AP8BAAAIAIDDNAAAAL8DIAAgAEQAUgBBAEYAVAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0A YQBuAAAAUABvAHcAZQByAFAAbAB1AHMAVwBhAHQAZQByAE0AYQByAGsATwBiAGoAZQBjAHQAMgAA AFMAIvEeAAAAjwMCAAAAkAMAAAAAkQMCAAAAkgMAAAAAvwMAAACAAAAQ8AQAAAAAAAAAAAAR8AQA AAABAAAADwAE8PgAAACCCArwCAAAAAMIAAAACgAAswAL8KIAAAAEAAAAOwHAwAwAAADDAAAAAQDF wCAAAAD/AABAgMCBAcDAwACCAQCAAAC/ARAAEAD/AQAACACAwzQAAAC/AyAAIABEAFIAQQBGAFQA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAFAAbwB3AGUAcgBQAGwAdQBzAFcAYQB0 AGUAcgBNAGEAcgBrAE8AYgBqAGUAYwB0ADMAAABTACLxHgAAAI8DAgAAAJADAAAAAJEDAgAAAJID AAAAAL8DAAAAgAAAEPAEAAAAAQAAAAAAEfAEAAAAAQAAAA8ABPD4AAAAgggK8AgAAAAECAAAAAoA ALMAC/CiAAAABAAAADsBwMAMAAAAwwAAAAEAxcAgAAAA/wAAQIDAgQHAwMAAggEAgAAAvwEQABAA /wEAAAgAgMM0AAAAvwMgACAARABSAEEARgBUAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAABQAG8AdwBlAHIAUABsAHUAcwBXAGEAdABlAHIATQBhAHIAawBPAGIAagBlAGMAdAA0AAAA UwAi8R4AAACPAwIAAACQAwAAAACRAwIAAACSAwAAAAC/AwAAAIAAABDwBAAAAAUAAAAAABHwBAAA AAEAAAAPAATw+AAAAIIICvAIAAAABQgAAAAKAACzAAvwogAAAAQAAAA7AcDADAAAAMMAAAABAMXA IAAAAP8AAECAwIEBwMDAAIIBAIAAAL8BEAAQAP8BAAAIAIDDNAAAAL8DIAAgAEQAUgBBAEYAVAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAUABvAHcAZQByAFAAbAB1AHMAVwBhAHQA ZQByAE0AYQByAGsATwBiAGoAZQBjAHQANQAAAFMAIvEeAAAAjwMCAAAAkAMAAAAAkQMCAAAAkgMA AAAAvwMAAACAAAAQ8AQAAAADAAAAAAAR8AQAAAABAAAADwAE8PgAAACCCArwCAAAAAYIAAAACgAA swAL8KIAAAAEAAAAOwHAwAwAAADDAAAAAQDFwCAAAAD/AABAgMCBAcDAwACCAQCAAAC/ARAAEAD/ AQAACACAwzQAAAC/AyAAIABEAFIAQQBGAFQAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEA bgAAAFAAbwB3AGUAcgBQAGwAdQBzAFcAYQB0AGUAcgBNAGEAcgBrAE8AYgBqAGUAYwB0ADYAAABT ACLxHgAAAI8DAgAAAJADAAAAAJEDAgAAAJIDAAAAAL8DAAAAgAAAEPAEAAAABAAAAAAAEfAEAAAA AQAAAA8ABPD4AAAAgggK8AgAAAAHCAAAAAoAALMAC/CiAAAABAAAADsBwMAMAAAAwwAAAAEAxcAg AAAA/wAAQIDAgQHAwMAAggEAgAAAvwEQABAA/wEAAAgAgMM0AAAAvwMgACAARABSAEEARgBUAAAA VABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABQAG8AdwBlAHIAUABsAHUAcwBXAGEAdABl AHIATQBhAHIAawBPAGIAagBlAGMAdAA3AAAAUwAi8R4AAACPAwIAAACQAwAAAACRAwIAAACSAwAA AAC/AwAAAIAAABDwBAAAAAgAAAAAABHwBAAAAAEAAAAPAATw+AAAAIIICvAIAAAACAgAAAAKAACz AAvwogAAAAQAAAA7AcDADAAAAMMAAAABAMXAIAAAAP8AAECAwIEBwMDAAIIBAIAAAL8BEAAQAP8B AAAIAIDDNAAAAL8DIAAgAEQAUgBBAEYAVAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAAUABvAHcAZQByAFAAbAB1AHMAVwBhAHQAZQByAE0AYQByAGsATwBiAGoAZQBjAHQAOAAAAFMA IvEeAAAAjwMCAAAAkAMAAAAAkQMCAAAAkgMAAAAAvwMAAACAAAAQ8AQAAAAGAAAAAAAR8AQAAAAB AAAADwAE8PgAAACCCArwCAAAAAkIAAAACgAAswAL8KIAAAAEAAAAOwHAwAwAAADDAAAAAQDFwCAA AAD/AABAgMCBAcDAwACCAQCAAAC/ARAAEAD/AQAACACAwzQAAAC/AyAAIABEAFIAQQBGAFQAAABU AGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAFAAbwB3AGUAcgBQAGwAdQBzAFcAYQB0AGUA cgBNAGEAcgBrAE8AYgBqAGUAYwB0ADkAAABTACLxHgAAAI8DAgAAAJADAAAAAJEDAgAAAJIDAAAA AL8DAAAAgAAAEPAEAAAABwAAAAAAEfAEAAAAAQAAAA8ABPD6AAAAgggK8AgAAAAKCAAAAAoAALMA C/CkAAAABAAAADsBwMAMAAAAwwAAAAEAxcAgAAAA/wAAQIDAgQHAwMAAggEAgAAAvwEQABAA/wEA AAgAgMM2AAAAvwMgACAARABSAEEARgBUAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AABQAG8AdwBlAHIAUABsAHUAcwBXAGEAdABlAHIATQBhAHIAawBPAGIAagBlAGMAdAAxADAAAABT ACLxHgAAAI8DAgAAAJADAAAAAJEDAgAAAJIDAAAAAL8DAAAAgAAAEPAEAAAACQAAAAAAEfAEAAAA AQAAAAAPAALwDAEAABAACPAIAAAAAgAAAAIEAAAPAAPwqgAAAA8ABPAoAAAAAQAJ8BAAAAADAAAA AAkAAJUAAABQAQAAAgAK8AgAAAAABAAABQAAAA8ABPByAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2 AAAAgAAAAAEAgQCcMQAAggCcMQAAgwCcMQAAhACcMQAAvwEAABAAwAH///8A/wEAAAgAPwIAAAIA AAAQ8AQAAAAAAAAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAEADwAE8EIAAAASAArwCAAAAAEEAAAA DgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAAAAAA kDoAAAIEAAD6AgAAGwMAAMoiAABgBQAAdAAAAAAADAAAAB0AAAA1AAAAogAAAMkAAADMAAAAzwAA APYAAAAfAQAAMAEAAFABAAACCAAAAAAAAAAAAAAIJwAAnA8AAHQAAAAAAAMIAACS+///PP3//5oi AADYDAAAdAAAAAAAAQgAAAAAAAAAAAAACCcAAJwPAAB0AAAAAAAFCAAAAAAAAAAAAAAIJwAAnA8A AHQAAAAAAAYIAAAAAAAAAAAAAAgnAACcDwAAdAAAAAAABAgAAAAAAAAAAAAACCcAAJwPAAB0AAAA AAAICAAAAAAAAAAAAAAIJwAAnA8AAHQAAAAAAAkIAAAAAAAAAAAAAAgnAACcDwAAdAAAAAAABwgA AAAAAAAAAAAACCcAAJwPAAB0AAAAAAAKCAAAAAAAAAAAAAAIJwAAnA8AAHQAAAAAAP//DgAAAA0A XwBUAG8AYwAxADAAOAA4ADMANAA3ADMANgANAF8AVABvAGMAMQAwADgAOAAzADQANwAzADcADQBf AFQAbwBjADEAMAA4ADgAMwA0ADcAMwA4AA0AXwBUAG8AYwAxADAAOAA4ADMANAA3ADMAOQANAF8A VABvAGMAMQAwADgAOAAzADQANwA0ADAADQBfAFQAbwBjADEAMAA4ADgAMwA0ADcANAAxAA0AXwBU AG8AYwAxADAAOAA4ADMANAA3ADQAMgANAF8AVABvAGMAMQAwADgAOAAzADQANwA0ADMADQBfAFQA bwBjADEAMAA4ADgAMwA0ADcANAA0AA0AXwBUAG8AYwAxADAAOAA4ADMANAA3ADQANQANAF8AVABv AGMAMQAwADgAOAAzADQANwA0ADYADQBfAFQAbwBjADEAMAA4ADgAMwA0ADcANAA3AA0AXwBUAG8A YwAxADAAOAA4ADMANAA3ADQAOAANAF8AVABvAGMAMQAwADgAOAAzADQANwA0ADkAHQkAAB0OAABt EQAAjxEAAEQVAAD7GQAA/iEAAPokAACzKwAALywAACwwAAAXMgAAizMAALI1AACROgAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAABaCQAAKA4A AI4RAACmEQAAXhUAAAkaAAAaIgAAJiUAALsrAABDLAAAOzAAAC0yAACSMwAAyzUAAJE6AAAAAAAA DAYAACsGAAA6BgAAWQYAAH4GAACdBgAAugYAANkGAAD5BgAAGAcAACwHAABLBwAAbQcAAIwHAAC8 BwAA2wcAAOcHAAAGCAAAIAgAAD8IAABUCAAAcwgAAI8IAACuCAAAuwgAANoIAAD3CAAAFgkAAEgO AABQDgAAvTgAAL04AAC/OAAAvzgAAMA4AADAOAAAwjgAAMM4AADFOAAAxjgAAMg4AADJOAAA8zgA AP44AAB5OQAAgzkAAKY5AACwOQAAzTkAANc5AADdOQAA6DkAAO45AAD5OQAA/jkAAAg6AAAKOgAA CzoAAI46AACROgAABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAH AAcABwAHAAcABwAHABwABwAEAAcABAACAAQABwAEAAcABAAHAAQABwAFAAcABwAHAAcABwAHAAcA BQAHAAUABwAHAAcAAgAHAAcAAAAAAAwGAAArBgAAOgYAAFkGAAB+BgAAnQYAALoGAADZBgAA+QYA ABgHAAAsBwAASwcAAG0HAACMBwAAvAcAANsHAADnBwAABggAACAIAAA/CAAAVAgAAHMIAACPCAAA rggAALsIAADaCAAA9wgAABYJAAC8OAAAvTgAAHk5AACDOQAApjkAALA5AADNOQAA1zkAAJE6AAAD AAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMA BwACAAcAAgAHAAIABwACAAAAAAAMBgAAKwYAADoGAABZBgAAfgYAAJ0GAAC6BgAA2QYAAPkGAAAY BwAALAcAAEsHAABtBwAAjAcAALwHAADbBwAA5wcAAAYIAAAgCAAAPwgAAFQIAABzCAAAjwgAAK4I AAC7CAAA2ggAANsIAAD3CAAAFgkAAE4JAABbCQAARBUAAF8VAADTGgAA+xoAAC8sAABELAAAvTgA AL04AAC/OAAAvzgAAMA4AADAOAAAwjgAAMM4AADFOAAAxjgAAMg4AADJOAAAyjgAANg4AADaOAAA 8DgAAPI4AAD9OAAAXzkAAHk5AACDOQAAhDkAAIw5AACmOQAAsDkAALE5AACzOQAAzTkAANc5AADY OQAA3DkAAOc5AADtOQAA/jkAAAo6AAALOgAAkToAAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcA BAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAUABAAHAAUABwAFAAcABQAHAAUABwAEAAcABAAC AAQABwAEAAcABAAHAAQABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAIABwD//wIAAAANAEoAbwBoAG4AIABIAG8AcgByAG8AYwBrAHMAhwBDADoAXABEAG8AYwB1 AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwASgBvAGgAbgAgAEgAbwByAHIA bwBjAGsAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAQwB1AHIAcgBlAG4AdAAgAFcAbwBy AGsAXAAwAEQAdABpAFwARQBDAEMAIABUAFIASQBTAFwAUAB1AGIAbABpAHMAaABlAGQAIABkAGUA bABpAHYAZQByAGEAYgBsAGUAcwBcAFIAZQBwAG8AcgB0ACAANwA1ACAASQBQACAAaQBuAHQAZQBy AGMAbwBuAG4AZQBjAHQAaQBvAG4ALgBkAG8AYwAIADw1UxKCXCbn/w//D/8P/w//D/8P/w//D/8P EABwQyMXEHq4pgEAAgADAAQABQAGAAcACAAJAAAAIlIoHJ7OkMD/DwAAAAAAAAAAAAAAAAAAAAAB ALQLTyGstvBI/w//D/8P/w//D/8P/w//D/8PEAAdMTw3ns6QwP8PAAAAAAAAAAAAAAAAAAAAAAEA 8WMfPhTEOKX/D/8P/w//D/8P/w//D/8P/w8QAGMt7Up2VQYT/w//D/8P/w//D/8P/w//D/8PAACQ UdN9FuHMqv8P/w//D/8P/w//D/8P/w//DxAAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E 0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oGAFFKBgBvKAABAKfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBR SgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQ DmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TgEBGEmP4V xgUAAeAQBl6E4BBghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oGAFFKBgBvKAAB AKfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EsAERhFD+FcYFAAGwAQZehLABYIRQ/gEA AAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAAGAAAD4RAAhGEwP0VxgUAAUACBl6EQAJghMD9AwAA AC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAAGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9 BQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAABgAAA+EYAMRhKD8FcYFAAFgAwZe hGADYISg/AcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAAGAAAD4TwAxGE EPwVxgUAAfADBl6E8ANghBD8CQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAA AAAAAAAAGAAAD4SABBGEgPsVxgUAAYAEBl6EgARghID7CwAAAC4AAQAuAAIALgADAC4ABAAuAAUA AQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAABgAAA+EEAURhPD6FcYFAAEQBQZehBAFYITw+g0AAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAAAGAAAD4SgBRGE YPoVxgUAAaAFBl6EoAVghGD6DwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAAB AwUHCQsNDxEAAAAAAAAAAAAAGAAAD4QwBhGE0PkVxgUAATAGBl6EMAZghND5EQAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EaAER hJj+FcYFAAFoAQZehGgBYISY/m8oAAEAAAABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQ AhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFK AQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQEYSY/hXG BQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8oAAEA p/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygA AQAAAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAF Bl6EoAVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EcAgR hJj+FcYFAAFwCAZehHAIYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYA bygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CE mP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SAFhGEmP4VxgUA AYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E UBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBgBRSgYAbygAAQCn8AEAAAAAEAEAAAAAAAAAAAAAAAAA AAAAACYYAAAPhLABEYRQ/hXGBQABsAEGXoSwAWCEUP41CAE2CAA7CAFDShQAT0oDAFFKAwBhShQA bygAh2gAAAAAiEgAAAEAAAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAjGAEAD4RAAhGEwP0VxgUA AUACBl6EQAJghMD9NQgBNggAQ0oUAE9KAwBRSgMAYUoUAG8oAIdoAAAAAIhIAAADAAAALgABAAEA AAAAAAEDBQAAAAAAAAAAAAAAAAAAACMYAgAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP01CAE2CAFD ShQAT0oDAFFKAwBhShQAbygAh2gAAAAAiEgAAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAA AAAAAAAAACMYAwAPhGADEYSg/BXGBQABYAMGXoRgA2CEoPw1CAA2CAFDShQAT0oAAFFKAABhShQA bygAh2gAAAAAiEgAAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAbGAQA D4TwAxGEEPwVxgUAAfADBl6E8ANghBD8NQgBNggAQ0oUAGFKFABvKACHaAAAAACISAAACQAAAC4A AQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAANGAUAD4SABBGEgPsVxgUAAYAE Bl6EgARghID7bygAh2gAAAAAiEgAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJ Cw0AAAAAAAAAAAAAAA0YBgAPhBAFEYTw+hXGBQABEAUGXoQQBWCE8PpvKACHaAAAAACISAAADQAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAA0YBwAPhKAF EYRg+hXGBQABoAUGXoSgBWCEYPpvKACHaAAAAACISAAADwAAAC4AAQAuAAIALgADAC4ABAAuAAUA LgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAANGAgAD4QwBhGE0PkVxgUAATAGBl6EMAZg hND5bygAh2gAAAAAiEgAABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAX EAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8o AAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+ T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFw CAZehHAIYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYAbygAAQCn8AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoB AG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZg hJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+FcYF AAFQGQZehFAZYISY/k9KBgBRSgYAbygAAQCn8AgAAAAiUigcAAAAAAAAAAAAAAAAHTE8NwAAAAAA AAAAAAAAAHBDIxcAAAAAAAAAAAAAAABjLe1KAAAAAAAAAAAAAAAAtAtPIQAAAAAAAAAAAAAAAJBR 030AAAAAAAAAAAAAAAA8NVMSAAAAAAAAAAAAAAAA8WMfPgAAAAAAAAAAAAAAAP////////////// //////////////////////////////8IAAAAAAAAAAAAAAAAAAAAAAAAAP//CAAAABIAAQAJBAMA CQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAAAAABIAAQAJBAMACQQFAAkEAQAJBAMACQQF AAkEAQAJBAMACQQFAAkEAAASAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAAA EgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQS9OAAAvzgAAMI4AADFOAAAyDgA AKE5AACzOQAAkToAAAAAAAABAAAAAQAAAAEAAAABAAAABQAAAAUAAAD/QACAAQAAAAAAAAAAAPDB QgABAAEAAAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAAAJA6AABQAAAIAEAAAP//AQAAAAcAVQBuAGsA bgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAH AAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4A ZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAA AFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEA cgBpAGEAbAAAAHEEvAIAFQICCAMHBQUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBl AHMAIABOAGUAdwAgAFIAbwBtAGEAbgAgAEIAbwBsAGQAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIA bwBtAGEAbgAAADUjkAEAAAILBgQDBQQEAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGEAaABv AG0AYQAAAD8xkAEAAAIHAwkCAgUCBAQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkA ZQByACAATgBlAHcAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBp AG4AZwBkAGkAbgBnAHMAAAAjAAQAMQioGADw0AIAAGgBAAAAACJsl2YibJdmJlqXJgIAAQAAADUI AADILgAACQAXAAAABAADEGMAAAB4CAAARjAAAAkAGAAAAGYAAAAAAAAAIQMA8BAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAABIwAAAQABkAZAAAABkAAABzOQAAvjgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzDUAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AACIAgAAAAAEMoNRAPAQAN/fAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhY//8SAAAAAABt AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABKAG8A aABuACAASABvAHIAcgBvAGMAawBzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABDAHUAcgBy AGUAbgB0ACAAdwBvAHIAawBcADAARAB0AGkAXABFAEMAQwAgAFQAUgBJAFMAXABUAGUAbQBwAGwA YQB0AGUAcwBcAFIAZQBwAG8AcgB0ACAAdABlAG0AcABsAGEAdABlAC4AZABvAHQAHwBBACAATgBl AHcAIABNAG8AZABlAGwAIABmAG8AcgAgAEkAbgB0AGUAcgBjAG8AbgBuAGUAYwB0AGkAbwBuAAAA AAAAAAgARQBDAEMAIABUAFIASQBTAA0ASgBvAGgAbgAgAEgAbwByAHIAbwBjAGsAcwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf 8vlPaBCrkQgAKyez2TAAAACYAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAwAAAAAQAAADMAAAA BQAAAOAAAAAHAAAA7AAAAAgAAAAIAQAACQAAACABAAASAAAALAEAAAoAAABIAQAACwAAAFQBAAAM AAAAYAEAAA0AAABsAQAADgAAAHgBAAAPAAAAgAEAABAAAACIAQAAEwAAAJABAAACAAAA5AQAAB4A AAAgAAAAQSBOZXcgTW9kZWwgZm9yIEludGVyY29ubmVjdGlvbgAeAAAAAQAAAAAgTmUeAAAACQAA AEVDQyBUUklTAGVsIB4AAAABAAAAAENDIB4AAAAUAAAAUmVwb3J0IHRlbXBsYXRlLmRvdAAeAAAA DgAAAEpvaG4gSG9ycm9ja3MAZS4eAAAAAgAAADIAaG4eAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDku MAAAQAAAAABGwyMAAAAAQAAAAAD8Y3brhcUBQAAAAACkTUrAh8UBQAAAAACkTUrAh8UBAwAAAAkA AAADAAAANQgAAAMAAADILgAAAwAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cI ACss+a4wAAAACAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAA FwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAOgAAAAC AAAA5AQAAB4AAAAEAAAARVJPAAMAAABjAAAAAwAAABcAAAADAAAAczkAAAMAAAAOGwkACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACAAAABBIE5ldyBNb2RlbCBmb3IgSW50 ZXJjb25uZWN0aW9uAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAA AA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAAp AAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAA/v///zQAAAA1AAAANgAAADcA AAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAA AEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAA VAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABi AAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAAD+////bAAAAG0AAABuAAAAbwAAAHAA AABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAA AH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAA jQAAAI4AAACPAAAA/v///5EAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAAD+////mQAAAJoAAACb AAAAnAAAAJ0AAACeAAAAnwAAAP7////9/////f///6MAAAD+/////v////7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAQadRSwIfFAaUAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAACJuAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrAAAAD0kAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADS ZAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAkAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAQadRSwIfFARBp1FLAh8UBAAAAAAAA AAAAAAAAAQAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3Vt ZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA== ------=_NextPart_000_00AA_01C598E2.E7F9DD30 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_00AA_01C598E2.E7F9DD30-- From enum-bounces@ietf.org Thu Aug 04 08:43:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f4Z-0008S3-0T; Thu, 04 Aug 2005 08:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d4f-0002rS-QA for enum@megatron.ietf.org; Thu, 04 Aug 2005 06:35:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24310 for ; Thu, 4 Aug 2005 06:35:38 -0400 (EDT) Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dbT-0003JY-BL for enum@ietf.org; Thu, 04 Aug 2005 07:09:39 -0400 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:35:23 +0100 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Aug 2005 11:35:23 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 11:35:22 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1123151721863; Thu, 4 Aug 2005 11:35:21 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.92]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id j74AZIDr013026; Thu, 4 Aug 2005 11:35:21 +0100 Message-Id: <5.2.1.1.2.20050804112044.02b6dc30@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 04 Aug 2005 11:35:17 +0100 To: David Meyer From: Bob Briscoe In-Reply-To: <20050804093305.GA9189@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Aug 2005 10:35:22.0929 (UTC) FILETIME=[37FC1210:01C598E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Thu, 04 Aug 2005 08:43:36 -0400 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, sipping@ietf.org Subject: [Enum] Re: [voipeer] voipeer BOF presentations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org David, Thanks for (most of) slides. I was planning on attending the BoF... until it was re-scheduled to clash with tsvwg where I was presenting. Ugh. I understand the upshot was a re-BoF was requested for next IETF. My take (particularly on your slides) is that you can't talk about gathering requirements in isolation from what these requirements are being gathered for. Before a BoF we need a view on which area(s) the IETF (and specifically some new w-g that this BoF is expecting to start) is eventually planning on setting standards in. This involves determining which standards areas from the pick list you've given will NOT be done in the IETF (because there might be better fora). Finally, given your original charter had the words long-term in it, I wanted to share a paper we've just completed on how the long term economics of IP QoS interconnect will pan out. It covers: - where value will be generated, where profits will be eroded and why, - how QoS will be provided, - how accountability will be done, - how the session layer relates to the network and transport layers and specifically to QoS. Commercial Models for IP Quality of Service Interconnect, Bob Briscoe & Steve Rudkin (BT), in BTTJ Special Edition on IP Quality of Service, 23(2) (Apr 2005). (26pp, 44 refs, 8 figs; pre-print) Cheers Bob At 10:33 04/08/2005, David Meyer wrote: > http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides > > I'm still trying to collect a few of the presentations. > > > Dave > ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 08 12:38:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2AeG-0000vf-9h; Mon, 08 Aug 2005 12:38:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2AeE-0000vP-3v; Mon, 08 Aug 2005 12:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01543; Mon, 8 Aug 2005 12:38:43 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2BBv-0004xk-Kz; Mon, 08 Aug 2005 13:13:38 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j78GcY6F017456; Mon, 8 Aug 2005 09:38:34 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j78GcYDH017455; Mon, 8 Aug 2005 09:38:34 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 8 Aug 2005 09:38:34 -0700 From: David Meyer To: voipeer@lists.uoregon.edu Message-ID: <20050808163834.GA17181@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: enum@ietf.org, sipping@ietf.org Subject: [Enum] brief summary of the voipeer BOF X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775061749==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1775061749== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, =20 I just wanted to give a (very) brief summary of what happened at voipeer BOF. I will post detailed minutes to the list as soon as I can edit the notes (BTW, would the kind person who took the notes retransmit them to me? Thanks). =20 A couple of interesting outcomes: =20 (i). Interest in the broad topic =20 People clearly want to do *something* in this space. That was the almost unanimous sense of the room, and of the feedback I've personally=20 received. The challenge, of course, is to construct an appropriately scoped charter. Among other approaches, we should at the use cases and see if we can rule some of them out.=20 =20 (ii). Terminology =20 One of the things that became clear during the BOF was that we need common and well defined terminology. As a result, I'm working on a terminology document as our first document (assumes we do another BOF, see (iv) below). =20 (iii). BOF name =20 In keeping with our consensus that we have a terminology issue, I'd like to change the name. However, but given the trouble this time with BOF names, that's probably not a good idea. If/when we charter the WG, I will want to change the name (removing the term peer), if this isn't too much of a problem. =20 (iv). Documents to prepare before Vancouver=20 =20 First, I'm assuming we will do another BOF there (Jon and I have discussed this a bit). Given that, I would (minimally) like to have a terminology document and one or more use cases written up as input to the BOF. So I'm looking for folks who are interested in writing up use suc cases; please let me know if you are game. =20 (v). Division of labor with ENUM While not directly an outcome during the voipeer BOF, a clear division of labor with ENUM WG emerged during ENUM WG session on Friday. In particular, it became clear that the natural division of labor was that the ENUM WG is in the business of specifying the content and form of what goes into the DNS, and while voipeer specifies the use cases for that database. =20 =20 I've collected the current set of materials on http://www.1-4-5.net/~dmm/IETF/IETF63/VOIPEER/slides. If=20 you're presentation isn't yet here, please send it to me. Finally, thanks again to everyone who presented and participated in what was quite an interesting and productive session. =20 =20 Dave --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC94qKORgD1qCZ2KcRAn4gAJwLuaLyU1+zkGohnFl/q6E+BIsxqQCgiqiu sXyAUB40ciBlFQ52fup7xLg= =HGHZ -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- --===============1775061749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1775061749==-- From enum-bounces@ietf.org Wed Aug 10 11:39:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sg4-0005kv-Hv; Wed, 10 Aug 2005 11:39:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sg3-0005kj-5N for enum@megatron.ietf.org; Wed, 10 Aug 2005 11:39:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06862 for ; Wed, 10 Aug 2005 11:39:32 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2tEA-0002J6-Ji for enum@ietf.org; Wed, 10 Aug 2005 12:14:51 -0400 Received: from [10.31.13.109] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7AFe8eh013125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Aug 2005 08:40:09 -0700 Message-ID: <42FA1FA9.7040106@shockey.us> Date: Wed, 10 Aug 2005 11:39:21 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Enum] Just in casy you needed a early WG meeting report. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org http://voipandenum.blogspot.com/2005/08/ietf-63-carrier-enum-and-voip-peering.html :-) -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 02:58:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3718-0000Ta-94; Thu, 11 Aug 2005 02:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3716-0000TS-LS for enum@megatron.ietf.org; Thu, 11 Aug 2005 02:58:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12248 for ; Thu, 11 Aug 2005 02:58:14 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E37ZL-0002iD-J0 for enum@ietf.org; Thu, 11 Aug 2005 03:33:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 11 Aug 2005 09:01:35 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0A9@oefeg-s04.oefeg.loc> Thread-Topic: Carrier ENUM Thread-Index: AcWeGZasOiJMMQfOQsO1wSBtqAFfBQAJl9DN From: "Stastny Richard" To: "Richard Shockey" , "David Meyer" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu Subject: [Enum] Carrier ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Dear all, =20 After finally adopting "Carrier" ENUM in ENUM WG, the discussion at the voipeer mailing list shows that there is a problem with the term "carrier" and VoiP Peering and want to replace the term with something else, e.g. RTCSP =20 So doe we now have RTCSP ENUM? =20 No =20 VoIP peering is basically be talking about peering between SIP servers and the routing is done naturally via sip URI.. You do not need an E.164 number to do so. =20 User and Carrier ENUM is controlled from the E.164 end and so you have to play along the rules of E.164. =20 User ENUM is for End User (the entity who has the right to "use" the number. =20 Carrier ENUM is for "Carriers" (I am also not very happy with this term - so another term may be also here necessary) but this MUST NOT be the same term be used in voipeer. the term MUST indicate the linkage to E.164 numbers, that is for entities which give E.164 numbers to end-users and which are "hosting" the related services for=20 the End-users. =20 This is clear for geo-graphic numbers, for service numbers there is some additional discussion necessary, e.g. 800 numbers or corporate numbers can (e.g. in Austria) assigened from the regulator either via a "Carrier" or DIRECTLY=20 to the End-user, e.g. an enterprise To use these numbers on the PSTN , the enterprise needs to find a carrier hosting these numbers. =20 Q: the enterprise of course has the right to opt-in in user ENUM, but what about carrier ENUM? =20 In the sinnreich.com case discussed. Henry may voippeer with MCI directly, the situation in ENUM is depending on the E.164 numbers he wants to use =20 -regards Richard =20 _________________________________________________________________________= ____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User = Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 03:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37Ss-00067W-Ud; Thu, 11 Aug 2005 03:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37Ss-00067R-3C for enum@megatron.ietf.org; Thu, 11 Aug 2005 03:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13499 for ; Thu, 11 Aug 2005 03:26:56 -0400 (EDT) Received: from mail114.messagelabs.com ([195.245.231.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E3818-0003SD-4s for enum@ietf.org; Thu, 11 Aug 2005 04:02:22 -0400 X-VirusChecked: Checked X-Env-Sender: Paul.Rosbotham@cwmsg.cwplc.com X-Msg-Ref: server-7.tower-114.messagelabs.com!1123745206!11947478!1 X-StarScan-Version: 5.4.15; banners=cwmsg.cwplc.com,-,- X-Originating-IP: [194.6.6.20] Received: (qmail 31734 invoked from network); 11 Aug 2005 07:26:46 -0000 Received: from mx.cwplc.com (194.6.6.20) by server-7.tower-114.messagelabs.com with SMTP; 11 Aug 2005 07:26:46 -0000 Received: from GBCWSWIEV001.ad.plc.cwintra.com ([148.185.93.211]) by mx.cwplc.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j7B7PjF14645 for ; Thu, 11 Aug 2005 08:25:45 +0100 (BST) Received: from GBCWSWIEC002.ad.plc.cwintra.com (unverified) by GBCWSWIEV001.ad.plc.cwintra.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 11 Aug 2005 08:27:16 +0100 Received: from GBCWSWIEM002.ad.plc.cwintra.com ([148.185.93.204]) by GBCWSWIEC002.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 08:27:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Carrier ENUM Date: Thu, 11 Aug 2005 08:27:13 +0100 Message-ID: <9322B78036E1534A99B0BC51DEB0F9D6017256ED@GBCWSWIEM002.ad.plc.cwintra.com> Thread-Topic: Carrier ENUM Thread-Index: AcWeGZasOiJMMQfOQsO1wSBtqAFfBQAJl9DNAAFNc+A= From: "Rosbotham, Paul" To: "Stastny Richard" , "Richard Shockey" , "David Meyer" , X-OriginalArrivalTime: 11 Aug 2005 07:27:14.0264 (UTC) FILETIME=[184EBD80:01C59E46] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >This=20is=20clear=20for=20geo-graphic=20numbers,=20for >service=20numbers=20there=20is=20some=20additional >discussion=20necessary,=20e.g.=20800=20numbers >or=20corporate=20numbers=20can=20(e.g.=20in=20Austria)=20assigened=20from= >the=20regulator=20either=20via=20a=20"Carrier"=20or=20DIRECTLY=20 >to=20the=20End-user,=20e.g.=20an=20enterprise=20To=20use=20these >numbers=20on=20the=20PSTN=20,=20the=20enterprise=20needs=20to=20find >a=20carrier=20hosting=20these=20numbers. Richard, This=20is=20probably=20a=20naive=20answer,=20but=20haven't=20you=20answere= d=20your=20own=20question=20here?=20=20Regardless=20of=20the=20number=20be= ing=20assigned=20directly=20to=20the=20enterprise,=20they=20still=20need=20= to=20contract=20with=20a=20carrier=20for=20it=20to=20work=20on=20the=20pub= lic=20telephony=20network.=20=20Shouldn't=20it=20then=20be=20that=20carrie= r=20which=20is=20publishing=20location=20information=20in=20carrier-ENUM=20= for=20other=20carriers=20to=20act=20upon? *Within=20E.164*=20(ie=20excluding=20short=20codes=20etc)=20I'm=20only=20a= ware=20of=20one=20class=20of=20number=20that=20can=20be=20served=20by=20mu= ltiple=20carriers,=20and=20that's=20Universal=20International=20Freephone=20= Numbers=20(UIFNs,=20+800)....and=20even=20in=20this=20case=20I'm=20not=20a= ware=20of=20(m)any=20customers=20actually=20using=20the=20facility.=20[Bac= kground,=20the=20idea=20was=20that=20a=20multinational=20could=20use=20e.g= .=20a=20Japanese=20carrier=20for=20+800=20calls=20originated=20from=20Asia= ,=20French=20for=20calls=20originated=20from=20Europe,=20Canadian=20from=20= the=20Americas=20etc]=20=20Therefore,=20for=20the=20vast=20majority=20of=20= numbers=20there's=20only=20one=20carrier=20of=20record. Cheers Paul _______________________________________________ enum=20mailing=20list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20=20visit=20http://www.cw.com/uk/emailprotection/=20 =20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 08:28:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CAb-0004pq-TI; Thu, 11 Aug 2005 08:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CAa-0004ph-11 for enum@megatron.ietf.org; Thu, 11 Aug 2005 08:28:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27188 for ; Thu, 11 Aug 2005 08:28:22 -0400 (EDT) Received: from mmtest1.michael.terraluna.org ([64.71.149.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Ciq-0003Di-EP for enum@ietf.org; Thu, 11 Aug 2005 09:03:51 -0400 Received: from c-24-98-171-50.hsd1.ga.comcast.net ([::ffff:24.98.171.50]) (AUTH: PLAIN michael, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mmtest1.michael.terraluna.org with esmtp; Thu, 11 Aug 2005 12:28:02 +0000 id 001405A7.42FB4453.00001CAF From: Michael Mealling To: enum@ietf.org Date: Thu, 11 Aug 2005 08:28:01 -0400 Message-Id: <1123763281.22740.3.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.2.2 (2.2.2-5) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Enum] Now that carrier enum is seperate, will user enum ever be deployed? X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Apologies for missing the discussion but after reading draft-haberler-carrier-enum I'm curious whether the discussion got to whether or not this would cause user enum to never be deployed in any useful level? It would seem that by seperating the two the pressure is off of the carriers to implement the rest of the tree? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 08:56:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Cbl-0001up-2z; Thu, 11 Aug 2005 08:56:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Cbd-0001uV-TF for enum@megatron.ietf.org; Thu, 11 Aug 2005 08:56:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28944 for ; Thu, 11 Aug 2005 08:56:18 -0400 (EDT) Received: from sip.mah.priv.at ([81.223.16.194] helo=www.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3D9s-0003uP-8f for enum@ietf.org; Thu, 11 Aug 2005 09:31:47 -0400 Received: from localhost ([127.0.0.1] helo=mah9.inode.at) by www.mah.priv.at with esmtp (Exim 3.36 #1 (Debian)) id 1E3CbB-00042i-00; Thu, 11 Aug 2005 14:55:53 +0200 Message-Id: <6.2.1.2.2.20050811144834.0532fc00@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 11 Aug 2005 14:55:51 +0200 To: Michael Mealling , enum@ietf.org From: Michael Haberler Subject: Re: [Enum] Now that carrier enum is seperate, will user enum ever be deployed? In-Reply-To: <1123763281.22740.3.camel@blackdell.neonym.net> References: <1123763281.22740.3.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3D911274 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 14:28 11.08.2005, Michael Mealling wrote: >Apologies for missing the discussion but after reading >draft-haberler-carrier-enum I'm curious whether the discussion got to >whether or not this would cause user enum to never be deployed in any >useful level? at least we do not intend to do that for +43 - both are useful and serve different purposes I would conjecture other folks share that thinking (speak up!) >It would seem that by seperating the two the pressure is >off of the carriers to implement the rest of the tree? Unfortunately I fail to detect any significant "pressure on carriers to implement User ENUM" in the first place, which is part of the problem - my perception is anything from remote interest to blissful ignorance What I do see is demand for "Carrier" ENUM which will help to get e164.arpa delegations in place, registries going, and thus serve both purposes. I would assume if a country or NPA decides to get going, eventually both trees will be available. -Michael _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 09:06:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Cl5-0003aI-5i; Thu, 11 Aug 2005 09:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Ckz-0003Wy-9O for enum@megatron.ietf.org; Thu, 11 Aug 2005 09:06:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29669 for ; Thu, 11 Aug 2005 09:05:59 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3DJH-0004C5-Vu for enum@ietf.org; Thu, 11 Aug 2005 09:41:29 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 1C8B26D56F; Thu, 11 Aug 2005 14:01:45 +0100 (BST) In-Reply-To: <1123763281.22740.3.camel@blackdell.neonym.net> References: <1123763281.22740.3.camel@blackdell.neonym.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Now that carrier enum is seperate, will user enum ever be deployed? Date: Thu, 11 Aug 2005 14:05:15 +0100 To: Michael Mealling X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Michael, good to see your posting. Another (converse) view is that: - an "enlightened" originating provider might want to try both to see if they can find an IP termination to save on termination charges. - some providers rather like getting termination charges, and are not enthusiastic about publishing SIP URLs so that other providers can avoid paying (or seeing ENUM . If the end user/registrant publishes a reachable SIP URL, then their terminating provider may not need to be enthusiastic/aware/involved/... From the end user/registrant perspective, it could be like having a LoCall/Free phone number (if there are enough "enlightened" providers. That's the question. Given that a certain carrier spent over 10 years noticing that some competitor-originated calls were (allegedly) taking "non-optimal" routes across the US, you might think that every carrier would jump at the chance of saving call costs, but I couldn't possibly comment. all the best, Lawrence On 11 Aug 2005, at 13:28, Michael Mealling wrote: > Apologies for missing the discussion but after reading > draft-haberler-carrier-enum I'm curious whether the discussion got to > whether or not this would cause user enum to never be deployed in any > useful level? It would seem that by seperating the two the pressure is > off of the carriers to implement the rest of the tree? > > -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 11 12:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GNs-0007sn-0g; Thu, 11 Aug 2005 12:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GNq-0007si-L2 for enum@megatron.ietf.org; Thu, 11 Aug 2005 12:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13752 for ; Thu, 11 Aug 2005 12:58:20 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E3Gvz-00021e-9M for enum@ietf.org; Thu, 11 Aug 2005 13:33:40 -0400 Content-class: urn:content-classes:message Subject: Re: [Enum] Now that carrier enum is seperate, will user enum ever be deployed? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2005 18:57:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0AE@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Now that carrier enum is seperate, will user enum ever be deployed? Thread-Index: AcWecMZt4QEDNCFbRJWWMA4fcXwljwAJPFLc From: "Stastny Richard" To: "Michael Mealling" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > It would seem that by seperating the two the pressure is >off of the carriers to implement the rest of the tree? This was the basic problem with User ENUM in the first place: there is no pressure for the carrier to implement User ENUM at all User ENUM is regulator and End-User opt-in, the carreirs have no say whatsoever in User ENUM Now we have two options and we will see what will be deployed. It is still the end-user who decides: Does he use User ENUM or leave it to the carrier to deploy Carreir ENUM. A smart carrier may offer their useres to query both. -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Michael Mealling Gesendet: Do 11.08.2005 14:28 An: enum@ietf.org Betreff: [Enum] Now that carrier enum is seperate,will user enum ever be = deployed? Apologies for missing the discussion but after reading draft-haberler-carrier-enum I'm curious whether the discussion got to whether or not this would cause user enum to never be deployed in any useful level? It would seem that by seperating the two the pressure is off of the carriers to implement the rest of the tree? -MM _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 12 11:14:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bEh-0003xZ-4E; Fri, 12 Aug 2005 11:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bEf-0003xU-S5 for enum@megatron.ietf.org; Fri, 12 Aug 2005 11:14:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00228 for ; Fri, 12 Aug 2005 11:14:14 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E3bn7-0004I4-6A for enum@ietf.org; Fri, 12 Aug 2005 11:49:59 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1123859499!4163211!57 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 19215 invoked from network); 12 Aug 2005 15:14:01 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-9.tower-121.messagelabs.com with SMTP; 12 Aug 2005 15:14:01 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 42EFDDE1005A0DD2; Fri, 12 Aug 2005 11:14:00 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Now that carrier enum is seperate, will user enumever be deployed? Date: Fri, 12 Aug 2005 11:13:59 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ADC66C3@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] Now that carrier enum is seperate, will user enumever be deployed? Thread-Index: AcWedGeQpOUzw7VZRJKsN6hRdAkneAA2tVLw From: "Pfautz, Penn L, NEO" To: "Michael Haberler" , "Michael Mealling" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I'll second Michael's Haberler's view - carrier ENUM may be what jumpstarts user ENUM, at least in the US. No end user ENUM trial has shown strong demand, and interestingly, Scott Bradner said at the ENUM Summit that he never expected ENUM to take off quickly. Carriers (and some vendors) have been doing the work to get ENUM delegations and registries in place but it's folly to think that will continue unless it works for them too. I'd like to see the two flavors linked somehow under e164.arpa and am cautiously optimistic, but we'll see... Penn -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Michael Haberler Sent: Thursday, August 11, 2005 8:56 AM To: Michael Mealling; enum@ietf.org Subject: Re: [Enum] Now that carrier enum is seperate, will user enumever be deployed? At 14:28 11.08.2005, Michael Mealling wrote: >Apologies for missing the discussion but after reading >draft-haberler-carrier-enum I'm curious whether the discussion got to >whether or not this would cause user enum to never be deployed in any >useful level? at least we do not intend to do that for +43 - both are useful and serve different purposes I would conjecture other folks share that thinking (speak up!) >It would seem that by seperating the two the pressure is >off of the carriers to implement the rest of the tree? Unfortunately I fail to detect any significant "pressure on carriers to=20 implement User ENUM" in the first place, which is part of the problem - my=20 perception is anything from remote interest to blissful ignorance What I do see is demand for "Carrier" ENUM which will help to get e164.arpa=20 delegations in place, registries going, and thus serve both purposes. I=20 would assume if a country or NPA decides to get going, eventually both=20 trees will be available. -Michael=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 17 12:11:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QVN-0005tX-7F; Wed, 17 Aug 2005 12:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QVL-0005sd-Py; Wed, 17 Aug 2005 12:11:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09275; Wed, 17 Aug 2005 12:11:00 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5R4u-00042l-OJ; Wed, 17 Aug 2005 12:47:49 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 17 Aug 2005 18:14:35 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0C8@oefeg-s04.oefeg.loc> Thread-Topic: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWi8omYd0Dbj5pSQ5adTC79WMsofQATF6fh From: "Stastny Richard" To: "Jonathan Rosenberg" , "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, enum@ietf.org Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I fully agree that there seems to be an issue here, because the problem is currently discussed at voipeer also.The format sip:+1-232-555-1234@foo.com;user=3Dphone=20 gets very important especially for Carrier ENUM indicating the destination providers (see below) =20 It also concerns the CLI and CLIR aspect not yet fully discussed in voipeer. This is one issue definitely in scope of voipeer. comments inline=20 =20 Jonathan wrote: >I'll reply to some of the technical comments inline, but I want to step >back a second here. >All of this discussion is making it clear that there is a MUCH bigger >mess here that needs attention, around phone number usage, >interpretation and equivalence across tel and SIP URI. This is a common >source of interop problems in the wild and it makes sense to address = it. I fully agree. At voipeer the question is raised what format to use if E.164 or phone numbers in general are to be transmitted between = peers. also in the to: field >However, the problem at hand is to complete the common policy document, >and it seems to me a mistake to hold up common policy until that mess = is >sorted out. Furthermore, I would argue that the common policy spec is >not the place where that mess should be sorted out. Could this be done in voipeer ? Or at least partially The problem is that only a special aspect of the semantic of the usage of these URIs is under discussion; namely the usage for signalling >My suggestion therefore is to keep the "id" attribute as an NAI form, >and make sure common policy is extensible to allow other ways of >representing identities in the future. We then declare phone numbers = out >of scope for this version of common policy, finish that spec, sort out >the tel/sip uri mess, and when thats done, we can issue an extension to >common policy that adds phone number support. >more inline. >Paul Kyzivat wrote: >> >> Aki Niemi wrote: >> >>> Hi Paul, >> >>> ext Paul Kyzivat wrote: >>> >>>> Then what do you do with sip:+1-232-555-1234@foo.com;user=3Dphone ? >>>> >>>> I don't think you can convert it to: >>>> >>>> 4.3.2.1.5.5.5.2.3.2.1.foo.com >>>> >>>> and if you could then it it wouldn't match the e164.arpa form. >>> >>> No you can't >>> >>> Well, 'sip:+1-232-555-1234@foo.com;user=3Dphone' is indeed a tricky >>> identity to put into a From header in the first place. I'm not sure = it >>> is a telephone number at all. Why wouldn't the From include a tel = URL? This is an interesting point I have not considered yet. Thinking about it, I would prefer a tel URI in this case. This is IMHO an issue where voipeer could make a BCP. >> >> >> Personally, I generally think it should. However I have run into many >> people who don't seem to believe in tel URIs, and always use the sip >> form. I would like to convince them of the error in their ways, but = no >> luck so far. If one uses the sip URI, it has to be defined what the foo.bar is: Is it the domain of the originating service provider or the domain of the provious hop, being modified each time? >I think the problem is that we've not made it clear what the semantic >differences really are. >> >> The other case is when I really, definitely, only want to be = contacted >> via SIP. In this case you should use a SIP alias and not a phone number, because sip:+1-232-555-1234@foo.com;user=3Dphone is the equivalent to a phone number >> >>> I suppose that matching a SIP URI converted from a tel URL will be a >>> problem regardless of the way in which we choose to represent them = in >>> common policy. I do not think so. Especially if you use global numbers (E.164 numbers) only you can map back and forth as much as you like, done properly, it should always be the same number. >> > >> I am relaxing my theoretical objections in favor of pragmatism, and >> suggesting that for purposes of determining what authorization policy = to >> apply it will be ok to treat this as a phone number. >Stepping back for a sec, I think there are real differences between the >tel URI and the sip version. The way to think about it is that the tel >URI is a NAME, and you need to think of it as if it were a URN. A SIP >URI is an address. Procedures like enum allow the resolution of a name >to an address. Hmm. We should not go down this path ;-? This is not so simple:=20 This is also a terminology problem between differnent standard bodies A phone number could also be a name and an address, In ITU and ETSI terms a sip AoR or email address is also a name. Only an IP-address is an address. Also with SIP URIs you may have: A. A SIP AoR, which is a name B. A SIP Contact Address, which is either a name or an (IP) address C: A SIP URI with parm user=3Dphone, which is a phone number (a name?) D. A GRUU, which is ? >As such, it really makes no sense to compare a name and an address. = Just >because I work at 600 Lanidex Plaza in Parsippany, does that make >"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza, >Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel >URI and SIP URL are NEVER equivalent; you need to convert the name to = an >address for comparison. I cannot fully follow this argument: Lets try it in another way. There is other usages for URIs A. You put it on a webpage to be clicked on: In this case you would either use a plain tel URI to indicate a phone = number or a sip URI in the format sip:userID@foo.bar to indicate rachability = via sip In the first case the client linked to the tel URI may even chose to use = a dialler in the second case it wold indicate to use a sip-client. If you use sip:+1-232-555-1234@foo.com;user=3Dphone , this would indicate also to = use the sip client? B: in ENUM. (now we are finallyat the point ;-) If one queries ENUM for the phone number +1-232-555-1234 it would be completely useless to get back the same=20 number in tel:+1-232-555-1234 we need here sip:+1-232-555-1234@foo.com;user=3Dphone with the same number to indicate the foo.com domain of the carrier This is basically the essential information Of course one could also put in sip:userID@foo.com, but only in User ENUM, in Carrier ENUM this will not be possible for privacy = reasons. C: the nect, yet undicided question is what you use in case B within = signalling now in the to field: the tel URI or the sip URI returned by ENUM. Current practice here is to use the SIP URI. >Givne this, the meaning of sip:@domain;user=3Dphone means >that the domain is asserting ownership of the identity in the user = part, >in this case a global phone number. As such, its appropriate to use = this >form only when it is authoritatively known that the domain in question >"owns" that phone number. This is a very interesting aspect, leading to the CLI and CLIR problem not yet discussed fully in voipeer. The CLI problem is IMHO definitely in scope of voipeer. CLI is required for call-back (especially if gatewaying to the PSTN), for MCI to = emergency services and also requires CLIR support for anonymous calls. >-Jonathan R. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 17 14:02:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SFT-0005P0-AQ; Wed, 17 Aug 2005 14:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5SFQ-0005OS-UY; Wed, 17 Aug 2005 14:02:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14905; Wed, 17 Aug 2005 14:02:43 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5Soy-00075g-F4; Wed, 17 Aug 2005 14:39:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 17 Aug 2005 20:06:06 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0CB@oefeg-s04.oefeg.loc> Thread-Topic: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWjS71ElbBToYs9SmC1wyvLKQaqhwAAnOMt From: "Stastny Richard" To: "James M. Polk" , "Jonathan Rosenberg" , "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, enum@ietf.org Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org James wrote: >So, and perhaps this is a naive point/question -=20 yes ;-) =20 >what happens when a >carrier no longer operates a phone number that is in operation by = another >carrier? You mean, what happens if you port a phone number from one = cariier-of-record to another? This is exactly what Carreir ENUM is for. >For example, my wife has had the same cell phone number for 15+ years, = yet >she has recently changed to her third carrier. The company that = originally >owned her phone number is being acquired by a 4th company now (here in = the >US, giving you a hint as to two of the players involved). >What does this do to your statement: > "The format sip:+1-232-555-1234@foo.com;user=3Dphone >gets very important especially for Carrier ENUM indicating >the destination providers" sip:+1-232-555-1234@foo.com;user=3Dphone has to be changed to sip:+1-232-555-1234@bar.com;user=3Dphone to indicate the new carrier-of-record -richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 02:07:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5dYm-000338-G1; Thu, 18 Aug 2005 02:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5dYk-00032y-GZ; Thu, 18 Aug 2005 02:07:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06549; Thu, 18 Aug 2005 02:07:22 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5e8N-0004Yo-UA; Thu, 18 Aug 2005 02:44:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2005 23:07:13 -0700 X-IronPort-AV: i="3.96,120,1122879600"; d="scan'208"; a="333275044:sNHT34289368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7I66t0T028385; Wed, 17 Aug 2005 23:07:09 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 02:07:04 -0400 Received: from [192.168.1.100] ([10.86.242.6]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 02:07:03 -0400 Message-ID: <4303FAB8.4000807@cisco.com> Date: Wed, 17 Aug 2005 23:04:24 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D4613C0C8@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0C8@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2005 06:07:03.0592 (UTC) FILETIME=[0DD0B280:01C5A3BB] X-Spam-Score: 0.7 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Paul Kyzivat , enum@ietf.org Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org inline. Stastny Richard wrote: >>All of this discussion is making it clear that there is a MUCH bigger >>mess here that needs attention, around phone number usage, >>interpretation and equivalence across tel and SIP URI. This is a common >>source of interop problems in the wild and it makes sense to address it. > > > I fully agree. At voipeer the question is raised what format to use > if E.164 or phone numbers in general are to be transmitted between peers. > also in the to: field I see this probably as having little to do with peering. Its a problem in general for SIP, and confusion on the interpretation exists between clients and there proxies, proxies and proxies, and so on. > > >>However, the problem at hand is to complete the common policy document, >>and it seems to me a mistake to hold up common policy until that mess is >>sorted out. Furthermore, I would argue that the common policy spec is >>not the place where that mess should be sorted out. > > > Could this be done in voipeer ? Or at least partially > The problem is that only a special aspect of the semantic > of the usage of these URIs is under discussion; > namely the usage for signalling Per above, I think that is a mistake. Sorting out the differences between tel URI, SIP uri with and without user=phone, and so on, are general sip problems. >>Stepping back for a sec, I think there are real differences between the >>tel URI and the sip version. The way to think about it is that the tel >>URI is a NAME, and you need to think of it as if it were a URN. A SIP >>URI is an address. Procedures like enum allow the resolution of a name >>to an address. > > > Hmm. We should not go down this path ;-? This is not so simple: > This is also a terminology problem between differnent standard bodies > > A phone number could also be a name and an address, In ITU and > ETSI terms a sip AoR or email address is also a name. Only an IP-address > is an address. There are addresses at all layers in the stack. We have IP addresses, but also MAC addresses. You translate from one to the other. Something is an address when it identifies an object by its location. In that sense, the SIP URI is fundamentally an address, in that the presence of the domain part indicates that we are identifying something by its location. > > Also with SIP URIs you may have: > > A. A SIP AoR, which is a name > B. A SIP Contact Address, which is either a name or an (IP) address > C: A SIP URI with parm user=phone, which is a phone number (a name?) > D. A GRUU, which is ? Actually based on the definitions above, all are addresses, even an AoR. After all, the A in AoR stands for "address". > > >>As such, it really makes no sense to compare a name and an address. Just >>because I work at 600 Lanidex Plaza in Parsippany, does that make >>"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza, >>Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel >>URI and SIP URL are NEVER equivalent; you need to convert the name to an >>address for comparison. > > > I cannot fully follow this argument: > > Lets try it in another way. There is other usages for URIs > > A. You put it on a webpage to be clicked on: > In this case you would either use a plain tel URI to indicate a phone number > or a sip URI in the format sip:userID@foo.bar to indicate rachability via sip > In the first case the client linked to the tel URI may even chose to use a dialler > in the second case it wold indicate to use a sip-client. If you use > sip:+1-232-555-1234@foo.com;user=phone , this would indicate also to use > the sip client? The usage of a URI for different applications is quite separate from whehter a URI represents a name or an address, and separate still from equality rules for these things. My point is that I think it makes sense to consider the tel URI a URN, and that it is merely an accident of history that it wasn't a URN more properly. Now, as you and I both know phone numbers in the PSTN are abused to represent lots of things, but there is no reason to carry forward this confusion into voip. This is why I am proposing that when a phone number is in a tel URI, it represents a name. We don't know where it is on the network (indeed even if its on an IP network). To know that, we translate to an address. That address is a SIP URI. That SIP URI can contain a phone number, i.e. sip:+19739525000@provider.net;user=phone, however in this format the phone number has been resolved to an address. The act of porting a number is a change in the translation of the phone number as a name (the tel URI) to the phone number as an address (the SIP URI). > > B: in ENUM. (now we are finallyat the point ;-) > If one queries ENUM for the phone number +1-232-555-1234 > it would be completely useless to get back the same > number in tel:+1-232-555-1234 Agree. My point is exactly this; had tel URI been a URN proper, than enum would exactly be the resolution service for resolving that URN scheme to a SIP URI. > > we need here sip:+1-232-555-1234@foo.com;user=phone with > the same number to indicate the foo.com domain of the carrier > This is basically the essential information Right, and this is an address. >>Givne this, the meaning of sip:@domain;user=phone means >>that the domain is asserting ownership of the identity in the user part, >>in this case a global phone number. As such, its appropriate to use this >>form only when it is authoritatively known that the domain in question >>"owns" that phone number. > > > This is a very interesting aspect, leading to the CLI and CLIR problem > not yet discussed fully in voipeer. I don't follow what you are talking about here. > > The CLI problem is IMHO definitely in scope of voipeer. CLI is required > for call-back (especially if gatewaying to the PSTN), for MCI to emergency services > and also requires CLIR support for anonymous calls. We have numerous specs covering conveyance and assertion of identities. See in particular draft-rosenberg-sip-identity-privacy which talks about how to properly support anonymous calling with draft-ietf-sip-identity. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 06:33:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hiT-000145-Pc; Thu, 18 Aug 2005 06:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hiR-000138-9n; Thu, 18 Aug 2005 06:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25048; Thu, 18 Aug 2005 06:33:40 -0400 (EDT) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5iI5-0003mp-6F; Thu, 18 Aug 2005 07:10:38 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 80AC01A3A5; Thu, 18 Aug 2005 12:33:17 +0200 (CEST) Date: Thu, 18 Aug 2005 12:33:17 +0200 From: Otmar Lendl To: voipeer@lists.uoregon.edu, geopriv@ietf.org, enum@ietf.org Message-ID: <20050818103317.GA26663@nic.at> Mail-Followup-To: Otmar Lendl , voipeer@lists.uoregon.edu, geopriv@ietf.org, enum@ietf.org References: <32755D354E6B65498C3BD9FD496C7D4613C0C8@oefeg-s04.oefeg.loc> <4303FAB8.4000807@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4303FAB8.4000807@cisco.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org On 2005/08/18 05:08, Jonathan Rosenberg wrote: > > My point is that I think it makes sense to consider the tel URI a URN, > and that it is merely an accident of history that it wasn't a URN more > properly. Now, as you and I both know phone numbers in the PSTN are > abused to represent lots of things, but there is no reason to carry > forward this confusion into voip. This is why I am proposing that when a > phone number is in a tel URI, it represents a name. We don't know where > it is on the network (indeed even if its on an IP network). To know > that, we translate to an address. That address is a SIP URI. That SIP > URI can contain a phone number, i.e. > sip:+19739525000@provider.net;user=phone, however in this format the > phone number has been resolved to an address. The act of porting a > number is a change in the translation of the phone number as a name (the > tel URI) to the phone number as an address (the SIP URI). > This is a very sensible notion. Based on this thinking the dialing of a number on a VoIP-phone goes through the following conceptual stages: 1) User enters a (potentially partial) number on his phone. The phone appends its default domain and sends the invite to its proxy: e.g. sip:5056416@my-voip-provider.at 2) The SIP proxy applies the local dialplan to translate the SIP address to an E.164 number: e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 -> We now have a URN: tel:+4315056416 3) The SIP proxy now tries to route the call. In this example, user ENUM finds: "E2U+sip" "!^.*$!sip:office@enum.at!" or it could map to the local PSTN gateway with an URI like sip:+4315056416@AS5300.my-voip-provider.at /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 08:39:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jgF-0006OC-TX; Thu, 18 Aug 2005 08:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jgD-0006MT-Sp; Thu, 18 Aug 2005 08:39:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01494; Thu, 18 Aug 2005 08:39:32 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5kFx-0007Wm-0U; Thu, 18 Aug 2005 09:16:30 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 18 Aug 2005 14:42:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B20B7@oefeg-s04.oefeg.loc> Thread-Topic: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWju5q+x7tvwvxQSdG0wpybahHOpAANHxRA From: "Stastny Richard" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Paul Kyzivat , enum@ietf.org Subject: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jonathan wrote:=20 > > > > we need here sip:+1-232-555-1234@foo.com;user=3Dphone with > > the same number to indicate the foo.com domain of the carrier > > This is basically the essential information >=20 > Right, and this is an address. Ok, let's say it is an address (in IETF terminology) Just for avoidance of doubt: A construct like sip:+1-232-555-1234@foo.com;user=3Dphone does NOT indicate that foo.com is necessarily the=20 carrier-of-record hosting the E.164 number. Therefor your next statement does not hold for the to-field (it may be true for the from field) =20 > >>Given this, the meaning of sip:@domain;user=3Dphone means > >>that the domain is asserting ownership of the identity in the user part, > >>in this case a global phone number. As such, its appropriate to use this > >>form only when it is authoritatively known that the domain in question > >>"owns" that phone number. Examples: this URI may be used to send a request from a UA to his proxy in which case foo.com in most case does not have the ownership, it is just indicating the digit dialled. It is also used to send an invite to a gateway to the PSTN, etc. >=20 > We have numerous specs covering conveyance and assertion of identities. > See in particular draft-rosenberg-sip-identity-privacy which talks about > how to properly support anonymous calling with draft-ietf-sip-identity. Will do and come back later on the CLI issue. -richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 09:20:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kJe-00087g-2c; Thu, 18 Aug 2005 09:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5R3p-0000tt-5M; Wed, 17 Aug 2005 12:46:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11004; Wed, 17 Aug 2005 12:46:38 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5RdN-00052Q-Uf; Wed, 17 Aug 2005 13:23:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Aug 2005 09:46:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7HGkNQO009470; Wed, 17 Aug 2005 09:46:26 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 09:46:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.89.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 09:46:22 -0700 Message-Id: <4.3.2.7.2.20050817114223.03715ca8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Aug 2005 11:46:21 -0500 To: "Stastny Richard" , "Jonathan Rosenberg" , "Paul Kyzivat" , From: "James M. Polk" In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0C8@oefeg-s04.oefeg.loc > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Aug 2005 16:46:22.0919 (UTC) FILETIME=[3357BD70:01C5A34B] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Thu, 18 Aug 2005 09:20:16 -0400 Cc: geopriv@ietf.org, enum@ietf.org Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: >I fully agree that there seems to be an issue here, >because the problem is currently discussed at voipeer >also.The format sip:+1-232-555-1234@foo.com;user=phone >gets very important especially for Carrier ENUM indicating >the destination providers (see below) So, and perhaps this is a naive point/question - what happens when a carrier no longer operates a phone number that is in operation by another carrier? For example, my wife has had the same cell phone number for 15+ years, yet she has recently changed to her third carrier. The company that originally owned her phone number is being acquired by a 4th company now (here in the US, giving you a hint as to two of the players involved). What does this do to your statement: "The format sip:+1-232-555-1234@foo.com;user=phone gets very important especially for Carrier ENUM indicating the destination providers" > >It also concerns the CLI and CLIR aspect not yet fully discussed >in voipeer. This is one issue definitely in scope of voipeer. > >comments inline > cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 09:36:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kZ0-0003M5-MZ; Thu, 18 Aug 2005 09:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kYz-0003L0-PH; Thu, 18 Aug 2005 09:36:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04342; Thu, 18 Aug 2005 09:36:08 -0400 (EDT) Message-Id: <200508181336.JAA04342@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5l8j-0000iF-Ol; Thu, 18 Aug 2005 10:13:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E5kYh-0000sT-Od; Thu, 18 Aug 2005 08:35:52 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , , , Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Thu, 18 Aug 2005 09:35:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <20050818103317.GA26663@nic.at> Thread-Index: AcWj4MHW01Kqk/2cT5epJHRM/1wudAAGBiRg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org In step 1, if the phone does not do dialplan interpretation, then what the user entered is a dialstring, and not a telephone number. This could be encoded, as you show, as a SIP uri, but might be better encoded as a dialstring, per draft-rosen-iptel-dialstring-02.txt. A tel uri is explicitly NOT used to carry a dialstring. I think it would be better labeled as a dialstring, and not something that could be confused as a telephone number. It remains true that the user-part of sip:5056416@my-voip-provider.at can only be interpreted by the my-voip-provider.at domain, so your flow definitely can work. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 6:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy On 2005/08/18 05:08, Jonathan Rosenberg wrote: > > My point is that I think it makes sense to consider the tel URI a URN, > and that it is merely an accident of history that it wasn't a URN more > properly. Now, as you and I both know phone numbers in the PSTN are > abused to represent lots of things, but there is no reason to carry > forward this confusion into voip. This is why I am proposing that when a > phone number is in a tel URI, it represents a name. We don't know where > it is on the network (indeed even if its on an IP network). To know > that, we translate to an address. That address is a SIP URI. That SIP > URI can contain a phone number, i.e. > sip:+19739525000@provider.net;user=phone, however in this format the > phone number has been resolved to an address. The act of porting a > number is a change in the translation of the phone number as a name (the > tel URI) to the phone number as an address (the SIP URI). > This is a very sensible notion. Based on this thinking the dialing of a number on a VoIP-phone goes through the following conceptual stages: 1) User enters a (potentially partial) number on his phone. The phone appends its default domain and sends the invite to its proxy: e.g. sip:5056416@my-voip-provider.at 2) The SIP proxy applies the local dialplan to translate the SIP address to an E.164 number: e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 -> We now have a URN: tel:+4315056416 3) The SIP proxy now tries to route the call. In this example, user ENUM finds: "E2U+sip" "!^.*$!sip:office@enum.at!" or it could map to the local PSTN gateway with an URI like sip:+4315056416@AS5300.my-voip-provider.at /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 10:16:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lBt-0005Si-5U; Thu, 18 Aug 2005 10:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lBr-0005S8-LF; Thu, 18 Aug 2005 10:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07538; Thu, 18 Aug 2005 10:16:17 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5llc-00022I-HZ; Thu, 18 Aug 2005 10:53:17 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs incommonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 18 Aug 2005 16:19:48 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B20B8@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs incommonpolicy Thread-Index: AcWj4MHW01Kqk/2cT5epJHRM/1wudAAGBiRgAAFy0tA= From: "Stastny Richard" To: "Brian Rosen" , "Otmar Lendl" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I strongly support this, because this would finally end the confusion with dialled digits and=20 phone numbers BTW, Brian, please update=20 draft-rosen-iptel-dialstring-02.txt becauseit is obsolete already. In addition, I would propose then a WGLC So I copy this to the iptel list also Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Thursday, August 18, 2005 3:36 PM > To: 'Otmar Lendl'; voipeer@lists.uoregon.edu; geopriv@ietf.org; > enum@ietf.org > Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs > incommonpolicy >=20 > In step 1, if the phone does not do dialplan interpretation, then what the > user entered is a dialstring, and not a telephone number. This could be > encoded, as you show, as a SIP uri, but might be better encoded as a > dialstring, per draft-rosen-iptel-dialstring-02.txt. A tel uri is > explicitly NOT used to carry a dialstring. >=20 > I think it would be better labeled as a dialstring, and not something that > could be confused as a telephone number. It remains true that the user- > part > of sip:5056416@my-voip-provider.at can only be interpreted by the > my-voip-provider.at domain, so your flow definitely can work. >=20 > Brian >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Otmar Lendl > Sent: Thursday, August 18, 2005 6:33 AM > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in > commonpolicy >=20 > On 2005/08/18 05:08, Jonathan Rosenberg wrote: > > > > My point is that I think it makes sense to consider the tel URI a URN, > > and that it is merely an accident of history that it wasn't a URN more > > properly. Now, as you and I both know phone numbers in the PSTN are > > abused to represent lots of things, but there is no reason to carry > > forward this confusion into voip. This is why I am proposing that when a > > phone number is in a tel URI, it represents a name. We don't know where > > it is on the network (indeed even if its on an IP network). To know > > that, we translate to an address. That address is a SIP URI. That SIP > > URI can contain a phone number, i.e. > > sip:+19739525000@provider.net;user=3Dphone, however in this format = the > > phone number has been resolved to an address. The act of porting a > > number is a change in the translation of the phone number as a name (the > > tel URI) to the phone number as an address (the SIP URI). > > >=20 > This is a very sensible notion. >=20 > Based on this thinking the dialing of a number on a VoIP-phone > goes through the following conceptual stages: >=20 > 1) User enters a (potentially partial) number on his phone. > The phone appends its default domain and sends the invite to its proxy: > e.g. sip:5056416@my-voip-provider.at >=20 > 2) The SIP proxy applies the local dialplan to translate the > SIP address to an E.164 number: >=20 > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > -> We now have a URN: tel:+4315056416 >=20 > 3) The SIP proxy now tries to route the call. In this example, > user ENUM finds: > "E2U+sip" "!^.*$!sip:office@enum.at!" >=20 > or it could map to the local PSTN gateway with an URI like > sip:+4315056416@AS5300.my-voip-provider.at >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 10:39:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lY7-0002sW-3i; Thu, 18 Aug 2005 10:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lY5-0002sR-5h for enum@megatron.ietf.org; Thu, 18 Aug 2005 10:39:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09261 for ; Thu, 18 Aug 2005 10:39:15 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5m7p-0002lS-DY for enum@ietf.org; Thu, 18 Aug 2005 11:16:14 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7IEau208482; Thu, 18 Aug 2005 10:36:56 -0400 (EDT) Received: from [127.0.0.1] (acart095.ca.nortel.com [47.130.17.15]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFTN1JB; Thu, 18 Aug 2005 10:38:45 -0400 Message-ID: <43049D61.20102@nortel.com> Date: Thu, 18 Aug 2005 10:38:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy References: <32755D354E6B65498C3BD9FD496C7D461B20B7@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B20B7@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org You make a good point, that inclusion of a number in an address does not equate to ownership. Effectively, the same telephone number (an identifier) is potentially reachable through many addresses (i.e., many gateway-operating domains) if it is in the PSTN. ENUM has chosen to add the concept of "ownership" to narrow down the range of possibilities ... and has thereby embroiled itself in politics. Stastny Richard wrote: > Jonathan wrote: > >>>we need here sip:+1-232-555-1234@foo.com;user=phone with >>>the same number to indicate the foo.com domain of the carrier >>>This is basically the essential information >> >>Right, and this is an address. > > > Ok, let's say it is an address (in IETF terminology) > > Just for avoidance of doubt: > A construct like sip:+1-232-555-1234@foo.com;user=phone > does NOT indicate that foo.com is necessarily the > carrier-of-record hosting the E.164 number. Therefor > your next statement does not hold for the to-field > (it may be true for the from field) > > >>>>Given this, the meaning of sip:@domain;user=phone > > means > >>>>that the domain is asserting ownership of the identity in the user > > part, > >>>>in this case a global phone number. As such, its appropriate to use > > this > >>>>form only when it is authoritatively known that the domain in > > question > >>>>"owns" that phone number. > > > Examples: this URI may be used to send a request from a UA to his proxy > in which case foo.com in most case does not have the ownership, > it is just indicating the digit dialled. > It is also used to send an invite to a gateway to the PSTN, > etc. > > ... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 10:50:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lix-00068f-8B; Thu, 18 Aug 2005 10:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5liw-00068T-5c for enum@megatron.ietf.org; Thu, 18 Aug 2005 10:50:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10386 for ; Thu, 18 Aug 2005 10:50:27 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5mIb-0003Fy-CW for enum@ietf.org; Thu, 18 Aug 2005 11:27:26 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-131.messagelabs.com!1124376509!7957384!28 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 5054 invoked from network); 18 Aug 2005 14:50:13 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-10.tower-131.messagelabs.com with SMTP; 18 Aug 2005 14:50:13 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 42EFDDE100C08D51; Thu, 18 Aug 2005 10:50:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy Date: Thu, 18 Aug 2005 10:50:10 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0AE68787@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWkAsGhIM6SZCogSTqNsPRdJhqaMQAAN78w From: "Pfautz, Penn L, NEO" To: "Tom-PT Taylor" , "Stastny Richard" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org =20 Tom-PT Taylor wrote... "ENUM has chosen to add=20 the concept of "ownership" to narrow down the range of possibilities ... and has thereby embroiled itself in politics." There is isn't really a choice involved if you ever want to evolve PSTN interconnection. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 11:13:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5m4n-0004AB-73; Thu, 18 Aug 2005 11:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5m4l-00049v-OT; Thu, 18 Aug 2005 11:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11744; Thu, 18 Aug 2005 11:13:01 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5meW-0003yA-Bw; Thu, 18 Aug 2005 11:50:01 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 Aug 2005 08:12:54 -0700 X-IronPort-AV: i="3.96,121,1122879600"; d="scan'208"; a="205934271:sNHT36660702" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7IFC33I026308; Thu, 18 Aug 2005 08:12:50 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 11:12:44 -0400 Received: from [192.168.1.100] ([10.86.242.208]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 11:12:43 -0400 Message-ID: <4304A56A.2010406@cisco.com> Date: Thu, 18 Aug 2005 11:12:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy References: <200508181336.JAA04342@ietf.org> In-Reply-To: <200508181336.JAA04342@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2005 15:12:43.0699 (UTC) FILETIME=[48709030:01C5A407] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, 'Otmar Lendl' , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I agree. There is a two step process, fundamentally: dial string ----> name -----> address The translation steps themselves can be done entirely in the UA, entirely in a proxy, or split. When one step is done in a UA, and the other in a proxy, there is a need to convey the dial string, the name, or the address on the wire (proxy to proxy is the same). The formats here are: 1. dial strings would be represented using Brian's dial string draft, i.e.: sip:@domain;user=dialstring 2. names are represented as tel URI, and is obtained by applying the dial string to the dial plan. 3. addresses are represented as a SIP URI with user=phone, and is obtained by performing enum, or through any other suitable translation service that can convert a name to an address. For example, a provider's databases may definitively say that a particular name is its own, and thus it can convert tel:number to sip:number@provider.com;user=phone In many cases, once a tel URI/name is determined, a provider can't obtain a sip URI for it. All it knows is that the number lives on the PSTN. In that case, it needs to go to a PSTN gateway. How to do this? I would argue further that the PSTN gateway represents a ROUTE to get to somewhere (the pstn) that can resolve the name to an address and route it there (all within the PSTN). In SIP, the way we do routing is via loose routes. So, to send a call to a pstn gateway: INVITE tel:+1973952500 SIP/2.0 Route: sip:@gateway.provider.com The URI in the route header could contain a phone number in the user part, but the resource being identified for the route is not the phone number itself, but a piece of routing and gateway logic, and thus it makes no sense to have user=phone there. BTW, I had mentioned in the enum session while at the mic that I was working on a doc that talked about phone numbers in SIP and the difference between tel and sip URI; that doc basically says the above. -Jonathan R. Brian Rosen wrote: > In step 1, if the phone does not do dialplan interpretation, then what the > user entered is a dialstring, and not a telephone number. This could be > encoded, as you show, as a SIP uri, but might be better encoded as a > dialstring, per draft-rosen-iptel-dialstring-02.txt. A tel uri is > explicitly NOT used to carry a dialstring. > > I think it would be better labeled as a dialstring, and not something that > could be confused as a telephone number. It remains true that the user-part > of sip:5056416@my-voip-provider.at can only be interpreted by the > my-voip-provider.at domain, so your flow definitely can work. > > Brian > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Otmar Lendl > Sent: Thursday, August 18, 2005 6:33 AM > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in > commonpolicy > > On 2005/08/18 05:08, Jonathan Rosenberg wrote: > >>My point is that I think it makes sense to consider the tel URI a URN, >>and that it is merely an accident of history that it wasn't a URN more >>properly. Now, as you and I both know phone numbers in the PSTN are >>abused to represent lots of things, but there is no reason to carry >>forward this confusion into voip. This is why I am proposing that when a >>phone number is in a tel URI, it represents a name. We don't know where >>it is on the network (indeed even if its on an IP network). To know >>that, we translate to an address. That address is a SIP URI. That SIP >>URI can contain a phone number, i.e. >>sip:+19739525000@provider.net;user=phone, however in this format the >>phone number has been resolved to an address. The act of porting a >>number is a change in the translation of the phone number as a name (the >>tel URI) to the phone number as an address (the SIP URI). >> > > > This is a very sensible notion. > > Based on this thinking the dialing of a number on a VoIP-phone > goes through the following conceptual stages: > > 1) User enters a (potentially partial) number on his phone. > The phone appends its default domain and sends the invite to its proxy: > e.g. sip:5056416@my-voip-provider.at > > 2) The SIP proxy applies the local dialplan to translate the > SIP address to an E.164 number: > > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > -> We now have a URN: tel:+4315056416 > > 3) The SIP proxy now tries to route the call. In this example, > user ENUM finds: > "E2U+sip" "!^.*$!sip:office@enum.at!" > > or it could map to the local PSTN gateway with an URI like > sip:+4315056416@AS5300.my-voip-provider.at > > /ol -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 11:58:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mmm-0000SI-GO; Thu, 18 Aug 2005 11:58:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mmi-0000Ne-Nw for enum@megatron.ietf.org; Thu, 18 Aug 2005 11:58:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14051 for ; Thu, 18 Aug 2005 11:58:25 -0400 (EDT) Received: from bay103-dav8.bay103.hotmail.com ([65.54.174.80] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nMS-0005Jd-Cm for enum@ietf.org; Thu, 18 Aug 2005 12:35:26 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Aug 2005 08:58:15 -0700 Message-ID: Received: from 65.54.174.203 by BAY103-DAV8.phx.gbl with DAV; Thu, 18 Aug 2005 15:58:15 +0000 X-Originating-IP: [65.54.174.203] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" To: "'Tom-PT Taylor'" Subject: RE: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy Date: Thu, 18 Aug 2005 08:58:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43049D61.20102@nortel.com> Thread-Index: AcWkAr+F+RHDQR3xTaOE65A9Phd8qwAAP6kg X-OriginalArrivalTime: 18 Aug 2005 15:58:15.0680 (UTC) FILETIME=[A4D3C800:01C5A40D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Tom-PT Taylor > Sent: Thursday, August 18, 2005 7:38 AM > To: Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] RE: [Geopriv] Re: [Simple] tel URIs in common policy > > You make a good point, that inclusion of a number in an address does not > equate to ownership. Effectively, the same telephone number (an > identifier) is potentially reachable through many addresses (i.e., many > gateway-operating domains) if it is in the PSTN. ENUM has chosen to add > the concept of "ownership" to narrow down the range of possibilities ... > and has thereby embroiled itself in politics. Didn't Richard Stastny indicate that the sip number/domain name form is just a source address, for application-layer relays? Only when the sip/tel URI is in a certificate (or an authoritative DNS entry) can it be interpreted as a ownership-grade statement - for secure routing (in the military Internet) or wiretapping/connect-controls (in the civilian Internet). What's the difference between the name form in sip/tel and peter%msn.com@cs.ucl.cs.uk, or peter%123.456.789.123@cs.ucl.ac.uk in the internet mail world (which was just a refinement on the extreme 30 year old UUCP source routing patterns using the modems' phone numbers)? Perhaps folks remember the weird ISO address syntaxes (that some IETF folks used to harry and parry for the unweildiness) such as peter%cs.ucl.ac.uk@ADMD=*;PRMD=AC;O=UCL-CS;OU=something. This was (just) the carrier ENUM form of the routing backbone mail, with internet mapping at the edges of the ADMD=* naming core for optional protocol translation between the application domains. In the mail world, such as that peter address does not indicate who the authoritative DNS owner is, for any of the domains mentioned: its just an application string, resolved by application resolvers. If those resolvers have access to certified names/addresses (by whatever technology), ownership and authority issues can also be resolved - not that this is necessary to deliver facilitate the connect per se, or get the mail body through the relay net. I could have used more modern example than "old" mail - the core/edge naming spaces of the secured class D network applications, where once again its not the form of the address that matters for ownership/security controls. Its an out of bound certified signal that conveys authority, for end-end security policies; or, it's a carrier enum styled (src)-addressing architecture that facilitates hop-by-hop security policy transfer between trusted providers/IP-routers. The main point of the original comment was "politics", of course. And, we have to address the politics headon. We can no longer shroud ourselves in the DARPA mystique: dominating technology to bring US-styled democracy to all, through research and learning, and lots of defense spending on advanced networks. We are no longer the nice guys! We are the instrument of public policy. The politics is now nasty: WE will wiretap, WE will do connect-time interception and WE will do it in 2 years, and it WILL be 99% effective, or YOU will be fined: and IETF members will now OVERTLY standardize the wiretapping-capable (and trap and trace-capable) architecture, this time around: not those "nasty carriers" working deviously in "ISO". As the carrier-based URI architecture has worked in that (horrid, but necessary) regulatory environment, we need to focus on what elements of the broader standards toolkit we need to pick through: maintaining the src-routable name/address form, separating ownership assertions from src routing, and distinguishing DNS registration controls from the DNS data distribution controls. We can argue about names vs addressees, owernship vs name caching, for the millionth time, and the "future" role of an authoritative DNS. But the clock is ticking on the 2 year window. The Carrier ENUM folks WILL deploy a secure naming core (they have no choice under the regulation regime), and the SIP proxy operators WILL be constrained to use it (or a naming core with equivalent effect) - so as to enforce the public policy on end-end connect-time controls. Yes politics is here, in the form of wiretapping regulations on voip connects and sip address registration/management. All that's really changed is now the policy OVERTLY impacts the contents of the public IETF standards. Its no longer a matter for "classified supplements". We might aswell get used to the public policy issues, now forced into the IETF technology politics. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 12:33:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nKU-00044j-5C; Thu, 18 Aug 2005 12:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nKR-00044G-Gu; Thu, 18 Aug 2005 12:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16330; Thu, 18 Aug 2005 12:33:16 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nuC-0006Wp-1a; Thu, 18 Aug 2005 13:10:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2005 09:33:08 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,121,1122879600"; d="scan'208"; a="6452303:sNHT23326872" 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 j7IGWoR1007904; Thu, 18 Aug 2005 12:33:06 -0400 (EDT) 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.211); Thu, 18 Aug 2005 12:33:10 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Date: Thu, 18 Aug 2005 12:32:55 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374C9AA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWj+BZtSyQ8pAjFSVOlvB4djyRgFwAF2Qcw From: "Michael Hammer \(mhammer\)" To: "James Polk \(jmpolk\)" , "Stastny Richard" , "Jonathan Rosenberg \(jdrosen\)" , "Paul Kyzivat \(pkyzivat\)" , X-OriginalArrivalTime: 18 Aug 2005 16:33:10.0469 (UTC) FILETIME=[856B3750:01C5A412] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org James, This seems to be a number portability question. E.164 numbers get assigned by the national authority either directly to the individual or to a carrier. In the individual case, when the number ports from one SIP address to another, it remains "owned" by the individual. In the carrier case (at least in the US as I understand it), the number is assigned to what is known as the donor switch/network/carrier. This is typically the network that "owned" the number before number portability was invented. When a user ports to a new serving switch/network/carrier, the NP database maps the number to a location routing number (LRN). Carrier ENUM does essentially the same thing, it records the current E.164 to SIP URI of Serving Carrier point of interconnect. If the user ports again, the donor network remains the same, while the serving network in ENUM will change. If the user relinquishes the number (cancels service), the number reverts back to the donor network to be assigned to their next new customer. (Not sure if this is same worldwide.) If one carrier buys another carrier, then the numbers owned by the acquired carrier will now belong to the buying carrier. So: Donor 1 =3D ENUM leaf (original carrier moves customer to ENUM) Donor 1 -> Serving 2 =3D ENUM leaf (first port) Donor 1 -> Serving 3 =3D ENUM leaf (second port) Donor 1 -> Serving 4 =3D ENUM leaf (third port) Donor 5 -> Serving 4 =3D ENUM leaf (carrier 5 buys carrier 1) Donor 5 =3D ENUM leaf (customer cancels) Does that make sense? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of James Polk (jmpolk) > Sent: Wednesday, August 17, 2005 12:46 PM > To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul=20 > Kyzivat (pkyzivat); voipeer@lists.uoregon.edu > Cc: geopriv@ietf.org; enum@ietf.org > Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy >=20 > At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: > >I fully agree that there seems to be an issue here, because=20 > the problem=20 > >is currently discussed at voipeer also.The format=20 > >sip:+1-232-555-1234@foo.com;user=3Dphone > >gets very important especially for Carrier ENUM indicating the=20 > >destination providers (see below) >=20 > So, and perhaps this is a naive point/question - what happens=20 > when a carrier no longer operates a phone number that is in=20 > operation by another carrier? >=20 > For example, my wife has had the same cell phone number for=20 > 15+ years, yet she has recently changed to her third carrier.=20 > The company that originally owned her phone number is being=20 > acquired by a 4th company now (here in the US, giving you a=20 > hint as to two of the players involved). >=20 > What does this do to your statement: >=20 > "The format sip:+1-232-555-1234@foo.com;user=3Dphone > gets very important especially for Carrier ENUM indicating=20 > the destination providers" >=20 > > > >It also concerns the CLI and CLIR aspect not yet fully discussed in=20 > >voipeer. This is one issue definitely in scope of voipeer. > > > >comments inline > > >=20 >=20 > cheers, > James >=20 > ******************* > Truth is not to be argued... it is to be presented. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 12:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nQp-0006hJ-59; Thu, 18 Aug 2005 12:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nQm-0006hB-Vo; Thu, 18 Aug 2005 12:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16786; Thu, 18 Aug 2005 12:39:50 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5o0Z-0006lV-9L; Thu, 18 Aug 2005 13:16:51 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2005 09:39:43 -0700 X-IronPort-AV: i="3.96,121,1122879600"; d="scan'208"; a="333464422:sNHT34964028" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7IGdboq013958; Thu, 18 Aug 2005 09:39:40 -0700 (PDT) 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.211); Thu, 18 Aug 2005 12:39:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Date: Thu, 18 Aug 2005 12:39:36 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374C9AF@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWj+BZtSyQ8pAjFSVOlvB4djyRgFwAF2QcwAADzQrA= From: "Michael Hammer \(mhammer\)" To: "Michael Hammer \(mhammer\)" , "James Polk \(jmpolk\)" , "Stastny Richard" , "Jonathan Rosenberg \(jdrosen\)" , "Paul Kyzivat \(pkyzivat\)" , X-OriginalArrivalTime: 18 Aug 2005 16:39:37.0122 (UTC) FILETIME=[6BE1C820:01C5A413] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Not sure why Outlook is omitting carriage returns: So: Donor 1 =3D ENUM leaf (original carrier moves customer to ENUM)=20 Donor 1 -> Serving 2 =3D ENUM leaf (first port)=20 Donor 1 -> Serving 3 =3D ENUM leaf (second port)=20 Donor 1 -> Serving 4 =3D ENUM leaf (third port)=20 Donor 5 -> Serving 4 =3D ENUM leaf (carrier 5 buys carrier 1) Donor 5 = =3D ENUM leaf (customer cancels) Does that make sense? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Michael Hammer (mhammer) > Sent: Thursday, August 18, 2005 12:33 PM > To: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg=20 > (jdrosen); Paul Kyzivat (pkyzivat); voipeer@lists.uoregon.edu > Cc: geopriv@ietf.org; enum@ietf.org > Subject: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in=20 > common policy >=20 > James, >=20 > This seems to be a number portability question. E.164=20 > numbers get assigned by the national authority either=20 > directly to the individual or to a carrier. >=20 > In the individual case, when the number ports from one SIP=20 > address to another, it remains "owned" by the individual. >=20 > In the carrier case (at least in the US as I understand it),=20 > the number is assigned to what is known as the donor=20 > switch/network/carrier. This is typically the network that=20 > "owned" the number before number portability was invented. =20 > When a user ports to a new serving switch/network/carrier,=20 > the NP database maps the number to a location routing number=20 > (LRN). Carrier ENUM does essentially the same thing, it=20 > records the current E.164 to SIP URI of Serving Carrier point=20 > of interconnect. >=20 > If the user ports again, the donor network remains the same,=20 > while the serving network in ENUM will change. >=20 > If the user relinquishes the number (cancels service), the=20 > number reverts back to the donor network to be assigned to=20 > their next new customer. (Not sure if this is same worldwide.) >=20 > If one carrier buys another carrier, then the numbers owned=20 > by the acquired carrier will now belong to the buying carrier. >=20 > So: >=20 > Donor 1 =3D ENUM leaf (original carrier moves customer to=20 > ENUM) Donor 1 -> Serving 2 =3D ENUM leaf (first port) Donor 1=20 > -> Serving 3 =3D ENUM leaf (second port) Donor 1 -> Serving 4=20 > =3D ENUM leaf (third port) Donor 5 -> Serving 4 =3D ENUM leaf =20 > (carrier 5 buys carrier 1) Donor 5 =3D ENUM leaf (customer cancels) >=20 > Does that make sense? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]=20 > On Behalf=20 > > Of James Polk (jmpolk) > > Sent: Wednesday, August 17, 2005 12:46 PM > > To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul Kyzivat=20 > > (pkyzivat); voipeer@lists.uoregon.edu > > Cc: geopriv@ietf.org; enum@ietf.org > > Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy > >=20 > > At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: > > >I fully agree that there seems to be an issue here, because > > the problem > > >is currently discussed at voipeer also.The format=20 > > >sip:+1-232-555-1234@foo.com;user=3Dphone > > >gets very important especially for Carrier ENUM indicating the=20 > > >destination providers (see below) > >=20 > > So, and perhaps this is a naive point/question - what=20 > happens when a=20 > > carrier no longer operates a phone number that is in operation by=20 > > another carrier? > >=20 > > For example, my wife has had the same cell phone number for > > 15+ years, yet she has recently changed to her third carrier.=20 > > The company that originally owned her phone number is=20 > being acquired=20 > > by a 4th company now (here in the US, giving you a hint as=20 > to two of=20 > > the players involved). > >=20 > > What does this do to your statement: > >=20 > > "The format sip:+1-232-555-1234@foo.com;user=3Dphone > > gets very important especially for Carrier ENUM indicating the=20 > > destination providers" > >=20 > > > > > >It also concerns the CLI and CLIR aspect not yet fully=20 > discussed in=20 > > >voipeer. This is one issue definitely in scope of voipeer. > > > > > >comments inline > > > > >=20 > >=20 > > cheers, > > James > >=20 > > ******************* > > Truth is not to be argued... it is to be presented. > >=20 > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 15:01:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5peF-0000Il-GH; Thu, 18 Aug 2005 15:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5peD-0000IE-OW; Thu, 18 Aug 2005 15:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23647; Thu, 18 Aug 2005 15:01:52 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5qDz-0002Ig-0f; Thu, 18 Aug 2005 15:38:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 18 Aug 2005 21:05:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0D3@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy Thread-Index: AcWkB9++suo9C9jMTIqCssYGDRyfqQAG9qlB From: "Stastny Richard" To: "Jonathan Rosenberg" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Otmar Lendl , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Jonathan, =20 I think you made a very important point here for a BCP coming out for voipeer: =20 >INVITE tel:+1973952500 SIP/2.0 >Route: sip:@gateway.provider.com =20 instead of the currently used=20 sip:tel:+1973952500 @gateway.provider.com;user=3Dphone =20 I will try to summarize: 1. The user A normally enters a dialstring, which should be signalled with a. = sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1= (luckily there does not exist a global dialling plan, so always a context can be submitted) other examples are: sip:9793321@userA.provider.com;user=3Ddialstring;phone-context=3D+431 or=20 sip:4321@sip.companyA.com;user=3Ddialstring;phone-context=3DcompanyA.com =20 b. only if the user enters a full E.164 number with + (or the device is able to convert this by its own, the signalling should be either with a tel:+4319793321 or with sip:+439793321@userA.provider.com The preferred way should be recommended =20 2. the SIP server of user A provider is now trying to figure out what to do with the dialstring, e.g. using local mapping or translate it to an E.164 number Now the provider either tries to look up ENUM to get a SIP URI or forward the call to a gateway to the PSTN by one of the above proposed methods >INVITE tel:+1973952500 SIP/2.0 >Route: sip:@gateway.provider.com or sip:tel:+1973952500 @gateway.provider.com;user=3Dphone =20 There is only one issue left out: there is more then dialstrings which always have local context and full E.164 numbers it is national numbers and non-E.164 numbers defined in RFC3966 defining the tel: URI =20 These are in my opinion no URN (because they are not unique and also need always a context. =20 It should be recommended that if possible always the global format should be used, the translation to a required national format should be done by the gateway interfacing to the PSTN =20 For signalling non-E.164 numbers some additional investigation seems to be necessary (examples) -richard ________________________________ Von: geopriv-bounces@ietf.org im Auftrag von Jonathan Rosenberg Gesendet: Do 18.08.2005 17:12 An: Brian Rosen Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; 'Otmar Lendl'; = enum@ietf.org Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin = commonpolicy I agree. There is a two step process, fundamentally: dial string ----> name -----> address The translation steps themselves can be done entirely in the UA, entirely in a proxy, or split. When one step is done in a UA, and the other in a proxy, there is a need to convey the dial string, the name, or the address on the wire (proxy to proxy is the same). The formats here are: 1. dial strings would be represented using Brian's dial string draft, = i.e.: sip:@domain;user=3Ddialstring 2. names are represented as tel URI, and is obtained by applying the dial string to the dial plan. 3. addresses are represented as a SIP URI with user=3Dphone, and is obtained by performing enum, or through any other suitable translation service that can convert a name to an address. For example, a provider's databases may definitively say that a particular name is its own, and thus it can convert tel:number to sip:number@provider.com;user=3Dphone In many cases, once a tel URI/name is determined, a provider can't obtain a sip URI for it. All it knows is that the number lives on the PSTN. In that case, it needs to go to a PSTN gateway. How to do this? I would argue further that the PSTN gateway represents a ROUTE to get to somewhere (the pstn) that can resolve the name to an address and route it there (all within the PSTN). In SIP, the way we do routing is via loose routes. So, to send a call to a pstn gateway: INVITE tel:+1973952500 SIP/2.0 Route: sip:@gateway.provider.com The URI in the route header could contain a phone number in the user part, but the resource being identified for the route is not the phone number itself, but a piece of routing and gateway logic, and thus it makes no sense to have user=3Dphone there. BTW, I had mentioned in the enum session while at the mic that I was working on a doc that talked about phone numbers in SIP and the difference between tel and sip URI; that doc basically says the above. -Jonathan R. Brian Rosen wrote: > In step 1, if the phone does not do dialplan interpretation, then what = the > user entered is a dialstring, and not a telephone number. This could = be > encoded, as you show, as a SIP uri, but might be better encoded as a > dialstring, per draft-rosen-iptel-dialstring-02.txt. A tel uri is > explicitly NOT used to carry a dialstring. > > I think it would be better labeled as a dialstring, and not something = that > could be confused as a telephone number. It remains true that the = user-part > of sip:5056416@my-voip-provider.at can only be interpreted by the > my-voip-provider.at domain, so your flow definitely can work. > > Brian > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Otmar Lendl > Sent: Thursday, August 18, 2005 6:33 AM > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in > commonpolicy > > On 2005/08/18 05:08, Jonathan Rosenberg wrote: > >>My point is that I think it makes sense to consider the tel URI a URN, >>and that it is merely an accident of history that it wasn't a URN more >>properly. Now, as you and I both know phone numbers in the PSTN are >>abused to represent lots of things, but there is no reason to carry >>forward this confusion into voip. This is why I am proposing that when = a >>phone number is in a tel URI, it represents a name. We don't know = where >>it is on the network (indeed even if its on an IP network). To know >>that, we translate to an address. That address is a SIP URI. That SIP >>URI can contain a phone number, i.e. >>sip:+19739525000@provider.net;user=3Dphone, however in this format the >>phone number has been resolved to an address. The act of porting a >>number is a change in the translation of the phone number as a name = (the >>tel URI) to the phone number as an address (the SIP URI). >> > > > This is a very sensible notion. > > Based on this thinking the dialing of a number on a VoIP-phone > goes through the following conceptual stages: > > 1) User enters a (potentially partial) number on his phone. > The phone appends its default domain and sends the invite to its = proxy: > e.g. sip:5056416@my-voip-provider.at > > 2) The SIP proxy applies the local dialplan to translate the > SIP address to an E.164 number: > > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > -> We now have a URN: tel:+4315056416 > > 3) The SIP proxy now tries to route the call. In this example, > user ENUM finds: > "E2U+sip" "!^.*$!sip:office@enum.at!" > > or it could map to the local PSTN gateway with an URI like > sip:+4315056416@AS5300.my-voip-provider.at > > /ol -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 15:38:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qDa-0000kp-DV; Thu, 18 Aug 2005 15:38:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qDX-0000k6-RN; Thu, 18 Aug 2005 15:38:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26637; Thu, 18 Aug 2005 15:38:22 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5qnL-0003OS-Ee; Thu, 18 Aug 2005 16:15:24 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 18 Aug 2005 21:37:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0D4@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy Thread-Index: AcWkB9++suo9C9jMTIqCssYGDRyfqQAG9qlBAAImIUY= From: "Stastny Richard" To: "Jonathan Rosenberg" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Otmar Lendl , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Just one add-on before I am getting ahead of myself: regarding: >2. the SIP server of user A provider is now trying >to figure out what to do with the dialstring, e.g. using local mapping >or translate it to an E.164 number >Now the provider either tries to look up ENUM to get a SIP URI ... in this case the ENUM entry will in most cases be sip:+439793321@userA.provider.com;user=3Dphone or even sip:\1@userA.provider.com;user=3Dphone because of privacy reasons -richard ________________________________ Von: owner-voipeer@lists.uoregon.edu im Auftrag von Stastny Richard Gesendet: Do 18.08.2005 21:05 An: Jonathan Rosenberg; Brian Rosen Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl; = enum@ietf.org Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin = commonpolicy Jonathan, I think you made a very important point here for a BCP coming out for voipeer: >INVITE tel:+1973952500 SIP/2.0 >Route: sip:@gateway.provider.com instead of the currently used sip:tel:+1973952500 @gateway.provider.com;user=3Dphone I will try to summarize: 1. The user A normally enters a dialstring, which should be signalled with a. = sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1= (luckily there does not exist a global dialling plan, so always a context can be submitted) other examples are: sip:9793321@userA.provider.com;user=3Ddialstring;phone-context=3D+431 or sip:4321@sip.companyA.com;user=3Ddialstring;phone-context=3DcompanyA.com b. only if the user enters a full E.164 number with + (or the device is able to convert this by its own, the signalling should be either with a tel:+4319793321 or with sip:+439793321@userA.provider.com The preferred way should be recommended 2. the SIP server of user A provider is now trying to figure out what to do with the dialstring, e.g. using local mapping or translate it to an E.164 number Now the provider either tries to look up ENUM to get a SIP URI or forward the call to a gateway to the PSTN by one of the above proposed methods >INVITE tel:+1973952500 SIP/2.0 >Route: sip:@gateway.provider.com or sip:tel:+1973952500 @gateway.provider.com;user=3Dphone There is only one issue left out: there is more then dialstrings which always have local context and full E.164 numbers it is national numbers and non-E.164 numbers defined in RFC3966 defining the tel: URI These are in my opinion no URN (because they are not unique and also need always a context. It should be recommended that if possible always the global format should be used, the translation to a required national format should be done by the gateway interfacing to the PSTN For signalling non-E.164 numbers some additional investigation seems to be necessary (examples) -richard ________________________________ Von: geopriv-bounces@ietf.org im Auftrag von Jonathan Rosenberg Gesendet: Do 18.08.2005 17:12 An: Brian Rosen Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; 'Otmar Lendl'; = enum@ietf.org Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin = commonpolicy I agree. There is a two step process, fundamentally: dial string ----> name -----> address The translation steps themselves can be done entirely in the UA, entirely in a proxy, or split. When one step is done in a UA, and the other in a proxy, there is a need to convey the dial string, the name, or the address on the wire (proxy to proxy is the same). The formats here are: 1. dial strings would be represented using Brian's dial string draft, = i.e.: sip:@domain;user=3Ddialstring 2. names are represented as tel URI, and is obtained by applying the dial string to the dial plan. 3. addresses are represented as a SIP URI with user=3Dphone, and is obtained by performing enum, or through any other suitable translation service that can convert a name to an address. For example, a provider's databases may definitively say that a particular name is its own, and thus it can convert tel:number to sip:number@provider.com;user=3Dphone In many cases, once a tel URI/name is determined, a provider can't obtain a sip URI for it. All it knows is that the number lives on the PSTN. In that case, it needs to go to a PSTN gateway. How to do this? I would argue further that the PSTN gateway represents a ROUTE to get to somewhere (the pstn) that can resolve the name to an address and route it there (all within the PSTN). In SIP, the way we do routing is via loose routes. So, to send a call to a pstn gateway: INVITE tel:+1973952500 SIP/2.0 Route: sip:@gateway.provider.com The URI in the route header could contain a phone number in the user part, but the resource being identified for the route is not the phone number itself, but a piece of routing and gateway logic, and thus it makes no sense to have user=3Dphone there. BTW, I had mentioned in the enum session while at the mic that I was working on a doc that talked about phone numbers in SIP and the difference between tel and sip URI; that doc basically says the above. -Jonathan R. Brian Rosen wrote: > In step 1, if the phone does not do dialplan interpretation, then what = the > user entered is a dialstring, and not a telephone number. This could = be > encoded, as you show, as a SIP uri, but might be better encoded as a > dialstring, per draft-rosen-iptel-dialstring-02.txt. A tel uri is > explicitly NOT used to carry a dialstring. > > I think it would be better labeled as a dialstring, and not something = that > could be confused as a telephone number. It remains true that the = user-part > of sip:5056416@my-voip-provider.at can only be interpreted by the > my-voip-provider.at domain, so your flow definitely can work. > > Brian > > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf = Of > Otmar Lendl > Sent: Thursday, August 18, 2005 6:33 AM > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in > commonpolicy > > On 2005/08/18 05:08, Jonathan Rosenberg wrote: > >>My point is that I think it makes sense to consider the tel URI a URN, >>and that it is merely an accident of history that it wasn't a URN more >>properly. Now, as you and I both know phone numbers in the PSTN are >>abused to represent lots of things, but there is no reason to carry >>forward this confusion into voip. This is why I am proposing that when = a >>phone number is in a tel URI, it represents a name. We don't know = where >>it is on the network (indeed even if its on an IP network). To know >>that, we translate to an address. That address is a SIP URI. That SIP >>URI can contain a phone number, i.e. >>sip:+19739525000@provider.net;user=3Dphone, however in this format the >>phone number has been resolved to an address. The act of porting a >>number is a change in the translation of the phone number as a name = (the >>tel URI) to the phone number as an address (the SIP URI). >> > > > This is a very sensible notion. > > Based on this thinking the dialing of a number on a VoIP-phone > goes through the following conceptual stages: > > 1) User enters a (potentially partial) number on his phone. > The phone appends its default domain and sends the invite to its = proxy: > e.g. sip:5056416@my-voip-provider.at > > 2) The SIP proxy applies the local dialplan to translate the > SIP address to an E.164 number: > > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > -> We now have a URN: tel:+4315056416 > > 3) The SIP proxy now tries to route the call. In this example, > user ENUM finds: > "E2U+sip" "!^.*$!sip:office@enum.at!" > > or it could map to the local PSTN gateway with an URI like > sip:+4315056416@AS5300.my-voip-provider.at > > /ol -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _________________________________________________________________________= ____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 15:58:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qWc-0004yf-7D; Thu, 18 Aug 2005 15:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qWa-0004yN-5I; Thu, 18 Aug 2005 15:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28321; Thu, 18 Aug 2005 15:58:02 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5r6N-0004EV-U7; Thu, 18 Aug 2005 16:35:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2005 12:57:54 -0700 X-IronPort-AV: i="3.96,121,1122879600"; d="scan'208"; a="333549954:sNHT34798940" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7IJvUp6002047; Thu, 18 Aug 2005 12:57:51 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 15:57:43 -0400 Received: from [192.168.1.100] ([10.86.242.208]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 15:57:43 -0400 Message-ID: <4304E836.4090709@cisco.com> Date: Thu, 18 Aug 2005 15:57:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy References: <32755D354E6B65498C3BD9FD496C7D4613C0D3@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0D3@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2005 19:57:43.0327 (UTC) FILETIME=[189CBAF0:01C5A42F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Otmar Lendl , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: > Jonathan, > > I think you made a very important point here for > a BCP coming out for voipeer: Well, I think a BCP is needed, yes. But as I have said, it is a general SIP problem and not specific to the peering problem. > > >>INVITE tel:+1973952500 SIP/2.0 >>Route: sip:@gateway.provider.com > > > instead of the currently used > sip:tel:+1973952500 @gateway.provider.com;user=phone > > I will try to summarize: > > 1. The user A normally enters a dialstring, which > should be signalled with > a. sip:0114319793321@userA.provider.com;user=dialstring;phone-context=+1 > (luckily there does not exist a global dialling plan, so always > a context can be submitted) I must say I don't understand the value of the phone context in the dial string. To me, its completely redundant with the domain in the URI. Furthermore, I don't know how an endpoint would set the context, since the whole problem in the first place is that the endpoint doesn't know how to interpret these digits. > other examples are: > sip:9793321@userA.provider.com;user=dialstring;phone-context=+431 > or > sip:4321@sip.companyA.com;user=dialstring;phone-context=companyA.com I'd personally prefer just sip:@provider.com. > > b. only if the user enters a full E.164 number with + (or the device is > able to convert this by its own, the signalling should be > either with a tel:+4319793321 Yes. > or with sip:+439793321@userA.provider.com > The preferred way should be recommended NO. How can the client KNOW that this number is owned by the domain on the RHS of the @? Firstly, that right hand side is "userA.provider.com", which seems to be some kind of user specific thing. That makes no sense to me; even if the endpoint could determine who owns the number, it wouldn't be "userA.provider.com". > > 2. the SIP server of user A provider is now trying > to figure out what to do with the dialstring, e.g. using local mapping > or translate it to an E.164 number > Now the provider either tries to look up ENUM to get a SIP > URI or forward the call to a gateway to the PSTN > by one of the above proposed methods > > >>INVITE tel:+1973952500 SIP/2.0 >>Route: sip:@gateway.provider.com > > or > sip:tel:+1973952500 @gateway.provider.com;user=phone If the provider can translate the name to a SIP address, the request URI would be sip:@provider.com;user=phone and that would be in the request URI. > > There is only one issue left out: there is more then dialstrings > which always have local context and full E.164 numbers > it is national numbers and non-E.164 numbers defined > in RFC3966 defining the tel: URI Things like 411 are easily handled in this model; there is a dialstring, which is what the user enters: sip:411@provider.net;user=dialstring and this is translated into a URN based on the dial plan: urn:directory-services which is then translated to a SIP address if the directory service is reachable via a SIP address, else goes to a PSTN gateway as above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 16:26:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qyD-0008OQ-M0; Thu, 18 Aug 2005 16:26:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qyC-0008OI-I9; Thu, 18 Aug 2005 16:26:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01771; Thu, 18 Aug 2005 16:26:34 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rY1-0005n6-4i; Thu, 18 Aug 2005 17:03:37 -0400 Received: from Mpierce1@aol.com by imo-m28.mx.aol.com (mail_out_v38_r4.1.) id k.19f.3a1c4ca3 (3850); Thu, 18 Aug 2005 16:26:23 -0400 (EDT) Message-ID: <19f.3a1c4ca3.303648ef@aol.com> Date: Thu, 18 Aug 2005 16:26:23 EDT Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy To: Richard.Stastny@oefeg.at MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0733299983==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0733299983== Content-Type: multipart/alternative; boundary="part1_19f.3a1c4ca3.303648ef_boundary" --part1_19f.3a1c4ca3.303648ef_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/18/2005 3:05:13 PM Eastern Daylight Time, Richard.Stastny@oefeg.at writes: > 1. The user A normally enters a dialstring, which > should be signalled with > a. sip:0114319793321@userA.provider.com;user=dialstring;phone-context=+1 > (luckily there does not exist a global dialling plan, so always > a context can be submitted) > other examples are: > sip:9793321@userA.provider.com;user=dialstring;phone-context=+431 > or > sip:4321@sip.companyA.com;user=dialstring;phone-context=companyA.com > I don't understand this item. A dialstring is exactly that. It's a string of digits that was dialed, but with no meaning. Therefore, there can not be a "context" which implies some knowledge of what the string means (+1 in the above example, which apparently menas that the string is a North American E.164 number, which, incidentally, it is not). I thought this had all been sorted out in the discussion on the tell:uri and again on the sos:uri. Apparently not. I guess we'll go forever with this question: "How does the phone know the dial plan?" and what to do about it when it doesn't. Mike Pierce --part1_19f.3a1c4ca3.303648ef_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 8/18/2005 3:05:13 PM Eastern Daylight Time, Richard.Stastny@oefe= g.at writes:


1. The user A normally enters a= dialstring, which
should be signalled with
a. sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1=
(luckily there does not exist a global dialling plan, so always
a context can be submitted)
other examples are:
sip:9793321@userA.provider.com;user=3Ddialstring;phone-context=3D+431
or
sip:4321@sip.companyA.com;user=3Ddialstring;phone-context=3DcompanyA.com


I don't understand this item. A dialstring is exactly that. It's a string of= digits that was dialed, but with no meaning. Therefore, there can not be a=20= "context" which implies some knowledge of what the string means (+1 in the a= bove example, which apparently menas that the string is a North American E.1= 64 number, which, incidentally, it is not).

I thought this had all been sorted out in the discussion on the tell:uri and= again on the sos:uri. Apparently not. I guess we'll go forever with this qu= estion: "How does the phone know the dial plan?" and what to do about it whe= n it doesn't.

Mike Pierce
 --part1_19f.3a1c4ca3.303648ef_boundary-- --===============0733299983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0733299983==-- From enum-bounces@ietf.org Thu Aug 18 17:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rnV-0004a0-FU; Thu, 18 Aug 2005 17:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rnU-0004Z7-0E for enum@megatron.ietf.org; Thu, 18 Aug 2005 17:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04027 for ; Thu, 18 Aug 2005 17:19:33 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5sNI-00077y-As for enum@ietf.org; Thu, 18 Aug 2005 17:56:37 -0400 Received: from [10.31.13.183] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j7ILJOFg002023 for ; Thu, 18 Aug 2005 21:19:24 GMT Message-ID: <4304FB5B.3080601@neustar.biz> Date: Thu, 18 Aug 2005 17:19:23 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: b4b36b0fb877eeac6f347960137fc10b Subject: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242297470==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0242297470== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit

PLEASE SEMD ME COMMENTS REVISIONS ASAP

IETF 63  Telephone Number Mapping (ENUM) WG Meeting Minutes

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

Transport Area Advisor:
Allison Mankin  <mankin@psg.com>


Friday, August 6 2005  9:AM to 12:30 PM

AGENDA BASHING (5 min)


1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )

Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-02.txt
        Pages           : 29
        Date            : 2005-7-1

This document captures experience in implementing systems based on    the ENUM protocol, and experience of ENUM data that have been created    by others.  As such, it is informational only, and produced as a help    to others in reporting what is "out there" and the potential pitfalls  in interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt

 

WG ACTION :  After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.


2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

WG ACTION : Put this document into WGLC after one more revision by author.

DISCUSSION Some concerns whether this document is mature enough for even WG last call,  response is that the document will see another revision and pushing towards    last call is only meant to spur document forward.

 


3. New/old work on enumservice registrations  ( 20 M )


3.1


        Title           : IANA Registration for Enumservice Voice
        Author(s)       : R. Brandner, et al.
        Filename        : draft-brandner-enum-voice-00.txt
        Pages           : 12
        Date            : 2005-7-7

   This document registers the ENUMservice ^voice^ (which has a defined    sub-type ^tel^), as per the IANA registration process defined in the    ENUM specification RFC3761.  This service indicates that the contact   held in the generated URI can be used to initiate an interactive  voice (audio) call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.

DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.


3.2
        Title           : IANA Registration for an Enumservice  Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8

   This document registers the Enumservice "npd" and subtype "tel" using    the URI scheme 'tel:' as per the IANA registration process defined in   the ENUM specification, RFC 3761.  This data is used to facilitate  the routing of telephone calls in those countries where Number  Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt

 

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 

DISCUSSION :

 

Comments include:
    - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
    - Global Spin Std.
    - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
    - TEL URI scope problem : examples should include both TEL and SIP URI examples
    - For IMS, limited usefulness
    - RFC 3671 db?  1 or collection? (Latter) 

    - Document should discuss sage of portability data as it relates national policy
    -


3.3

  Title           : IANA Registration for ENUMservice Mobile Webpage
  Author(s)       : J. Ra, et al.
  Filename        : draft-ra-shin-enum-mobileweb-00.txt
  Pages           :
  Date            : 2005-7-7

   This document registers the ENUMservice “mobweb” using the URI    schemes 'http:' and 'https:' as per the IANA registration process  defined in the ENUM specification RFC3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt

 

WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.

 

DISCUSSION:
Discussion dove into issue of DNS vs. Application layer indication of  protocol stack capabilities.

    - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
    - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection)
    - HTTP negotiation accomplishes the same once connection is in place
    - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP)
    - RFC 3824, guidelines on SIP and ENUM as reference

   - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.



4. ENUM Validation Issues. 3 Drafts 15 -20

 4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00

        Title           : ENUM Validation Architecture
        Author(s)       : A. Mayrhofer, B. Hoeneisen
        Filename        : draft-mayrhofer-enum-validation-arch-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164   number.  The process of verifying whether or not the Registrant of an  ENUM domain name is identical to the Assignee of the corresponding  E.164 number is commonly called ^validation^.  This document  describes validation requirements and a high level architecture for  an ENUM validation infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt

 


WG ACTION :  WG humm agrees to draft as ENUM WG work item.



4.2  "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt


        Title           : ENUM Validation Token Format Definition
        Author(s)       : O. Lendl
        Filename        : draft-lendl-enum-validation-token-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164  number.  The process of verifying whether the Registrant of an ENUM  domain name is identical to the Assignee of the corresponding E.164  number is commonly called ^validation^.  This document describes an  signed XML data format -- the Validation Token -- with which
 Validation Entities can convey successful completion of a validation  procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 


4.3  Bernie Hoeneisen

  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

 

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 

DISCUSSION: Very little technical discussion of the above 3 documents.



#################

5. PART 2  1/2 hours. 3 Items

WG AGENDA: Terms and Conditions of discussion.

The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand.
 


#################

5.1 Discussion of drafts on Carrier ENUM - Requirements ?

  Title           : Infrastructure ENUM Requirements
        Author(s)       : S. Lind
        Filename        : draft-lind-infrastructure-enum-reqs-00.txt
        Pages           : 8
        Date            : 2005-7-15

 There has been much discussion in various industries about the  concept of infrastructure (or carrier) ENUM. Some of this discussion   has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the  Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus    industry-wide on even what infrastructure ENUM is, why it seems to be  important, or what the requirements for implementing it are.

 At the request of the WG co-chairs, this document attempts to gather   together the bits and pieces from those discussions (i.e., I stole   the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that   will enable enlightened discussion and hopefully achieve consensus.   Some items listed below may be duplicative and suggest alternative    wordings for similar and other contradictory issues. As such, this  list is very raw and should not be viewed as complete, cohesive or  correct.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt

 

WG ACTION:  This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.

Penn Pfautz agrees to collaborate with Steve Lind on future drafts.

5.2  Title           : IANA Carrier/User enumservice Registration
        Author(s)       : P. Pfautz, et al.
        Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
        Pages           : 10
        Date            : 2005-6-6

This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry  to support end user and carrier services with independent name   servers holding the terminal NAPTR (Naming Authority Pointer) records  identifying the communication services for each.  The to-be-  registered enumservices make use of non-terminal NAPTR records and  DDDS (Dynamic Delegation Discovery System) replacement to achieve  this end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt


5.3       Title           : Combined User and Carrier ENUM in the e164.arpa tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-haberler-carrier-enum-00.txt
        Pages           : 10
        Date            : 2005-7-11

   ENUM as defined now in RFC3761 is not well suited for the purpose of    interconnection by carriers, as can be seen by the use of various  private tree arrangements based on ENUM mechanisms.  A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number.  This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt


DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.


  As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant.  Three approaches were mentioned but only two seem "obvious".

   Non-terminal NAPTR records

 Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier.  Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup.

   Separated branches of the DNS tree

   A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or

 

B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.

 

 End users ( number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa.

   Requirements/Desired results
   1) Minimize number of lookups
   2) Retain flexibility
   3) Consistency from CC to CC for predictability

   Discussion

   -  Data in DNS does not guarantee reachability ("deny's" allowed)

   -  DNS MUST answer.
   - Uniformity in "c" label, name and where, is important
   - Non-terminal NAPTRs are untried
   - Questions on whether DNS wildcards are pertinent to the issue
   - Three questions - what's better for 1) DNS, 2) Application, and 3) "life"
   - Should not preclude private carrier-carrier traffic control

WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.

Further Discussion on Next Steps


   - Needs requirements and especially use cases to indicate what it is about

 

WG ACTION: Requirements document added as WG item.
   - RFC 3761 should remain untouched
   - Scope needs definition (stop at re-write rules?)
   - Use cases, use cases, use cases
   - Terminology and definitions needed

 The Chair also asked for a straw poll based on the three approaches on which is preferred “at this time”. 

   4 Options

 

  1. Pfautz approach of use of non-terminal NAPTR’s
  2. Harbler approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa
  3. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa
  4. Using a different (non-e164.arpa) domain

 

Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU.

 

 

Further Discussion:

 

Division of labor with VOIPEER BoF effort required

6.0 Title           : Non-Terminal NAPTR Processing: A Modest Proposal
        Author(s)       : L. Conroy
        Filename        : draft-conroy-enum-modestproposal-00.txt
        Pages           : 12
        Date            : 2005-7-6

  Recent Discussions within the IETF and in other fora have highlighted  differences in interpretation of the set of standards associated with    ENUM and DDDS, on which it relies.  Specifically, the operation and   semantics surrounding support for non-terminal NAPTRs has led to some    confusion.  This document is n attempt to add clarification to non-   terminal NAPTR processing.  In this, it clarifies RFC3403.  A    subsequent document will build on this one to extend FC3761 further,    permitting registration of non-terminal Enumservices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt

WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.

 

Meeting Concludes.


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0242297470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0242297470==-- From enum-bounces@ietf.org Thu Aug 18 17:44:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sBy-0002gY-VZ; Thu, 18 Aug 2005 17:44:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sBx-0002g1-43; Thu, 18 Aug 2005 17:44:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04989; Thu, 18 Aug 2005 17:44:50 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5sll-0007mq-BU; Thu, 18 Aug 2005 18:21:54 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 18 Aug 2005 23:48:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0D5@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsin commonpolicy Thread-Index: AcWkM6Huqt7DW+rHTuSrBnUDXZDtZgACYTlk From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Inline 1. The user A normally enters a dialstring, which should be signalled with a. = sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1= (luckily there does not exist a global dialling plan, so always >I don't understand this item. A dialstring is exactly that. It's a = string of digits that was dialed, but with no meaning. I normally dial nmeaning ful numbers ;-) =20 >Therefore, there can not be a "context" which implies some knowledge of = what the string means (+1 in the above example, >which apparently menas = that the string is a North American E.164 number, which, incidentally, = it is not). =20 The context in the dialstring should give the context within the number = is dialled (basically what your local dialing plan is) The context +1 means that the number is dialed within the North America, = not to which country the number belongs to sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1= =20 if the same E.164 number is dialled in Germany, the dialstring would be sip:004319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+49= =20 and if it is dialed from a mobile phone in Austria it could be sip:019793321@userA.provider.com;user=3Ddialstring;phone-context=3D+43 Of course the question is valid how the client knows the context. Well, = this could be a configuration=20 parameter. =20 -richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 18:10:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5saz-0002AJ-WF; Thu, 18 Aug 2005 18:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5say-00029i-5f; Thu, 18 Aug 2005 18:10:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06842; Thu, 18 Aug 2005 18:10:41 -0400 (EDT) Message-Id: <200508182210.SAA06842@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tAn-000078-La; Thu, 18 Aug 2005 18:47:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E5saj-0000dl-7X; Thu, 18 Aug 2005 17:10:29 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy Date: Thu, 18 Aug 2005 18:10:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0D5@oefeg-s04.oefeg.loc> Thread-Index: AcWkM6Huqt7DW+rHTuSrBnUDXZDtZgACYTlkAADXxCA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard There are two situations, a phone that DOES understand a local dialplan, and a phone that DOES NOT understand a local dial plan. If the phone DOES understand a local dial plan, then it always sends phone numbers, and never sends dialstrings. In such a phone, you always get a full phone number, including a "+" if it's a global number. If the phone DOES NOT understand a local dial plan, then it must have a context, which it has to learn by some sort of provisioning. While you COULD have a context called "+1", that is very, very unlikely. It's more likely "providerA.com" or even more likely "chicago.providerA.com", but it could also be "foo". The provider.com domain needs to understand how to interpret the dialstring 0114319793321 in the dialplan "foo" to a phone number. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Thursday, August 18, 2005 5:48 PM To: Mpierce1@aol.com Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; enum@ietf.org Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy Inline 1. The user A normally enters a dialstring, which should be signalled with a. sip:0114319793321@userA.provider.com;user=dialstring;phone-context=+1 (luckily there does not exist a global dialling plan, so always >I don't understand this item. A dialstring is exactly that. It's a string of digits that was dialed, but with no meaning. I normally dial nmeaning ful numbers ;-) >Therefore, there can not be a "context" which implies some knowledge of what the string means (+1 in the above example, >which apparently menas that the string is a North American E.164 number, which, incidentally, it is not). The context in the dialstring should give the context within the number is dialled (basically what your local dialing plan is) The context +1 means that the number is dialed within the North America, not to which country the number belongs to sip:0114319793321@userA.provider.com;user=dialstring;phone-context=+1 if the same E.164 number is dialled in Germany, the dialstring would be sip:004319793321@userA.provider.com;user=dialstring;phone-context=+49 and if it is dialed from a mobile phone in Austria it could be sip:019793321@userA.provider.com;user=dialstring;phone-context=+43 Of course the question is valid how the client knows the context. Well, this could be a configuration parameter. -richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 18:31:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5svM-0000K7-Gl; Thu, 18 Aug 2005 18:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5svK-0000Ja-37; Thu, 18 Aug 2005 18:31:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08580; Thu, 18 Aug 2005 18:31:43 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5tV7-0000iN-Em; Thu, 18 Aug 2005 19:08:47 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 19 Aug 2005 00:35:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0D7@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy Thread-Index: AcWkM6Huqt7DW+rHTuSrBnUDXZDtZgACYTlkAADXxCAAAONmdQ== From: "Stastny Richard" To: "Brian Rosen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian, =20 >There are two situations, a phone that DOES understand a local = dialplan, and >a phone that DOES NOT understand a local dial plan. >If the phone DOES understand a local dial plan, then it always sends = phone >numbers, and never sends dialstrings. In such a phone, you always get = a >full phone number, including a "+" if it's a global number. Agreed >If the phone DOES NOT understand a local dial plan, then it must have a >context, which it has to learn by some sort of provisioning. While you >COULD have a context called "+1", that is very, very unlikely. It's = more >likely "providerA.com" or even more likely "chicago.providerA.com", but = it >could also be "foo". The provider.com domain needs to understand how = to >interpret the dialstring 0114319793321 in the dialplan "foo" to a phone >number. providerA.com is not enough ;-), if you have customers out of the NANP =20 If you use a mobile phone and 11D digit dialing context +1 is ok you could also use us.providerA.com or nanp.providerA.com If you want local context and context +1301 and washington.providerA.com is equivalent. =20 -richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Aug 18 21:37:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vpA-0000Sk-Pv; Thu, 18 Aug 2005 21:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vp8-0000SZ-RS for enum@megatron.ietf.org; Thu, 18 Aug 2005 21:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21614 for ; Thu, 18 Aug 2005 21:37:33 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5wOz-0007VS-5J for enum@ietf.org; Thu, 18 Aug 2005 22:14:38 -0400 Received: from [68.165.240.34] (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7J1c7s4021375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2005 18:38:09 -0700 Message-ID: <430537D0.2030807@shockey.us> Date: Thu, 18 Aug 2005 21:37:20 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] ENUM WG Document Authors Please Note ... X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org ENUM WG authors should note some of the decisions we made on various drafts in Paris . It would be worth while for all authors of approved WG items and mature drafts to resubmit as soon as possible to the ID Editor, Patrik and myself so we can A. get them properly listed as WG items. B. Go to WG last call on those items we decided are ready or need little or no discussion. Reminder all first time Official ENUM WG drafts must be submitted to Patrik and myself so we can properly alert the ID editor of their status. The chairs like to get some actual progress on our work product now as opposed to the mad rush before Vancouver. And a reminder before you send in your drafts ... In the course of your efforts, you will likely be submitting Internet-Drafts to the IESG for consideration as RFCs. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in the ID-Checklist (http://www.ietf.org/ID-Checklist.html), or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish an Internet-Draft to the IESG. The content issues should be addressed early on in the work since they are integral to the technical makeup of the Internet-Draft. Thank you in advance for your cooperation. The IETF Secretariat -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 11:05:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68R2-0004z5-Mc; Fri, 19 Aug 2005 11:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68Qz-0004uo-TO; Fri, 19 Aug 2005 11:05:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08496; Fri, 19 Aug 2005 11:05:27 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E690y-0003hn-1v; Fri, 19 Aug 2005 11:42:40 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2005 08:05:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,125,1122879600"; d="scan'208"; a="6599533:sNHT26715448" 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 j7JF4rR9020506; Fri, 19 Aug 2005 11:05:17 -0400 (EDT) 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.211); Fri, 19 Aug 2005 11:05:17 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] telURIsin commonpolicy Date: Fri, 19 Aug 2005 11:05:11 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374CBC6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] telURIsin commonpolicy Thread-Index: AcWkB9++suo9C9jMTIqCssYGDRyfqQAG9qlBAAImIUYAKKXAUA== From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Jonathan Rosenberg \(jdrosen\)" , "Brian Rosen" X-OriginalArrivalTime: 19 Aug 2005 15:05:17.0933 (UTC) FILETIME=[6927D1D0:01C5A4CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Otmar Lendl , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I don't get the privacy bit. The user dials a number, that is somehow interpreted as an E.164 number, then it gets omitted from the SIP address to hide from whom? It is called party, no? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Stastny Richard > Sent: Thursday, August 18, 2005 3:38 PM > To: Jonathan Rosenberg (jdrosen); Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl;=20 > enum@ietf.org > Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > telURIsin commonpolicy >=20 > Just one add-on before I am getting ahead of myself: > regarding: > >2. the SIP server of user A provider is now trying to figure=20 > out what=20 > >to do with the dialstring, e.g. using local mapping or=20 > translate it to=20 > >an E.164 number Now the provider either tries to look up=20 > ENUM to get a=20 > >SIP URI ... >=20 > in this case the ENUM entry will in most cases be=20 > sip:+439793321@userA.provider.com;user=3Dphone > or even > sip:\1@userA.provider.com;user=3Dphone >=20 > because of privacy reasons >=20 > -richard >=20 > ________________________________ >=20 > Von: owner-voipeer@lists.uoregon.edu im Auftrag von Stastny Richard > Gesendet: Do 18.08.2005 21:05 > An: Jonathan Rosenberg; Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl;=20 > enum@ietf.org > Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIsin commonpolicy >=20 >=20 >=20 > Jonathan, >=20 > I think you made a very important point here for a BCP coming=20 > out for voipeer: >=20 > >INVITE tel:+1973952500 SIP/2.0 > >Route: sip:@gateway.provider.com >=20 > instead of the currently used > sip:tel:+1973952500 @gateway.provider.com;user=3Dphone >=20 > I will try to summarize: >=20 > 1. The user A normally enters a dialstring, which should be=20 > signalled with a.=20 > = sip:0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1= > (luckily there does not exist a global dialling plan, so=20 > always a context can be submitted) other examples are: > sip:9793321@userA.provider.com;user=3Ddialstring;phone-context=3D+431 > or > = sip:4321@sip.companyA.com;user=3Ddialstring;phone-context=3DcompanyA.com >=20 > b. only if the user enters a full E.164 number with + (or the=20 > device is able to convert this by its own, the signalling=20 > should be either with a tel:+4319793321 or with=20 > sip:+439793321@userA.provider.com The preferred way should be=20 > recommended >=20 > 2. the SIP server of user A provider is now trying to figure=20 > out what to do with the dialstring, e.g. using local mapping=20 > or translate it to an E.164 number Now the provider either=20 > tries to look up ENUM to get a SIP URI or forward the call to=20 > a gateway to the PSTN by one of the above proposed methods >=20 > >INVITE tel:+1973952500 SIP/2.0 > >Route: sip:@gateway.provider.com > or > sip:tel:+1973952500 @gateway.provider.com;user=3Dphone >=20 > There is only one issue left out: there is more then=20 > dialstrings which always have local context and full E.164=20 > numbers it is national numbers and non-E.164 numbers defined=20 > in RFC3966 defining the tel: URI >=20 > These are in my opinion no URN (because they are not unique=20 > and also need always a context. >=20 > It should be recommended that if possible always the global=20 > format should be used, the translation to a required national=20 > format should be done by the gateway interfacing to the PSTN >=20 > For signalling non-E.164 numbers some additional=20 > investigation seems to be necessary (examples) >=20 > -richard >=20 > ________________________________ >=20 > Von: geopriv-bounces@ietf.org im Auftrag von Jonathan Rosenberg > Gesendet: Do 18.08.2005 17:12 > An: Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; 'Otmar=20 > Lendl'; enum@ietf.org > Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIsin commonpolicy >=20 >=20 >=20 > I agree. There is a two step process, fundamentally: >=20 > dial string ----> name -----> address >=20 >=20 > The translation steps themselves can be done entirely in the=20 > UA, entirely in a proxy, or split. When one step is done in a=20 > UA, and the other in a proxy, there is a need to convey the=20 > dial string, the name, or the address on the wire (proxy to=20 > proxy is the same). The formats here are: >=20 > 1. dial strings would be represented using Brian's dial=20 > string draft, i.e.: >=20 > sip:@domain;user=3Ddialstring >=20 > 2. names are represented as tel URI, and is obtained by=20 > applying the dial string to the dial plan. >=20 > 3. addresses are represented as a SIP URI with user=3Dphone,=20 > and is obtained by performing enum, or through any other=20 > suitable translation service that can convert a name to an=20 > address. For example, a provider's databases may definitively=20 > say that a particular name is its own, and thus it can=20 > convert tel:number to sip:number@provider.com;user=3Dphone >=20 >=20 >=20 > In many cases, once a tel URI/name is determined, a provider=20 > can't obtain a sip URI for it. All it knows is that the=20 > number lives on the PSTN. In that case, it needs to go to a=20 > PSTN gateway. How to do this? I would argue further that the=20 > PSTN gateway represents a ROUTE to get to somewhere (the=20 > pstn) that can resolve the name to an address and route it=20 > there (all within the PSTN). In SIP, the way we do routing is=20 > via loose routes. So, to send a call to a pstn gateway: >=20 > INVITE tel:+1973952500 SIP/2.0 > Route: sip:@gateway.provider.com >=20 > The URI in the route header could contain a phone number in=20 > the user part, but the resource being identified for the=20 > route is not the phone number itself, but a piece of routing=20 > and gateway logic, and thus it makes no sense to have=20 > user=3Dphone there. >=20 > BTW, I had mentioned in the enum session while at the mic=20 > that I was working on a doc that talked about phone numbers=20 > in SIP and the difference between tel and sip URI; that doc=20 > basically says the above. >=20 > -Jonathan R. >=20 >=20 > Brian Rosen wrote: >=20 > > In step 1, if the phone does not do dialplan=20 > interpretation, then what=20 > > the user entered is a dialstring, and not a telephone number. This=20 > > could be encoded, as you show, as a SIP uri, but might be better=20 > > encoded as a dialstring, per=20 > draft-rosen-iptel-dialstring-02.txt. A=20 > > tel uri is explicitly NOT used to carry a dialstring. > > > > I think it would be better labeled as a dialstring, and not=20 > something=20 > > that could be confused as a telephone number. It remains true that=20 > > the user-part of sip:5056416@my-voip-provider.at can only be=20 > > interpreted by the my-voip-provider.at domain, so your flow=20 > definitely can work. > > > > Brian > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]=20 > On Behalf=20 > > Of Otmar Lendl > > Sent: Thursday, August 18, 2005 6:33 AM > > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIs in=20 > > commonpolicy > > > > On 2005/08/18 05:08, Jonathan Rosenberg wrote: > > > >>My point is that I think it makes sense to consider the tel=20 > URI a URN,=20 > >>and that it is merely an accident of history that it wasn't=20 > a URN more=20 > >>properly. Now, as you and I both know phone numbers in the PSTN are=20 > >>abused to represent lots of things, but there is no reason to carry=20 > >>forward this confusion into voip. This is why I am=20 > proposing that when=20 > >>a phone number is in a tel URI, it represents a name. We don't know=20 > >>where it is on the network (indeed even if its on an IP=20 > network). To=20 > >>know that, we translate to an address. That address is a=20 > SIP URI. That=20 > >>SIP URI can contain a phone number, i.e. > >>sip:+19739525000@provider.net;user=3Dphone, however in this=20 > format the=20 > >>phone number has been resolved to an address. The act of porting a=20 > >>number is a change in the translation of the phone number as a name=20 > >>(the tel URI) to the phone number as an address (the SIP URI). > >> > > > > > > This is a very sensible notion. > > > > Based on this thinking the dialing of a number on a VoIP-phone goes=20 > > through the following conceptual stages: > > > > 1) User enters a (potentially partial) number on his phone. > > The phone appends its default domain and sends the=20 > invite to its proxy: > > e.g. sip:5056416@my-voip-provider.at > > > > 2) The SIP proxy applies the local dialplan to translate the > > SIP address to an E.164 number: > > > > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > > -> We now have a URN: tel:+4315056416 > > > > 3) The SIP proxy now tries to route the call. In this example, > > user ENUM finds: > > "E2U+sip" "!^.*$!sip:office@enum.at!" > > > > or it could map to the local PSTN gateway with an URI like > > sip:+4315056416@AS5300.my-voip-provider.at > > > > /ol >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > ______________________________________________________________ > _______________ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 12:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69sx-0002uH-6R; Fri, 19 Aug 2005 12:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69sv-0002uC-Eo for enum@megatron.ietf.org; Fri, 19 Aug 2005 12:38:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14071 for ; Fri, 19 Aug 2005 12:38:22 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6ASt-0006ft-Lc for enum@ietf.org; Fri, 19 Aug 2005 13:15:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 19 Aug 2005 18:37:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0DD@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Thread-Index: AcWkO1v7tJz+mD8nRTe0n0nLTW7dUgAoPwlD From: "Stastny Richard" To: "Richard Shockey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org IMHO there is a minor inconsistency here: =20 >The Chair also asked for a straw poll based on the three approaches on = which is preferred "at this time". =20 > 4 Options=20 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa=20 C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 D. Using a different (non-e164.arpa) domain=20 >Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of = carrier tree at RIPE/ITU. There where only three options for hum B and C where one option, the choice between the two was for further = discussion BTW, it is Haberler -richard =20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 15:18:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CO5-0004ka-Qs; Fri, 19 Aug 2005 15:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CO4-0004ji-J2 for enum@megatron.ietf.org; Fri, 19 Aug 2005 15:18:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23593 for ; Fri, 19 Aug 2005 15:18:41 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Cy3-0003GA-GS for enum@ietf.org; Fri, 19 Aug 2005 15:55:56 -0400 Received: from [10.31.13.120] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7JJJFcB009694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 12:19:17 -0700 Message-ID: <43063083.3020505@shockey.us> Date: Fri, 19 Aug 2005 15:18:27 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY References: <32755D354E6B65498C3BD9FD496C7D4613C0DD@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0DD@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.2 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0452239599==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0452239599== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stastny Richard wrote: 
IMHO there is a minor inconsistency here:
 
  

A.	Pfautz approach of use of non-terminal NAPTR's 
B.	Harbler approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa 
C.	Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa 
D.	Using a different (non-e164.arpa) domain 

  
Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU.
    


There where only three options for hum
B and C where one option, the choice between the two was for further discussion

HUMMM ... I distinctly remember offering it up as 4 options ..but my brain cells have not been firing properly of late.

Can anyone else comment here?  I certainly could be mistaken.
BTW, it is Haberler
of course .. sorry ..
-richard


 

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum

  


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============0452239599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0452239599==-- From enum-bounces@ietf.org Fri Aug 19 15:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Cta-0004Uo-Kd; Fri, 19 Aug 2005 15:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CtY-0004Uf-Qx for enum@megatron.ietf.org; Fri, 19 Aug 2005 15:51:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25952 for ; Fri, 19 Aug 2005 15:51:14 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6DTV-0004PN-9a for enum@ietf.org; Fri, 19 Aug 2005 16:28:30 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1124481059!5661853!2 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 8331 invoked from network); 19 Aug 2005 19:51:00 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-13.tower-120.messagelabs.com with SMTP; 19 Aug 2005 19:51:00 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 42EFDDE100DC9FF4; Fri, 19 Aug 2005 15:51:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Date: Fri, 19 Aug 2005 15:50:59 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0AE982F9@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Thread-Index: AcWk80ymQUCyjZS9RUCgcdiz1pCb6QAA/MfA From: "Pfautz, Penn L, NEO" To: "Richard Shockey" , "Stastny Richard" X-Spam-Score: 1.7 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1946236029==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1946236029== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A4F7.52DE616C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A4F7.52DE616C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Rich: I just have the three in my notes too. =20 Penn ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, August 19, 2005 3:18 PM To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Stastny Richard wrote:=20 IMHO there is a minor inconsistency here: =20 =20 =09 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa=20 C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 D. Using a different (non-e164.arpa) domain=20 =09 =20 Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU. =20 =09 =09 There where only three options for hum B and C where one option, the choice between the two was for further discussion =20 HUMMM ... I distinctly remember offering it up as 4 options ..but my brain cells have not been firing properly of late. Can anyone else comment here? I certainly could be mistaken. BTW, it is Haberler =20 of course .. sorry .. -richard =09 =09 =20 =09 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =09 =20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 =20 ; =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------_=_NextPart_001_01C5A4F7.52DE616C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Rich:
I just have the three in my notes = too.
 
Penn

From: enum-bounces@ietf.org=20 [mailto:enum-bounces@ietf.org] On Behalf Of Richard=20 Shockey
Sent: Friday, August 19, 2005 3:18 PM
To: = Stastny=20 Richard
Cc: enum@ietf.org
Subject: Re: [Enum] ENUM = WG=20 Meeting Minutes IETF 63 Paris - PRELIMINARY

Stastny Richard wrote:=20 
IMHO there is a minor inconsistency here:
=20
  

A.	Pfautz approach of use of non-terminal NAPTR's=20
B.	Harbler approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa=20
C.	Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20
D.	Using a different (non-e164.arpa) domain=20

  
Hum indicates strong =
preference for B. [CC]. c.e164.arpa delegation of carrier tree at =
RIPE/ITU.
    


There where only three options for hum
B and C where one option, the choice between the two was for further =
discussion

HUMMM ... I distinctly remember offering it up = as 4=20 options ..but my brain cells have not been firing properly of = late.

Can=20 anyone else comment here?  I certainly could be mistaken.
BTW, it is Haberler
of course .. sorry ..
-richard


=20

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/enum

  


--=20


>>>>>>>>>>>>>>>>>>&=
gt;>>>>>>>>>>>>>>>>>&g=
t;>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us>=
; or=20
<mailto:richard.shockey=
(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<&=
lt;<<<<<<<<<<<<<<<<<&l=
t;<<<<<<<<<<<<<<<<
------_=_NextPart_001_01C5A4F7.52DE616C-- --===============1946236029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1946236029==-- From enum-bounces@ietf.org Fri Aug 19 16:41:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DgM-0002UE-8U; Fri, 19 Aug 2005 16:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6DgK-0002U9-Bw for enum@megatron.ietf.org; Fri, 19 Aug 2005 16:41:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04258 for ; Fri, 19 Aug 2005 16:41:37 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6EGJ-0007qa-IA for enum@ietf.org; Fri, 19 Aug 2005 17:18:54 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7JKfFF18062; Fri, 19 Aug 2005 16:41:15 -0400 (EDT) Received: from [127.0.0.1] (acart542.ca.nortel.com [47.130.17.199]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFTNNCY; Fri, 19 Aug 2005 16:41:00 -0400 Message-ID: <430643D0.3090400@nortel.com> Date: Fri, 19 Aug 2005 16:40:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY References: <34DA635B184A644DA4588E260EC0A25A0AE982F9@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0AE982F9@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Same here. Pfautz, Penn L, NEO wrote: > Rich: > I just have the three in my notes too. > > Penn > > ________________________________ > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Friday, August 19, 2005 3:18 PM > To: Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY > > > Stastny Richard wrote: > > IMHO there is a minor inconsistency here: > > > > A. Pfautz approach of use of non-terminal NAPTR's > B. Harbler approach with delegation at RIPE/ITU aka [CC]. > c.e164.arpa > C. Harbler approach with delegation after RIPE/ITU c. > [CC].e164.arpa > D. Using a different (non-e164.arpa) domain > > > > Hum indicates strong preference for B. [CC]. c.e164.arpa > delegation of carrier tree at RIPE/ITU. > > > > > There where only three options for hum > B and C where one option, the choice between the two was for > further discussion > > > > HUMMM ... I distinctly remember offering it up as 4 options ..but my > brain cells have not been firing properly of late. > > Can anyone else comment here? I certainly could be mistaken. > > > BTW, it is Haberler > > > of course .. sorry .. > > > -richard > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 17:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E4y-000095-Jj; Fri, 19 Aug 2005 17:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E4t-00008r-HH for enum@megatron.ietf.org; Fri, 19 Aug 2005 17:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05214 for ; Fri, 19 Aug 2005 17:07:00 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Eeu-00005v-TE for enum@ietf.org; Fri, 19 Aug 2005 17:44:17 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2005 14:06:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,126,1122879600"; d="scan'208,217"; a="6653347:sNHT35369588" 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 j7JL6jQp023789; Fri, 19 Aug 2005 17:06:51 -0400 (EDT) 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.211); Fri, 19 Aug 2005 17:06:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Date: Fri, 19 Aug 2005 17:06:48 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374CCE4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Thread-Index: AcWk815OW5q1jTtgTjiTAieiGl9gswADlA5A From: "Michael Hammer \(mhammer\)" To: "Richard Shockey" , "Stastny Richard" X-OriginalArrivalTime: 19 Aug 2005 21:06:31.0098 (UTC) FILETIME=[DF5E59A0:01C5A501] X-Spam-Score: 1.4 (+) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673051907==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1673051907== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A501.EA67F253" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A501.EA67F253 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Umm... I wasn't there, but have a question. =20 =20 Which holds more weight, a hum at the f2f meeting or the email list? =20 If there is doubt about a decision, shouldn't that be put to the list in any case? =20 Why not just poll the list now? =20 Mike =20 ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, August 19, 2005 3:18 PM To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY =09 =09 Stastny Richard wrote:=20 IMHO there is a minor inconsistency here: =20 =20 =09 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa=20 C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 D. Using a different (non-e164.arpa) domain=20 =09 =20 Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU. =20 =09 =09 There where only three options for hum B and C where one option, the choice between the two was for further discussion =20 HUMMM ... I distinctly remember offering it up as 4 options ..but my brain cells have not been firing properly of late. =09 Can anyone else comment here? I certainly could be mistaken. =09 BTW, it is Haberler =20 of course .. sorry .. =09 -richard =09 =09 =20 =09 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =09 =20 --=20 =09 =09 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 =20 ; =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------_=_NextPart_001_01C5A501.EA67F253 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Umm...  I wasn't there, but have a question. =20
 
Which holds more weight, a hum at the f2f meeting or the = email=20 list?
 
If there is doubt about a decision, shouldn't that be = put to the=20 list in any case?
 
Why not just poll the list now?
 
Mike
 

From: enum-bounces@ietf.org=20 [mailto:enum-bounces@ietf.org] On Behalf Of Richard=20 Shockey
Sent: Friday, August 19, 2005 3:18 PM
To: = Stastny=20 Richard
Cc: enum@ietf.org
Subject: Re: [Enum] ENUM = WG=20 Meeting Minutes IETF 63 Paris - PRELIMINARY

Stastny Richard wrote:=20 
IMHO there is a minor inconsistency here:
=20
  

A.	Pfautz approach of use of non-terminal NAPTR's=20
B.	Harbler approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa=20
C.	Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20
D.	Using a different (non-e164.arpa) domain=20

  
Hum indicates strong =
preference for B. [CC]. c.e164.arpa delegation of carrier tree at =
RIPE/ITU.
    


There where only three options for hum
B and C where one option, the choice between the two was for further =
discussion

HUMMM ... I distinctly remember offering it up = as 4=20 options ..but my brain cells have not been firing properly of = late.

Can=20 anyone else comment here?  I certainly could be mistaken.
BTW, it is Haberler
of course .. sorry ..
-richard


=20

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/enum

  


--=20


>>>>>>>>>>>>>>>>>>&=
gt;>>>>>>>>>>>>>>>>>&g=
t;>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us>=
; or=20
<mailto:richard.shockey=
(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<&=
lt;<<<<<<<<<<<<<<<<<&l=
t;<<<<<<<<<<<<<<<<
------_=_NextPart_001_01C5A501.EA67F253-- --===============1673051907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1673051907==-- From enum-bounces@ietf.org Fri Aug 19 17:11:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E94-0002GY-0O; Fri, 19 Aug 2005 17:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6E90-0002Bo-Gp for enum@megatron.ietf.org; Fri, 19 Aug 2005 17:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05466 for ; Fri, 19 Aug 2005 17:11:15 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6Ej0-0000Ea-2P for enum@ietf.org; Fri, 19 Aug 2005 17:48:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 19 Aug 2005 23:11:59 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0DE@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Thread-Index: AcWk815OW5q1jTtgTjiTAieiGl9gswADlA5AAAA9GsU= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Richard Shockey" X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org There is only a doubt about the minutes It must be possible to correct minutes without having a poll on the list =20 -richard PS: it was a nonbinding hum anyway (should also be mentioned in the = minutes) for the avoidance of doubt ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 19.08.2005 23:06 An: Richard Shockey; Stastny Richard Cc: enum@ietf.org Betreff: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Umm... I wasn't there, but have a question. =20 =20 Which holds more weight, a hum at the f2f meeting or the email list? =20 If there is doubt about a decision, shouldn't that be put to the list in = any case? =20 Why not just poll the list now? =20 Mike =20 ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Richard Shockey Sent: Friday, August 19, 2005 3:18 PM To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY =09 =09 Stastny Richard wrote:=20 IMHO there is a minor inconsistency here: =20 =20 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa = C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 D. Using a different (non-e164.arpa) domain=20 =09 =20 Hum indicates strong preference for B. [CC]. c.e164.arpa delegation = of carrier tree at RIPE/ITU. =20 There where only three options for hum B and C where one option, the choice between the two was for further = discussion =20 HUMMM ... I distinctly remember offering it up as 4 options ..but my = brain cells have not been firing properly of late. =09 Can anyone else comment here? I certainly could be mistaken. =09 BTW, it is Haberler =20 of course .. sorry .. =09 -richard =09 =09 =20 =09 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =09 =20 --=20 =09 =09 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 = =20 ; = =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 17:13:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6EBC-0003am-UQ; Fri, 19 Aug 2005 17:13:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6EBA-0003Yc-IN for enum@megatron.ietf.org; Fri, 19 Aug 2005 17:13:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05540 for ; Fri, 19 Aug 2005 17:13:29 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6ElB-0000Is-01 for enum@ietf.org; Fri, 19 Aug 2005 17:50:46 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-131.messagelabs.com!1124485966!8057850!11 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 16191 invoked from network); 19 Aug 2005 21:13:18 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-10.tower-131.messagelabs.com with SMTP; 19 Aug 2005 21:13:18 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 42EFDDE100DE053E; Fri, 19 Aug 2005 17:13:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Date: Fri, 19 Aug 2005 17:13:16 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0AE9846C@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Thread-Index: AcWk815OW5q1jTtgTjiTAieiGl9gswADlA5AAAA6evA= From: "Pfautz, Penn L, NEO" To: "Michael Hammer \(mhammer\)" , "Richard Shockey" , "Stastny Richard" X-Spam-Score: 1.7 (+) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1415576538==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1415576538== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A502.D20F9A68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A502.D20F9A68 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The agreement of the chairs at the meeting was that the hum was non-binding since it was deemed inappropriate to make a decision until the requirements I-D had been agreed on. That being said, I'd certainly welcome hearing the list's opinions. ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Michael Hammer (mhammer) Sent: Friday, August 19, 2005 5:07 PM To: Richard Shockey; Stastny Richard Cc: enum@ietf.org Subject: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Umm... I wasn't there, but have a question. =20 =20 Which holds more weight, a hum at the f2f meeting or the email list? =20 If there is doubt about a decision, shouldn't that be put to the list in any case? =20 Why not just poll the list now? =20 Mike =20 ________________________________ From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Friday, August 19, 2005 3:18 PM To: Stastny Richard Cc: enum@ietf.org Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY =09 =09 Stastny Richard wrote:=20 IMHO there is a minor inconsistency here: =20 =20 =09 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa=20 C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 D. Using a different (non-e164.arpa) domain=20 =09 =20 Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU. =20 =09 =09 There where only three options for hum B and C where one option, the choice between the two was for further discussion =20 HUMMM ... I distinctly remember offering it up as 4 options ..but my brain cells have not been firing properly of late. =09 Can anyone else comment here? I certainly could be mistaken. =09 BTW, it is Haberler =20 of course .. sorry .. =09 -richard =09 =09 =20 =09 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum =09 =20 --=20 =09 =09 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 =20 ; =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------_=_NextPart_001_01C5A502.D20F9A68 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
The agreement of the chairs at the meeting was = that the hum=20 was non-binding since it was deemed inappropriate to make a decision = until the=20 requirements I-D had been agreed on. That being said, I'd certainly = welcome=20 hearing the list's opinions.

From: enum-bounces@ietf.org=20 [mailto:enum-bounces@ietf.org] On Behalf Of Michael Hammer=20 (mhammer)
Sent: Friday, August 19, 2005 5:07 PM
To: = Richard=20 Shockey; Stastny Richard
Cc: enum@ietf.org
Subject: = RE:=20 [Enum] ENUM WG Meeting Minutes IETF 63 Paris - = PRELIMINARY

Umm...  I wasn't there, but have a question. =20
 
Which holds more weight, a hum at the f2f meeting or the = email=20 list?
 
If there is doubt about a decision, shouldn't that be = put to the=20 list in any case?
 
Why not just poll the list now?
 
Mike
 

From: enum-bounces@ietf.org=20 [mailto:enum-bounces@ietf.org] On Behalf Of Richard=20 Shockey
Sent: Friday, August 19, 2005 3:18 PM
To: = Stastny=20 Richard
Cc: enum@ietf.org
Subject: Re: [Enum] ENUM = WG=20 Meeting Minutes IETF 63 Paris - PRELIMINARY

Stastny Richard wrote:=20 
IMHO there is a minor inconsistency here:
=20
  

A.	Pfautz approach of use of non-terminal NAPTR's=20
B.	Harbler approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa=20
C.	Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20
D.	Using a different (non-e164.arpa) domain=20

  
Hum indicates strong =
preference for B. [CC]. c.e164.arpa delegation of carrier tree at =
RIPE/ITU.
    


There where only three options for hum
B and C where one option, the choice between the two was for further =
discussion

HUMMM ... I distinctly remember offering it up = as 4=20 options ..but my brain cells have not been firing properly of = late.

Can=20 anyone else comment here?  I certainly could be mistaken.
BTW, it is Haberler
of course .. sorry ..
-richard


=20

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/enum

  


--=20


>>>>>>>>>>>>>>>>>>&=
gt;>>>>>>>>>>>>>>>>>&g=
t;>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us>=
; or=20
<mailto:richard.shockey=
(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<&=
lt;<<<<<<<<<<<<<<<<<&l=
t;<<<<<<<<<<<<<<<<
------_=_NextPart_001_01C5A502.D20F9A68-- --===============1415576538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1415576538==-- From enum-bounces@ietf.org Fri Aug 19 18:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Eza-0000zc-7t; Fri, 19 Aug 2005 18:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6EzX-0000xf-AT; Fri, 19 Aug 2005 18:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07854; Fri, 19 Aug 2005 18:05:32 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6FZX-0001hT-9t; Fri, 19 Aug 2005 18:42:49 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 19 Aug 2005 15:05:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,127,1122879600"; d="scan'208"; a="6659561:sNHT24075880" 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 j7JM5KQl005476; Fri, 19 Aug 2005 18:05:21 -0400 (EDT) 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.211); Fri, 19 Aug 2005 18:05:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Date: Fri, 19 Aug 2005 18:05:19 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37C484F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWlBedqTrMu6eVwQJSNCiGzXrptxgAA6MVA From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 19 Aug 2005 22:05:13.0766 (UTC) FILETIME=[130AD460:01C5A50A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , "James Polk \(jmpolk\)" , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Paul, I understand what you are driving at when presented a sip address containing an E.164 number with no other context. But, I would suggest that putting such a number into Carrier ENUM must be limited to the carrier of record currently serving that phone number. Otherwise, what stops all 3000+ carriers in the US from asking to put an entry for my phone number into that location of the Carrier ENUM tree pointing traffic to their domain? Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Friday, August 19, 2005 5:35 PM > To: Michael Hammer (mhammer) > Cc: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg=20 > (jdrosen); voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in=20 > common policy >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > James, > >=20 > > This seems to be a number portability question. E.164 numbers get=20 > > assigned by the national authority either directly to the=20 > individual=20 > > or to a carrier. > >=20 > > In the individual case, when the number ports from one SIP=20 > address to=20 > > another, it remains "owned" by the individual. > >=20 > > In the carrier case (at least in the US as I understand it), the=20 > > number is assigned to what is known as the donor=20 > > switch/network/carrier. This is typically the network that "owned"=20 > > the number before number portability was invented. When a=20 > user ports=20 > > to a new serving switch/network/carrier, the NP database maps the=20 > > number to a location routing number (LRN). Carrier ENUM does=20 > > essentially the same thing, it records the current E.164 to=20 > SIP URI of=20 > > Serving Carrier point of interconnect. > >=20 > > If the user ports again, the donor network remains the=20 > same, while the=20 > > serving network in ENUM will change. >=20 > I thought I saw a note that the ENUM WG accepted a work item=20 > to do exactly this, which would imply that it isn't yet being=20 > done this way.=20 > If its not, then I would assume that the carrier enum would=20 > simply point to the donor network. >=20 > > If the user relinquishes the number (cancels service), the number=20 > > reverts back to the donor network to be assigned to their next new=20 > > customer. (Not sure if this is same worldwide.) > >=20 > > If one carrier buys another carrier, then the numbers owned by the=20 > > acquired carrier will now belong to the buying carrier. > >=20 > > So: > >=20 > > Donor 1 =3D ENUM leaf (original carrier moves customer to=20 > ENUM) Donor 1=20 > > -> Serving 2 =3D ENUM leaf (first port) Donor 1 -> Serving 3 =3D = ENUM=20 > > leaf (second port) Donor 1 -> Serving 4 =3D ENUM leaf (third port) = > > Donor 5 -> Serving 4 =3D ENUM leaf (carrier 5 buys carrier=20 > 1) Donor 5 =3D=20 > > ENUM leaf (customer cancels) > >=20 > > Does that make sense? >=20 > Modulo the above comments. But I don't think this really has=20 > a whole lot to do with the original question. This comes down=20 > to whether you believe that >=20 > sip:+1-232-555-1234@foo.com;user=3Dphone >=20 > is only valid if foo.com is the serving network/carrier for=20 > +1-232-555-1234. There are a whole lot of people who don't think that. >=20 > In my mind all that you can conclude from such a URI is that=20 > foo.com is to participate in routing calls to that URI.=20 > Whether they terminate in foo.com's network, or are=20 > eventually terminated someplace else is for foo.com to decide. >=20 > Paul >=20 >=20 > >>-----Original Message----- > >>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org]=20 > On Behalf=20 > >>Of James Polk (jmpolk) > >>Sent: Wednesday, August 17, 2005 12:46 PM > >>To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul Kyzivat=20 > >>(pkyzivat); voipeer@lists.uoregon.edu > >>Cc: geopriv@ietf.org; enum@ietf.org > >>Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy > >> > >>At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: > >> > >>>I fully agree that there seems to be an issue here, because > >> > >>the problem > >> > >>>is currently discussed at voipeer also.The format=20 > >>>sip:+1-232-555-1234@foo.com;user=3Dphone > >>>gets very important especially for Carrier ENUM indicating the=20 > >>>destination providers (see below) > >> > >>So, and perhaps this is a naive point/question - what=20 > happens when a=20 > >>carrier no longer operates a phone number that is in operation by=20 > >>another carrier? > >> > >>For example, my wife has had the same cell phone number for > >>15+ years, yet she has recently changed to her third carrier.=20 > >> The company that originally owned her phone number is=20 > being acquired=20 > >>by a 4th company now (here in the US, giving you a hint as=20 > to two of=20 > >>the players involved). > >> > >>What does this do to your statement: > >> > >> "The format sip:+1-232-555-1234@foo.com;user=3Dphone > >>gets very important especially for Carrier ENUM indicating the=20 > >>destination providers" > >> > >> > >>>It also concerns the CLI and CLIR aspect not yet fully=20 > discussed in=20 > >>>voipeer. This is one issue definitely in scope of voipeer. > >>> > >>>comments inline > >>> > >> > >> > >>cheers, > >>James > >> > >> ******************* > >> Truth is not to be argued... it is to be presented. > >> > >>_______________________________________________ > >>enum mailing list > >>enum@ietf.org > >>https://www1.ietf.org/mailman/listinfo/enum > >> > >=20 > >=20 >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 18:32:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6FPO-0007HI-Au; Fri, 19 Aug 2005 18:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6FPM-0007Gj-A9; Fri, 19 Aug 2005 18:32:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09566; Fri, 19 Aug 2005 18:32:13 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6FzO-0002H5-7v; Fri, 19 Aug 2005 19:09:30 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 20 Aug 2005 00:35:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0DF@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWlBedqTrMu6eVwQJSNCiGzXrptxgAA6MVAAACvi2E= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Paul Kyzivat \(pkyzivat\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, "James Polk \(jmpolk\)" , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org I think we have detected a problem here: (I have read the sip-identity draft now ;-) =20 Starting with Jonathans request to use=20 sip:+1-232-555-1234@foo.com;user=3Dphone only if foo.com is the carrier hosting the E.164 number in the FROM Field for identity assertion he also proposed to use this in the TO field only if the carrier is the one hosting the E.164 number in all other case the following should be used if=20 an intermediary is used =20 >>INVITE tel:+1973952500 SIP/2.0 >>Route: sip:@gateway.provider.com > >=20 > instead of the currently used > sip:tel:+1973952500@gateway.provider.com;user=3Dphone =20 This makes sense also in carrier ENUM, but: only if the NAPTR is pointing to the final destination network =20 But there could be cases that a group of carriers, say e.g. the mobile operators, still want to use for final routing their own provate network. The public carrier ENUM enrty could then point to a SBC sitting of the edge of the private network =20 According to the above proposal in this case >>INVITE tel:+1973952500 SIP/2.0 >>Route: sip:@gateway.provider.com =20 should be used to access the SBC but this cannot be entered in ENUM only > sip:tel:+1973952500@gateway.provider.com;user=3Dphone is currently possible but there is no way to distuingish for the originating network if the destination is a gateway or the destination network =20 Maybe an additional parameter could help here to construct >>INVITE tel:+1973952500 SIP/2.0 >>Route: sip:@gateway.provider.com out of the ENUM URI if this becomes recommended practice. sip:tel:+1973952500@gateway.provider.com;user=3Dphone;route=3Dgw -richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Sa 20.08.2005 00:05 An: Paul Kyzivat (pkyzivat) Cc: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg (jdrosen); = voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Betreff: RE: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy Paul, I understand what you are driving at when presented a sip address containing an E.164 number with no other context. But, I would suggest that putting such a number into Carrier ENUM must be limited to the carrier of record currently serving that phone number. Otherwise, what stops all 3000+ carriers in the US from asking to put an entry for my phone number into that location of the Carrier ENUM tree pointing traffic to their domain? Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Friday, August 19, 2005 5:35 PM > To: Michael Hammer (mhammer) > Cc: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg > (jdrosen); voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in > common policy > > > > Michael Hammer (mhammer) wrote: > > James, > > > > This seems to be a number portability question. E.164 numbers get > > assigned by the national authority either directly to the > individual > > or to a carrier. > > > > In the individual case, when the number ports from one SIP > address to > > another, it remains "owned" by the individual. > > > > In the carrier case (at least in the US as I understand it), the > > number is assigned to what is known as the donor > > switch/network/carrier. This is typically the network that "owned" > > the number before number portability was invented. When a > user ports > > to a new serving switch/network/carrier, the NP database maps the > > number to a location routing number (LRN). Carrier ENUM does > > essentially the same thing, it records the current E.164 to > SIP URI of > > Serving Carrier point of interconnect. > > > > If the user ports again, the donor network remains the > same, while the > > serving network in ENUM will change. > > I thought I saw a note that the ENUM WG accepted a work item > to do exactly this, which would imply that it isn't yet being > done this way. > If its not, then I would assume that the carrier enum would > simply point to the donor network. > > > If the user relinquishes the number (cancels service), the number > > reverts back to the donor network to be assigned to their next new > > customer. (Not sure if this is same worldwide.) > > > > If one carrier buys another carrier, then the numbers owned by the > > acquired carrier will now belong to the buying carrier. > > > > So: > > > > Donor 1 =3D ENUM leaf (original carrier moves customer to > ENUM) Donor 1 > > -> Serving 2 =3D ENUM leaf (first port) Donor 1 -> Serving 3 =3D = ENUM > > leaf (second port) Donor 1 -> Serving 4 =3D ENUM leaf (third port) > > Donor 5 -> Serving 4 =3D ENUM leaf (carrier 5 buys carrier > 1) Donor 5 =3D > > ENUM leaf (customer cancels) > > > > Does that make sense? > > Modulo the above comments. But I don't think this really has > a whole lot to do with the original question. This comes down > to whether you believe that > > sip:+1-232-555-1234@foo.com;user=3Dphone > > is only valid if foo.com is the serving network/carrier for > +1-232-555-1234. There are a whole lot of people who don't think that. > > In my mind all that you can conclude from such a URI is that > foo.com is to participate in routing calls to that URI. > Whether they terminate in foo.com's network, or are > eventually terminated someplace else is for foo.com to decide. > > Paul > > > >>-----Original Message----- > >>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] > On Behalf > >>Of James Polk (jmpolk) > >>Sent: Wednesday, August 17, 2005 12:46 PM > >>To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul Kyzivat > >>(pkyzivat); voipeer@lists.uoregon.edu > >>Cc: geopriv@ietf.org; enum@ietf.org > >>Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy > >> > >>At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: > >> > >>>I fully agree that there seems to be an issue here, because > >> > >>the problem > >> > >>>is currently discussed at voipeer also.The format > >>>sip:+1-232-555-1234@foo.com;user=3Dphone > >>>gets very important especially for Carrier ENUM indicating the > >>>destination providers (see below) > >> > >>So, and perhaps this is a naive point/question - what > happens when a > >>carrier no longer operates a phone number that is in operation by > >>another carrier? > >> > >>For example, my wife has had the same cell phone number for > >>15+ years, yet she has recently changed to her third carrier. > >> The company that originally owned her phone number is > being acquired > >>by a 4th company now (here in the US, giving you a hint as > to two of > >>the players involved). > >> > >>What does this do to your statement: > >> > >> "The format sip:+1-232-555-1234@foo.com;user=3Dphone > >>gets very important especially for Carrier ENUM indicating the > >>destination providers" > >> > >> > >>>It also concerns the CLI and CLIR aspect not yet fully > discussed in > >>>voipeer. This is one issue definitely in scope of voipeer. > >>> > >>>comments inline > >>> > >> > >> > >>cheers, > >>James > >> > >> ******************* > >> Truth is not to be argued... it is to be presented. > >> > >>_______________________________________________ > >>enum mailing list > >>enum@ietf.org > >>https://www1.ietf.org/mailman/listinfo/enum > >> > > > > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 18:59:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Fpx-0006Hp-U6; Fri, 19 Aug 2005 18:59:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Fpw-0006Hk-KM for enum@megatron.ietf.org; Fri, 19 Aug 2005 18:59:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10818 for ; Fri, 19 Aug 2005 18:59:40 -0400 (EDT) Received: from central.switch.ch ([130.59.11.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6GPx-0002zK-TO for enum@ietf.org; Fri, 19 Aug 2005 19:36:59 -0400 Received: from machb.switch.ch ([130.59.6.129]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1E6FpV-0006Be-00; Sat, 20 Aug 2005 00:59:17 +0200 Date: Sat, 20 Aug 2005 00:57:39 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: Richard Shockey Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY In-Reply-To: <43063083.3020505@shockey.us> Message-ID: References: <32755D354E6B65498C3BD9FD496C7D4613C0DD@oefeg-s04.oefeg.loc> <43063083.3020505@shockey.us> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="98048-2042015844-1124492259=:1254" X-Spam-Score: 0.8 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --98048-2042015844-1124492259=:1254 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE You could also check from the Jabber-log, and there are only 3 options. (I personally typed them in during the session... ;-) ) cheers, Bernie On Fri, 19 Aug 2005, Richard Shockey wrote: > Stastny Richard wrote: >=20 > IMHO there is a minor inconsistency here: >=20 >=20 >=20 > A.=09Pfautz approach of use of non-terminal NAPTR's=20 > B.=09Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa= =20 > C.=09Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa=20 > D.=09Using a different (non-e164.arpa) domain=20 >=20 >=20 >=20 > Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of c= arrier tree at RIPE/ITU. >=20 >=20 > There where only three options for hum > B and C where one option, the choice between the two was for further disc= ussion >=20 >=20 >=20 > HUMMM ... I distinctly remember offering it up as 4 options ..but my > brain cells have not been firing properly of late. >=20 > Can anyone else comment here?=A0 I certainly could be mistaken. >=20 > BTW, it is Haberler >=20 >=20 > of course .. sorry .. >=20 > -richard >=20 >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 >=20 >=20 >=20 > --=20 >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or=20 > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 > --98048-2042015844-1124492259=:1254 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --98048-2042015844-1124492259=:1254-- From enum-bounces@ietf.org Fri Aug 19 22:02:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ih0-0002oz-PH; Fri, 19 Aug 2005 22:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Igx-0002ou-PQ for enum@megatron.ietf.org; Fri, 19 Aug 2005 22:02:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17154 for ; Fri, 19 Aug 2005 22:02:37 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6JGz-0007O6-V6 for enum@ietf.org; Fri, 19 Aug 2005 22:39:56 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7K21k43014450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 19:01:49 -0700 Message-ID: <43068EDB.1070203@shockey.us> Date: Fri, 19 Aug 2005 22:00:59 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY References: <32755D354E6B65498C3BD9FD496C7D4613C0DE@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0DE@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, "Michael Hammer \(mhammer\)" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >There is only a doubt about the minutes > >It must be possible to correct minutes without having a poll on the list > >-richard >PS: it was a nonbinding hum anyway (should also be mentioned in the minutes) >for the avoidance of doubt > > yes ..it was a "straw poll" and as such non binding. I will reflect this in the minutes. >________________________________ > >Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >Gesendet: Fr 19.08.2005 23:06 >An: Richard Shockey; Stastny Richard >Cc: enum@ietf.org >Betreff: RE: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY > > >Umm... I wasn't there, but have a question. > >Which holds more weight, a hum at the f2f meeting or the email list? > >If there is doubt about a decision, shouldn't that be put to the list in any case? > >Why not just poll the list now? > >Mike > > > >________________________________ > > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: Friday, August 19, 2005 3:18 PM > To: Stastny Richard > Cc: enum@ietf.org > Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY > > > Stastny Richard wrote: > > IMHO there is a minor inconsistency here: > > > A. Pfautz approach of use of non-terminal NAPTR's > B. Harbler approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa > C. Harbler approach with delegation after RIPE/ITU c. [CC].e164.arpa > D. Using a different (non-e164.arpa) domain > > > > Hum indicates strong preference for B. [CC]. c.e164.arpa delegation of carrier tree at RIPE/ITU. > > > There where only three options for hum > B and C where one option, the choice between the two was for further discussion > > > > HUMMM ... I distinctly remember offering it up as 4 options ..but my brain cells have not been firing properly of late. > > Can anyone else comment here? I certainly could be mistaken. > > > BTW, it is Haberler > > > of course .. sorry .. > > > -richard > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > > > > -- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Aug 19 22:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Imt-00037t-NK; Fri, 19 Aug 2005 22:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Imr-00037o-By for enum@megatron.ietf.org; Fri, 19 Aug 2005 22:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17321 for ; Fri, 19 Aug 2005 22:08:42 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6JMu-0007Xh-K5 for enum@ietf.org; Fri, 19 Aug 2005 22:46:01 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7K29CPa015011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Aug 2005 19:09:14 -0700 Message-ID: <43069099.8000605@shockey.us> Date: Fri, 19 Aug 2005 22:08:25 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Subject: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2 Content-Type: multipart/mixed; boundary="------------040407080905080703070809" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: d9951f061208886fc6ada4b24aa6f98d X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------040407080905080703070809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IETF 63  Telephone Number Mapping (ENUM) WG Meeting Minutes

Comments from the list incorporated.

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

Transport Area Advisor:
Allison Mankin  <mankin@psg.com>


Friday, August 6 2005  9:AM to 12:30 PM

AGENDA BASHING (5 min)


1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )

Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-02.txt
        Pages           : 29
        Date            : 2005-7-1

This document captures experience in implementing systems based on    the ENUM protocol, and experience of ENUM data that have been created    by others.  As such, it is informational only, and produced as a help    to others in reporting what is "out there" and the potential pitfalls  in interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt

 

WG ACTION :  After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.


2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

WG ACTION : Put this document into WGLC after one more revision by author.

DISCUSSION Some concerns whether this document is mature enough for even WG last call,  response is that the document will see another revision and pushing towards    last call is only meant to spur document forward.

3. New/old work on enumservice registrations  ( 20 M )

3.1


        Title           : IANA Registration for Enumservice Voice
        Author(s)       : R. Brandner, et al.
        Filename        : draft-brandner-enum-voice-00.txt
        Pages           : 12
        Date            : 2005-7-7

   This document registers the ENUMservice ^voice^ (which has a defined    sub-type ^tel^), as per the IANA registration process defined in the    ENUM specification RFC3761.  This service indicates that the contact   held in the generated URI can be used to initiate an interactive  voice (audio) call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.

DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.


3.2
        Title   : IANA Registration for an Enumservice  Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8

   This document registers the Enumservice "npd" and subtype "tel" using    the URI scheme 'tel:' as per the IANA registration process defined in   the ENUM specification, RFC 3761.  This data is used to facilitate  the routing of telephone calls in those countries where Number  Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt

 

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 

DISCUSSION :

 

Comments include:
    - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
    - Global Spin Std.
    - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
    - TEL URI scope problem : examples should include both TEL and SIP URI examples
    - For IMS, limited usefulness
    - RFC 3671 db?  1 or collection? (Latter) 

    - Document should discuss sage of portability data as it relates national policy
    -


3.3

  Title           : IANA Registration for ENUMservice Mobile Webpage
  Author(s)       : J. Ra, et al.
  Filename        : draft-ra-shin-enum-mobileweb-00.txt
  Pages           :
  Date            : 2005-7-7

   This document registers the ENUMservice “mobweb” using the URI    schemes 'http:' and 'https:' as per the IANA registration process  defined in the ENUM specification RFC3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt

 

WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.

 

DISCUSSION:
Discussion dove into issue of DNS vs. Application layer indication of  protocol stack capabilities.

    - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
    - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection)
    - HTTP negotiation accomplishes the same once connection is in place
    - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP)
    - RFC 3824, guidelines on SIP and ENUM as reference

   - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.



4. ENUM Validation Issues. 3 Drafts 15 -20

 4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00

        Title           : ENUM Validation Architecture
        Author(s)       : A. Mayrhofer, B. Hoeneisen
        Filename        : draft-mayrhofer-enum-validation-arch-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164   number.  The process of verifying whether or not the Registrant of an  ENUM domain name is identical to the Assignee of the corresponding  E.164 number is commonly called ^validation^.  This document  describes validation requirements and a high level architecture for  an ENUM validation infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt

 


WG ACTION :  WG humm agrees to draft as ENUM WG work item.



4.2  "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt


        Title           : ENUM Validation Token Format Definition
        Author(s)       : O. Lendl
        Filename        : draft-lendl-enum-validation-token-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164  number.  The process of verifying whether the Registrant of an ENUM  domain name is identical to the Assignee of the corresponding E.164  number is commonly called ^validation^.  This document describes an  signed XML data format -- the Validation Token -- with which
 Validation Entities can convey successful completion of a validation  procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

4.3  Bernie Hoeneisen


  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

DISCUSSION: Very little technical discussion of the above 3 documents.



#################

5. PART 2  1/2 hours. 3 Items

WG AGENDA: Terms and Conditions of discussion.

The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand.
 


#################

5.1 Discussion of drafts on Carrier ENUM - Requirements ?

  Title           : Infrastructure ENUM Requirements
        Author(s)       : S. Lind
        Filename        : draft-lind-infrastructure-enum-reqs-00.txt
        Pages           : 8
        Date            : 2005-7-15

 There has been much discussion in various industries about the  concept of infrastructure (or carrier) ENUM. Some of this discussion   has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the  Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus    industry-wide on even what infrastructure ENUM is, why it seems to be  important, or what the requirements for implementing it are.

 At the request of the WG co-chairs, this document attempts to gather   together the bits and pieces from those discussions (i.e., I stole   the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that   will enable enlightened discussion and hopefully achieve consensus.   Some items listed below may be duplicative and suggest alternative    wordings for similar and other contradictory issues. As such, this  list is very raw and should not be viewed as complete, cohesive or  correct.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt

 

WG ACTION:  This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.

Penn Pfautz agrees to collaborate with Steve Lind on future drafts.

5.2  Title           : IANA Carrier/User enumservice Registration
        Author(s)       : P. Pfautz, et al.
        Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
        Pages           : 10
        Date            : 2005-6-6

This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry  to support end user and carrier services with independent name   servers holding the terminal NAPTR (Naming Authority Pointer) records  identifying the communication services for each.  The to-be-  registered enumservices make use of non-terminal NAPTR records and  DDDS (Dynamic Delegation Discovery System) replacement to achieve  this end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt


5.3       Title           : Combined User and Carrier ENUM in the e164.arpa tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-haberler-carrier-enum-00.txt
        Pages           : 10
        Date            : 2005-7-11

   ENUM as defined now in RFC3761 is not well suited for the purpose of    interconnection by carriers, as can be seen by the use of various  private tree arrangements based on ENUM mechanisms.  A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number.  This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt


DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.


  As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant.  Three approaches were mentioned but only two seem "obvious".

   Non-terminal NAPTR records

 Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier.  Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup.

   Separated branches of the DNS tree

 A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or

B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.

 End users ( number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa.

   Requirements/Desired results
   1) Minimize number of lookups
   2) Retain flexibility
   3) Consistency from CC to CC for predictability

   Discussion

   -  Data in DNS does not guarantee reachability ("deny's" allowed)

   -  DNS MUST answer.
   - Uniformity in "c" label, name and where, is important
   - Non-terminal NAPTRs are untried
   - Questions on whether DNS wildcards are pertinent to the issue
   - Three questions - what's better for 1) DNS, 2) Application, and 3) "life"
   - Should not preclude private carrier-carrier traffic control

WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.

Further Discussion on Next Steps

   - Needs requirements and especially use cases to indicate what it is about

WG ACTION: Requirements document added as WG item.
   - RFC 3761 should remain untouched
   - Scope needs definition (stop at re-write rules?)
   - Use cases, use cases, use cases
   - Terminology and definitions needed

 The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred “at this time”. 

3 Options

  1. Pfautz approach of use of non-terminal NAPTR’s
  2. Haberler/Stastny approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa
  3. Haberler/Stastny approach with delegation after RIPE/ITU c. [CC].e164.arpa

Hum indicates strong preference for B/C with further discussion the WG necessary.

Further Discussion:

Division of labor with VOIPEER BoF effort required

6.0 Title           : Non-Terminal NAPTR Processing: A Modest Proposal
        Author(s)       : L. Conroy
        Filename        : draft-conroy-enum-modestproposal-00.txt
        Pages           : 12
        Date            : 2005-7-6

  Recent Discussions within the IETF and in other fora have highlighted  differences in interpretation of the set of standards associated with    ENUM and DDDS, on which it relies.  Specifically, the operation and   semantics surrounding support for non-terminal NAPTRs has led to some    confusion.  This document is n attempt to add clarification to non-   terminal NAPTR processing.  In this, it clarifies RFC3403.  A    subsequent document will build on this one to extend FC3761 further,    permitting registration of non-terminal Enumservices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt

WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.

 

Meeting Concludes.


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--------------040407080905080703070809 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------040407080905080703070809 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------040407080905080703070809-- From enum-bounces@ietf.org Fri Aug 19 22:26:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6J3i-0000A3-Re; Fri, 19 Aug 2005 22:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6J3h-00009y-Dn for enum@megatron.ietf.org; Fri, 19 Aug 2005 22:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17782 for ; Fri, 19 Aug 2005 22:26:06 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Jdl-0007vX-Qt for enum@ietf.org; Fri, 19 Aug 2005 23:03:26 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7K2QdL3016116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 19:26:40 -0700 Message-ID: <430694B0.1070108@shockey.us> Date: Fri, 19 Aug 2005 22:25:52 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Allison Mankin , "Peterson, Jon" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Subject: [Enum] Discussion and acceptance of Carrier / Private ENUM items dependent on WG recharter. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org The Chairs want to make it explicitly clear that ultimate acceptance of Carrier / Private ENUM related drafts are fundamentally Dependant upon WG recharter. This task has been long over due. The Chairs are now actively engaged in the task of drafting language to the AD's/ IESG incorporating the wishes of the WG to move forward on these issues including specific Goals and Milestones. In addition there is a clear relationship of our efforts to the emerging discussions coming out of the voipeer BOF that must be taken into consideration. That said the spirited discussion within the ENUM WG to date and in tandem with the voipeer community should indicate the general consensus on where a recharter should be focused on. The Chairs will keep you posted as needed. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Aug 20 03:45:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6O2y-0002W0-NE; Sat, 20 Aug 2005 03:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6O2w-0002Vs-Bz for enum@megatron.ietf.org; Sat, 20 Aug 2005 03:45:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10037 for ; Sat, 20 Aug 2005 03:45:40 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6Ocz-00064U-9k for enum@ietf.org; Sat, 20 Aug 2005 04:22:58 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 20 Aug 2005 09:45:11 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0E0@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2 Thread-Index: AcWlLRj2ttstS68MTaqzJcC0OnLTnQALf9Zm From: "Stastny Richard" To: "Richard Shockey" , X-Spam-Score: 0.8 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Sorry to be picky, but it is wrong again: =20 It should read: =20 The Chair also asked for a non binding "straw poll" based on the three = approaches on which is preferred "at this time". =20 3 Options=20 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Haberler/Stastny approach with delegation at RIPE/ITU aka [CC]. = c.e164.arpa or with delegation after RIPE/ITU c. [CC].e164.arpa=20 C. Using a different (non-e164.arpa) domain Hum indicates strong preference for B with further discussion the WG = necessary. -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Richard Shockey Gesendet: Sa 20.08.2005 04:08 An: enum@ietf.org Betreff: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY = Version 2 IETF 63 Telephone Number Mapping (ENUM) WG Meeting Minutes=20 Comments from the list incorporated. Chair(s):=20 Patrik Faltstrom =20 Richard Shockey = =20 Transport Area Advisor:=20 Allison Mankin =20 Friday, August 6 2005 9:AM to 12:30 PM=20 AGENDA BASHING (5 min)=20 1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? = )=20 Title : ENUM Implementation Issues and Experiences=20 Author(s) : L. Conroy, K. Fujiwara=20 Filename : draft-ietf-enum-experiences-02.txt=20 Pages : 29=20 Date : 2005-7-1=20 This document captures experience in implementing systems based on = the ENUM protocol, and experience of ENUM data that have been created = by others. As such, it is informational only, and produced as a help = to others in reporting what is "out there" and the potential pitfalls = in interpreting the set of documents that specify the protocol.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt=20 =20 WG ACTION : After some minor discussion agreement that the document = should go through one more iteratina and then take directly to WGLC. 2. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? )=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt=20 WG ACTION : Put this document into WGLC after one more revision by = author. DISCUSSION Some concerns whether this document is mature enough for even = WG last call, response is that the document will see another revision = and pushing towards last call is only meant to spur document forward. 3. New/old work on enumservice registrations ( 20 M )=20 3.1=20 Title : IANA Registration for Enumservice Voice=20 Author(s) : R. Brandner, et al.=20 Filename : draft-brandner-enum-voice-00.txt=20 Pages : 12=20 Date : 2005-7-7=20 This document registers the ENUMservice ^voice^ (which has a defined = sub-type ^tel^), as per the IANA registration process defined in the = ENUM specification RFC3761. This service indicates that the contact = held in the generated URI can be used to initiate an interactive voice = (audio) call.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt=20 WG ACTION : WG humm agrees to draft as ENUM WG work item. Given the = straightforward nature of this draft it is probable that it can go to = WGLC after one iteration. DISCUSSION: Document is a simplification of a larger ENUM service = registration document on voice services. The document only specifies the = concept of voice:tel. 3.2=20 Title : IANA Registration for an Enumservice Containing = Number Portability and PSTN=20 Signaling Information=20 Author(s) : J. Livingood, R. Shockey=20 Filename : draft-livingood-shockey-enum-npd-00.txt=20 Pages : 8=20 Date : 2005-7-8=20 This document registers the Enumservice "npd" and subtype "tel" using = the URI scheme 'tel:' as per the IANA registration process defined in = the ENUM specification, RFC 3761. This data is used to facilitate = the routing of telephone calls in those countries where Number = Portability exists.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.t= xt=20 =20 WG ACTION : WG humm agrees to draft as ENUM WG work item.=20 =20 DISCUSSION :=20 =20 Comments include:=20 - Doc needs to clarify "which" ENUM this is Public, vs Private vs = Carrier - Global Spin Std.=20 - Are there size problems? Referring to SS7 size of databases can = the DNS actually handle this class of queries even if privately cached. - TEL URI scope problem : examples should include both TEL and SIP = URI examples - For IMS, limited usefulness=20 - RFC 3671 db? 1 or collection? (Latter)=20 - Document should discuss sage of portability data as it relates = national policy -=20 3.3=20 Title : IANA Registration for ENUMservice Mobile Webpage=20 Author(s) : J. Ra, et al.=20 Filename : draft-ra-shin-enum-mobileweb-00.txt=20 Pages :=20 Date : 2005-7-7=20 This document registers the ENUMservice "mobweb" using the URI = schemes 'http:' and 'https:' as per the IANA registration process = defined in the ENUM specification RFC3761.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt=20 =20 WG ACTION: Considerable disagreement on the nature and scope that this = document ultimately has. WG decision NOT to make WG item at this time. =20 DISCUSSION:=20 Discussion dove into issue of DNS vs. Application layer indication of = protocol stack capabilities.=20 - Meta question, what are the criteria for an ENUMSERVICE = registration? There was a general discussion of what those possible = criterion are. - In the classic registration cases, want to know if there's common = protocol before setting up a transport arrangement (connection)=20 - HTTP negotiation accomplishes the same once connection is in place = - This draft introduces "Complexity" in placing possible application = negotiation in two places (DNS and HTTP)=20 - RFC 3824, guidelines on SIP and ENUM as reference=20 - Consensus in discussion that ENUMSERVICE registrations should NOT = be used to negotiate capabilities that could be handled within the = underlying protocol. Registrations are useful to discover hints as to = the underlying service or protocol if no other method is available. 4. ENUM Validation Issues. 3 Drafts 15 -20=20 4.1 ENUM Validation Architecture = draft-mayrhofer-enum-validation-arch-00=20 Title : ENUM Validation Architecture=20 Author(s) : A. Mayrhofer, B. Hoeneisen=20 Filename : draft-mayrhofer-enum-validation-arch-00.txt=20 Pages : 16=20 Date : 2005-7-11=20 An ENUM domain name is tightly coupled with the underlying E.164 = number. The process of verifying whether or not the Registrant of an = ENUM domain name is identical to the Assignee of the corresponding = E.164 number is commonly called ^validation^. This document describes = validation requirements and a high level architecture for an ENUM = validation infrastructure.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-= 00.txt=20 =20 WG ACTION : WG humm agrees to draft as ENUM WG work item.=20 4.2 "ENUM Validation Token Format Definition" - = draft-lendl-enum-validation-token-00.txt=20 Title : ENUM Validation Token Format Definition=20 Author(s) : O. Lendl=20 Filename : draft-lendl-enum-validation-token-00.txt=20 Pages : 16=20 Date : 2005-7-11=20 An ENUM domain name is tightly coupled with the underlying E.164 = number. The process of verifying whether the Registrant of an ENUM = domain name is identical to the Assignee of the corresponding E.164 = number is commonly called ^validation^. This document describes an = signed XML data format -- the Validation Token -- with which=20 Validation Entities can convey successful completion of a validation = procedure in a secure fashion.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.= txt=20 WG ACTION : WG humm agrees to draft as ENUM WG work item.=20 4.3 Bernie Hoeneisen=20 http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt=20 http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html=20 WG ACTION : WG humm agrees to draft as ENUM WG work item.=20 DISCUSSION: Very little technical discussion of the above 3 documents. #################=20 5. PART 2 1/2 hours. 3 Items=20 WG AGENDA: Terms and Conditions of discussion. The first order of business is to attempt to create some very basic = common ground on what is the problem Carrier/Infrastructure/Private ENUM = is trying to solve based on what we generally understand are the = orthogonal interests of A. the E.164 number holder vs B. the carrier of = record for that number. In addition try to place this problem statement = in the over all context of converged carrier networks and the desire for = interconnection and peering.=20 We are NOT going to solve the Carrier ENUM definition and problem = statement in Paris but there needs to be some baseline before we can = generally review the drafts at hand.=20 =20 #################=20 5.1 Discussion of drafts on Carrier ENUM - Requirements ?=20 Title : Infrastructure ENUM Requirements=20 Author(s) : S. Lind=20 Filename : draft-lind-infrastructure-enum-reqs-00.txt=20 Pages : 8=20 Date : 2005-7-15=20 There has been much discussion in various industries about the concept = of infrastructure (or carrier) ENUM. Some of this discussion has been = has been reflected within the ENUM WG mailing list and some within other = organizations, including ETSI, the US ENUM Forum and the Country Code 1 = ENUM LLC. While there has been consensus within some pockets of = individual efforts, there has been little consensus industry-wide on = even what infrastructure ENUM is, why it seems to be important, or what = the requirements for implementing it are.=20 At the request of the WG co-chairs, this document attempts to gather = together the bits and pieces from those discussions (i.e., I stole the = words shamelessly from the various sources) and, with an absolute = minimum of editing, present them in some sort of cohesive manner that = will enable enlightened discussion and hopefully achieve consensus. = Some items listed below may be duplicative and suggest alternative = wordings for similar and other contradictory issues. As such, this list = is very raw and should not be viewed as complete, cohesive or correct.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-0= 0.txt =20 WG ACTION: This document is now a WG item and is a requirement for any = other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind = thanked for putting such a document together on such short notice. Penn Pfautz agrees to collaborate with Steve Lind on future drafts. 5.2 Title : IANA Carrier/User enumservice Registration=20 Author(s) : P. Pfautz, et al.=20 Filename : draft-pfautz-lind-enum-carrier-user-00.txt=20 Pages : 10=20 Date : 2005-6-6=20 This document registers, pursuant to the guidelines in RFC 3761, = tElephone NUmber Mapping (ENUM) services to allow a single registry to = support end user and carrier services with independent name servers = holding the terminal NAPTR (Naming Authority Pointer) records = identifying the communication services for each. The to-be- registered = enumservices make use of non-terminal NAPTR records and DDDS (Dynamic = Delegation Discovery System) replacement to achieve this end.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-0= 0.txt=20 5.3 Title : Combined User and Carrier ENUM in the = e164.arpa tree=20 Author(s) : M. Haberler, R. Stastny=20 Filename : draft-haberler-carrier-enum-00.txt=20 Pages : 10=20 Date : 2005-7-11=20 ENUM as defined now in RFC3761 is not well suited for the purpose of = interconnection by carriers, as can be seen by the use of various = private tree arrangements based on ENUM mechanisms. A combined end- = user and carrier ENUM tree solution would leverage the ENUM = infrastructure in e164.arpa, increase resolution rates, and decrease the = cost per registered telephone number. This document describes a=20 minimally invasive scheme to provide both end-user and carrier data in = ENUM.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt=20 DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed = together. As opposed to end user, opt-in ENUM, this is registration of = information in DNS for carriers. Service provider of record as opposed = to the number holder is considered the effective registrant. Three = approaches were mentioned but only two seem "obvious".=20 Non-terminal NAPTR records=20 Records are placed in e164.arpa domain, at the tel number. One record = for end user other for carrier. Differentiation is inside NAPTR record = with the use of the NAPTR substititution field to indicate different = re-write rules to generate the next lookup.=20 Separated branches of the DNS tree=20 A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main = tree where [CC ] is the relevant Country code or B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main = tree where [CC ] is the relevant Country code. Difference being = authority delegated pre or post RIPE/ITU. End users ( number holders) remain in .e164.arpa. carriers = in .c.e164.arpa.=20 Requirements/Desired results=20 1) Minimize number of lookups=20 2) Retain flexibility=20 3) Consistency from CC to CC for predictability=20 Discussion=20 - Data in DNS does not guarantee reachability ("deny's" allowed)=20 - DNS MUST answer. - Uniformity in "c" label, name and where, is important=20 - Non-terminal NAPTRs are untried=20 - Questions on whether DNS wildcards are pertinent to the issue=20 - Three questions - what's better for 1) DNS, 2) Application, and 3) = "life"=20 - Should not preclude private carrier-carrier traffic control=20 WG ACTION : Chair asks for a show of hands whether the WG should accept = the general concept of Carrier ENUM as a WG item. There was a large show = of hands that Carrier ENUM is of interest as a work topic no = dissentions. Further Discussion on Next Steps - Needs requirements and especially use cases to indicate what it is = about=20 WG ACTION: Requirements document added as WG item.=20 - RFC 3761 should remain untouched=20 - Scope needs definition (stop at re-write rules?)=20 - Use cases, use cases, use cases=20 - Terminology and definitions needed=20 The Chair also asked for a non binding "straw poll" based on the three = approaches on which is preferred "at this time". =20 3 Options=20 A. Pfautz approach of use of non-terminal NAPTR's=20 B. Haberler/Stastny approach with delegation at RIPE/ITU aka [CC]. = c.e164.arpa=20 C. Haberler/Stastny approach with delegation after RIPE/ITU c. = [CC].e164.arpa=20 Hum indicates strong preference for B/C with further discussion the WG = necessary. Further Discussion: Division of labor with VOIPEER BoF effort required=20 6.0 Title : Non-Terminal NAPTR Processing: A Modest Proposal=20 Author(s) : L. Conroy=20 Filename : draft-conroy-enum-modestproposal-00.txt=20 Pages : 12=20 Date : 2005-7-6=20 Recent Discussions within the IETF and in other fora have highlighted = differences in interpretation of the set of standards associated with = ENUM and DDDS, on which it relies. Specifically, the operation and = semantics surrounding support for non-terminal NAPTRs has led to some = confusion. This document is n attempt to add clarification to non- = terminal NAPTR processing. In this, it clarifies RFC3403. A = subsequent document will build on this one to extend FC3761 further, = permitting registration of non-terminal Enumservices.=20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.tx= t = =20 WG ACTION : No action taken. Document may be incorporated into revision = of RFC 3761 since it is clear there are a number of changes that have to = be made before it could become Draft Standard. =20 Meeting Concludes. --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or=20 = =20 ; = =20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Aug 20 11:30:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VIH-0008LV-4l; Sat, 20 Aug 2005 11:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68g1-0000Ka-MI; Fri, 19 Aug 2005 11:21:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09285; Fri, 19 Aug 2005 11:20:58 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E69Fw-0004Fl-T2; Fri, 19 Aug 2005 11:58:12 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1124464745!4536884!34 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 17989 invoked from network); 19 Aug 2005 15:20:46 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-2.tower-121.messagelabs.com with SMTP; 19 Aug 2005 15:20:46 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00BE08FD; Fri, 19 Aug 2005 11:20:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy Date: Fri, 19 Aug 2005 10:20:44 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0B9F0@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy Thread-Index: AcWkB9++suo9C9jMTIqCssYGDRyfqQAG9qlBAAImIUYAKKXAUAAAmdBw From: "Dolly, Martin C, ALABS" To: "Michael Hammer \(mhammer\)" , "Stastny Richard" , "Jonathan Rosenberg \(jdrosen\)" , "Brian Rosen" X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a78ee79e7121d5e3529be34866f161 X-Mailman-Approved-At: Sat, 20 Aug 2005 11:29:59 -0400 Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Otmar Lendl , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1744439235==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1744439235== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A4D1.919E3AC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A4D1.919E3AC9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The only time I believe where the destination number may need to be restricted is when there is a forwarding/redirection/refer... and the OCN is no longer the destination number. In this case the destination number may be restricted to the calling party. -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]On Behalf Of Michael Hammer (mhammer) Sent: Friday, August 19, 2005 11:05 AM To: Stastny Richard; Jonathan Rosenberg (jdrosen); Brian Rosen Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl; enum@ietf.org Subject: RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin commonpolicy I don't get the privacy bit. The user dials a number, that is somehow interpreted as an E.164 number, then it gets omitted from the SIP address to hide from whom? It is called party, no? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto: enum-bounces@ietf.org] On=20 > Behalf Of Stastny Richard > Sent: Thursday, August 18, 2005 3:38 PM > To: Jonathan Rosenberg (jdrosen); Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl;=20 > enum@ietf.org > Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > telURIsin commonpolicy >=20 > Just one add-on before I am getting ahead of myself: > regarding: > >2. the SIP server of user A provider is now trying to figure=20 > out what=20 > >to do with the dialstring, e.g. using local mapping or=20 > translate it to=20 > >an E.164 number Now the provider either tries to look up=20 > ENUM to get a=20 > >SIP URI ... >=20 > in this case the ENUM entry will in most cases be=20 > sip:+ 439793321@userA.provider.com;user=3Dphone > or even > sip:\ 1@userA.provider.com;user=3Dphone >=20 > because of privacy reasons >=20 > -richard >=20 > ________________________________ >=20 > Von: owner-voipeer@lists.uoregon.edu im Auftrag von Stastny Richard > Gesendet: Do 18.08.2005 21:05 > An: Jonathan Rosenberg; Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl;=20 > enum@ietf.org > Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIsin commonpolicy >=20 >=20 >=20 > Jonathan, >=20 > I think you made a very important point here for a BCP coming=20 > out for voipeer: >=20 > >INVITE tel:+1973952500 SIP/2.0 > >Route: sip:@gateway.provider.com >=20 > instead of the currently used > sip:tel:+1973952500 @gateway.provider.com;user=3Dphone >=20 > I will try to summarize: >=20 > 1. The user A normally enters a dialstring, which should be=20 > signalled with a.=20 > sip: = 0114319793321@userA.provider.com;user=3Ddialstring;phone-context=3D+1 > (luckily there does not exist a global dialling plan, so=20 > always a context can be submitted) other examples are: > sip: 9793321@userA.provider.com;user=3Ddialstring;phone-context=3D+431 > or > sip: = 4321@sip.companyA.com;user=3Ddialstring;phone-context=3DcompanyA.com >=20 > b. only if the user enters a full E.164 number with + (or the=20 > device is able to convert this by its own, the signalling=20 > should be either with a tel:+4319793321 or with=20 > sip:+ 439793321@userA.provider.com The preferred way should be=20 > recommended >=20 > 2. the SIP server of user A provider is now trying to figure=20 > out what to do with the dialstring, e.g. using local mapping=20 > or translate it to an E.164 number Now the provider either=20 > tries to look up ENUM to get a SIP URI or forward the call to=20 > a gateway to the PSTN by one of the above proposed methods >=20 > >INVITE tel:+1973952500 SIP/2.0 > >Route: sip:@gateway.provider.com > or > sip:tel:+1973952500 @gateway.provider.com;user=3Dphone >=20 > There is only one issue left out: there is more then=20 > dialstrings which always have local context and full E.164=20 > numbers it is national numbers and non-E.164 numbers defined=20 > in RFC3966 defining the tel: URI >=20 > These are in my opinion no URN (because they are not unique=20 > and also need always a context. >=20 > It should be recommended that if possible always the global=20 > format should be used, the translation to a required national=20 > format should be done by the gateway interfacing to the PSTN >=20 > For signalling non-E.164 numbers some additional=20 > investigation seems to be necessary (examples) >=20 > -richard >=20 > ________________________________ >=20 > Von: geopriv-bounces@ietf.org im Auftrag von Jonathan Rosenberg > Gesendet: Do 18.08.2005 17:12 > An: Brian Rosen > Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; 'Otmar=20 > Lendl'; enum@ietf.org > Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIsin commonpolicy >=20 >=20 >=20 > I agree. There is a two step process, fundamentally: >=20 > dial string ----> name -----> address >=20 >=20 > The translation steps themselves can be done entirely in the=20 > UA, entirely in a proxy, or split. When one step is done in a=20 > UA, and the other in a proxy, there is a need to convey the=20 > dial string, the name, or the address on the wire (proxy to=20 > proxy is the same). The formats here are: >=20 > 1. dial strings would be represented using Brian's dial=20 > string draft, i.e.: >=20 > sip:@domain;user=3Ddialstring >=20 > 2. names are represented as tel URI, and is obtained by=20 > applying the dial string to the dial plan. >=20 > 3. addresses are represented as a SIP URI with user=3Dphone,=20 > and is obtained by performing enum, or through any other=20 > suitable translation service that can convert a name to an=20 > address. For example, a provider's databases may definitively=20 > say that a particular name is its own, and thus it can=20 > convert tel:number to sip: number@provider.com;user=3Dphone >=20 >=20 >=20 > In many cases, once a tel URI/name is determined, a provider=20 > can't obtain a sip URI for it. All it knows is that the=20 > number lives on the PSTN. In that case, it needs to go to a=20 > PSTN gateway. How to do this? I would argue further that the=20 > PSTN gateway represents a ROUTE to get to somewhere (the=20 > pstn) that can resolve the name to an address and route it=20 > there (all within the PSTN). In SIP, the way we do routing is=20 > via loose routes. So, to send a call to a pstn gateway: >=20 > INVITE tel:+1973952500 SIP/2.0 > Route: sip:@gateway.provider.com >=20 > The URI in the route header could contain a phone number in=20 > the user part, but the resource being identified for the=20 > route is not the phone number itself, but a piece of routing=20 > and gateway logic, and thus it makes no sense to have=20 > user=3Dphone there. >=20 > BTW, I had mentioned in the enum session while at the mic=20 > that I was working on a doc that talked about phone numbers=20 > in SIP and the difference between tel and sip URI; that doc=20 > basically says the above. >=20 > -Jonathan R. >=20 >=20 > Brian Rosen wrote: >=20 > > In step 1, if the phone does not do dialplan=20 > interpretation, then what=20 > > the user entered is a dialstring, and not a telephone number. This=20 > > could be encoded, as you show, as a SIP uri, but might be better=20 > > encoded as a dialstring, per=20 > draft-rosen-iptel-dialstring-02.txt. A=20 > > tel uri is explicitly NOT used to carry a dialstring. > > > > I think it would be better labeled as a dialstring, and not=20 > something=20 > > that could be confused as a telephone number. It remains true that=20 > > the user-part of sip: 5056416@my-voip-provider.at can only be=20 > > interpreted by the my-voip-provider.at domain, so your flow=20 > definitely can work. > > > > Brian > > > > -----Original Message----- > > From: enum-bounces@ietf.org [mailto: enum-bounces@ietf.org]=20 > On Behalf=20 > > Of Otmar Lendl > > Sent: Thursday, August 18, 2005 6:33 AM > > To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org > > Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIs in=20 > > commonpolicy > > > > On 2005/08/18 05:08, Jonathan Rosenberg < jdrosen@cisco.com> wrote: > > > >>My point is that I think it makes sense to consider the tel=20 > URI a URN,=20 > >>and that it is merely an accident of history that it wasn't=20 > a URN more=20 > >>properly. Now, as you and I both know phone numbers in the PSTN are=20 > >>abused to represent lots of things, but there is no reason to carry=20 > >>forward this confusion into voip. This is why I am=20 > proposing that when=20 > >>a phone number is in a tel URI, it represents a name. We don't know=20 > >>where it is on the network (indeed even if its on an IP=20 > network). To=20 > >>know that, we translate to an address. That address is a=20 > SIP URI. That=20 > >>SIP URI can contain a phone number, i.e. > >>sip:+ 19739525000 @provider.net"> 19739525000 @provider.net;user=3Dphone, however in = this > format the=20 > >>phone number has been resolved to an address. The act of porting a=20 > >>number is a change in the translation of the phone number as a name=20 > >>(the tel URI) to the phone number as an address (the SIP URI). > >> > > > > > > This is a very sensible notion. > > > > Based on this thinking the dialing of a number on a VoIP-phone goes=20 > > through the following conceptual stages: > > > > 1) User enters a (potentially partial) number on his phone. > > The phone appends its default domain and sends the=20 > invite to its proxy: > > e.g. sip: 5056416@my-voip-provider.at > > > > 2) The SIP proxy applies the local dialplan to translate the > > SIP address to an E.164 number: > > > > e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416 > > -> We now have a URN: tel:+4315056416 > > > > 3) The SIP proxy now tries to route the call. In this example, > > user ENUM finds: > > "E2U+sip" "!^.*$!sip: office@enum.at!" > > > > or it could map to the local PSTN gateway with an URI like > > sip:+ 4315056416 @AS5300.my-voip-provider.at"> 4315056416 @AS5300.my-voip-provider.at > > > > /ol >=20 > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 =20 > http://www.jdrosen.net PHONE: (973) 952-5000 =20 > http://www.cisco.com >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > ______________________________________________________________ > _______________ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ------_=_NextPart_001_01C5A4D1.919E3AC9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]telURIsin = commonpolicy
The=20 only time I believe where the destination number may need to be = restricted=20 is when there is a forwarding/redirection/refer... and the OCN is no = longer the=20 destination number. In this case the destination number may be = restricted to the=20 calling party.
-----Original Message-----
From: = geopriv-bounces@ietf.org=20 [mailto:geopriv-bounces@ietf.org]On Behalf Of Michael Hammer=20 (mhammer)
Sent: Friday, August 19, 2005 11:05 = AM
To:=20 Stastny Richard; Jonathan Rosenberg (jdrosen); Brian = Rosen
Cc:=20 geopriv@ietf.org; voipeer@lists.uoregon.edu; Otmar Lendl;=20 enum@ietf.org
Subject: RE: [Enum] Re: [voipeer] Re: = [Geopriv] Re:=20 [Simple]telURIsin commonpolicy

I don't get the = privacy=20 bit. The user dials a number, that is somehow
interpreted as an = E.164=20 number, then it gets omitted from the SIP
address to hide from = whom? It is=20 called party, no?

Mike


> -----Original=20 Message-----
> From: enum-bounces@ietf.org = [mailto:enum-bounces@ietf.org] On =
>=20 Behalf Of Stastny Richard
> Sent: Thursday, August 18, 2005 3:38 = PM
> To: Jonathan Rosenberg (jdrosen); Brian Rosen
> Cc: = geopriv@ietf.org; voipeer@lists.uoregon.edu; = Otmar=20 Lendl;
> enum@ietf.org
>=20 Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
>=20 telURIsin commonpolicy
>
> Just one add-on before I am = getting=20 ahead of myself:
> regarding:
> >2. the SIP server of = user A=20 provider is now trying to figure
> out what
> >to do = with the=20 dialstring, e.g. using local mapping or
> translate it to =
>=20 >an E.164 number Now the provider either tries to look up
> = ENUM to=20 get a
> >SIP URI ...
>
> in this case the ENUM = entry=20 will in most cases be
> sip:+439793321@userA.provider.com= ;user=3Dphone
>=20 or even
> sip:\1@userA.provider.com;user=3Dphon= e
>=20
> because of privacy reasons
>
> -richard
> =
>=20 ________________________________
>
> Von: owner-voipeer@lists.uoreg= on.edu=20 im Auftrag von Stastny Richard
> Gesendet: Do 18.08.2005 = 21:05
>=20 An: Jonathan Rosenberg; Brian Rosen
> Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; = Otmar=20 Lendl;
> enum@ietf.org
>=20 Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
> = tel=20 URIsin commonpolicy
>
>
>
> = Jonathan,
>=20
> I think you made a very important point here for a BCP coming =
> out for voipeer:
>
> >INVITE tel:+1973952500=20 SIP/2.0
> >Route:=20 sip:<whatever-you-want>@gateway.provider.com
>
> = instead of=20 the currently used
> sip:tel:+1973952500=20 @gateway.provider.com;user=3Dphone
>
> I will try to=20 summarize:
>
> 1. The user A normally enters a = dialstring, which=20 should be
> signalled with a.
> sip:0114319793321@userA.prov= ider.com;user=3Ddialstring;phone-context=3D+1
>=20 (luckily there does not exist a global dialling plan, so
> = always a=20 context can be submitted) other examples are:
> sip:9793321@userA.provider.com= ;user=3Ddialstring;phone-context=3D+431
>=20 or
> sip:4321@sip.companyA.com;user=3Ddi= alstring;phone-context=3DcompanyA.com
>=20
> b. only if the user enters a full E.164 number with + (or the =
> device is able to convert this by its own, the signalling =
>=20 should be either with a tel:+4319793321 or with
> sip:+439793321@userA.provider.com= =20 The preferred way should be
> recommended
>
> 2. = the SIP=20 server of user A provider is now trying to figure
> out what to = do with=20 the dialstring, e.g. using local mapping
> or translate it to = an E.164=20 number Now the provider either
> tries to look up ENUM to get a = SIP URI=20 or forward the call to
> a gateway to the PSTN by one of the = above=20 proposed methods
>
> >INVITE tel:+1973952500 = SIP/2.0
>=20 >Route: sip:<whatever-you-want>@gateway.provider.com
>=20 or
> sip:tel:+1973952500 = @gateway.provider.com;user=3Dphone
>=20
> There is only one issue left out: there is more then
> = dialstrings which always have local context and full E.164
> = numbers it=20 is national numbers and non-E.164 numbers defined
> in RFC3966 = defining=20 the tel: URI
>
> These are in my opinion no URN (because = they are=20 not unique
> and also need always a context.
>
> = It should=20 be recommended that if possible always the global
> format = should be=20 used, the translation to a required national
> format should be = done by=20 the gateway interfacing to the PSTN
>
> For signalling = non-E.164=20 numbers some additional
> investigation seems to be necessary=20 (examples)
>
> -richard
>
>=20 ________________________________
>
> Von: geopriv-bounces@ietf.org = im Auftrag=20 von Jonathan Rosenberg
> Gesendet: Do 18.08.2005 17:12
> = An: Brian=20 Rosen
> Cc: geopriv@ietf.org; voipeer@lists.uoregon.edu; = 'Otmar=20
> Lendl'; enum@ietf.org
>=20 Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple]
> = tel=20 URIsin commonpolicy
>
>
>
> I agree. There = is a two=20 step process, fundamentally:
>
> dial string ----> = name=20 -----> address
>
>
> The translation steps = themselves=20 can be done entirely in the
> UA, entirely in a proxy, or = split. When=20 one step is done in a
> UA, and the other in a proxy, there is = a need=20 to convey the
> dial string, the name, or the address on the = wire=20 (proxy to
> proxy is the same). The formats here are:
> =
>=20 1. dial strings would be represented using Brian's dial
> = string draft,=20 i.e.:
>
> = sip:<dial-string>@domain;user=3Ddialstring
>=20
> 2. names are represented as tel URI, and is obtained by =
>=20 applying the dial string to the dial plan.
>
> 3. = addresses are=20 represented as a SIP URI with user=3Dphone,
> and is obtained = by=20 performing enum, or through any other
> suitable translation = service=20 that can convert a name to an
> address. For example, a = provider's=20 databases may definitively
> say that a particular name is its = own, and=20 thus it can
> convert tel:number to sip:number@provider.com;user=3Dphone<= BR>>=20
>
>
> In many cases, once a tel URI/name is = determined, a=20 provider
> can't obtain a sip URI for it. All it knows is that = the=20
> number lives on the PSTN. In that case, it needs to go to a =
>=20 PSTN gateway. How to do this? I would argue further that the
> = PSTN=20 gateway represents a ROUTE to get to somewhere (the
> pstn) = that can=20 resolve the name to an address and route it
> there (all within = the=20 PSTN). In SIP, the way we do routing is
> via loose routes. So, = to send=20 a call to a pstn gateway:
>
> INVITE tel:+1973952500=20 SIP/2.0
> Route:=20 sip:<whatever-you-want>@gateway.provider.com
>
> = The URI in=20 the route header could contain a phone number in
> the user = part, but=20 the resource being identified for the
> route is not the phone = number=20 itself, but a piece of routing
> and gateway logic, and thus it = makes=20 no sense to have
> user=3Dphone there.
>
> BTW, I = had=20 mentioned in the enum session while at the mic
> that I was = working on=20 a doc that talked about phone numbers
> in SIP and the = difference=20 between tel and sip URI; that doc
> basically says the = above.
>=20
> -Jonathan R.
>
>
> Brian Rosen = wrote:
>=20
> > In step 1, if the phone does not do dialplan
>=20 interpretation, then what
> > the user entered is a = dialstring, and=20 not a telephone number. This
> > could be encoded, as you = show, as a=20 SIP uri, but might be better
> > encoded as a dialstring, = per=20
> draft-rosen-iptel-dialstring-02.txt. A
> > tel uri = is=20 explicitly NOT used to carry a dialstring.
> >
> > I = think=20 it would be better labeled as a dialstring, and not
> something =
> > that could be confused as a telephone number. It remains = true=20 that
> > the user-part of sip:5056416@my-voip-provider.at can=20 only be
> > interpreted by the my-voip-provider.at domain, = so your=20 flow
> definitely can work.
> >
> > = Brian
>=20 >
> > -----Original Message-----
> > From: enum-bounces@ietf.org = [mailto:enum-bounces@ietf.org] =
> On=20 Behalf
> > Of Otmar Lendl
> > Sent: Thursday, = August 18,=20 2005 6:33 AM
> > To: voipeer@lists.uoregon.edu; = geopriv@ietf.org; enum@ietf.org
> > Subject: = [Enum] Re:=20 [voipeer] Re: [Geopriv] Re: [Simple]
> tel URIs in
> = >=20 commonpolicy
> >
> > On 2005/08/18 05:08, Jonathan = Rosenberg=20 <jdrosen@cisco.com>=20 wrote:
> >
> >>My point is that I think it makes = sense to=20 consider the tel
> URI a URN,
> >>and that it is = merely an=20 accident of history that it wasn't
> a URN more
>=20 >>properly. Now, as you and I both know phone numbers in the = PSTN are=20
> >>abused to represent lots of things, but there is no = reason to=20 carry
> >>forward this confusion into voip. This is why I = am=20
> proposing that when
> >>a phone number is in a = tel URI,=20 it represents a name. We don't know
> >>where it is on = the=20 network (indeed even if its on an IP
> network). To
>=20 >>know that, we translate to an address. That address is a =
> SIP=20 URI. That
> >>SIP URI can contain a phone number, = i.e.
>=20 >>sip:+19739525000@provider.net">19739525000@provider.net;user=3Dphone, = however=20 in this
> format the
> >>phone number has been = resolved to=20 an address. The act of porting a
> >>number is a change = in the=20 translation of the phone number as a name
> >>(the tel = URI) to=20 the phone number as an address (the SIP URI).
> >>
> = >
> >
> > This is a very sensible notion.
> = >
> > Based on this thinking the dialing of a number on a=20 VoIP-phone goes
> > through the following conceptual = stages:
>=20 >
> > 1) User enters a (potentially partial) number on his = phone.
> > The phone appends its default domain and sends the =
> invite to its proxy:
> > e.g. sip:5056416@my-voip-provider.at
>=20 >
> > 2) The SIP proxy applies the local dialplan to = translate=20 the
> > SIP address to an E.164 number:
> >
> = >=20 e.g. customer is in vienna, thus 5056416 maps to +43 1 5056416
> = >=20 -> We now have a URN: tel:+4315056416
> >
> > 3) = The SIP=20 proxy now tries to route the call. In this example,
> > user = ENUM=20 finds:
> > "E2U+sip" "!^.*$!sip:office@enum.at!"
> = >
> > or=20 it could map to the local PSTN gateway with an URI like
> > = sip:+4315056416@AS5300.my-voip-provider.at">4315056416@AS5300.my-voip-provider.at>=20 >
> > /ol
>
> --
> Jonathan D. = Rosenberg, Ph.D.=20 600 Lanidex Plaza
> Director, Service Provider VoIP Architecture = Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.cisco.com
> =
>=20 _______________________________________________
> Geopriv = mailing=20 list
> Geopriv@ietf.org
> https://www1.ietf= .org/mailman/listinfo/geopriv
>=20
>
>
>=20 ______________________________________________________________
> = _______________
> List Archive: http://darkwing.uor= egon.edu/~llynch/voipeer/
>=20 User Tools: http://darkwing= .uoregon.edu/~llynch/voipeer.html
>=20
>
>
>=20 _______________________________________________
> enum mailing=20 list
> enum@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/enum
>=20

_______________________________________________
Geopriv = mailing=20 list
Geopriv@ietf.org
https://www1.ietf= .org/mailman/listinfo/geopriv
 ------_=_NextPart_001_01C5A4D1.919E3AC9-- --===============1744439235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1744439235==-- From enum-bounces@ietf.org Sat Aug 20 11:30:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VIH-0008Lw-Mx; Sat, 20 Aug 2005 11:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6EWW-0000jb-9l; Fri, 19 Aug 2005 17:35:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06551; Fri, 19 Aug 2005 17:35:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6F6X-0000wI-0Q; Fri, 19 Aug 2005 18:12:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2005 14:35:26 -0700 X-IronPort-AV: i="3.96,127,1122879600"; d="scan'208"; a="333983898:sNHT33705556" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JLYwQe018327; Fri, 19 Aug 2005 14:35:23 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 17:35:22 -0400 Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 17:35:39 -0400 Message-ID: <43065099.3090504@cisco.com> Date: Fri, 19 Aug 2005 17:35:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy References: <072C5B76F7CEAB488172C6F64B30B5E374C9AA@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2005 21:35:39.0770 (UTC) FILETIME=[F1A885A0:01C5A505] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Aug 2005 11:29:59 -0400 Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , "James Polk \(jmpolk\)" , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Michael Hammer (mhammer) wrote: > James, > > This seems to be a number portability question. E.164 numbers get > assigned by the national authority either directly to the individual or > to a carrier. > > In the individual case, when the number ports from one SIP address to > another, it remains "owned" by the individual. > > In the carrier case (at least in the US as I understand it), the number > is assigned to what is known as the donor switch/network/carrier. This > is typically the network that "owned" the number before number > portability was invented. When a user ports to a new serving > switch/network/carrier, the NP database maps the number to a location > routing number (LRN). Carrier ENUM does essentially the same thing, it > records the current E.164 to SIP URI of Serving Carrier point of > interconnect. > > If the user ports again, the donor network remains the same, while the > serving network in ENUM will change. I thought I saw a note that the ENUM WG accepted a work item to do exactly this, which would imply that it isn't yet being done this way. If its not, then I would assume that the carrier enum would simply point to the donor network. > If the user relinquishes the number (cancels service), the number > reverts back to the donor network to be assigned to their next new > customer. (Not sure if this is same worldwide.) > > If one carrier buys another carrier, then the numbers owned by the > acquired carrier will now belong to the buying carrier. > > So: > > Donor 1 = ENUM leaf (original carrier moves customer to ENUM) > Donor 1 -> Serving 2 = ENUM leaf (first port) > Donor 1 -> Serving 3 = ENUM leaf (second port) > Donor 1 -> Serving 4 = ENUM leaf (third port) > Donor 5 -> Serving 4 = ENUM leaf (carrier 5 buys carrier 1) > Donor 5 = ENUM leaf (customer cancels) > > Does that make sense? Modulo the above comments. But I don't think this really has a whole lot to do with the original question. This comes down to whether you believe that sip:+1-232-555-1234@foo.com;user=phone is only valid if foo.com is the serving network/carrier for +1-232-555-1234. There are a whole lot of people who don't think that. In my mind all that you can conclude from such a URI is that foo.com is to participate in routing calls to that URI. Whether they terminate in foo.com's network, or are eventually terminated someplace else is for foo.com to decide. Paul >>-----Original Message----- >>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On >>Behalf Of James Polk (jmpolk) >>Sent: Wednesday, August 17, 2005 12:46 PM >>To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul >>Kyzivat (pkyzivat); voipeer@lists.uoregon.edu >>Cc: geopriv@ietf.org; enum@ietf.org >>Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy >> >>At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: >> >>>I fully agree that there seems to be an issue here, because >> >>the problem >> >>>is currently discussed at voipeer also.The format >>>sip:+1-232-555-1234@foo.com;user=phone >>>gets very important especially for Carrier ENUM indicating the >>>destination providers (see below) >> >>So, and perhaps this is a naive point/question - what happens >>when a carrier no longer operates a phone number that is in >>operation by another carrier? >> >>For example, my wife has had the same cell phone number for >>15+ years, yet she has recently changed to her third carrier. >> The company that originally owned her phone number is being >>acquired by a 4th company now (here in the US, giving you a >>hint as to two of the players involved). >> >>What does this do to your statement: >> >> "The format sip:+1-232-555-1234@foo.com;user=phone >>gets very important especially for Carrier ENUM indicating >>the destination providers" >> >> >>>It also concerns the CLI and CLIR aspect not yet fully discussed in >>>voipeer. This is one issue definitely in scope of voipeer. >>> >>>comments inline >>> >> >> >>cheers, >>James >> >> ******************* >> Truth is not to be argued... it is to be presented. >> >>_______________________________________________ >>enum mailing list >>enum@ietf.org >>https://www1.ietf.org/mailman/listinfo/enum >> > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Aug 20 11:30:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6VII-0008MO-9d; Sat, 20 Aug 2005 11:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6GLu-0006vC-Mz; Fri, 19 Aug 2005 19:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12091; Fri, 19 Aug 2005 19:32:43 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Gvv-0003r0-81; Fri, 19 Aug 2005 20:10:01 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2005 16:32:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7JNWV2i018189; Fri, 19 Aug 2005 16:32:32 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 19:32:31 -0400 Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 19:32:31 -0400 Message-ID: <43066C0E.6010301@cisco.com> Date: Fri, 19 Aug 2005 19:32:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy References: <072C5B76F7CEAB488172C6F64B30B5E37C484F@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2005 23:32:31.0179 (UTC) FILETIME=[44C8A1B0:01C5A516] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Aug 2005 11:29:59 -0400 Cc: geopriv@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , "James Polk \(jmpolk\)" , enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Mike, I agree that the keepers of an enum root can make any rules they want about what can go into it. So what you suggest would be perfectly reasonable in carrier enum. But that has little to do with what goes in From and To, or much of anywhere else. Paul Michael Hammer (mhammer) wrote: > Paul, > > I understand what you are driving at when presented a sip address > containing an E.164 number with no other context. But, I would suggest > that putting such a number into Carrier ENUM must be limited to the > carrier of record currently serving that phone number. Otherwise, what > stops all 3000+ carriers in the US from asking to put an entry for my > phone number into that location of the Carrier ENUM tree pointing > traffic to their domain? > > Mike > > > >>-----Original Message----- >>From: Paul Kyzivat (pkyzivat) >>Sent: Friday, August 19, 2005 5:35 PM >>To: Michael Hammer (mhammer) >>Cc: James Polk (jmpolk); Stastny Richard; Jonathan Rosenberg >>(jdrosen); voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org >>Subject: Re: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in >>common policy >> >> >> >>Michael Hammer (mhammer) wrote: >> >>>James, >>> >>>This seems to be a number portability question. E.164 numbers get >>>assigned by the national authority either directly to the >> >>individual >> >>>or to a carrier. >>> >>>In the individual case, when the number ports from one SIP >> >>address to >> >>>another, it remains "owned" by the individual. >>> >>>In the carrier case (at least in the US as I understand it), the >>>number is assigned to what is known as the donor >>>switch/network/carrier. This is typically the network that "owned" >>>the number before number portability was invented. When a >> >>user ports >> >>>to a new serving switch/network/carrier, the NP database maps the >>>number to a location routing number (LRN). Carrier ENUM does >>>essentially the same thing, it records the current E.164 to >> >>SIP URI of >> >>>Serving Carrier point of interconnect. >>> >>>If the user ports again, the donor network remains the >> >>same, while the >> >>>serving network in ENUM will change. >> >>I thought I saw a note that the ENUM WG accepted a work item >>to do exactly this, which would imply that it isn't yet being >>done this way. >>If its not, then I would assume that the carrier enum would >>simply point to the donor network. >> >> >>>If the user relinquishes the number (cancels service), the number >>>reverts back to the donor network to be assigned to their next new >>>customer. (Not sure if this is same worldwide.) >>> >>>If one carrier buys another carrier, then the numbers owned by the >>>acquired carrier will now belong to the buying carrier. >>> >>>So: >>> >>>Donor 1 = ENUM leaf (original carrier moves customer to >> >>ENUM) Donor 1 >> >>>-> Serving 2 = ENUM leaf (first port) Donor 1 -> Serving 3 = ENUM >>>leaf (second port) Donor 1 -> Serving 4 = ENUM leaf (third port) >>>Donor 5 -> Serving 4 = ENUM leaf (carrier 5 buys carrier >> >>1) Donor 5 = >> >>>ENUM leaf (customer cancels) >>> >>>Does that make sense? >> >>Modulo the above comments. But I don't think this really has >>a whole lot to do with the original question. This comes down >>to whether you believe that >> >> sip:+1-232-555-1234@foo.com;user=phone >> >>is only valid if foo.com is the serving network/carrier for >>+1-232-555-1234. There are a whole lot of people who don't think that. >> >>In my mind all that you can conclude from such a URI is that >>foo.com is to participate in routing calls to that URI. >>Whether they terminate in foo.com's network, or are >>eventually terminated someplace else is for foo.com to decide. >> >> Paul >> >> >> >>>>-----Original Message----- >>>>From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] >>> >>On Behalf >> >>>>Of James Polk (jmpolk) >>>>Sent: Wednesday, August 17, 2005 12:46 PM >>>>To: Stastny Richard; Jonathan Rosenberg (jdrosen); Paul Kyzivat >>>>(pkyzivat); voipeer@lists.uoregon.edu >>>>Cc: geopriv@ietf.org; enum@ietf.org >>>>Subject: [Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy >>>> >>>>At 06:14 PM 8/17/2005 +0200, Stastny Richard wrote: >>>> >>>> >>>>>I fully agree that there seems to be an issue here, because >>>> >>>>the problem >>>> >>>> >>>>>is currently discussed at voipeer also.The format >>>>>sip:+1-232-555-1234@foo.com;user=phone >>>>>gets very important especially for Carrier ENUM indicating the >>>>>destination providers (see below) >>>> >>>>So, and perhaps this is a naive point/question - what >>> >>happens when a >> >>>>carrier no longer operates a phone number that is in operation by >>>>another carrier? >>>> >>>>For example, my wife has had the same cell phone number for >>>>15+ years, yet she has recently changed to her third carrier. >>>>The company that originally owned her phone number is >>> >>being acquired >> >>>>by a 4th company now (here in the US, giving you a hint as >>> >>to two of >> >>>>the players involved). >>>> >>>>What does this do to your statement: >>>> >>>> "The format sip:+1-232-555-1234@foo.com;user=phone >>>>gets very important especially for Carrier ENUM indicating the >>>>destination providers" >>>> >>>> >>>> >>>>>It also concerns the CLI and CLIR aspect not yet fully >>>> >>discussed in >> >>>>>voipeer. This is one issue definitely in scope of voipeer. >>>>> >>>>>comments inline >>>>> >>>> >>>> >>>>cheers, >>>>James >>>> >>>> ******************* >>>> Truth is not to be argued... it is to be presented. >>>> >>>>_______________________________________________ >>>>enum mailing list >>>>enum@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/enum >>>> >>> >>> >> > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Aug 20 12:19:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6W3s-0000w9-Kd; Sat, 20 Aug 2005 12:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6W3q-0000vj-Mf for enum@megatron.ietf.org; Sat, 20 Aug 2005 12:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28133 for ; Sat, 20 Aug 2005 12:19:08 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Wdz-0008UR-NH for enum@ietf.org; Sat, 20 Aug 2005 12:56:34 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7KGJeeQ010466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Aug 2005 09:19:42 -0700 Message-ID: <430757EC.9060808@shockey.us> Date: Sat, 20 Aug 2005 12:18:52 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2 References: <32755D354E6B65498C3BD9FD496C7D4613C0E0@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0E0@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Stastny Richard wrote: >Sorry to be picky, but it is wrong again: > > OK no problem ... > >It should read: > >The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time". > > > >3 Options > >A. Pfautz approach of use of non-terminal NAPTR's >B. Haberler/Stastny approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa or > with delegation after RIPE/ITU c. [CC].e164.arpa >C. Using a different (non-e164.arpa) domain > >Hum indicates strong preference for B with further discussion the WG necessary. > >-richard > > >________________________________ > >Von: enum-bounces@ietf.org im Auftrag von Richard Shockey >Gesendet: Sa 20.08.2005 04:08 >An: enum@ietf.org >Betreff: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2 > > >IETF 63 Telephone Number Mapping (ENUM) WG Meeting Minutes > >Comments from the list incorporated. > > >Chair(s): >Patrik Faltstrom >Richard Shockey > >Transport Area Advisor: >Allison Mankin > > > > >Friday, August 6 2005 9:AM to 12:30 PM > >AGENDA BASHING (5 min) > > >1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? ) > >Title : ENUM Implementation Issues and Experiences > Author(s) : L. Conroy, K. Fujiwara > Filename : draft-ietf-enum-experiences-02.txt > Pages : 29 > Date : 2005-7-1 > >This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt > > > >WG ACTION : After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC. > > >2. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? ) > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt > > > >WG ACTION : Put this document into WGLC after one more revision by author. > > > >DISCUSSION Some concerns whether this document is mature enough for even WG last call, response is that the document will see another revision and pushing towards last call is only meant to spur document forward. > >3. New/old work on enumservice registrations ( 20 M ) > >3.1 > > > Title : IANA Registration for Enumservice Voice > Author(s) : R. Brandner, et al. > Filename : draft-brandner-enum-voice-00.txt > Pages : 12 > Date : 2005-7-7 > > This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt > >WG ACTION : WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration. > >DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel. > > >3.2 > Title : IANA Registration for an Enumservice Containing Number Portability and PSTN > Signaling Information > Author(s) : J. Livingood, R. Shockey > Filename : draft-livingood-shockey-enum-npd-00.txt > Pages : 8 > Date : 2005-7-8 > > This document registers the Enumservice "npd" and subtype "tel" using the URI scheme 'tel:' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt > > > >WG ACTION : WG humm agrees to draft as ENUM WG work item. > > > >DISCUSSION : > > > >Comments include: > - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier > - Global Spin Std. > - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached. > - TEL URI scope problem : examples should include both TEL and SIP URI examples > - For IMS, limited usefulness > - RFC 3671 db? 1 or collection? (Latter) > > - Document should discuss sage of portability data as it relates national policy > - > > >3.3 > > Title : IANA Registration for ENUMservice Mobile Webpage > Author(s) : J. Ra, et al. > Filename : draft-ra-shin-enum-mobileweb-00.txt > Pages : > Date : 2005-7-7 > > This document registers the ENUMservice "mobweb" using the URI schemes 'http:' and 'https:' as per the IANA registration process defined in the ENUM specification RFC3761. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt > > > >WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time. > > > >DISCUSSION: >Discussion dove into issue of DNS vs. Application layer indication of protocol stack capabilities. > > - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are. > - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection) > - HTTP negotiation accomplishes the same once connection is in place > - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP) > - RFC 3824, guidelines on SIP and ENUM as reference > > - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available. > > > >4. ENUM Validation Issues. 3 Drafts 15 -20 > > 4.1 ENUM Validation Architecture draft-mayrhofer-enum-validation-arch-00 > > Title : ENUM Validation Architecture > Author(s) : A. Mayrhofer, B. Hoeneisen > Filename : draft-mayrhofer-enum-validation-arch-00.txt > Pages : 16 > Date : 2005-7-11 > > An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt > > > > >WG ACTION : WG humm agrees to draft as ENUM WG work item. > > > >4.2 "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt > > > Title : ENUM Validation Token Format Definition > Author(s) : O. Lendl > Filename : draft-lendl-enum-validation-token-00.txt > Pages : 16 > Date : 2005-7-11 > > An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes an signed XML data format -- the Validation Token -- with which > Validation Entities can convey successful completion of a validation procedure in a secure fashion. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt > >WG ACTION : WG humm agrees to draft as ENUM WG work item. > >4.3 Bernie Hoeneisen > > > > http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt > http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html > >WG ACTION : WG humm agrees to draft as ENUM WG work item. > >DISCUSSION: Very little technical discussion of the above 3 documents. > > > >################# > >5. PART 2 1/2 hours. 3 Items > >WG AGENDA: Terms and Conditions of discussion. > >The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering. > >We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand. > > > >################# > >5.1 Discussion of drafts on Carrier ENUM - Requirements ? > > Title : Infrastructure ENUM Requirements > Author(s) : S. Lind > Filename : draft-lind-infrastructure-enum-reqs-00.txt > Pages : 8 > Date : 2005-7-15 > > There has been much discussion in various industries about the concept of infrastructure (or carrier) ENUM. Some of this discussion has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus industry-wide on even what infrastructure ENUM is, why it seems to be important, or what the requirements for implementing it are. > > At the request of the WG co-chairs, this document attempts to gather together the bits and pieces from those discussions (i.e., I stole the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that will enable enlightened discussion and hopefully achieve consensus. Some items listed below may be duplicative and suggest alternative wordings for similar and other contradictory issues. As such, this list is very raw and should not be viewed as complete, cohesive or correct. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt > > > >WG ACTION: This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice. > >Penn Pfautz agrees to collaborate with Steve Lind on future drafts. > > > >5.2 Title : IANA Carrier/User enumservice Registration > Author(s) : P. Pfautz, et al. > Filename : draft-pfautz-lind-enum-carrier-user-00.txt > Pages : 10 > Date : 2005-6-6 > >This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt > > >5.3 Title : Combined User and Carrier ENUM in the e164.arpa tree > Author(s) : M. Haberler, R. Stastny > Filename : draft-haberler-carrier-enum-00.txt > Pages : 10 > Date : 2005-7-11 > > ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a >minimally invasive scheme to provide both end-user and carrier data in ENUM. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt > > > > >DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together. > > > As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant. Three approaches were mentioned but only two seem "obvious". > > Non-terminal NAPTR records > > Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier. Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup. > > Separated branches of the DNS tree > > A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or > >B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU. > > End users ( number holders) remain in .e164.arpa. carriers in .c.e164.arpa. > > Requirements/Desired results > 1) Minimize number of lookups > 2) Retain flexibility > 3) Consistency from CC to CC for predictability > > Discussion > > - Data in DNS does not guarantee reachability ("deny's" allowed) > > - DNS MUST answer. > - Uniformity in "c" label, name and where, is important > - Non-terminal NAPTRs are untried > - Questions on whether DNS wildcards are pertinent to the issue > - Three questions - what's better for 1) DNS, 2) Application, and 3) "life" > - Should not preclude private carrier-carrier traffic control > >WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions. > > > >Further Discussion on Next Steps > > - Needs requirements and especially use cases to indicate what it is about > >WG ACTION: Requirements document added as WG item. > - RFC 3761 should remain untouched > - Scope needs definition (stop at re-write rules?) > - Use cases, use cases, use cases > - Terminology and definitions needed > > The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time". > > > >3 Options > >A. Pfautz approach of use of non-terminal NAPTR's >B. Haberler/Stastny approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa >C. Haberler/Stastny approach with delegation after RIPE/ITU c. [CC].e164.arpa > >Hum indicates strong preference for B/C with further discussion the WG necessary. > > >Further Discussion: > >Division of labor with VOIPEER BoF effort required > > > >6.0 Title : Non-Terminal NAPTR Processing: A Modest Proposal > Author(s) : L. Conroy > Filename : draft-conroy-enum-modestproposal-00.txt > Pages : 12 > Date : 2005-7-6 > > Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is n attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend FC3761 further, permitting registration of non-terminal Enumservices. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt > >WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard. > > > >Meeting Concludes. > > > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Aug 20 12:22:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6W73-0001R5-43; Sat, 20 Aug 2005 12:22:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6W72-0001Qv-3D for enum@megatron.ietf.org; Sat, 20 Aug 2005 12:22:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28255 for ; Sat, 20 Aug 2005 12:22:25 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6WhD-00007U-1M for enum@ietf.org; Sat, 20 Aug 2005 12:59:52 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7KGMuAc010641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Aug 2005 09:22:57 -0700 Message-ID: <430758B0.3010500@shockey.us> Date: Sat, 20 Aug 2005 12:22:08 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Subject: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 3 Content-Type: multipart/mixed; boundary="------------090007050906080600060204" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.4 (+) X-Scan-Signature: 6852087d2a39b5d20c975154ae1cd415 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --------------090007050906080600060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IETF 63  Telephone Number Mapping (ENUM) WG Meeting Minutes

Comments from the list incorporated.

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

Transport Area Advisor:
Allison Mankin  <mankin@psg.com>


Friday, August 6 2005  9:AM to 12:30 PM

AGENDA BASHING (5 min)


1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )

Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-02.txt
        Pages           : 29
        Date            : 2005-7-1

This document captures experience in implementing systems based on    the ENUM protocol, and experience of ENUM data that have been created    by others.  As such, it is informational only, and produced as a help    to others in reporting what is "out there" and the potential pitfalls  in interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt

 

WG ACTION :  After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.


2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

WG ACTION : Put this document into WGLC after one more revision by author.

DISCUSSION Some concerns whether this document is mature enough for even WG last call,  response is that the document will see another revision and pushing towards    last call is only meant to spur document forward.

3. New/old work on enumservice registrations  ( 20 M )

3.1


        Title           : IANA Registration for Enumservice Voice
        Author(s)       : R. Brandner, et al.
        Filename        : draft-brandner-enum-voice-00.txt
        Pages           : 12
        Date            : 2005-7-7

   This document registers the ENUMservice ^voice^ (which has a defined    sub-type ^tel^), as per the IANA registration process defined in the    ENUM specification RFC3761.  This service indicates that the contact   held in the generated URI can be used to initiate an interactive  voice (audio) call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.

DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.


3.2
        Title   : IANA Registration for an Enumservice  Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8

   This document registers the Enumservice "npd" and subtype "tel" using    the URI scheme 'tel:' as per the IANA registration process defined in   the ENUM specification, RFC 3761.  This data is used to facilitate  the routing of telephone calls in those countries where Number  Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt

 

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 

DISCUSSION :

 

Comments include:
    - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
    - Global Spin Std.
    - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
    - TEL URI scope problem : examples should include both TEL and SIP URI examples
    - For IMS, limited usefulness
    - RFC 3671 db?  1 or collection? (Latter) 

    - Document should discuss sage of portability data as it relates national policy
    -


3.3

  Title           : IANA Registration for ENUMservice Mobile Webpage
  Author(s)       : J. Ra, et al.
  Filename        : draft-ra-shin-enum-mobileweb-00.txt
  Pages           :
  Date            : 2005-7-7

   This document registers the ENUMservice “mobweb” using the URI    schemes 'http:' and 'https:' as per the IANA registration process  defined in the ENUM specification RFC3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt

 

WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.

 

DISCUSSION:
Discussion dove into issue of DNS vs. Application layer indication of  protocol stack capabilities.

    - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
    - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection)
    - HTTP negotiation accomplishes the same once connection is in place
    - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP)
    - RFC 3824, guidelines on SIP and ENUM as reference

   - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.



4. ENUM Validation Issues. 3 Drafts 15 -20

 4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00

        Title           : ENUM Validation Architecture
        Author(s)       : A. Mayrhofer, B. Hoeneisen
        Filename        : draft-mayrhofer-enum-validation-arch-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164   number.  The process of verifying whether or not the Registrant of an  ENUM domain name is identical to the Assignee of the corresponding  E.164 number is commonly called ^validation^.  This document  describes validation requirements and a high level architecture for  an ENUM validation infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt

 


WG ACTION :  WG humm agrees to draft as ENUM WG work item.



4.2  "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt


        Title           : ENUM Validation Token Format Definition
        Author(s)       : O. Lendl
        Filename        : draft-lendl-enum-validation-token-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164  number.  The process of verifying whether the Registrant of an ENUM  domain name is identical to the Assignee of the corresponding E.164  number is commonly called ^validation^.  This document describes an  signed XML data format -- the Validation Token -- with which
 Validation Entities can convey successful completion of a validation  procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

4.3  Bernie Hoeneisen


  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

DISCUSSION: Very little technical discussion of the above 3 documents.



#################

5. PART 2  1/2 hours. 3 Items

WG AGENDA: Terms and Conditions of discussion.

The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand.
 


#################

5.1 Discussion of drafts on Carrier ENUM - Requirements ?

  Title           : Infrastructure ENUM Requirements
        Author(s)       : S. Lind
        Filename        : draft-lind-infrastructure-enum-reqs-00.txt
        Pages           : 8
        Date            : 2005-7-15

 There has been much discussion in various industries about the  concept of infrastructure (or carrier) ENUM. Some of this discussion   has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the  Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus    industry-wide on even what infrastructure ENUM is, why it seems to be  important, or what the requirements for implementing it are.

 At the request of the WG co-chairs, this document attempts to gather   together the bits and pieces from those discussions (i.e., I stole   the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that   will enable enlightened discussion and hopefully achieve consensus.   Some items listed below may be duplicative and suggest alternative    wordings for similar and other contradictory issues. As such, this  list is very raw and should not be viewed as complete, cohesive or  correct.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt

 

WG ACTION:  This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.

Penn Pfautz agrees to collaborate with Steve Lind on future drafts.

5.2  Title           : IANA Carrier/User enumservice Registration
        Author(s)       : P. Pfautz, et al.
        Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
        Pages           : 10
        Date            : 2005-6-6

This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry  to support end user and carrier services with independent name   servers holding the terminal NAPTR (Naming Authority Pointer) records  identifying the communication services for each.  The to-be-  registered enumservices make use of non-terminal NAPTR records and  DDDS (Dynamic Delegation Discovery System) replacement to achieve  this end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt


5.3       Title           : Combined User and Carrier ENUM in the e164.arpa tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-haberler-carrier-enum-00.txt
        Pages           : 10
        Date            : 2005-7-11

   ENUM as defined now in RFC3761 is not well suited for the purpose of    interconnection by carriers, as can be seen by the use of various  private tree arrangements based on ENUM mechanisms.  A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number.  This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt


DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.


  As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant.  Three approaches were mentioned but only two seem "obvious".

   Non-terminal NAPTR records

 Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier.  Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup.

   Separated branches of the DNS tree

 A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or

B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.

 End users ( number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa.

   Requirements/Desired results
   1) Minimize number of lookups
   2) Retain flexibility
   3) Consistency from CC to CC for predictability

   Discussion

   -  Data in DNS does not guarantee reachability ("deny's" allowed)

   -  DNS MUST answer.
   - Uniformity in "c" label, name and where, is important
   - Non-terminal NAPTRs are untried
   - Questions on whether DNS wildcards are pertinent to the issue
   - Three questions - what's better for 1) DNS, 2) Application, and 3) "life"
   - Should not preclude private carrier-carrier traffic control

WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.

Further Discussion on Next Steps

   - Needs requirements and especially use cases to indicate what it is about

WG ACTION: Requirements document added as WG item.
   - RFC 3761 should remain untouched
   - Scope needs definition (stop at re-write rules?)
   - Use cases, use cases, use cases
   - Terminology and definitions needed
 
The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time". 

3 Options 

A.	Pfautz approach of use of non-terminal NAPTR's 
B.	Haberler/Stastny approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa or
	with delegation after RIPE/ITU c. [CC].e164.arpa 
C.	Using a different (non-e164.arpa) domain

Hum indicates strong preference for B with further discussion the WG necessary.

Further Discussion:

Division of labor with VOIPEER BoF effort required

6.0 Title           : Non-Terminal NAPTR Processing: A Modest Proposal
        Author(s)       : L. Conroy
        Filename        : draft-conroy-enum-modestproposal-00.txt
        Pages           : 12
        Date            : 2005-7-6

  Recent Discussions within the IETF and in other fora have highlighted  differences in interpretation of the set of standards associated with    ENUM and DDDS, on which it relies.  Specifically, the operation and   semantics surrounding support for non-terminal NAPTRs has led to some    confusion.  This document is n attempt to add clarification to non-   terminal NAPTR processing.  In this, it clarifies RFC3403.  A    subsequent document will build on this one to extend FC3761 further,    permitting registration of non-terminal Enumservices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt

WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.

 

Meeting Concludes.


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--------------090007050906080600060204 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/RICHAR%7E1/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------090007050906080600060204 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------090007050906080600060204-- From enum-bounces@ietf.org Sun Aug 21 09:18:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6piM-0003nf-QN; Sun, 21 Aug 2005 09:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6piL-0003na-9K for enum@megatron.ietf.org; Sun, 21 Aug 2005 09:18:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27953 for ; Sun, 21 Aug 2005 09:18:15 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6qIh-0006sd-LZ for enum@ietf.org; Sun, 21 Aug 2005 09:55:52 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 206A36DB17; Sun, 21 Aug 2005 14:13:52 +0100 (BST) In-Reply-To: <430758B0.3010500@shockey.us> References: <430758B0.3010500@shockey.us> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <397B01D2-8344-488E-AB8F-6B0B5FB41D69@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Date: Sun, 21 Aug 2005 14:17:46 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org Subject: [Enum] Clarification of WG Actions from IETF63 - modest proposal/experiences X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi Richard, folks, Many thanks for publishing these minutes. They're invaluable, as until the audio stream/archive is stable this is the only way to know what's happening. [It is sure useful even when attending, IIRC :] I do have a pair of tied questions on the WG actions. In short, Should we just go ahead and update the experiences draft to tell folk how to interpret 3403, or should we update 3403 and/or 3761 now? (i) The coming update of the experiences draft was intended to reflect the discussions triggered by Carrier vs. Infrastructure vs. User ENUM, as they relate to ENUM implementations. The experiences draft WAS going to include a "if you do non-terminals, DON'T put something in the REGEXP field of a non-terminal and expect anyone to be able to handle it". (ii) There looks like there will be changes to 3761 - fine. However, the modest proposal was for a clarification of 3403, as that's where this particular can of worms arose - section 4.1 has text that is "not quite transparent". This was intended as a first step before updating 3761. Does the WG think that it does NOT need E2U-specific non- terminals? IF the WG thinks that it does NOT need to allow specification of non- terminal Enumservices (which can't be done right now as the 3761 template doesn't allow it), then IMHO we have two choices: - Stick a caveat in 3403 to clarify the section 4.1 text on the REGEXP field. This could simply say that this field is not used in non-terminals. or - Stick a caveat in 3761 stating that the REGEXP field MUST be empty with non-terminal NAPTRs used with this 'E2U' DDDS Application. Of course, without non-terminal flags and/or non-terminal Enumservices, the Service field must be empty as it requires at least on Enumservice token to be valid and non-empty, so there's no easy way to tell whether or not this is an E2U NAPTR. Expanding 3761 and clarifying 3403 to allow such exotic non-terminals is a LOT of work for very little gain, so I'd be very happy with a simple caveat being added to 3403 or 3761. The modest proposal was the first part of a complex fix that personally I'm not convinced we will ever need. So.... When do we start work on updating 3403/3761, and do I replace the modest proposal with a (simpler - hooray!) "Don't do this" caveat for 3403 or 3761? all the best, Lawrence p.s. I finally managed to connect to the audio stream just before the end of the meeting. FYI, the audio stream still carries on after the meeting, so any comments on bottles of wine and customs officials, when spoken near the podium microphone, are carried clearly over the 'net :). On 20 Aug 2005, at 17:22, Richard Shockey wrote: > IETF 63 Telephone Number Mapping (ENUM) WG Meeting Minutes > 1. Review of the existing drafts - Ready to go to Last call ( 5-10 > M ? ) > WG ACTION : After some minor discussion agreement that the > document should go through one more iteratina and then take > directly to WGLC. > 6.0 Title : Non-Terminal NAPTR Processing: A Modest Proposal > WG ACTION : No action taken. Document may be incorporated into > revision of RFC 3761 since it is clear there are a number of > changes that have to be made before it could become Draft Standard. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Aug 21 11:22:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6rf1-0007aj-Og; Sun, 21 Aug 2005 11:22:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6rf0-0007ae-KV for enum@megatron.ietf.org; Sun, 21 Aug 2005 11:22:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04928 for ; Sun, 21 Aug 2005 11:22:56 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6sFO-0001L4-GD for enum@ietf.org; Sun, 21 Aug 2005 12:00:34 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7LFN24g017582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Aug 2005 08:23:22 -0700 Message-ID: <43089C26.8090009@shockey.us> Date: Sun, 21 Aug 2005 11:22:14 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] Clarification of WG Actions from IETF63 - modest proposal/experiences References: <430758B0.3010500@shockey.us> <397B01D2-8344-488E-AB8F-6B0B5FB41D69@insensate.co.uk> In-Reply-To: <397B01D2-8344-488E-AB8F-6B0B5FB41D69@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Richard, folks, > > Many thanks for publishing these minutes. > They're invaluable, as until the audio stream/archive is stable this > is the only > way to know what's happening. [It is sure useful even when attending, > IIRC :] > > I do have a pair of tied questions on the WG actions. > In short, Should we just go ahead and update the experiences draft > to tell folk > how to interpret 3403, or should we update 3403 and/or 3761 now? This is a personal opinion ( chair hat off ) IMHO, IF I were you , update the experiences draft on how to interpret 3403 now. The task of updating 3761 and related documents is going to be a long one and require recharter. The recharter process is underway but that will take time. > > (i) The coming update of the experiences draft was intended to > reflect the > discussions triggered by Carrier vs. Infrastructure vs. User > ENUM, as > they relate to ENUM implementations. The experiences draft WAS > going to > include a "if you do non-terminals, DON'T put something in the > REGEXP > field of a non-terminal and expect anyone to be able to handle it". Again this is a perfectly legitmiate comment to add to the experiences draft. > > (ii) There looks like there will be changes to 3761 - fine. However, the > modest proposal was for a clarification of 3403, as that's where > this > particular can of worms arose - section 4.1 has text that is > "not quite > transparent". This was intended as a first step before updating > 3761. > Does the WG think that it does NOT need E2U-specific non- terminals? On this I'm not sure. There may in fact be perfectly uses of non terminal NAPTR records outside the context of Carrier ENUM ..some application specific thing some one may dream up. However .. I have personally disliked the use of non-terminal NAPTR records as defined in the Pfautz draft ( chair hat off) and infinitely prefer the Haberler approach to defining a carrier ENUM tree though I have some firm opinions on that as well. > > IF the WG thinks that it does NOT need to allow specification of non- > terminal > Enumservices (which can't be done right now as the 3761 template doesn't > allow it), then IMHO we have two choices: > > - Stick a caveat in 3403 to clarify the section 4.1 text on the > REGEXP field. > This could simply say that this field is not used in non-terminals. > or > - Stick a caveat in 3761 stating that the REGEXP field MUST be empty > with > non-terminal NAPTRs used with this 'E2U' DDDS Application. > Of course, without non-terminal flags and/or non-terminal > Enumservices, > the Service field must be empty as it requires at least on > Enumservice > token to be valid and non-empty, so there's no easy way to tell > whether > or not this is an E2U NAPTR. Third option is to put the caveat in the experiences document until we can revisit 3761 and 3403. > > Expanding 3761 and clarifying 3403 to allow such exotic non-terminals is > a LOT of work for very little gain, so I'd be very happy with a simple > caveat being added to 3403 or 3761. The modest proposal was the first > part of a complex fix that personally I'm not convinced we will ever > need. > > So.... When do we start work on updating 3403/3761, its going to take a while ... > and do I replace the modest > proposal with a (simpler - hooray!) "Don't do this" caveat for 3403 > or 3761? "Dont do this." discussion in the Experiences document is IMHO the best option. > > all the best, > Lawrence > > p.s. > I finally managed to connect to the audio stream just before the > end of > the meeting. FYI, the audio stream still carries on after the meeting, > so any comments on bottles of wine and customs officials, when spoken > near the podium microphone, are carried clearly over the 'net :). > > > On 20 Aug 2005, at 17:22, Richard Shockey wrote: > >> IETF 63 Telephone Number Mapping (ENUM) WG Meeting Minutes > > > >> 1. Review of the existing drafts - Ready to go to Last call ( 5-10 >> M ? ) > > > >> WG ACTION : After some minor discussion agreement that the document >> should go through one more iteratina and then take directly to WGLC. > > > >> 6.0 Title : Non-Terminal NAPTR Processing: A Modest Proposal > > > >> WG ACTION : No action taken. Document may be incorporated into >> revision of RFC 3761 since it is clear there are a number of changes >> that have to be made before it could become Draft Standard. > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Aug 21 16:59:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wuH-00033Q-2j; Sun, 21 Aug 2005 16:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wuB-00032t-T0; Sun, 21 Aug 2005 16:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18733; Sun, 21 Aug 2005 16:58:57 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6xUb-0000Nv-Or; Sun, 21 Aug 2005 17:36:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 21 Aug 2005 23:02:16 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0E3@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAAimdMQ= From: "Stastny Richard" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: Subject: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Henry, =20 I know your position ;-) and I basically agree. =20 >Since the dial plan topic is so complex, even for the experts in the = IETF ... You mean "especially" for the (dial plan) experts in the IETF ;-) >...how can anyone hope that developers or even more, users will get it = right? User normally had no problems with dial plans since more than 50 years. >KISS and use only one of the three: >1. E.164 numbers for the Internet challenged, >2. SIP URIs for everyone else, or the best of all >3. Hide any type of CA in the AO and use Presence. Just click to call. I basically agree. Anybody using a softclient, be it on a laptop, PDA or softphone should use the same practice like on mobile phone, entering E.164 = numbers=20 ONLY (or preferably) in the international format with the leading "+" Nevertheless, there are still may POTS phones out using terminal = adapters capable only of entering digits aad * and #. So you MUST use a dialing plan and this can only be a national, local or private dialing plan, because NO international dialing plan exists. >I have followed the discussions on dial plans for a while, and it has = been >going on actually for several years.=20 Yes, and I tried some two years ago to get a discussion going (ask Carl) = to find a solution for global VoIP providers and eventually also a common=20 practice to dial international numbers e.g. with * or ** as replacement for +, with no reaction. I am currently thinking to revive and rewrite = the draft http://enum.nic.at/documents/IETF/Internet_Drafts/draft-stastny-enum-numb= ering-voip-00.txt cheers -richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 08:23:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BLF-00061e-MA; Mon, 22 Aug 2005 08:23:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6t82-0005zY-8c for enum@megatron.ietf.org; Sun, 21 Aug 2005 12:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08110 for ; Sun, 21 Aug 2005 12:56:59 -0400 (EDT) Message-Id: <200508211656.MAA08110@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6tiN-0003Kz-OJ for enum@ietf.org; Sun, 21 Aug 2005 13:34:39 -0400 Received: (qmail 21777 invoked by uid 510); 21 Aug 2005 13:52:22 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.118.81):. Processed in 0.96955 secs); 21 Aug 2005 17:52:22 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.118.81):. Processed in 0.96955 secs Process 21769) Received: from unknown (HELO 1AB764895C324D3) (henry@pulver.com@67.187.118.81) by 192.246.69.184 with SMTP; Sun, 21 Aug 2005 17:52:21 +0000 From: "Henry Sinnreich" To: , , Date: Sun, 21 Aug 2005 11:56:38 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQ In-Reply-To: <20050818103317.GA26663@nic.at> X-Antivirus-MYDOMAIN-Message-ID: <112464674183521769@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Aug 2005 08:23:53 -0400 Cc: Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 08:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BLG-000623-2A; Mon, 22 Aug 2005 08:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6y0X-0006Eg-Bh for enum@megatron.ietf.org; Sun, 21 Aug 2005 18:09:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21838 for ; Sun, 21 Aug 2005 18:09:33 -0400 (EDT) Message-Id: <200508212209.SAA21838@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6yaw-00024u-Po for enum@ietf.org; Sun, 21 Aug 2005 18:47:16 -0400 Received: (qmail 6505 invoked by uid 510); 21 Aug 2005 19:05:10 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.120.26):. Processed in 0.947236 secs); 21 Aug 2005 23:05:10 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.120.26):. Processed in 0.947236 secs Process 6500) Received: from unknown (HELO 1AB764895C324D3) (henry@pulver.com@67.187.120.26) by 192.246.69.184 with SMTP; Sun, 21 Aug 2005 23:05:09 +0000 From: "Henry Sinnreich" To: "'Stastny Richard'" , , , Date: Sun, 21 Aug 2005 17:09:27 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAAimdMQAAnOOIA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613C0E3@oefeg-s04.oefeg.loc> X-Antivirus-MYDOMAIN-Message-ID: <11246655098356500@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Aug 2005 08:23:53 -0400 Cc: 'Karl Stahl' , jean.j.brierre@exgate.tek.com Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Richard, >Nevertheless, there are still may POTS phones out using terminal >adapters capable only of entering digits and * and #. A properly designed adapter (like the FXS station in the Intertex IX67) will support converting a phone number, like +1-972-123-5555 into a URL by dialing a prefix, for example, dialing 90: 90-1-972-123-5555 will call out to sip:user@example.com The phone adapter will then have sort of a customized phone book. Since VoIP is still in its initial growth curve, the IETF could give such indications for SIP-PSTN adapters to support PSTN number translation to SIP URIs. In this way we can keep our dear old phones and the beloved phone numbers :-) but will relieve SIP based calling of supporting dial plans that are an eternal discussion tema at the IETF. Will this work? Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard Sent: Sunday, August 21, 2005 4:02 PM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Henry, I know your position ;-) and I basically agree. >Since the dial plan topic is so complex, even for the experts in the IETF ... You mean "especially" for the (dial plan) experts in the IETF ;-) >...how can anyone hope that developers or even more, users will get it right? User normally had no problems with dial plans since more than 50 years. >KISS and use only one of the three: >1. E.164 numbers for the Internet challenged, >2. SIP URIs for everyone else, or the best of all >3. Hide any type of CA in the AO and use Presence. Just click to call. I basically agree. Anybody using a softclient, be it on a laptop, PDA or softphone should use the same practice like on mobile phone, entering E.164 numbers ONLY (or preferably) in the international format with the leading "+" Nevertheless, there are still may POTS phones out using terminal adapters capable only of entering digits aad * and #. So you MUST use a dialing plan and this can only be a national, local or private dialing plan, because NO international dialing plan exists. >I have followed the discussions on dial plans for a while, and it has been >going on actually for several years. Yes, and I tried some two years ago to get a discussion going (ask Carl) to find a solution for global VoIP providers and eventually also a common practice to dial international numbers e.g. with * or ** as replacement for +, with no reaction. I am currently thinking to revive and rewrite the draft http://enum.nic.at/documents/IETF/Internet_Drafts/draft-stastny-enum-numberi ng-voip-00.txt cheers -richard ____________________________________________________________________________ _ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 09:30:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CNo-0001Ol-Q0; Mon, 22 Aug 2005 09:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CNm-0001OB-8E; Mon, 22 Aug 2005 09:30:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15408; Mon, 22 Aug 2005 09:30:31 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7CyL-0000uU-0I; Mon, 22 Aug 2005 10:08:21 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 22 Aug 2005 15:33:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B20C3@oefeg-s04.oefeg.loc> Thread-Topic: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAAimdMQAAnOOIAAgaXKA From: "Stastny Richard" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: Karl Stahl , jean.j.brierre@exgate.tek.com Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > A properly designed adapter (like the FXS station in the Intertex IX67) > will > support converting a phone number, like +1-972-123-5555 into a URL by > dialing a prefix, for example, dialing 90: >=20 > 90-1-972-123-5555 will call out to sip:user@example.com So you are proposing a new international standard using "90" as=20 access code for international calls? FYI, there is already one recommended by ITU-T: "00". Not all countries are compliant, but most. In addition: you cannot expect end-user to configure their=20 IX67 and Sipura. It just has to work and it should work consistently like the old phone system. Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Monday, August 22, 2005 12:09 AM > To: Stastny Richard; voipeer@lists.uoregon.edu; geopriv@ietf.org; > enum@ietf.org > Cc: 'Karl Stahl'; jean.j.brierre@exgate.tek.com > Subject: RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common > policy >=20 > Richard, >=20 > >Nevertheless, there are still may POTS phones out using terminal > >adapters capable only of entering digits and * and #. >=20 > A properly designed adapter (like the FXS station in the Intertex IX67) > will > support converting a phone number, like +1-972-123-5555 into a URL by > dialing a prefix, for example, dialing 90: >=20 > 90-1-972-123-5555 will call out to sip:user@example.com >=20 > The phone adapter will then have sort of a customized phone book. > Since VoIP is still in its initial growth curve, the IETF could give such > indications for SIP-PSTN adapters to support PSTN number translation to > SIP > URIs. >=20 > In this way we can keep our dear old phones and the beloved phone numbers > :-) but will relieve SIP based calling of supporting dial plans that are > an > eternal discussion tema at the IETF. >=20 > Will this work? >=20 > Thanks, Henry >=20 >=20 >=20 > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Stastny Richard > Sent: Sunday, August 21, 2005 4:02 PM > To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; > enum@ietf.org > Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common > policy >=20 > Henry, >=20 > I know your position ;-) and I basically agree. >=20 > >Since the dial plan topic is so complex, even for the experts in the IETF > ... > You mean "especially" for the (dial plan) experts in the IETF ;-) >=20 > >...how can anyone hope that developers or even more, users will get it > right? > User normally had no problems with dial plans since more than 50 years. >=20 > >KISS and use only one of the three: >=20 > >1. E.164 numbers for the Internet challenged, > >2. SIP URIs for everyone else, or the best of all > >3. Hide any type of CA in the AO and use Presence. Just click to call. >=20 > I basically agree. >=20 > Anybody using a softclient, be it on a laptop, PDA or softphone > should use the same practice like on mobile phone, entering E.164 numbers > ONLY (or preferably) in the international format with the leading "+" >=20 > Nevertheless, there are still may POTS phones out using terminal adapters > capable only of entering digits aad * and #. >=20 > So you MUST use a dialing plan and this can only be a national, local or > private dialing plan, because NO international dialing plan exists. >=20 > >I have followed the discussions on dial plans for a while, and it has > been > >going on actually for several years. >=20 > Yes, and I tried some two years ago to get a discussion going (ask Carl) > to > find > a solution for global VoIP providers and eventually also a common > practice to dial international numbers e.g. with * or ** as replacement > for +, with no reaction. I am currently thinking to revive and rewrite the > draft > http://enum.nic.at/documents/IETF/Internet_Drafts/draft-stastny-enum- > numberi > ng-voip-00.txt >=20 > cheers >=20 > -richard >=20 >=20 >=20 >=20 > ________________________________________________________________________ __ > __ > _ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 10:19:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7D8f-0001pm-31; Mon, 22 Aug 2005 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7D8c-0001pb-U5; Mon, 22 Aug 2005 10:18:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18431; Mon, 22 Aug 2005 10:18:56 -0400 (EDT) Message-Id: <200508221418.KAA18431@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7DjD-0002F4-1G; Mon, 22 Aug 2005 10:56:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E7D8H-0002GZ-N9; Mon, 22 Aug 2005 09:18:38 -0500 From: "Brian Rosen" To: , , , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Mon, 22 Aug 2005 10:18:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <200508211656.MAA08110@ietf.org> Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having "dial tone", entering digits, and having a key press that indicates end of dialed number and forcing the user to put in all the prefixes, or some combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 10:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DdQ-0007dn-Je; Mon, 22 Aug 2005 10:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DdP-0007dM-Bi; Mon, 22 Aug 2005 10:50:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20560; Mon, 22 Aug 2005 10:50:45 -0400 (EDT) Message-Id: <200508221450.KAA20560@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EDz-0003EK-N8; Mon, 22 Aug 2005 11:28:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E7DdE-0003ja-Jn; Mon, 22 Aug 2005 09:50:37 -0500 From: "Brian Rosen" To: , , , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Mon, 22 Aug 2005 10:50:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1Nw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org FWIW, I agree with you; phones should do dialplan interpretation. That begs the issue of how you download a dialplan into a phone. However, there are very, very few phones that do dialplan interpretation, especially one suitable for an enterprise. We either have to change that behavior, or support dialstrings. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 10:42 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Brian, I agree with both you and Richard Stastny how you formulate the problem with dial plans. The fact however that so many IETF contributors have taken a stab at solving the dial plan problem and are still trying after all these years, makes me think the dial plan complexities should best left to the endpoints who should know what to do. Dial plans should be left to the implementers of endpoints and not with the IETF. I have only given in previous mail the example of endpoints that know what to do, to prove that endpoints can do it. So unless it is an E.164 PSTN phone number or a SIP URI, SIP services should not ever be burdened with anything else. Nor should users be burdened to know anything else. I bet however that in spite of this, there will be more engineering attempts to solve the dial plans in the IETF and will look forward with interest... My two cents. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:19 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having "dial tone", entering digits, and having a key press that indicates end of dialed number and forcing the user to put in all the prefixes, or some combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 11:28:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EDQ-0007K0-Cj; Mon, 22 Aug 2005 11:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EDP-0007Js-5l; Mon, 22 Aug 2005 11:27:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22751; Mon, 22 Aug 2005 11:27:56 -0400 (EDT) Message-Id: <200508221527.LAA22751@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Enz-0004Sm-P8; Mon, 22 Aug 2005 12:05:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1E7EDE-0005nP-1N; Mon, 22 Aug 2005 10:27:48 -0500 From: "Brian Rosen" To: , , , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Mon, 22 Aug 2005 11:27:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Henry This is waay to much hand waving. "Designers of enterprise communications systems" aren't any different from designers of residential communications systems. While there are firms who plan to provide both phones and servers, and hope their customers choose them for both tasks, there are many others who want the phone choice and the server choice to be independent. To do that, the phones and the servers have to follow standards, and that includes dial plans. The residential case is exactly the same. The phone vendors and the server vendors are more typically different, but you have some significant exceptions. I like presence and click to call, but don't think it's going to supplant dialing completely for some long time. If you dial, even occasionally, these issues arise. We need standards if we want dial plan interpretation in phones, and we need a fairly substantial change in existing phone code to get it. That applies to both residential and enterprise. I'm sanguine about that happening. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 11:01 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy >However, there are very, very few phones that do dialplan interpretation, >especially one suitable for an enterprise. We either have to change that >behavior, or support dialstrings. This is true and best left to implementers of enterprise communication systems where there is a different design space altogether. Enlightened enterprises may prefer presence anyhow to PBX-style dialing or just use mobile phone style click to call based on presence and SIP events. What goes over the net should be only E.164 addresses or SIP URIs. Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:51 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy FWIW, I agree with you; phones should do dialplan interpretation. That begs the issue of how you download a dialplan into a phone. However, there are very, very few phones that do dialplan interpretation, especially one suitable for an enterprise. We either have to change that behavior, or support dialstrings. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 10:42 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Brian, I agree with both you and Richard Stastny how you formulate the problem with dial plans. The fact however that so many IETF contributors have taken a stab at solving the dial plan problem and are still trying after all these years, makes me think the dial plan complexities should best left to the endpoints who should know what to do. Dial plans should be left to the implementers of endpoints and not with the IETF. I have only given in previous mail the example of endpoints that know what to do, to prove that endpoints can do it. So unless it is an E.164 PSTN phone number or a SIP URI, SIP services should not ever be burdened with anything else. Nor should users be burdened to know anything else. I bet however that in spite of this, there will be more engineering attempts to solve the dial plans in the IETF and will look forward with interest... My two cents. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:19 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having "dial tone", entering digits, and having a key press that indicates end of dialed number and forcing the user to put in all the prefixes, or some combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 12:08:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EqV-00062R-Gp; Mon, 22 Aug 2005 12:08:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EqT-00062L-Nd for enum@megatron.ietf.org; Mon, 22 Aug 2005 12:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24708 for ; Mon, 22 Aug 2005 12:08:18 -0400 (EDT) Received: from bay103-dav11.bay103.hotmail.com ([65.54.174.83] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FR3-0005c4-F7 for enum@ietf.org; Mon, 22 Aug 2005 12:46:10 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Aug 2005 09:08:10 -0700 Message-ID: Received: from 65.54.174.208 by BAY103-DAV11.phx.gbl with DAV; Mon, 22 Aug 2005 16:08:09 +0000 X-Originating-IP: [65.54.174.208] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" To: Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs incommonpolicy Date: Mon, 22 Aug 2005 09:08:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQ In-Reply-To: <200508221527.LAA22751@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 22 Aug 2005 16:08:10.0700 (UTC) FILETIME=[B123A0C0:01C5A733] X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Concerning recharter, We have to ensure that ENUM stays on an ENUM-specific mission: while voice service issues are an important driver, their impact on ENUM must be compartmentalized within the supporting enumservices. Our mission (here) is high-level: "Internet convergence with the PSTN"; its not "routing phone calls". Let me put it another way - as a program manager, who strategically vouched for carrier ENUM in the debate. Because of the class of management requirement (mostly security) that such as regulated voice services will bring, we needed a _provider-based_ management model, in addition to the user-based management model for data provisioning. The adoption of carrier ENUM in the charter (if it happens) convinces me that ENUM may have the architecture to succeed in the intended operating environments. Now that the religious phase of WG argument is over, we can perhaps get back down to Internet engineering. If ENUM leads DNS evolution in practice to (optionally) adopt just some of the most critical provider-centric management practices learned other name server infrastructure efforts, we will have made a big contribution to the Internet's evolution. Small, incremental infrastructure changes are what we are all about, after large amounts of email. ..showing that ENUM has all the necessary elements to support regulated voice was an academic exam that ENUM had to pass: but it's not actually the goal. In our charter reformulation, we focus on the infrastructure goals (now that we have the experience of discussion to better formulate them), not the particular (but critical) predictor of success. Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 13:11:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FpE-0003Oa-8L; Mon, 22 Aug 2005 13:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FpC-0003N9-HG; Mon, 22 Aug 2005 13:11:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28888; Mon, 22 Aug 2005 13:11:03 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7GPn-0007oe-LK; Mon, 22 Aug 2005 13:48:56 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs incommonpolicy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 22 Aug 2005 19:14:39 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0E7@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs incommonpolicy Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAADkSJN From: "Stastny Richard" To: "Brian Rosen" , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Following the discussion between you two, I first have agree with Henry's last statement: =20 >What goes over the net should be only E.164 addresses or SIP URIs. but restricted to=20 What goes over the net between SIP-server should be only E.164 addresses = or SIP URIs. (a bsic requiremnt for voipeer. =20 Now between UAC and proxy: here we will need dialstrings It is up the the UAC to have digit analysis and also send only E.164 numbers, SIP-URIs (and emergency URIs such as = sip:sos@foo.bar) Any UAC capable of queying user ENUM must be able to do so That is fine with me, but I agree with Brian =20 >We need standards if we want dial plan interpretation in phones, and we = need >a fairly substantial change in existing phone code to get it. That = applies >to both residential and enterprise. I'm sanguine about that happening =20 and in addition BUT there will be also many clients no capable of doing this and also for this the above mentioned standards are needed: It is not useful if every phone has iis own method to translate dialed digits to numbers. One reason is BTW that setting up a feasable dialing plan is not so easy and should NOT be left to average user - he may easily shot himself into the foot. =20 -richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Brian Rosen Gesendet: Mo 22.08.2005 17:27 An: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; = enum@ietf.org Betreff: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs = incommonpolicy Henry This is waay to much hand waving. "Designers of enterprise communications systems" aren't any different = from designers of residential communications systems. While there are firms = who plan to provide both phones and servers, and hope their customers choose them for both tasks, there are many others who want the phone choice and = the server choice to be independent. To do that, the phones and the servers have to follow standards, and that includes dial plans. The residential case is exactly the same. The phone vendors and the = server vendors are more typically different, but you have some significant exceptions. I like presence and click to call, but don't think it's going to = supplant dialing completely for some long time. If you dial, even occasionally, these issues arise. We need standards if we want dial plan interpretation in phones, and we = need a fairly substantial change in existing phone code to get it. That = applies to both residential and enterprise. I'm sanguine about that happening. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 11:01 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy >However, there are very, very few phones that do dialplan = interpretation, >especially one suitable for an enterprise. We either have to change = that >behavior, or support dialstrings. This is true and best left to implementers of enterprise communication systems where there is a different design space altogether. Enlightened enterprises may prefer presence anyhow to PBX-style dialing or just use mobile phone style click to call based on presence and SIP events. What goes over the net should be only E.164 addresses or SIP URIs. Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:51 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy FWIW, I agree with you; phones should do dialplan interpretation. That = begs the issue of how you download a dialplan into a phone. However, there are very, very few phones that do dialplan = interpretation, especially one suitable for an enterprise. We either have to change = that behavior, or support dialstrings. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 10:42 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Brian, I agree with both you and Richard Stastny how you formulate the problem = with dial plans. The fact however that so many IETF contributors have taken a stab at = solving the dial plan problem and are still trying after all these years, makes = me think the dial plan complexities should best left to the endpoints who should know what to do. Dial plans should be left to the implementers of endpoints and not with the IETF. I have only given in previous mail the example of endpoints that know what to do, to prove that endpoints can = do it. So unless it is an E.164 PSTN phone number or a SIP URI, SIP services = should not ever be burdened with anything else. Nor should users be burdened to know anything else. I bet however that in spite of this, there will be more engineering = attempts to solve the dial plans in the IETF and will look forward with = interest... My two cents. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:19 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how = long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits = according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having = "dial tone", entering digits, and having a key press that indicates end of = dialed number and forcing the user to put in all the prefixes, or some = combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has = been going on actually for several years. Since the dial plan topic is so = complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common = policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Aug 22 13:23:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G10-0005jd-4G; Mon, 22 Aug 2005 13:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G0y-0005jY-SJ for enum@megatron.ietf.org; Mon, 22 Aug 2005 13:23:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29496 for ; Mon, 22 Aug 2005 13:23:13 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GbZ-0008CP-Bp for enum@ietf.org; Mon, 22 Aug 2005 14:01:06 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2005 10:23:06 -0700 X-IronPort-AV: i="3.96,131,1122879600"; d="scan'208"; a="656004085:sNHT30699796" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7MHMQpK018714; Mon, 22 Aug 2005 10:23:04 -0700 (PDT) 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.211); Mon, 22 Aug 2005 13:23:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy Date: Mon, 22 Aug 2005 13:23:00 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E37C4A92@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQAANx4EA= From: "Michael Hammer \(mhammer\)" To: "Peter Williams" , X-OriginalArrivalTime: 22 Aug 2005 17:23:01.0927 (UTC) FILETIME=[261E7B70:01C5A73E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Peter, I find the statement that "it is not for routing phone calls" misleading. Nodes that do an ENUM lookup for SIP voice setup requests, will in fact result in targeting one SIP endpoint versus another. I call that voice routing, in addition to data packet targeting once the SIP address is converting to IP address. Could you please elaborate? Mike > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Peter Williams > Sent: Monday, August 22, 2005 12:08 PM > To: enum@ietf.org > Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple]=20 > tel URIsincommonpolicy >=20 >=20 > Concerning recharter, >=20 > We have to ensure that ENUM stays on an ENUM-specific=20 > mission: while voice service issues are an important driver,=20 > their impact on ENUM must be compartmentalized within the=20 > supporting enumservices. Our mission (here) is > high-level: "Internet convergence with the PSTN"; its not=20 > "routing phone calls". >=20 > Let me put it another way - as a program manager, who=20 > strategically vouched for carrier ENUM in the debate. >=20 > Because of the class of management requirement (mostly=20 > security) that such as regulated voice services will bring,=20 > we needed a _provider-based_ management model, in addition to=20 > the user-based management model for data provisioning. The=20 > adoption of carrier ENUM in the charter (if it happens)=20 > convinces me that ENUM may have the architecture to succeed=20 > in the intended operating environments. >=20 > Now that the religious phase of WG argument is over, we can=20 > perhaps get back down to Internet engineering. If ENUM leads=20 > DNS evolution in practice to > (optionally) adopt just some of the most critical=20 > provider-centric management practices learned other name=20 > server infrastructure efforts, we will have made a big=20 > contribution to the Internet's evolution. Small, incremental=20 > infrastructure changes are what we are all about, after large=20 > amounts of email. >=20 > ..showing that ENUM has all the necessary elements to support=20 > regulated voice was an academic exam that ENUM had to pass:=20 > but it's not actually the goal. >=20 > In our charter reformulation, we focus on the infrastructure=20 > goals (now that we have the experience of discussion to=20 > better formulate them), not the particular (but critical)=20 > predictor of success. >=20 > Peter. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 23 03:53:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Tb0-0004Lw-2V; Tue, 23 Aug 2005 03:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Tay-0004Lr-O7 for enum@megatron.ietf.org; Tue, 23 Aug 2005 03:53:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19794 for ; Tue, 23 Aug 2005 03:53:19 -0400 (EDT) Received: from bay103-dav10.bay103.hotmail.com ([65.54.174.82] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Tb3-0003Ew-9z for enum@ietf.org; Tue, 23 Aug 2005 03:53:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Aug 2005 00:53:11 -0700 Message-ID: Received: from 65.54.174.200 by BAY103-DAV10.phx.gbl with DAV; Tue, 23 Aug 2005 07:53:10 +0000 X-Originating-IP: [65.54.174.200] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: "Peter Williams" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] telURIsincommonpolicy Date: Tue, 23 Aug 2005 00:53:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkAAAOiKsAAAwOSQAANx4EAAHMCwAA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E37C4A92@xmb-rtp-20b.amer.cisco.com> X-OriginalArrivalTime: 23 Aug 2005 07:53:11.0136 (UTC) FILETIME=[B53B8E00:01C5A7B7] X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of > Michael Hammer (mhammer) > Sent: Monday, August 22, 2005 10:23 AM > > Peter, > > I find the statement that "it is not for routing phone calls" > misleading. Nodes that do an ENUM lookup for SIP voice setup requests, > will in fact result in targeting one SIP endpoint versus another. I > call that voice routing, in addition to data packet targeting once the > SIP address is converting to IP address. > > Could you please elaborate? View my comment in the context of program management - re-defining charters, etc. We rationalized Carrier ENUM based in part on the argument that regulated voice services required the management practices that the PSTN's current culture brings to the party. This addresses a bunch of legacy interchange and security domain practices. Before we (the internet users, not IETF) kill off that self-indulgent model - as we killed the ludicrous EDI interchange model and its bogus security assurances - first, we embrace it. So I making the simple point that I don't want the clear rationale for Carrier ENUM to carry forward more than it should, to the charter revision. We now have the necessary extra element (ADMDs and PRMDs based switching, in Carrier ENUM form) in the armory suited for the war on regulated voip, buts that all it is: another element. Just because regulated voice motivated us to incorporate a particular set of required ENUM capabilities in the overall architecture, does not mean that all ENUM services will require that operational model. It doesn't even mean that Carrier ENUM deployment model will prevail... There is no notion that ENUM (and the NG DNS that ENUM really represents) has been "skewed" a particular way, by this decision - or that the internet architecture itself has taken a particular path. It hasn't. The convergence will go in phases, that's all. The first phase is embrace. The next is extend ($1 to MS, please). For example. as members of an H.323 (over IP multicast, not PSTN) conference join the group core in its virtual connect land, we might rather more practically dynamically post the joining (aka connecting) user's E.164 address into a dynamically created tree, beneath a conferencing node - purely to be helpful to the conference members. This could allow folks to create PSTN-based H.323 sessions, in parallel to the multicast session. This has nothing to do whatsoever with getting the "connects" resolved, over multicast group management! The simplistic hierarchical posting of entries (beneath per-conference nodes) will definitely not serve H.323 over PSTN switching needs! "ENUM is not about voice/conference switching/routing, per se!" Its back to the venture pitch someone at Neustar made to me, 5 years ago: do you know we have 2 billion people completely familiar with the really effective name management system known as the 'phone number'.... So, with the general point and the somewhat contorted support example, I'm merely attempting to debunk any notion that Carrier ENUM was ever really about Internet religion. ENUM is bigger than voip - or the resolution of sip URLs, or mapping SIP URI onto optional transport paths over IP or PSTN. Its about PSTN convergence. Sure, we were missing a critical management model element (told you so, ha!). But, now we have realize that, in the charter we don't really need to do that much! If anything, Carrier ENUM just adds clarity to the ENUM vision. Peter. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 23 05:00:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UdX-0008Uc-1S; Tue, 23 Aug 2005 05:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DVD-000692-DF for enum@megatron.ietf.org; Mon, 22 Aug 2005 10:42:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20093 for ; Mon, 22 Aug 2005 10:42:16 -0400 (EDT) Message-Id: <200508221442.KAA20093@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7E5n-0002zZ-6q for enum@ietf.org; Mon, 22 Aug 2005 11:20:07 -0400 Received: (qmail 6733 invoked by uid 510); 22 Aug 2005 11:38:05 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.118.81):. Processed in 1.014693 secs); 22 Aug 2005 15:38:05 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.118.81):. Processed in 1.014693 secs Process 6728) Received: from unknown (HELO 1AB764895C324D3) (henry@pulver.com@67.187.118.81) by 192.246.69.184 with SMTP; Mon, 22 Aug 2005 15:38:04 +0000 From: "Henry Sinnreich" To: "'Brian Rosen'" , , , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Mon, 22 Aug 2005 09:42:08 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050822141840.553DA2CA146@mail32-haw.bigfish.com> X-Antivirus-MYDOMAIN-Message-ID: <11247250848356728@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Aug 2005 05:00:01 -0400 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Brian, I agree with both you and Richard Stastny how you formulate the problem with dial plans. The fact however that so many IETF contributors have taken a stab at solving the dial plan problem and are still trying after all these years, makes me think the dial plan complexities should best left to the endpoints who should know what to do. Dial plans should be left to the implementers of endpoints and not with the IETF. I have only given in previous mail the example of endpoints that know what to do, to prove that endpoints can do it. So unless it is an E.164 PSTN phone number or a SIP URI, SIP services should not ever be burdened with anything else. Nor should users be burdened to know anything else. I bet however that in spite of this, there will be more engineering attempts to solve the dial plans in the IETF and will look forward with interest... My two cents. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:19 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having "dial tone", entering digits, and having a key press that indicates end of dialed number and forcing the user to put in all the prefixes, or some combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 23 05:00:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UdX-0008Vb-M3; Tue, 23 Aug 2005 05:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dmy-0001O5-Qi for enum@megatron.ietf.org; Mon, 22 Aug 2005 11:00:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21268 for ; Mon, 22 Aug 2005 11:00:38 -0400 (EDT) Message-Id: <200508221500.LAA21268@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ENY-0003ZM-5W for enum@ietf.org; Mon, 22 Aug 2005 11:38:29 -0400 Received: (qmail 10290 invoked by uid 510); 22 Aug 2005 11:56:34 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.118.81):. Processed in 1.305769 secs); 22 Aug 2005 15:56:34 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.118.81):. Processed in 1.305769 secs Process 10277) Received: from unknown (HELO 1AB764895C324D3) (henry@pulver.com@67.187.118.81) by 192.246.69.184 with SMTP; Mon, 22 Aug 2005 15:56:32 +0000 From: "Henry Sinnreich" To: "'Brian Rosen'" , , , Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Date: Mon, 22 Aug 2005 10:00:36 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWj5/5Zpv/HNaIoSDqCa9nRBojT9AChqcbQAC1AAKAAAJYzoAAAp1NwAAAynkA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050822145038.E97974527F7@mail9-ash.bigfish.com> X-Antivirus-MYDOMAIN-Message-ID: <112472619283510277@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Aug 2005 05:00:02 -0400 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >However, there are very, very few phones that do dialplan interpretation, >especially one suitable for an enterprise. We either have to change that >behavior, or support dialstrings. This is true and best left to implementers of enterprise communication systems where there is a different design space altogether. Enlightened enterprises may prefer presence anyhow to PBX-style dialing or just use mobile phone style click to call based on presence and SIP events. What goes over the net should be only E.164 addresses or SIP URIs. Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:51 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy FWIW, I agree with you; phones should do dialplan interpretation. That begs the issue of how you download a dialplan into a phone. However, there are very, very few phones that do dialplan interpretation, especially one suitable for an enterprise. We either have to change that behavior, or support dialstrings. Brian -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Monday, August 22, 2005 10:42 AM To: 'Brian Rosen'; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Brian, I agree with both you and Richard Stastny how you formulate the problem with dial plans. The fact however that so many IETF contributors have taken a stab at solving the dial plan problem and are still trying after all these years, makes me think the dial plan complexities should best left to the endpoints who should know what to do. Dial plans should be left to the implementers of endpoints and not with the IETF. I have only given in previous mail the example of endpoints that know what to do, to prove that endpoints can do it. So unless it is an E.164 PSTN phone number or a SIP URI, SIP services should not ever be burdened with anything else. Nor should users be burdened to know anything else. I bet however that in spite of this, there will be more engineering attempts to solve the dial plans in the IETF and will look forward with interest... My two cents. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, August 22, 2005 9:19 AM To: henry@pulver.com; voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Henry You've been around enough to know that what you said is not the issue. Dialplans, and dialstrings, arise because you don't generally know how long a dialstring is, and phones don't know how to render a dialstring into a telephone number or service indication. Either you allow dialstrings in which case some entity, the phone or a proxy, interprets digits according to a dial plan to know when the terminal digit has been entered, adding appropriate prefixes, or you use the wireless mechanism of not having "dial tone", entering digits, and having a key press that indicates end of dialed number and forcing the user to put in all the prefixes, or some combination. Brian -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Sunday, August 21, 2005 12:57 PM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy Folks, I have followed the discussions on dial plans for a while, and it has been going on actually for several years. Since the dial plan topic is so complex even for the experts in the IETF, how can anyone hope that developers or even more, users will get it right? KISS and use only one of the three: 1. E.164 numbers for the Internet challenged, 2. SIP URIs for everyone else, or the best of all 3. Hide any type of CA in the AO and use Presence. Just click to call. Thanks, Henry -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl Sent: Thursday, August 18, 2005 5:33 AM To: voipeer@lists.uoregon.edu; geopriv@ietf.org; enum@ietf.org Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 23 09:31:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Yrn-0005gs-CX; Tue, 23 Aug 2005 09:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Yrl-0005gU-4k; Tue, 23 Aug 2005 09:31:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03142; Tue, 23 Aug 2005 09:30:59 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Yrr-0004Z4-OE; Tue, 23 Aug 2005 09:31:09 -0400 Received: from Mpierce1@aol.com by imo-m26.mx.aol.com (mail_out_v38_r4.1.) id k.9f.65b328b0 (1320); Tue, 23 Aug 2005 09:30:38 -0400 (EDT) Message-ID: <9f.65b328b0.303c7efe@aol.com> Date: Tue, 23 Aug 2005 09:30:38 EDT Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy To: Richard.Stastny@oefeg.at, henry@pulver.com, voipeer@lists.uoregon.edu, geopriv@ietf.org, enum@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10708 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0409695925==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============0409695925== Content-Type: multipart/alternative; boundary="part1_9f.65b328b0.303c7efe_boundary" --part1_9f.65b328b0.303c7efe_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/21/2005 5:01:54 PM Eastern Daylight Time, Richard.Stastny@oefeg.at writes: > Anybody using a softclient, be it on a laptop, PDA or softphone > should use the same practice like on mobile phone, entering E.164 numbers > ONLY (or preferably) in the international format with the leading "+" > > Nevertheless, there are still may POTS phones out using terminal adapters > capable only of entering digits aad * and #. > > So you MUST use a dialing plan and this can only be a national, local or > private dialing plan, because NO international dialing plan exists. > In the E164 plan, there was never any intention that the caller would actually dial a "+". It is only a way to represent numbers when written (like on letterhead). The "+" can be thought of as representing the extra digits for the international prefix that you must dial according to the local dialing plan before you dial the number which follows the "+". Since it's different in various countries, it shouldn't be written as a part of the number. There is no need to be able to enter a "+" on a keypad. Mike Pierce --part1_9f.65b328b0.303c7efe_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 8/21/2005 5:01:54 PM Eastern Daylight Time, Richard.Stastny@oefe= g.at writes:


Anybody using a softclient, be=20= it on a laptop, PDA or softphone
should use the same practice like on mobile phone, entering E.164 numbers ONLY (or preferably) in the international format with the leading "+"

Nevertheless, there are still may POTS phones out using terminal adapters capable only of entering digits aad * and #.

So you MUST use a dialing plan and this can only be a national, local or
private dialing plan, because NO international dialing plan exists.


In the E164 plan, there was never any intention that the caller would actual= ly dial a "+". It is only a way to represent numbers when written (like on l= etterhead). The "+" can be thought of as representing the extra digits for t= he international prefix that you must dial according to the local dialing pl= an before you dial the number which follows the "+". Since it's different in= various countries, it shouldn't be written as a part of the number.

There is no need to be able to enter a "+" on a keypad.

Mike Pierce


 --part1_9f.65b328b0.303c7efe_boundary-- --===============0409695925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0409695925==-- From enum-bounces@ietf.org Tue Aug 23 10:16:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZZa-00089Y-IL; Tue, 23 Aug 2005 10:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZZY-00087l-MX; Tue, 23 Aug 2005 10:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06699; Tue, 23 Aug 2005 10:16:14 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7ZZR-0005sS-45; Tue, 23 Aug 2005 10:16:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 Aug 2005 16:19:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0EF@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Thread-Index: AcWn52LJXhwhKR8GT+WwkiA0pSz3QwAAPlhK From: "Stastny Richard" To: , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org >In the E164 plan, there was never any intention that the caller would = actually dial a "+".=20 E.164 is a numbering plan, not a dialing plan =20 >The "+" can be thought of as representing the extra digits for the = international prefix that you must dial according >to the local dialing = plan before you dial the number which follows the "+". Since it's = different in various countries, it >shouldn't be written as a part of = the number. Correct =20 >There is no need to be able to enter a "+" on a keypad. So you never used a mobile phone out of the US. You enter a '+' and is = translated by the system to the local international access code as you say above. Richard ________________________________ Von: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Gesendet: Di 23.08.2005 15:30 An: Stastny Richard; henry@pulver.com; voipeer@lists.uoregon.edu; = geopriv@ietf.org; enum@ietf.org Betreff: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in = common policy In a message dated 8/21/2005 5:01:54 PM Eastern Daylight Time, = Richard.Stastny@oefeg.at writes: Anybody using a softclient, be it on a laptop, PDA or softphone should use the same practice like on mobile phone, entering E.164 = numbers=20 ONLY (or preferably) in the international format with the leading "+" =09 Nevertheless, there are still may POTS phones out using terminal = adapters capable only of entering digits aad * and #. =09 So you MUST use a dialing plan and this can only be a national, local = or private dialing plan, because NO international dialing plan exists. =09 In the E164 plan, there was never any intention that the caller would = actually dial a "+". It is only a way to represent numbers when written = (like on letterhead). The "+" can be thought of as representing the = extra digits for the international prefix that you must dial according = to the local dialing plan before you dial the number which follows the = "+". Since it's different in various countries, it shouldn't be written = as a part of the number. There is no need to be able to enter a "+" on a keypad. Mike Pierce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Aug 23 12:11:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bNU-0006XQ-Or; Tue, 23 Aug 2005 12:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bNR-0006Wx-DW; Tue, 23 Aug 2005 12:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12620; Tue, 23 Aug 2005 12:11:50 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bNZ-0000rB-4b; Tue, 23 Aug 2005 12:12:02 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j7NGBUwP003346; Tue, 23 Aug 2005 09:11:30 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j7NGBQ7V003345; Tue, 23 Aug 2005 09:11:26 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 23 Aug 2005 09:11:26 -0700 From: David Meyer To: Mpierce1@aol.com Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Message-ID: <20050823161126.GA3315@1-4-5.net> References: <9f.65b328b0.303c7efe@aol.com> Mime-Version: 1.0 In-Reply-To: <9f.65b328b0.303c7efe@aol.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: geopriv@ietf.org, henry@pulver.com, Richard.Stastny@oefeg.at, enum@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1460845550==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============1460845550== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2005 at 09:30:38AM -0400, Mpierce1@aol.com wrote: > In a message dated 8/21/2005 5:01:54 PM Eastern Daylight Time,=20 > Richard.Stastny@oefeg.at writes: >=20 >=20 > > Anybody using a softclient, be it on a laptop, PDA or softphone > > should use the same practice like on mobile phone, entering E.164 numbe= rs=20 > > ONLY (or preferably) in the international format with the leading "+" > >=20 > > Nevertheless, there are still may POTS phones out using terminal adapte= rs > > capable only of entering digits aad * and #. > >=20 > > So you MUST use a dialing plan and this can only be a national, local or > > private dialing plan, because NO international dialing plan exists. > >=20 >=20 > In the E164 plan, there was never any intention that the caller would=20 > actually dial a "+". It is only a way to represent numbers when written (= like on=20 > letterhead). The "+" can be thought of as representing the extra digits f= or the=20 > international prefix that you must dial according to the local dialing pl= an=20 > before you dial the number which follows the "+". Since it's different in= various=20 > countries, it shouldn't be written as a part of the number. >=20 > There is no need to be able to enter a "+" on a keypad. Not sure about most, but I use "+ " in front of every number I store in my GSM phone; this way I don't have to do any special dialing in most geographies in which I find myself (and my carrier is either present or has roaming agreements with someone who does). Dave --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDC0quORgD1qCZ2KcRAvgJAJ9GCEE9aOlHWAj6TNRg+9P/fx+uzwCfdcNd Ml+/yKXsEf5hrgCFTGNeRaA= =MmNx -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- --===============1460845550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1460845550==-- From enum-bounces@ietf.org Tue Aug 23 18:54:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7hf8-0001U8-2Y; Tue, 23 Aug 2005 18:54:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7hf5-0001Q5-B0; Tue, 23 Aug 2005 18:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17917; Tue, 23 Aug 2005 18:54:28 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7hfG-0000er-P0; Tue, 23 Aug 2005 18:54:44 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id C61546DC7E; Tue, 23 Aug 2005 23:49:48 +0100 (BST) In-Reply-To: <20050823161126.GA3315@1-4-5.net> References: <9f.65b328b0.303c7efe@aol.com> <20050823161126.GA3315@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AAA4C48-4C55-4176-959A-D8758D0474CC@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy Date: Tue, 23 Aug 2005 23:53:50 +0100 To: David Meyer X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: "'enum@ietf.org' ENUM" , henry@pulver.com, Stastny Richard , geopriv@ietf.org, voipeer@lists.uoregon.edu X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org Hi David, folks If they do nothing useful every again (which seems likely, IMHO), ETSI/3GPP can be thanked for specifying '+' and its interpretation in the GSM specs, and for the members who built GSM phones who implemented the spec. Let's face it, Virtual Home Environment just doesn't get implemented (and was as much of a source of hilarity as any IN-based architecture document can be). Thus one big reason for putting a + at the start of ALL diallable numbers in one's address book is clueless roaming agreements that mean one doesn't know (unless one checks the SPAM texts one receives closely) whether the dialling plan one should use whilst roaming in this network: - treats UK numbers as "national" (and in-country numbers need to be dialled in full international format), or - country-local numbers are treated as national, with UK numbers needing full international format. Thank you so much for that guys. Travelling by train back from the ICANN meeting was fun, whilst calling people in the UK and France. It would appear that certain operators still can't find their a** even with a sign to help them. Using national format in diallable numbers in address books are a bad idea; + is your friend. I mean, some benighted countries don't even use 00 as an international dialling access code - duh! Oh, and BTW, '+' IS a on the keypad of every phone I've used. If it isn't on yours, may I respectfully suggest that you find the phone vendor/operator and express your displeasure forcefully, prior to getting a real phone. Richard originally wrote: >>> Anybody using a softclient, be it on a laptop, PDA or softphone >>> should use the same practice like on mobile phone, entering E.164 >>> numbers >>> ONLY (or preferably) in the international format with the leading >>> "+" To which Mike Pierce responded: >> In the E164 plan, there was never any intention that the caller would >> actually dial a "+". It is only a way to represent numbers when >> written (like on >> letterhead). The "+" can be thought of as representing the extra >> digits for the >> international prefix that you must dial according to the local >> dialing plan >> before you dial the number which follows the "+". Since it's >> different in various >> countries, it shouldn't be written as a part of the number. >> There is no need to be able to enter a "+" on a keypad. To which Dave replied: > Not sure about most, but I use "+ " in > front of every number I store in my GSM phone; this way > I don't have to do any special dialing in most > geographies in which I find myself (and my carrier is > either present or has roaming agreements with someone who > does). all the best, Lawrence _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Aug 24 12:06:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xlt-0002VA-3J; Wed, 24 Aug 2005 12:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xlr-0002Uu-4E for enum@megatron.ietf.org; Wed, 24 Aug 2005 12:06:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00747; Wed, 24 Aug 2005 12:06:32 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xmB-0005cq-F3; Wed, 24 Aug 2005 12:06:56 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j7OG71AA011672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2005 09:07:03 -0700 Message-ID: <430C9AF1.3010207@shockey.us> Date: Wed, 24 Aug 2005 12:06:09 -0400 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: proceedings@ietf.org, enum@ietf.org X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 1.5 (+) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 Cc: Subject: [Enum] IETF-63 Proceedings Submission - ENUM WG Meeting Minutes - FINAL X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2091306375==" Sender: enum-bounces@ietf.org Errors-To: enum-bounces@ietf.org --===============2091306375== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IETF 63  Telephone Number Mapping (ENUM) WG Meeting Minutes

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

Transport Area Advisor:
Allison Mankin  <mankin@psg.com>

Friday, August 6 2005  9:AM to 12:30 PM

AGENDA BASHING (5 min)

1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )

Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-02.txt
        Pages           : 29
        Date            : 2005-7-1

This document captures experience in implementing systems based on    the ENUM protocol, and experience of ENUM data that have been created    by others.  As such, it is informational only, and produced as a help    to others in reporting what is "out there" and the potential pitfalls  in interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt

 

WG ACTION :  After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.


2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

WG ACTION : Put this document into WGLC after one more revision by author.

DISCUSSION Some concerns whether this document is mature enough for even WG last call,  response is that the document will see another revision and pushing towards    last call is only meant to spur document forward.

3. New/old work on enumservice registrations  ( 20 M )

3.1


        Title           : IANA Registration for Enumservice Voice
        Author(s)       : R. Brandner, et al.
        Filename        : draft-brandner-enum-voice-00.txt
        Pages           : 12
        Date            : 2005-7-7

   This document registers the ENUMservice ^voice^ (which has a defined    sub-type ^tel^), as per the IANA registration process defined in the    ENUM specification RFC3761.  This service indicates that the contact   held in the generated URI can be used to initiate an interactive  voice (audio) call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.

DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.


3.2
        Title   : IANA Registration for an Enumservice  Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8

   This document registers the Enumservice "npd" and subtype "tel" using    the URI scheme 'tel:' as per the IANA registration process defined in   the ENUM specification, RFC 3761.  This data is used to facilitate  the routing of telephone calls in those countries where Number  Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt

 

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

 

DISCUSSION :

 

Comments include:
    - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
    - Global Spin Std.
    - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
    - TEL URI scope problem : examples should include both TEL and SIP URI examples
    - For IMS, limited usefulness
    - RFC 3671 db?  1 or collection? (Latter) 

    - Document should discuss sage of portability data as it relates national policy
    -


3.3

  Title           : IANA Registration for ENUMservice Mobile Webpage
  Author(s)       : J. Ra, et al.
  Filename        : draft-ra-shin-enum-mobileweb-00.txt
  Pages           :
  Date            : 2005-7-7

   This document registers the ENUMservice “mobweb” using the URI    schemes 'http:' and 'https:' as per the IANA registration process  defined in the ENUM specification RFC3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt

 

WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.

 

DISCUSSION:
Discussion dove into issue of DNS vs. Application layer indication of  protocol stack capabilities.

    - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
    - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection)
    - HTTP negotiation accomplishes the same once connection is in place
    - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP)
    - RFC 3824, guidelines on SIP and ENUM as reference

   - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.



4. ENUM Validation Issues. 3 Drafts 15 -20

 4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00

        Title           : ENUM Validation Architecture
        Author(s)       : A. Mayrhofer, B. Hoeneisen
        Filename        : draft-mayrhofer-enum-validation-arch-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164   number.  The process of verifying whether or not the Registrant of an  ENUM domain name is identical to the Assignee of the corresponding  E.164 number is commonly called ^validation^.  This document  describes validation requirements and a high level architecture for  an ENUM validation infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt


WG ACTION :  WG humm agrees to draft as ENUM WG work item.


4.2  "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt


        Title           : ENUM Validation Token Format Definition
        Author(s)       : O. Lendl
        Filename        : draft-lendl-enum-validation-token-00.txt
        Pages           : 16
        Date            : 2005-7-11

   An ENUM domain name is tightly coupled with the underlying E.164  number.  The process of verifying whether the Registrant of an ENUM  domain name is identical to the Assignee of the corresponding E.164  number is commonly called ^validation^.  This document describes an  signed XML data format -- the Validation Token -- with which
 Validation Entities can convey successful completion of a validation  procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

4.3  Bernie Hoeneisen


  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

WG ACTION :  WG humm agrees to draft as ENUM WG work item.

DISCUSSION: Very little technical discussion of the above 3 documents.



#################

5. PART 2  1/2 hours. 3 Items

WG AGENDA: Terms and Conditions of discussion.

The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand.
 


#################

5.1 Discussion of drafts on Carrier ENUM - Requirements ?

  Title           : Infrastructure ENUM Requirements
        Author(s)       : S. Lind
        Filename        : draft-lind-infrastructure-enum-reqs-00.txt
        Pages           : 8
        Date            : 2005-7-15

 There has been much discussion in various industries about the  concept of infrastructure (or carrier) ENUM. Some of this discussion   has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the  Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus    industry-wide on even what infrastructure ENUM is, why it seems to be  important, or what the requirements for implementing it are.

 At the request of the WG co-chairs, this document attempts to gather   together the bits and pieces from those discussions (i.e., I stole   the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that   will enable enlightened discussion and hopefully achieve consensus.   Some items listed below may be duplicative and suggest alternative    wordings for similar and other contradictory issues. As such, this  list is very raw and should not be viewed as complete, cohesive or  correct.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt

 

WG ACTION:  This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.

Penn Pfautz agrees to collaborate with Steve Lind on future drafts.

5.2  Title           : IANA Carrier/User enumservice Registration
        Author(s)       : P. Pfautz, et al.
        Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
        Pages           : 10
        Date            : 2005-6-6

This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry  to support end user and carrier services with independent name   servers holding the terminal NAPTR (Naming Authority Pointer) records  identifying the communication services for each.  The to-be-  registered enumservices make use of non-terminal NAPTR records and  DDDS (Dynamic Delegation Discovery System) replacement to achieve  this end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt


5.3       Title           : Combined User and Carrier ENUM in the e164.arpa tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-haberler-carrier-enum-00.txt
        Pages           : 10
        Date            : 2005-7-11

   ENUM as defined now in RFC3761 is not well suited for the purpose of    interconnection by carriers, as can be seen by the use of various  private tree arrangements based on ENUM mechanisms.  A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number.  This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt


DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.


  As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant.  Three approaches were mentioned but only two seem "obvious".

   Non-terminal NAPTR records

 Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier.  Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup.

   Separated branches of the DNS tree

A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or

B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.

 End users ( number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa.

   Requirements/Desired results
   1) Minimize number of lookups
   2) Retain flexibility
   3) Consistency from CC to CC for predictability

  DISCUSSION:

   -  Data in DNS does not guarantee reachability ("deny's" allowed)

   -  DNS MUST answer.
   - Uniformity in "c" label, name and where, is important
   - Non-terminal NAPTRs are untried
   - Questions on whether DNS wildcards are pertinent to the issue
   - Three questions - what's better for 1) DNS, 2) Application, and 3) "life"
   - Should not preclude private carrier-carrier traffic control

WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.

Further Discussion on Next Steps

   - Needs requirements and especially use cases to indicate what it is about

WG ACTION: Requirements document added as WG item.
   - RFC 3761 should remain untouched
   - Scope needs definition (stop at re-write rules?)
   - Use cases, use cases, use cases
   - Terminology and definitions needed
 
The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time". 

3 Options 

A.	Pfautz approach of use of non-terminal NAPTR's 
B.	Haberler/Stastny approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa or
	with delegation after RIPE/ITU c. [CC].e164.arpa 
C.	Using a different (non-e164.arpa) domain

Hum indicates strong preference for B with further discussion the WG necessary.

Further Discussion:

Division of labor with VOIPEER BoF effort required

6.0 Title           : Non-Terminal NAPTR Processing: A Modest Proposal
        Author(s)       : L. Conroy
        Filename        : draft-conroy-enum-modestproposal-00.txt
        Pages           : 12
        Date            : 2005-7-6

  Recent Discussions within the IETF and in other fora have highlighted  differences in interpretation of the set of standards associated with    ENUM and DDDS, on which it relies.  Specifically, the operation and   semantics surrounding support for non-terminal NAPTRs has led to some    confusion.  This document is n attempt to add clarification to non-   terminal NAPTR processing.  In this, it clarifies RFC3403.  A    subsequent document will build on this one to extend FC3761 further,    permitting registration of non-terminal Enumservices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt

WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.

 

Meeting Concludes.


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--===============2091306375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2091306375==--