From daemon@optimus.ietf.org Fri Mar 1 00:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05902 for ; Fri, 1 Mar 2002 00:34:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25015 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 00:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24300; Fri, 1 Mar 2002 00:26:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24271 for ; Fri, 1 Mar 2002 00:25:56 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05714 for ; Fri, 1 Mar 2002 00:25:55 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g215OTb09516 for ; Fri, 1 Mar 2002 00:24:29 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g215OTl09504 for ; Fri, 1 Mar 2002 00:24:29 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Date: Thu, 28 Feb 2002 22:26:31 -0700 Message-ID: Thread-Topic: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Thread-Index: AcHAk2AQmIkcEsbcSGaa1FSH1NqBqgARqgJA From: "Zmolek, Andrew (Andrew)" To: "Brandner Rudolf" , "Richard Shockey" , Cc: "Conroy Lawrence" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA24272 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Follow-up comments inline... >> Strong association of detailed service capabilities with E.164 >> numbers via ENUM would either: >> A. Reduce accuracy of resulting information by giving >> information only for ENUM-registered endpoints when one or >> more non-registered endpoints >> may ultimately terminate a call to a given E.164 number. >> B. Somehow forbid non-registered endpoints from terminating a >> call initiated through ENUM (bye-bye call forwarding!) >> C. Force ENUM service providers to act as a public "presence" >> service, updating service-tags and capabilities in real-time. >> > > I do not get A. B. C. Would you please clarify what you mean by > 'ENUM-registered' or non-registered. ENUM-registered endpoints are those in the termination path for an E.164 number whose service capabilities are properly exposed in service field tags in NAPTR records. Since the PSTN today wouldn't prevent other endpoints in that termination path with capabilities not listed, or substitutions of a "non-registered" endpoint (such as in the call forward case), there is always some potential for mismatch between the termination path for an E.164 number and the list of services registered. I had perhaps oversimplified things a bit by referring to the endpoints as registered rather than their services. >> Note that none of these options is desirable, and none tackles >> issues in the sphere of privacy, public exposure of information, >> hacking via service profiling, etc. So it is my assertion that >> for many cases a "service resolution" level of indirection is >> justified here. I am careful to note, however, that in some >> specific cases, no level of indirection is needed or desired-- >> ENUM clearly has value in both cases. > > privacy, public exposure ...... > > Having a "service resolution" might not help much, too. If I ask > you a question, there are 2 basic answers: you just refuse to talk > to me, or you talk to me. Agreed, with ENUM, I might reveal more > information (which, to some extend is outlined in our draft) than > with a service resolution. If the "service resolution" finally > answeres my request, I think, that service profiling can be done > anyway. I *think*, because I actually do not know what that "service > resolution" is going to be in terms of authentication (which would be > necessary if you have ACLs), integrity and privacy. To answer or not answer is the most basic, but I can also us an SRS to answer or expose based on context (which may include authenticated identity where such a system is available, particularly if both parties are inside a closed system like an enterprise system), and I could even lie (in the case of those pesky telemarketers or creditors) or expose a bot-like IM service that mimics a human just enough to waste their time or discourage further discussion. With respect to exposure to hacks via service profiling, the SRS only solves this problem if the end user chooses a sufficiently narrow filter that gives little or no information to an unidentified requestor. But it does give the ENUM registrant a great deal more control, particularly with respect to allowing for "blacklisting" of known malicious requestors or request patterns, which ENUM is not prepared to do otherwise. > I am just worried, that the "service resolution" protocol might > add *much* extra cost through authentication, signing the content > and encryption. How much this might be I do not know, as I do not > know what you have in mind as a "service resolution" protocol and > application. I think these are valid concerns. My hope is to find enough interest to get a standalone presence service and protocol defined that isn't tied to any one message or media signaling protocol. The main design constraints would be a clean query structure, a lean protocol, and tight integration with an identity system that would be usable for real time communications and transactions. >> Frankly, many other presence services already exist within limited >> realms and all of them would benefit from an open protocol for >> interchange of that information. From the ENUM point of view, I would >> assert that we shouldn't be in the business of picking winners for >> presence services. Yet we should still make the bar reasonably high >> before assigning a service tag to such a service. > > Agreed, we should not pick winners. BTW: it would be good to know, who are the runners? While many proprietary systems exist today, I won't attempt to suggest an alternative to SIP/SIMPLE at the moment. Actually, my hope is to craft a better general-purpose presence system from scratch. Alternatively, adding some extensions to SIP presence might also work (though there may be some obstacles of religion in that approach, as it seems unlikely to me that I will ever see an h.323 URI exposed via SIP presence, for instance). We'll it's snowing hard here in Denver tonight and I need to get up early to take advantage of the fresh powder (not to mention the fresh perspective a day of snowboarding invariably provides). So I'm going to call it a night... --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 1 06:29:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10682 for ; Fri, 1 Mar 2002 06:29:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02215 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 06:29:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27680; Fri, 1 Mar 2002 06:20:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27544 for ; Fri, 1 Mar 2002 06:20:35 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10078 for ; Fri, 1 Mar 2002 06:20:29 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062998; Fri, 01 Mar 2002 11:20:22 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <29660208.1014913902@localhost> References: <29660208.1014913902@localhost> Date: Fri, 1 Mar 2002 11:20:16 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Brandner Rudolf From: Lawrence Conroy Subject: Re: AW: [Enum] Common Issues with ENUM and enumservices Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA27553 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi Patrik, Folks, Apologies for this, but comments inline: At 4:31 pm -0500 28/2/02, Patrik Fältström wrote: >--On 2002-02-28 21.07 +0100 Brandner Rudolf > wrote: > >>> Is your point the need for different entities for different >>> NAPTR records? >> >> Not quite, we know that a CNAME is a complete redirection. This is >> transparent to DDDS, so there are some impacts on RegExp matching. > >What impacts? Can you give an example? We gave an example in the 'tel' doc. If you match on the full AUS then this probably won't match against a query that has "arrived" via a CNAME. This allows some NAPTRs to match only if the number is queried directly. That is a restriction (or "Beware!") on the use of RegExps, I think. I think that there may even be occasions where it's not a good idea even to match against the '+'. > >> The priority/preference must be calculated over all NAPTR >>> records with the >>> same owner. I.e. it is calculated as part of the DNS >>> resolution, and not >>> the NAPTR resolution. >> >> I see, you mean in the same zone? > >The priority/preference is calculated over all NAPTR with the same owner. >If two sets of NAPTR are in the same zone, but with different owners, the >two sets are used separated from each other. > >Example: If I have a.example.com and two NAPTR for that owner, the priority >and preference is calculated over both records, regardless of the service >or flag fields. If also have b.example.com in the same zone, that is not >included in the calculation. > >I _think_ you with "zone" mean same "owner", i.e. same domain name? Now I'm mightily confused. Please clarify what is an owner. Can one have more than one "owner" within the same leaf zone, and how can the requestor tell? Are you talking about views here? > >> Not saying I don't want to write about them. Just as an explanation. >> >> So I look forward to reading this ;^) > >Hmmm....there are nice books about how DNS works ;-) > > paf Where? - DNS&BIND is not exactly up-to-date :( best regards from a puzzled Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 1 06:35:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11076 for ; Fri, 1 Mar 2002 06:35:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04684 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 06:35:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00084; Fri, 1 Mar 2002 06:26:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00054 for ; Fri, 1 Mar 2002 06:26:29 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10359 for ; Fri, 1 Mar 2002 06:26:25 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000062999; Fri, 01 Mar 2002 11:26:24 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> References: <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> Date: Fri, 1 Mar 2002 11:26:19 +0000 To: Richard Shockey From: Lawrence Conroy Subject: Re: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Cc: enum@ietf.org, Rudi Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 3:23 pm -0500 28/2/02, Richard Shockey wrote: >Ok ... correct me if I'm wrong. I'm trying to simplify the argument >here ..so the basic technical and business case for a TEL URL based >redirection service is that you can screw some poor unsuspecting >incumbent Telco out of a fat margin C7 based Call Forwarding >product. Right ? OK ... I'm sold. I'll buy that. Why did'nt you >say so in the first place? :-) > >Privacy issue is a non issue since this is Opt-In for the perceived >benefit(s). To which I reply... Speaking as someone who works for a vendor, you might think so but I couldn't possibly comment. Poor and unsuspecting, Hah! Speaking as poor Joe Public, I'd quite like this service if I'm not reduced to penury using it. Bang on with privacy point. If I need privacy (and rapid update, ...) I'll get someone else to pay for it; otherwise, I'll opt-in. All the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 1 07:27:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17110 for ; Fri, 1 Mar 2002 07:27:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23630 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 07:27:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23190; Fri, 1 Mar 2002 07:18:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23154 for ; Fri, 1 Mar 2002 07:18:15 -0500 (EST) Received: from www16-cn.sinonets.net.cn ([202.99.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16321 for ; Fri, 1 Mar 2002 07:18:09 -0500 (EST) From: info@polyglot.com.cn Received: from AN [218.19.26.104] by www16-cn.sinonets.net.cn (SMTPD32-6.06) id A10049A00E6; Fri, 01 Mar 2002 20:16:00 +0800 Date: ÐÇÆÚÎå, 01 ÈýÔ 2002 20:15:33 +0800 Content-Type: text/plain To: enum@ietf.org X-Library: WinShoes 7.035B X-Mailer: MSEND 1.01A Message-Id: <200203012016593.SM01096@AN> Subject: [Enum] Polyglot Translation Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Polyglot Translation Co., Ltd. We are a professional translation organization that provides translation, interpretation, and simultaneous meeting interpretation in all fields. In addition, we provide localization of websites into Chinese, writing articles in multi-languages, foreign languages recording, proofreading, Interpreters/translators recommending, website designing and making and so on. We can provide a large variety of languages translating services such as English, Japanese, French, German, Russian, Korean, Italian, Spanish, Dutch, Swedish, Finnish, Portuguese, Czechish, Slovak,Romanian, Polish, Hungarian,Bulgarian,Arabic,Turkish,Cambodian, Malay, Indonesian, Thai, Vietnamese, Nepali, Laotian, Burmese, Mongolian, Indic, Bengalese, Tamil and so on. Altogether, we can provide more than 30 languages translation service fast and accurately. For the details, please visit our website: http://www.polyglot.com.cn http://www.chinapolyglot.com Contact us: E-mail: info@polyglot.com.cn Tel: +86-20-8657-3608 Fax: +86-20-8657-3965 Add: Suite 968 Office Tower Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: ±£Á¢ÐÅ·­Ò빫˾ ±£Á¢ÐÅ·­Ò빫˾ÊÇÒ»¼Òרҵ·­Òë»ú¹¹,¿ÉÌṩ¸÷¸öÁìÓòµÄ±ÊÒë¡¢¿ÚÒë¡¢»áÒé µÄͬÉù´«Òë¡£ ´ËÍ⣬Ϊ¸÷ÀàÖÐÍâÍøÕ¾Ìṩ·­Òë°æ±¾£¬ÒÔ¼°Îª¿Í»§Ìṩ¶àÖÖÓïÑÔµÄ׫¸å·þÎñ¡¢ ÍâÎļÒô¡¢Ð£¸å¡¢·­ÒëÍƼö¡¢ÍøÕ¾Éè¼Æ¡¢ÖÆ×÷µÈ¡£ ·­ÒëÓïÖÖ£º¿ÉÌṩӢ¡¢ÈÕ¡¢·¨¡¢µÂ¡¢¶í¡¢º«¡¢Òâ´óÀû¡¢Î÷°àÑÀ¡¢ºÉÀ¼¡¢Èðµä¡¢ ·ÒÀ¼¡¢ÆÏÌÑÑÀ¡¢½Ý¿Ë¡¢Ë¹Âå·¥¿Ë¡¢ÂÞÂíÄáÑÇ¡¢²¨À¼¡¢ÐÙÑÀÀû¡¢±£¼ÓÀûÑÇ¡¢°¢À­²®¡¢ ÍÁ¶úÆä¡¢¼íÆÒÕ¯¡¢ ÂíÀ´¡¢Ó¡Äᡢ̩¡¢Ô½ÄÏ¡¢Äá²´¶û¡¢ ÀÏÎΡ¢Ãåµé¡¢Ãɹš¢Ó¡¶È¡¢ ÃϼÓÀ­¡¢Ì©Ã׶ûµÈÈýÊ®¶àÃÅÍâÓï×î׼ȷ¡¢¿ì½ÝµÄ·­ÒëµÄ·þÎñ¡£ ¹ØÓÚÏêÇ飬Çë²Î¹ÛÎÒÃǵÄÍøÖ·£º http://www.polyglot.com.cn http://www.chinapolyglot.com ÁªÏµ·½Ê½£º µçÓÊ: info@polyglot.com.cn µç»°: 020-86573608 ´«Õæ: 020-86573965 µØÖ·£ºÖйú¹ãÖÝ»ú³¡Â·33ºÅÖÐÑë¾Æµêд×ÖÂ¥968 Óʱࣺ510403 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 1 08:04:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19832 for ; Fri, 1 Mar 2002 08:04:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25253 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 08:04:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24515; Fri, 1 Mar 2002 07:55:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24484 for ; Fri, 1 Mar 2002 07:55:24 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19159 for ; Fri, 1 Mar 2002 07:55:21 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063003; Fri, 01 Mar 2002 12:55:21 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 1 Mar 2002 12:50:10 +0000 To: "Zmolek, Andrew (Andrew)" , Brandner Rudolf , Richard Shockey , enum@ietf.org From: Lawrence Conroy Subject: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Andrew, Folks, Again, sorry for the in-line comments:: At 10:26 pm -0700 28/2/02, Zmolek, Andrew (Andrew) wrote: >Follow-up comments inline... > >>> Strong association of detailed service capabilities with E.164 >>> numbers via ENUM would either: >>> A. Reduce accuracy of resulting information by giving >>> information only for ENUM-registered endpoints when one or >>> more non-registered endpoints >>> may ultimately terminate a call to a given E.164 number. >>> B. Somehow forbid non-registered endpoints from terminating a >>> call initiated through ENUM (bye-bye call forwarding!) >>> C. Force ENUM service providers to act as a public "presence" >>> service, updating service-tags and capabilities in real-time. >>> >> >> I do not get A. B. C. Would you please clarify what you mean by >> 'ENUM-registered' or non-registered. > >ENUM-registered endpoints are those in the termination path for an E.164 >number whose service capabilities are properly exposed in service field >tags in NAPTR records. Since the PSTN today wouldn't prevent other >endpoints in that termination path with capabilities not listed, or >substitutions of a "non-registered" endpoint (such as in the call >forward case), there is always some potential for mismatch between the >termination path for an E.164 number and the list of services >registered. I had perhaps oversimplified things a bit by referring to >the endpoints as registered rather than their services. To which LwC sez: You mean ENUM/DNS registrants, I think. Re. the comment on end points - I assume that you mean the combination of the (enumservice and its associated URI) within a NAPTR, yes? Also - Dead right, there is a potential for mismatch - that's one of the reasons why I'm hostile to E2VIDEO.G.263 and its ilk. It's an admin "challenge". > >> Note that none of these options is desirable, and none tackles >>> issues in the sphere of privacy, public exposure of information, >>> hacking via service profiling, etc. So it is my assertion that >>> for many cases a "service resolution" level of indirection is >>> justified here. I am careful to note, however, that in some >>> specific cases, no level of indirection is needed or desired-- >>> ENUM clearly has value in both cases. >> >> privacy, public exposure ...... >> >> Having a "service resolution" might not help much, too. If I ask >> you a question, there are 2 basic answers: you just refuse to talk >> to me, or you talk to me. Agreed, with ENUM, I might reveal more >> information (which, to some extend is outlined in our draft) than >> with a service resolution. If the "service resolution" finally >> answeres my request, I think, that service profiling can be done >> anyway. I *think*, because I actually do not know what that "service >> resolution" is going to be in terms of authentication (which would be >> necessary if you have ACLs), integrity and privacy. > >To answer or not answer is the most basic, but I can also us an SRS to >answer or expose based on context (which may include authenticated >identity where such a system is available, particularly if both parties >are inside a closed system like an enterprise system), and I could even >lie (in the case of those pesky telemarketers or creditors) or expose a >bot-like IM service that mimics a human just enough to waste their time >or discourage further discussion. > >With respect to exposure to hacks via service profiling, the SRS only >solves this problem if the end user chooses a sufficiently narrow filter >that gives little or no information to an unidentified requestor. But it >does give the ENUM registrant a great deal more control, particularly >with respect to allowing for "blacklisting" of known malicious >requestors or request patterns, which ENUM is not prepared to do >otherwise. To which LwC sez: ENUM isn't really prepared to do this at all. What you're suggesting is what happens AFTER we drop out of ENUM. These are all possible using a suitable authenticated (and maybe encrypted) exchange - however, this subsequent exchange is going to take time. I'm not sure that this is always going to be acceptable when fired out from the core network, in the middle of call setup (as per 3GPP). Post-dial delay is going to get long. > > >> I am just worried, that the "service resolution" protocol might >> add *much* extra cost through authentication, signing the content >> and encryption. How much this might be I do not know, as I do not >> know what you have in mind as a "service resolution" protocol and >> application. > >I think these are valid concerns. My hope is to find enough interest to >get a standalone presence service and protocol defined that isn't tied >to any one message or media signaling protocol. The main design >constraints would be a clean query structure, a lean protocol, and tight >integration with an identity system that would be usable for real time >communications and transactions. To which LwC groans: Whoa! Having endured the extended joy of IMPP, I (and I suspect Patrik) may be a tad unhappy at the thought or reliving that experience. > > >>> Frankly, many other presence services already exist within limited >>> realms and all of them would benefit from an open protocol for >>> interchange of that information. From the ENUM point of view, I would >>> assert that we shouldn't be in the business of picking winners for >>> presence services. Yet we should still make the bar reasonably high >>> before assigning a service tag to such a service. >> >> Agreed, we should not pick winners. BTW: it would be good to know, who >are the runners? > >While many proprietary systems exist today, I won't attempt to suggest >an alternative to SIP/SIMPLE at the moment. Actually, my hope is to >craft a better general-purpose presence system from scratch. >Alternatively, adding some extensions to SIP presence might also work >(though there may be some obstacles of religion in that approach, as it >seems unlikely to me that I will ever see an h.323 URI exposed via SIP >presence, for instance). To which LwC blinks and moves on: Again, I worry greatly about the "from scratch". Not group 3 again, or is this the first stirrings of group 4, of just forbidden planet, or ...? I agree with Rudi - until we know what this system is intended to be, it's hard to do anything but trade assumptions. I'm being dumb here, but I would be most interested your ideas on what exactly is missing from SIMPLE or SIP for which you need extensions to cover? Also, you use the reserved term "presence", and I'm not quite sure that this is quite correct here - in SIP terms the AoR is static and is returned via an ENUM query. The current contact address may be updated depending on the connectivity of a destination client's equipments but that is a hidden back-end process. I guess that this back-end process could be classified as "presence", if you look at it cross-eyed enough (Maybe after snowbarding into a tree ?). However, from ENUM, it's a static value; plain vanilla SIP is acting as the SRS. Re. h232: and SIP or SIMPLE, I don't see why not. The new, expanded, Typhon may well be interested. >We'll it's snowing hard here in Denver tonight and I need to get up >early to take advantage of the fresh powder (not to mention the fresh >perspective a day of snowboarding invariably provides). So I'm going to >call it a night... Some people have all the luck - we just have clouds and rain and ... all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 10:29:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00034 for ; Fri, 1 Mar 2002 10:29:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02659 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 10:29:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02225; Fri, 1 Mar 2002 10:20:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02123 for ; Fri, 1 Mar 2002 10:20:24 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29605 for ; Fri, 1 Mar 2002 10:20:21 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063011; Fri, 01 Mar 2002 15:20:23 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: Date: Fri, 1 Mar 2002 15:20:22 +0000 To: richard.stastny@oefeg.at, Rudi From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] "tel:" URIs and phone-context parameter Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard, Folks, Richard raises some interesting points on tel: URIs. I get the feeling that we need to add something on how these can be used. First, a bit of history - some thinking on this was initially done in PINT (and Annti combined this with the rest of the work he had been doing on the tel: URI). The theory is that not all numbers are dialable from everywhere, or rather you can dial them but you may well not connect to the same end point. Thus the phone-context parameter was introduced to indicate the service area in which this telephone number was valid. With PINT and the tel: work, we were focusing on the dialed number. (With PINT, both parties are called numbers as it describes a callback or International Arbitrage service). We assumed that the caller (or gateway) would know what *their* phone context was, and could match this against the service area indicated by the tel: URI they were using as the destination. If they match, then the number is valid; if they don't, then it isn't dialable from the caller's or gateway's location. The problem of originating a call within a particular region is not the caller's but the gateway service provider's. If the destination is specified using a tel: URI with a phone-context, then either the provider can fulfill the request as specified, or it can't. As customers don't like wrong numbers, I guess that the service provider will have to be careful about choosing to originate the PSTN segment of the call outside the requested context. Thus works if originated within the NANP region. So does . Also, works if originated in Austria, as does (Of course, these two probably don't terminate at the same end point :) One neat use is for network-specific service numbers; thus Scott Petrack's example from PINT is . "It so happens that +97252 defines one of the Israeli cell phone providers, and 123 reaches customer service when dialed within that network". Now, to your examples:: I think that you have 3 contexts. * The caller's allocated number context * The presented number context (e.g. the area code to be added to the local number in order to construct a full E.164 number, akin to the implied context with an Q.763 CalledPartyAddress with NAI of 1 or 3) * The PSTN call origination point context (i.e. the service area in which the called number is specified as being valid, and so where the PSTN segment of the call should be originated) As you point out, if the called party is specified using a local number format, then it *may* be possible to convert this into a full E.164 number. The problem I have with this is that it is not always possible to tell; for example, +97252123 will almost certainly not work as expected, but it is possible to convert to from . BTW, we included the Q763 parameters as described in section 3.4.3.3 of RFC2848 for this kind of case. I'm still a little uncomfortable with how these can be used; I suspect that any Operator will simply throw them away when received from an end user (this goes for the Calling Party Category as well). Maybe they are still useful, as not everything is received from the (public) ENUM - (perhaps from telekom.inside :)? Perhaps we could add a section to the next version of the 'tel' specification, on how tel: URIs can be used. This should describe resolution based not only on the ENUM system, but also on call origination validity (i.e. whether or not the origination point of the PSTN segment of a call is within a specified phone-context). I'm still not completely comfortable about including tel: URIs in the (public) ENUM that have limited validity (i.e. where a requestor may have returned a number that is, for them, invalid). One reason is exactly the one you specify; it can be hard for a caller to negotiate the PSTN origination point with their Gateway Service Provider (the counter-argument is, of course, that the service provider should expect their vendors to read and implement the RFCs :-). As an alternative, you could always use PINT - see section 3.4.3.1 of RFC2848. However, given that discomfiture, we can put the text into the next version (or another document), with the caveat that using this form needs thought. For our U.S. readers, that means that you SHOULD put in an entry with the full E.164 number as well as one with the context-specific version - NOT just the 1-800 number! As usual, any comments gratefully received. best regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 10:44:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00928 for ; Fri, 1 Mar 2002 10:44:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04053 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 10:44:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03455; Fri, 1 Mar 2002 10:36:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03423 for ; Fri, 1 Mar 2002 10:36:06 -0500 (EST) Received: from localhost ([211.222.117.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00356 for ; Fri, 1 Mar 2002 10:36:04 -0500 (EST) Message-Id: <200203011536.KAA00356@ietf.org> Reply-To: gtech01@gtech21.com From: (ÁÖ)ÁöÅØ To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 2 Mar 2002 00:12:03 +0900 Subject: [Enum] ȹ±âÀûÀÎ ÈÞ´ëÆù¿ë À̾îÆù !!! [±¤°í] Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org mail02-1
¢Á Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³»¼­ Á˼ÛÇÕ´Ï´Ù.
¢Á º»¸ÞÀÏÀº Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¢Á e-mail ÁÖ¼Ò´Â ÀÎÅͳݻ󿡼­ ÃëµæÇÏ¿´À¸¸ç, ÁÖ¼Ò¿Ü ¾î¶°ÇÑ °³ÀÎ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù.
¢Á ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é '¼ö½Å°ÅºÎ'¸¦ ´­·¯ÁÖ¼¼¿ä. [¼ö½Å°ÅºÎ]
 
 
 
 
(ÁÖ)ÁöÅØ ÀÎõ±¤¿ª½Ã °è¾ç±¸ ÀÛÀüµ¿ 852-73 Tel:(032)552-7222
E-mail : gtech@gtech21.com    Homepage : http://www.gtech21.com
 
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 11:11:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02670 for ; Fri, 1 Mar 2002 11:11:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06852 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 11:11:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05780; Fri, 1 Mar 2002 11:01:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05749 for ; Fri, 1 Mar 2002 11:01:45 -0500 (EST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01950 for ; Fri, 1 Mar 2002 11:01:42 -0500 (EST) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g21Fvrp17827; Fri, 1 Mar 2002 15:57:53 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 16gpPq-000Ouv-00; Fri, 01 Mar 2002 15:57:50 +0000 Date: Fri, 1 Mar 2002 15:57:50 +0000 From: "Clive D.W. Feather" To: Lawrence Conroy Cc: richard.stastny@oefeg.at, Rudi , enum@ietf.org Subject: Re: [Enum] "tel:" URIs and phone-context parameter Message-ID: <20020301155750.GU48327@finch-staff-1.demon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence Conroy said: > The theory is that not all numbers are dialable from everywhere, or > rather you can dial them but you may well not connect to the same end > point. Thus the phone-context parameter was introduced to indicate the > service area in which this telephone number was valid. Question: is this a practical problem for E.164 numbers ? > If the destination is > specified using a tel: URI with a phone-context, then either the > provider can fulfill the request as specified, or it can't. As customers > don't like wrong numbers, I guess that the service provider will have to > be careful about choosing to originate the PSTN segment of the call > outside the requested context. > > Thus works if originated within > the NANP region. So does . But +1-800-555-1234 works perfectly well from the +44 region. At least with some telcos. > Also, works if originated in > Austria, as does Since both of these numbers lie within E.164 space, only the second form ought to be used. [Question: does the first form include national numbering plan digits ? In other words, do I write or for +44-20-8371-1138 ?] I see three separate situations: [1] An E.164 number can only be reached from certain areas. This might be because some originating telcos won't route it (+44 8XX was a notorious example because many telcos tried to route it as +44 18XX) or because the recipient is rejecting "out-of-area" calls. I don't see "phone-context" as being the right way to say this; it's no different from any other situation where a call might fail, and the person writing the URI might not understand the rules (see the +1-800 example above). Also, how do I write "not" in a phone-context ? Consider the Demon "Purple ROMP", which is: [2] An E.164 number reaches different destinations depending on how the call is routed to the number (this applied to my own home number for most of the last two months, due to a number porting cock-up). If deliberate (e.g. to give multiple call centres a common number but have calls routed to the nearest one), should this fact be published in a tel: URI ? With this case, how do I write URIs for the call centres ? I want something like: Centre 1 Centre 2 Centre 3 except that I will have perhaps 100 or 200 possible contexts per number. [3] Numbers not in the E.164 system. As you say: > One neat use is for network-specific service numbers; thus Scott > Petrack's example from PINT is . > "It so happens that +97252 defines one of the Israeli cell phone > providers, and 123 reaches customer service when dialed within that > network". However, number portability rather breaks this: my mobile is in the numbering block +447973, allocated to one mobile provider, but it has been ported to a second one. 123 worked on the first provider but doesn't work on the second, though 121 now does the same job. > I think that you have 3 contexts. > * The caller's allocated number context Not sure what you mean by that one. > * The presented number context (e.g. the area code to be added to the > local number in order to construct a full E.164 number, akin to the > implied context with an Q.763 CalledPartyAddress with NAI of 1 or 3) If the number is in E.164, then there's little or no point in this. If it isn't, then you need: > * The PSTN call origination point context (i.e. the service area in > which the called number is specified as being valid, and so where the > PSTN segment of the call should be originated) -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 11:31:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04163 for ; Fri, 1 Mar 2002 11:31:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09589 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 11:31:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08039; Fri, 1 Mar 2002 11:20:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08008 for ; Fri, 1 Mar 2002 11:19:58 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03284 for ; Fri, 1 Mar 2002 11:19:55 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g21GJK827072; Fri, 1 Mar 2002 11:19:20 -0500 Message-Id: <5.1.0.14.2.20020301110546.04440e98@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 11:22:00 -0500 To: Lawrence Conroy From: Richard Shockey Cc: enum@ietf.org In-Reply-To: References: <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Privacy Considerations in Service Registrations ? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:26 AM 3/1/2002 +0000, Lawrence Conroy wrote: >At 3:23 pm -0500 28/2/02, Richard Shockey wrote: >>Ok ... correct me if I'm wrong. I'm trying to simplify the argument here >>..so the basic technical and business case for a TEL URL based >>redirection service is that you can screw some poor unsuspecting >>incumbent Telco out of a fat margin C7 based Call Forwarding >>product. Right ? OK ... I'm sold. I'll buy that. Why did'nt you say so >>in the first place? :-) >> >>Privacy issue is a non issue since this is Opt-In for the perceived >>benefit(s). > >To which I reply... > >Speaking as someone who works for a vendor, you might think so but I >couldn't possibly comment. >Poor and unsuspecting, Hah! >Speaking as poor Joe Public, I'd quite like this service if I'm not >reduced to penury using it. >Bang on with privacy point. If I need privacy (and rapid update, ...) I'll >get someone else to >pay for it; otherwise, I'll opt-in. To which I have a question for Patrik and Mike ... in the E.164-URI draft you begin to outline the requirements for service registration and you correctly require certain defined section to be present such as in 3.1.3 an analysis of Security Requirements, as is required for all IETF RFC's. Should we expand that list to include "Privacy Considerations" ? or perhaps in the beginning a clear well defined "Applicability Statement" or in other words 'Why we want to register this paramater' >All the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 13:50:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14362 for ; Fri, 1 Mar 2002 13:50:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20392 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 13:50:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19636; Fri, 1 Mar 2002 13:41:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19601 for ; Fri, 1 Mar 2002 13:41:54 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13613 for ; Fri, 1 Mar 2002 13:41:50 -0500 (EST) Received: from [193.118.192.40] ([193.118.192.40] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063021; Fri, 01 Mar 2002 18:41:49 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <20020301155750.GU48327@finch-staff-1.demon.net> References: <20020301155750.GU48327@finch-staff-1.demon.net> Date: Fri, 1 Mar 2002 18:41:47 +0000 To: "Clive D.W. Feather" From: Lawrence Conroy Subject: Re: [Enum] "tel:" URIs and phone-context parameter Cc: richard.stastny@oefeg.at, Rudi , enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Clive, folks, I'm still being lazy, so in-line comments I'm afraid:: At 3:57 pm +0000 1/3/02, Clive Feather wrote: >Lawrence Conroy said: >> The theory is that not all numbers are dialable from everywhere, or >> rather you can dial them but you may well not connect to the same end >> point. Thus the phone-context parameter was introduced to indicate the >> service area in which this telephone number was valid. > >Question: is this a practical problem for E.164 numbers ? Lwc sez: Depends on quite what you mean ; strictly (for E.164 numbers), no. In practice, yes (i.e. when using a similar presentation syntax). > > If the destination is >> specified using a tel: URI with a phone-context, then either the >> provider can fulfill the request as specified, or it can't. As customers >> don't like wrong numbers, I guess that the service provider will have to >> be careful about choosing to originate the PSTN segment of the call >> outside the requested context. >> >> Thus works if originated within >> the NANP region. So does . > >But +1-800-555-1234 works perfectly well from the +44 region. At least with >some telcos. LwC jests: No it doesn't - (it has a triple 5 in it :). But seriously, folks, here's the rub... it MAY work from the U.K. - this syntax states that it DOES work from within the NANP region. You SHOULDN'T use this out of area, as it isn't guaranteed to work as expected. If you go ahead and do it anyway, and it DOES work, great. But don't blame the tel: URL's author if it doesn't. Hence the MUST NOT in 2806. > > Also, works if originated in >> Austria, as does > >Since both of these numbers lie within E.164 space, only the second form >ought to be used. LwC contends: I beg to differ; I think that the first ("18005551234") is not a fully qualified E.164 number. The second "+431805551234" is. The plus indicates a NAI value of 4. >[Question: does the first form include national numbering plan digits ? In >other words, do I write or > for +44-20-8371-1138 ?] LwC suggests: Access digits? No, yes, or maybe. I think that this is a flaw in 2806, as it is silent on this topic. There are examples that include them (in the section on post dial strings) but that is probably the exception rather than the norm. Personally, I'd check in case the author is being dumb, and if so throw away the extraneous access digits. (I find a cricket bat around the head teaches them not to do it again :) >I see three separate situations: > >[1] An E.164 number can only be reached from certain areas. This might be >because some originating telcos won't route it (+44 8XX was a notorious >example because many telcos tried to route it as +44 18XX) or because the >recipient is rejecting "out-of-area" calls. I don't see "phone-context" >as being the right way to say this; it's no different from any other >situation where a call might fail, and the person writing the URI might not >understand the rules (see the +1-800 example above). LwC puzzles: Please clarify. The person writing the URI is either the person who is paying the TSP for the free-phone service (in which case I forgive them being bemused having looked at the huge contract) or their agent. In either case, they should know if they're paying for International free-phone service - they will notice! >Also, how do I write "not" in a phone-context ? Consider the Demon "Purple >ROMP", which is: > > > LwC ranks: You don't; nor do you need to do this. You have two NAPTRs in pref. order and then put the one that constructs the highest. It will be invalid for people outside Blighty, so they'll pick up the second one. (Indeed, you could do likewise for people in the Netherlands, ...) >[2] An E.164 number reaches different destinations depending on how the call >is routed to the number (this applied to my own home number for most of the >last two months, due to a number porting cock-up). LwC sympathises: My Sympathies (With ENUM, you can perform this particular cock-up yourself, so saving Operator staff valuable time :) >If deliberate (e.g. to >give multiple call centres a common number but have calls routed to the >nearest one), should this fact be published in a tel: URI ? > >With this case, how do I write URIs for the call centres ? I want something >like: > > Centre 1 > Centre 2 > Centre 3 > >except that I will have perhaps 100 or 200 possible contexts per number. LwC admits: Hmm....The none-of-the-above is (as you guess) a lower priority NAPTR. The others are (as you also guess) a challenge. The "or" is already in 2806 - just add more parameters, however this can lead to excessive length URIs. I'm not completely convinced that this is the way to do things, but with the old (Area Codes -> Modem pool number) list Demon used to have, I can see that it would be have been very useful. If you have 100 areas for a single telephone number then this is always going to be a problem. I wonder if reserving numbers in each of the calling areas and then CNAMEing them to a common number is the way to go. Not convinced on that, but if anyone else has any neat ideas, please holler. >[3] Numbers not in the E.164 system. As you say: > >> One neat use is for network-specific service numbers; thus Scott >> Petrack's example from PINT is . >> "It so happens that +97252 defines one of the Israeli cell phone >> providers, and 123 reaches customer service when dialed within that >> network". > >However, number portability rather breaks this: my mobile is in the >numbering block +447973, allocated to one mobile provider, but it has been >ported to a second one. 123 worked on the first provider but doesn't work >on the second, though 121 now does the same job. LwC agrees: Very good point - I suspect that we've have to re-specify using a modified TSP parameter to get the right effect (e.g. for your example we'd write something like ). > > I think that you have 3 contexts. >> * The caller's allocated number context > >Not sure what you mean by that one. LwC sez: If it's a PC and has been allocated a number by Oftel (or BT, or whoever) then this is the area code - some gateways may let the PC use local numbers but of course they need to know the area code in which it treats itself as being located. > >> * The presented number context (e.g. the area code to be added to the >> local number in order to construct a full E.164 number, akin to the >> implied context with an Q.763 CalledPartyAddress with NAI of 1 or 3) > >If the number is in E.164, then there's little or no point in this. If it >isn't, then you need: LwC enquires: I understand your point - we should all use E.164 when publishing our phone numbers - however, until they all die out, there is a sizeable chunk of the population who don't understand this and will feel more comfortable with local numbers - I haven't checked, but as you're in the smoke I would be interested in the format of the numbers on cards adorning the phone boxes. > > * The PSTN call origination point context (i.e. the service area in >> which the called number is specified as being valid, and so where the >> PSTN segment of the call should be originated) LwC expands: This differs from the previous in that the call origination point is at some gateway, somewhere connected to the PSTN. If the called number can converted into canonical E.164 format, AND is not restricted in service area, then this does not matter (unless you pay the bill). If there IS a restricted service area, then it DOES matter - the gateway provider may have to select a gateway interconnected in this service area. Thanks for the interesting comments - I will ponder the ROMP/Call Centre one further. Another reason, perhaps, to update 2806? All the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 16:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28168 for ; Fri, 1 Mar 2002 16:11:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29205 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 16:11:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28696; Fri, 1 Mar 2002 16:02:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28665 for ; Fri, 1 Mar 2002 16:02:07 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27361 for ; Fri, 1 Mar 2002 16:02:05 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g21L1b801692 for ; Fri, 1 Mar 2002 16:01:37 -0500 Message-Id: <5.1.0.14.2.20020301155933.022e0e30@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 16:04:19 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I've seen no comments on the proposed agenda... Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org "silence is consent" ? Generally ok? I would like to wrap this up and post it next week. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Mar 1 19:26:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07864 for ; Fri, 1 Mar 2002 19:26:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10609 for enum-archive@odin.ietf.org; Fri, 1 Mar 2002 19:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10028; Fri, 1 Mar 2002 19:14:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09998 for ; Fri, 1 Mar 2002 19:14:12 -0500 (EST) Received: from hotmail.com ([218.51.69.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07523 for ; Fri, 1 Mar 2002 19:14:08 -0500 (EST) Message-Id: <200203020014.TAA07523@ietf.org> Reply-To: protsf@hotmail.com From: HomeBay To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 2 Mar 2002 09:11:15 +0900 Subject: [Enum] [±¤ °í] ¹«·á ȨÆäÀÌÁö Á¦ÀÛÁß°³ Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Ȩº£ÀÌ È«º¸¸á

 

 

 

 



+ Ŭ¸¯ÇÏ½Ã¸é ¹Ù·Î ÀúÈñ ÀÚ·á¿¡¼­ ±ÍÇÏÀÇ À̸ÞÀÏ ÁÖ¼Ò°¡ »èÁ¦µË´Ï´Ù   ¢Ñ ¼ö½Å°ÅºÎ
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Mar 2 07:42:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29574 for ; Sat, 2 Mar 2002 07:42:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15493 for enum-archive@odin.ietf.org; Sat, 2 Mar 2002 07:42:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15206; Sat, 2 Mar 2002 07:32:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15173 for ; Sat, 2 Mar 2002 07:32:18 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29360 for ; Sat, 2 Mar 2002 07:32:15 -0500 (EST) Received: from [0.0.0.0] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA27251; Sat, 2 Mar 2002 13:31:40 +0100 (MET) Date: Fri, 01 Mar 2002 18:54:30 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Brandner Rudolf cc: enum@ietf.org Subject: Re: AW: [Enum] Common Issues with ENUM and enumservices Message-ID: <30812900.1015008870@localhost> In-Reply-To: References: <29660208.1014913902@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-01 11.20 +0000 Lawrence Conroy wrote: >> What impacts? Can you give an example? > > We gave an example in the 'tel' doc. If you match on the full AUS then > this probably won't match against a query that has "arrived" via a CNAME. > > This allows some NAPTRs to match only if the number is queried directly. > > That is a restriction (or "Beware!") on the use of RegExps, I think. > I think that there may even be occasions where it's not a good idea > even to match against the '+'. Ok, now I understand. If you have a NAPTR for owner A, and a CNAME for B which points to A, then "of course" the regexp must be such that it matches whatever the input will be. In this case something which matches both the number which lead to A and the number which lead to B. Are we on the same page now? A regexp which works might then be !(.*)!tel:\1! This is one of the examples why I really like having the ability of having regexps in NAPTR. Of course, it is a loaded gun you can shoot yourself in the foot with, but... >> I _think_ you with "zone" mean same "owner", i.e. same domain name? > > Now I'm mightily confused. Please clarify what is an owner. > Can one have more than one "owner" within the same leaf zone, > and how can the requestor tell? Are you talking about views here? A zone contain all records in a domain except domains which are delegated somewhere. A zone always start with an SOA record. Owner is the "name" to the left in a traditionally formatted domain name, and all owners in the same zone end with the name of the zone. So, in the zone example.com, you can have records: a.example.com. IN A ... b.example.com. IN NAPTR ... In this case, a.example.com and b.example.com are "owners". >> Hmmm....there are nice books about how DNS works ;-) > > Where? - DNS&BIND is not exactly up-to-date :( Edition 4 of DNS & BIND by Cricket Liu at O'Reilley is up to date... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Mar 2 09:03:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00282 for ; Sat, 2 Mar 2002 09:03:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18013 for enum-archive@odin.ietf.org; Sat, 2 Mar 2002 09:03:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17415; Sat, 2 Mar 2002 08:53:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17384 for ; Sat, 2 Mar 2002 08:53:28 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00165 for ; Sat, 2 Mar 2002 08:53:26 -0500 (EST) Received: from [0.0.0.0] (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA02555; Sat, 2 Mar 2002 14:52:47 +0100 (MET) Date: Sat, 02 Mar 2002 08:10:53 -0500 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , Lawrence Conroy cc: enum@ietf.org Subject: Re: [Enum] Privacy Considerations in Service Registrations ? Message-ID: <31097497.1015056653@localhost> In-Reply-To: <5.1.0.14.2.20020301110546.04440e98@popd.ix.netcom.com> References: <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> <5.1.0.14.2.20020228151056.022bd518@popd.ix.netcom.com> <5.1.0.14.2.20020301110546.04440e98@popd.ix.netcom.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-01 11.22 -0500 Richard Shockey wrote: > Should we expand that list to include "Privacy Considerations" ? or > perhaps in the beginning a clear well defined "Applicability Statement" > or in other words 'Why we want to register this paramater' Sure. No problem at all with that. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Mar 2 22:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09891 for ; Sat, 2 Mar 2002 22:45:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA16089 for enum-archive@odin.ietf.org; Sat, 2 Mar 2002 22:45:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15747; Sat, 2 Mar 2002 22:34:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15674 for ; Sat, 2 Mar 2002 22:34:33 -0500 (EST) Received: from t-my5zkussirfi5 ([211.152.107.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09760 for ; Sat, 2 Mar 2002 22:34:28 -0500 (EST) Message-Id: <200203030334.WAA09760@ietf.org> From: "T&F information" To: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Date: Sun, 3 Mar 2002 11:33:30 Subject: [Enum] T&F information Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A professional company providing credit & status report of Chinese company. Dear Sirs, T&F is a senior investigative corporation providing credit & status report of Chinese companies for global clients. If you are in need of data from China, we are available to provide that information on consignment. We are an established authority in the field of research and information gathering in China. At the same time, we can also consign investigative missions to you when we need data from your country. In this manner we would hope to achieve a mutually beneficial arrangement exchanging needed information on a regular basis. Our services include: 1/ Credit and status investigations, including: Registration; corporate history; corporate structure; background of legal person and executives; financial profiles; banking relationships; operating situation; staff; products; facilities; profiles of affiliates; and more. 2/ professional market research, including: Advertising effectiveness; new product market research; and more. 3/ Investment services: Investment feasibility analyses; business partners' credit and status reports; agenting for foreign companies; comprehensive inquiry services; and more. 4/ Information protection: Inquiries on trademark and patent registration in China; knowledge property protection; trademark investigation in cases of trademark imitation; more. 5/ Information collection: Information about enterprises within China; information collection on policies, laws, current and historical business trends; and open profiles of various enterprises. 6/ Legal consultation: All-around legal consultation services for both enterprises and individuals. 7/ Criminal record searches. T&F has built a large number of stable cooperative relationships with many governmental departments in China. For example, we have made successful arrangements with the Industry & Trade Administrative Bureau of China, China Statistics Bureau, China National Economic Information Center, etc. The large investigative network of T&F is made up of many economic specialists and professional investigators. We are interested in any opportunity of information exchanging. If our investigative abillities might be of assistance,please contact us. Awaiting your reply. Address: Room 210, Building 2, Chegongzhuang Street No.6; Xicheng District, Beijing; China. Post Code: 100044 Tel: +86-10-68003112 Fax: +86-10-68001452 Http://www.tangfeng.org Business E-mail: office@tangfeng.org We are apologize to the inconvenience arisen from this letter to you. Your name will be removed from our database upon request. ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 3 05:53:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21191 for ; Sun, 3 Mar 2002 05:53:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09697 for enum-archive@odin.ietf.org; Sun, 3 Mar 2002 05:53:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09549; Sun, 3 Mar 2002 05:45:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09518 for ; Sun, 3 Mar 2002 05:45:07 -0500 (EST) Received: from fsdafd ([211.229.230.234]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21117 for ; Sun, 3 Mar 2002 05:45:02 -0500 (EST) Message-Id: <200203031045.FAA21117@ietf.org> Reply-To: manajapan@hanmir.com From: Ãßõ¿Õ To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 3 Mar 2002 19:45:58 +0900 Subject: [Enum] [¼º.ÀÎ.±¤.°í] ½ºÆ®·¹½ºÇؼҿ¡ ¿ÍµûÀÔ´Ï´Ù.~~ Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ÀÌ ¸ÞÀÏÀº Á¤º¸Åë½ÅÀ±¸®À§¿øȸ ¹ßÇ¥(2002.1.17)»çÇ׿¡ ÀÇ°Å, Á¦¸ñ¿¡ [¼ºÀα¤°í]¶ó Ç¥½ÃµÈ ¼ºÀα¤°í ¸ÞÀÏÀÔ´Ï´Ù. º»¸ÞÀÏÀº ¹ß½ÅÀü¿ëÀÔ´Ï´Ù.
¹ß½ÅÀÚ¿¬¶ôó´Â : japanmana@hanmir.com ÀÔ´Ï´Ù.
¹ß½ÅÀÚ ¿¬¶ôó·Î ¿À´Â ¼ö½Å°ÅºÎ ¸ÞÀÏÀº ¹Ìó¸® µÉ¼öµµ ÀÖ»ç¿À´Ï
¸Ç¾Æ·¡ ¼ö½Å°ÅºÎ¸¦ ÀÌ¿ëÇØ ÁÖ½Ã¸é °¨»çÇÏ°Ú½À´Ï´Ù.
º»¸ÞÀÏÀº ´Ü Çѹø¸¸ º¸³»Áö¸ç ¼ö½Å°ÅºÎ½Ã¿¡ Àý´ë·Î ¼ºÀα¤°í¸ÞÀÏÀ» ´Ù½Ã º¸³»Áö ¾Ê°Ú½À´Ï´Ù.
±ÍÇÏÀÇ Email Á¤º¸´Â ÀÎÅͳݿ¡¼­ ¼öÁýÇÏ¿´½À´Ï´Ù.
 ¼ö½Å °ÅºÎ¸¦ ¿øÇÏ½Ç °æ¿ì ¹è³Ê ¸Ç ¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ¸¦ ²À Ŭ¸¯ÇØ ÁÖ¼¼¿ä~

2002³â »õÇØ°¡ ¹à¾Ò½À´Ï´Ù. ¿ÃÇØ´Â ¿ùµåÄÅÀ̶ó´Â Å« Çà»ç°¡ ÀÖ´Â ÇØÀÔ´Ï´Ù.
Ã౸¸¦ ÁÁ¾ÆÇÏ´Â »ç¶÷À¸·Î½á ¿ùµåÄÅ¿¡¼­ ÁÁÀº °á°ú°¡ ÀÖ¾úÀ¸¸é ÇÏ´Â °³ÀÎÀûÀÎ ¹Ù¶÷ÀÌ°í¿ä~
¿Ã ÇÑÇØ´Â ¿ì¸®³ª¶ó ±¹¹Îµé ¸ðµÎ~ ¸ðµÎ~ ¿ô´Â Àϸ¸ »ý°åÀ½ ÇÕ´Ï´Ù.
¿øÄ¡¾Ê´Â ¸ÞÀÏÀ̾ú´ã Á˼ÛÇÏ°í¿ä~
¼ºÀθ¸È­½ÎÀÌÅõ·Î´Â ²Û³»ÁÝ´Ï´Ù.  ¿äÁò ÇÑÂü Àαâ ÀýÁ¤..½ÎÀÌÅõ ¶ø´Ï´Ù.~~
 


 

 




 

¼ö½Å°ÅºÎ ½Åû

 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 4 10:58:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29628 for ; Mon, 4 Mar 2002 10:58:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06893 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 10:58:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06426; Mon, 4 Mar 2002 10:48:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06397 for ; Mon, 4 Mar 2002 10:48:09 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29241 for ; Mon, 4 Mar 2002 10:48:01 -0500 (EST) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063242; Mon, 04 Mar 2002 15:47:55 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 (Unverified) Message-Id: In-Reply-To: <5.1.0.14.2.20020301155933.022e0e30@popd.ix.netcom.com> References: <5.1.0.14.2.20020301155933.022e0e30@popd.ix.netcom.com> Date: Mon, 4 Mar 2002 15:47:51 +0000 To: Richard Shockey From: Lawrence Conroy Subject: Re: [Enum] I've seen no comments on the proposed agenda... Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Friday last Rich said: >"silence is consent" ? > >Generally ok? I would like to wrap this up and post it next week. > To which I reply: Fine by me, but... Ordering or preference is interesting; I wonder if the Service tags (Ranelli) presentation should come first, followed by the SRS one, followed by the SIP one, followed by Rudi's TEL one. Also, I *do* wonder about the "context" of the document set, as mentioned on the list. I still have a feeling that there's a missing document (not a one liner with .foo in it, IMHO :). As such, after the service field presentations, I kinda wonder if there could be a couple of minute "wrap up" that is a place holder for common features for ENUM services. Seems to me that RegExp restrictions//gotchas, and "Privacy Concerns" (as mentioned Rich's earlier post) are going to be common to SRS, SIP, TEL, and anything using DNS. On the RegExp stuff, as a Johnny Foreigner, it seems to me that if we give people guns we should at least tell them that, under certain circumstances, they may not do what one expects. (Of course, this is not intended as any sort of limitation on folks' rights to use them in any way they see fit, free of interference... :) all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 11:36:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01392 for ; Mon, 4 Mar 2002 11:36:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09876 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 11:36:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08565; Mon, 4 Mar 2002 11:26:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08528 for ; Mon, 4 Mar 2002 11:26:12 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00696 for ; Mon, 4 Mar 2002 11:26:08 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24GOeL09781 for ; Mon, 4 Mar 2002 11:24:40 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24GOeh09774 for ; Mon, 4 Mar 2002 11:24:40 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] I've seen no comments on the proposed agenda... X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 4 Mar 2002 09:26:43 -0700 Message-ID: Thread-Topic: [Enum] I've seen no comments on the proposed agenda... Thread-Index: AcHDlcx44XjKXBaeRd+lJ8XRzhxaKwAArUEA From: "Zmolek, Andrew (Andrew)" To: "Lawrence Conroy" , "Richard Shockey" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08529 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > I wonder if the Service tags (Ranelli) presentation should come > first, followed by the SRS one, followed by the SIP one, followed > by Rudi's TEL one. I agree with Lawrence that the SIP presentation probably makes more sense after the SRS one than before. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 12:13:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04089 for ; Mon, 4 Mar 2002 12:13:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14976 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 12:13:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13470; Mon, 4 Mar 2002 12:03:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13435 for ; Mon, 4 Mar 2002 12:02:56 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03179 for ; Mon, 4 Mar 2002 12:02:52 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA27079; Mon, 4 Mar 2002 12:02:14 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GGQ3FJL4; Mon, 4 Mar 2002 12:02:14 -0500 Message-Id: <5.1.0.14.2.20020304115824.0324ded8@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 12:02:10 -0500 To: "Zmolek, Andrew (Andrew)" , "Lawrence Conroy" , "Richard Shockey" From: Tony Rutkowski Subject: RE: [Enum] I've seen no comments on the proposed agenda... Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:26 AM 3/4/2002, Zmolek, Andrew (Andrew) wrote: > > I wonder if the Service tags (Ranelli) presentation should come > > first, followed by the SRS one, followed by the SIP one, followed > > by Rudi's TEL one. > >I agree with Lawrence that the SIP presentation probably makes more >sense after the SRS one than before. Hi Andrew, You might want to consider Framework for ENUM Neutrality http://search.ietf.org/internet-drafts/draft-rutkowski-enum-neutrality-01.txt in the same agenda item as an informative draft. Because the ENUM WG has not met for a while, the draft was not able to be considered. The ensuing months seem actually to have made the draft more relevant. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 12:44:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05561 for ; Mon, 4 Mar 2002 12:44:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17407 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 12:44:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16830; Mon, 4 Mar 2002 12:35:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16798 for ; Mon, 4 Mar 2002 12:35:04 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05083 for ; Mon, 4 Mar 2002 12:34:58 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA02591; Mon, 4 Mar 2002 18:34:21 +0100 (MET) Date: Mon, 04 Mar 2002 18:32:57 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , Richard Shockey cc: enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Message-ID: <5485182.1015266777@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-04 09.26 -0700 "Zmolek, Andrew (Andrew)" wrote: > I agree with Lawrence that the SIP presentation probably makes more > sense after the SRS one than before. As co-chair, I don't want _presentations_, but use the time for resolution of issues which have been discussed on this mailing list before the meeting. After the meeting, the proposed resolution(s) are sent to the mailing list so people which will not come to Minneapolis can come with input. I know it is a detail in what word to use, but... So, all of you (including myself) which have documents which have been discussed, please send a list of issues you feel have been brought up on this list no later than 1 week before the WG meeting so we know what we will discuss. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 13:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09533 for ; Mon, 4 Mar 2002 13:36:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21389 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 13:36:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19980; Mon, 4 Mar 2002 13:27:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19933 for ; Mon, 4 Mar 2002 13:27:16 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07954 for ; Mon, 4 Mar 2002 13:27:12 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IPlr18452 for ; Mon, 4 Mar 2002 13:25:47 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IPkY18442 for ; Mon, 4 Mar 2002 13:25:46 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 4 Mar 2002 11:27:50 -0700 Message-ID: Thread-Topic: [Enum] Fwd: I-D ACTION:draft-zmolek-enum-pointer-00.txt Thread-Index: AcHBIHGTG65zTifgTOeeMaIszRizYgCeweaA From: "Zmolek, Andrew (Andrew)" To: "Lawrence Conroy" , "Brandner Rudolf" , "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA19934 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit More follow-up comments in line... >> ENUM-registered endpoints are those in the termination path for an >> E.164 number whose service capabilities are properly exposed in >> service field tags in NAPTR records. Since the PSTN today wouldn't >> prevent other endpoints in that termination path with capabilities >> not listed, or substitutions of a "non-registered" endpoint (such as >> in the call forward case), there is always some potential for >> mismatch between the termination path for an E.164 number and the list >> of services registered. I had perhaps oversimplified things a bit by >> referring to the endpoints as registered rather than their services. > > To which LwC sez: > You mean ENUM/DNS registrants, I think. Right, but what other registrations would there be? SIP? > Re. the comment on end points - I assume that you mean the combination > of the (enumservice and its associated URI) within a NAPTR, yes? That's correct. > Also - Dead right, there is a potential for mismatch - that's one > of the reasons why I'm hostile to E2VIDEO.G.263 and its ilk. It's > an admin "challenge". That challenge is still there, but the point is that it belongs in an SRS because ENUM/DNS isn't engineered for this kind of dynamic. >> With respect to exposure to hacks via service profiling, the SRS >> only solves this problem if the end user chooses a sufficiently >> narrow filter that gives little or no information to an unidentified >> requestor. But it does give the ENUM registrant a great deal more >> control, particularly with respect to allowing for "blacklisting" >> of known malicious requestors or request patterns, which ENUM is not >> prepared to do otherwise. > > To which LwC sez: > ENUM isn't really prepared to do this at all. > What you're suggesting is what happens AFTER we drop out of ENUM. Exactly. This is a strong counter argument against the use of ENUM for detailed service capabilities as it implies that the service it points to is too weak to negotiate on its own or apply sophisticated access control, etc. > These are all possible using a suitable authenticated (and maybe > encrypted) exchange - however, this subsequent exchange is going to > take time. I'm not sure that this is always going to be acceptable > when fired out from the core network, in the middle of call setup > (as per 3GPP). Post-dial delay is going to get long. This is an excellent point. To avoid the latency gotchas around real-time authentication, some services may rely on pre-established relationships (could be among administrative realms, for instance). But it's clear that this is a difficult problem and one that has to be solved or we will have only created the world's most effective tool for reliable spam propagation. >> My hope is to find enough interest to get a standalone presence >> service and protocol defined that isn't tied to any one message >> or media signaling protocol. The main design constraints would be a >> clean query structure, a lean protocol, and tight integration with >> an identity system that would be usable for real time communications >> and transactions. > > To which LwC groans: > Whoa! Having endured the extended joy of IMPP, I (and I suspect Patrik) > may be a tad unhappy at the thought or reliving that experience. Can't say I blame you :-) On the other hand, it would take more than a few awkward extensions to make another protocol general enough to act as a pure presence service. Do you know of any system that will operate between any valid "address" (including E.164 voice, fax, pager numbers, URLs for tel, sip, h323, mailto, http, etc) and any valid service endpoint (black phone, PBX phone, PDA, blackberry, IM, softphone, fax, fax to email, IVR system, messaging system, web system, etc). SIP-based presence comes close, but it forces at least one endpoint to speak SIP, which is fine over the long run I suppose, but leaves out 99.99% of the world's current communication devices. Even if SIP is wildly successful, these older devices and systems aren't going away overnight. >> While many proprietary systems exist today, I won't attempt to >> suggest an alternative to SIP/SIMPLE at the moment. Actually, my hope >> is to craft a better general-purpose presence system from scratch. >> Alternatively, adding some extensions to SIP presence might also work >> (though there may be some obstacles of religion in that approach, as >> it seems unlikely to me that I will ever see an h.323 URI exposed via >> SIP presence, for instance). > > To which LwC blinks and moves on: > Again, I worry greatly about the "from scratch". Not group 3 again, or > is this the first stirrings of group 4, of just forbidden planet, or > ...? Fair enough. Especially if making something "from scratch" leads to another IMPP-like exercise. Still, I would think that an approach based on HTTP/SOAP queries and responses could be completed rapidly enough and would have a jump on other protocols that have more complex deployment issues with firewalls (or, to be fair, the whims and prejudices of administrators and associated policies). > I agree with Rudi - until we know what this system is intended to be, > it's hard to do anything but trade assumptions. I'm being dumb here, > but I would be most interested your ideas on what exactly is missing > from SIMPLE or SIP for which you need extensions to cover? To summarize from my discussion above, this is what's missing: - Support for non-SIP URIs besides tel: (i.e. h323) - No need for device to support other non-presence signaling (i.e. the rest of SIP) to use service without gatewaying - Pure any-address to any-device abstraction (i.e. media and signaling agnostic) - Idiot-proof firewall traversal story (SIP's isn't bad, but still forces "admin education") > Also, you use the reserved term "presence", and I'm not quite sure that > this is quite correct here - in SIP terms the AoR is static and is > returned via an ENUM query. The current contact address may be updated > depending on the connectivity of a destination client's equipments but > that is a hidden back-end process. I guess that this back-end process > could be classified as "presence", if you look at it cross-eyed enough > (Maybe after snowbarding into a tree ?). > However, from ENUM, it's a static value; plain vanilla SIP is acting > as the SRS. The notion of a presence and availability system is a back-end process but a separable one. Until recently, however, it has almost always been paired with a specific messaging or communications protocol. From the ENUM perspective, it's just another static service, yes. But it also reduces or eliminates from ENUM the burdens of privacy and service negotiation. SIP is an example of such an SRS, but it's not fully general. It is sometimes helpful to separate presence and availability as well. Think of the "presence" side as a data-collection service that knows all it can about the identity it services. It gathers data , analysis, and intelligence from all available sources. But it doesn't give that information out. That falls to the "availability" system which gets a query, places it in context (authentication, caller ID, domain, path, etc) and maps the presence data from the "presence" side against rules to determine what to do, how much to expose, whether to lie or fuzz the data, etc. > Re. h232: and SIP or SIMPLE, I don't see why not. The new, expanded, > Typhon may well be interested. I'm not opposed to this, but I would hope that a general solution doesn't force presence clients to support full SIP functionality if they only use SUBSCRIBE/NOTIFY/... to access presence. This is especially true for gatewaying services, but it's not a showstopper. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 13:42:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09830 for ; Mon, 4 Mar 2002 13:42:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21931 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 13:42:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20979; Mon, 4 Mar 2002 13:34:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20939 for ; Mon, 4 Mar 2002 13:34:04 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08892 for ; Mon, 4 Mar 2002 13:34:00 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IWZr24867 for ; Mon, 4 Mar 2002 13:32:35 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IWYY24855 for ; Mon, 4 Mar 2002 13:32:34 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] I've seen no comments on the proposed agenda... X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 4 Mar 2002 11:34:38 -0700 Message-ID: Thread-Topic: [Enum] I've seen no comments on the proposed agenda... Thread-Index: AcHDnm6HX//LtcsSTjGb1AeF3VGpMQAC+LMg From: "Zmolek, Andrew (Andrew)" To: "Tony Rutkowski" , "Lawrence Conroy" , "Richard Shockey" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA20942 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi Tony, Your draft raises some important points, but I'm not sure what specifically you're asking me to consider with respect to the SRS discussion. Or did you mean to direct your concern to the chairs so that time could be set aside to discuss it? --Andy -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@verisign.com] Sent: Monday, March 04, 2002 10:02 AM To: Zmolek, Andrew (Andrew); Lawrence Conroy; Richard Shockey Cc: enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... At 11:26 AM 3/4/2002, Zmolek, Andrew (Andrew) wrote: > > I wonder if the Service tags (Ranelli) presentation should come > > first, followed by the SRS one, followed by the SIP one, followed > > by Rudi's TEL one. > >I agree with Lawrence that the SIP presentation probably makes more >sense after the SRS one than before. Hi Andrew, You might want to consider Framework for ENUM Neutrality http://search.ietf.org/internet-drafts/draft-rutkowski-enum-neutrality-0 1.txt in the same agenda item as an informative draft. Because the ENUM WG has not met for a while, the draft was not able to be considered. The ensuing months seem actually to have made the draft more relevant. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 13:43:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09850 for ; Mon, 4 Mar 2002 13:43:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21945 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 13:43:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20878; Mon, 4 Mar 2002 13:33:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20847 for ; Mon, 4 Mar 2002 13:33:30 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08572 for ; Mon, 4 Mar 2002 13:33:26 -0500 (EST) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA15069; Mon, 4 Mar 2002 10:33:14 -0800 Message-Id: <5.1.0.14.2.20020304103015.01f8ddf8@127.0.0.1> X-Sender: dhc@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 10:33:01 -0800 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Dave Crocker Subject: RE: [Enum] I've seen no comments on the proposed agenda... Cc: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , Richard Shockey , enum@ietf.org In-Reply-To: <5485182.1015266777@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA20848 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 06:32 PM 3/4/2002 +0100, Patrik Fältström wrote: >As co-chair, I don't want _presentations_, but use the time for resolution >of issues which have been discussed on this mailing list before the >meeting... > >I know it is a detail in what word to use, but... > >So, all of you (including myself) which have documents which have been >discussed, please send a list of issues Patrik is making such a good suggestion -- requirement, really -- let me suggest that folks specify exactly what decisions need to be made and what alternatives are available for the decisions. That way, we will know what to debate, and the presenters will know what they need to say that is relevant to making decisions, rather than feeling that they must provide more general introductions. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; (new)fax +1.408.850.1850 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 13:57:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11424 for ; Mon, 4 Mar 2002 13:57:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22987 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 13:57:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22352; Mon, 4 Mar 2002 13:48:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22322 for ; Mon, 4 Mar 2002 13:48:51 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10627 for ; Mon, 4 Mar 2002 13:48:47 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IlMr09033 for ; Mon, 4 Mar 2002 13:47:22 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g24IlMY09023 for ; Mon, 4 Mar 2002 13:47:22 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] I've seen no comments on the proposed agenda... X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 4 Mar 2002 11:49:25 -0700 Message-ID: Thread-Topic: [Enum] I've seen no comments on the proposed agenda... Thread-Index: AcHDqyRiz3TRunA1Sk+SbS3uLj2ejgAAD/yw From: "Zmolek, Andrew (Andrew)" To: "Dave Crocker" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Lawrence Conroy" , "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22323 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I agree with Dave and Patrik on this. To that end, it would be nice to get some guidance from the list regarding how broadly I treat the SRS discussion. Specifically, much of the relevant list discussion has focused on how "presence" services are exposed in SIP or otherwise. The services themselves are out-of-scope to ENUM. But a narrower discussion on how the use of an SRS can relieve ENUM of many privacy and service capability considerations seems appropriate. On the other hand, there seems to be a great deal of interest in discussing how general-purpose presence is to be realized in conjunction with ENUM. There are a great many decisions and considerations to be made here (and the potential for new working groups to be created). To what degree would the chairs and the participants like to see this wider issue discussed? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Monday, March 04, 2002 11:33 AM To: Patrik Fältström Cc: Zmolek, Andrew (Andrew); Lawrence Conroy; Richard Shockey; enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... At 06:32 PM 3/4/2002 +0100, Patrik Fältström wrote: >As co-chair, I don't want _presentations_, but use the time for resolution >of issues which have been discussed on this mailing list before the >meeting... > >I know it is a detail in what word to use, but... > >So, all of you (including myself) which have documents which have been >discussed, please send a list of issues Patrik is making such a good suggestion -- requirement, really -- let me suggest that folks specify exactly what decisions need to be made and what alternatives are available for the decisions. That way, we will know what to debate, and the presenters will know what they need to say that is relevant to making decisions, rather than feeling that they must provide more general introductions. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; (new)fax +1.408.850.1850 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 4 14:13:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13953 for ; Mon, 4 Mar 2002 14:13:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24953 for enum-archive@odin.ietf.org; Mon, 4 Mar 2002 14:13:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24179; Mon, 4 Mar 2002 14:04:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24145 for ; Mon, 4 Mar 2002 14:04:30 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11694 for ; Mon, 4 Mar 2002 14:04:26 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA14122; Mon, 4 Mar 2002 20:03:15 +0100 (MET) Date: Mon, 04 Mar 2002 20:02:29 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , Dave Crocker cc: Lawrence Conroy , Richard Shockey , enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Message-ID: <5807432.1015272149@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-04 11.49 -0700 "Zmolek, Andrew (Andrew)" wrote: > Specifically, much of the relevant list discussion has focused on how > "presence" services are exposed in SIP or otherwise. The services > themselves are out-of-scope to ENUM. But a narrower discussion on how > the use of an SRS can relieve ENUM of many privacy and service > capability considerations seems appropriate. This is easy. Anyone which have specific issues with this draft should point out the _exact_ part of the I-D which they have issues with, and why. If nothing arrives, the draft is possibly ok. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 5 13:03:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12856 for ; Tue, 5 Mar 2002 13:03:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22306 for enum-archive@odin.ietf.org; Tue, 5 Mar 2002 13:03:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20547; Tue, 5 Mar 2002 12:53:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20385 for ; Tue, 5 Mar 2002 12:53:33 -0500 (EST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11916 for ; Tue, 5 Mar 2002 12:50:21 -0500 (EST) Received: from pool0235.cvx16-bradley.dialup.earthlink.net ([209.179.50.235] helo=dick.ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 16iJ4i-0002Yb-00; Tue, 05 Mar 2002 12:50:09 -0500 Message-Id: <5.1.0.14.2.20020305123129.02286450@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 12:42:59 -0500 To: Dave Crocker , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Richard Shockey Subject: RE: [Enum] I've seen no comments on the proposed agenda... Cc: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , enum@ietf.org In-Reply-To: <5.1.0.14.2.20020304103015.01f8ddf8@127.0.0.1> References: <5485182.1015266777@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA20396 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 10:33 AM 3/4/2002 -0800, Dave Crocker wrote: >At 06:32 PM 3/4/2002 +0100, Patrik Fältström wrote: >>As co-chair, I don't want _presentations_, but use the time for resolution >>of issues which have been discussed on this mailing list before the >>meeting... >> >>I know it is a detail in what word to use, but... >> >>So, all of you (including myself) which have documents which have been >>discussed, please send a list of issues > >Patrik is making such a good suggestion -- requirement, really -- let me >suggest that folks specify exactly what decisions need to be made and what >alternatives are available for the decisions. > >That way, we will know what to debate, and the presenters will know what >they need to say that is relevant to making decisions, rather than feeling >that they must provide more general I certainly concur with this ... the sense I have is that there are general issues with the what service fields are appropriate for ENUM and why and how in specific cases should records be processed ... aka SIP ... What are the requirements for service registration ... what is the justification for such registrations given issues of privacy ..what level of granularity is necessary ... this is the beginniing of a general issues resolution list for the service drafts etc....any additional suggestions. In addition I have not seen much comment and suggestion on 2916 bis beyond technicial corrections... Patrik had a list of issues that he wanted covered ... are we in consensus about these? ################ -Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I have here compiled a list of things to be changed to RFC 2916 when 2916bis is created. (1) It must be made clear that ENUM service is a delegation in the e164.arpa domain (2) It must be explained how ENUM-like mechanisms can be used for for example private dialing plans even though e164.arpa is the tree where ENUM is located (3) The use of NAPTR should instead of being some handwaving be a proper DDDS specification according to the DDDS documents which replaces RFC 2915 (4) A registration mechanism must be created for the first part of the flag field (5) Registrations must be made in separate documents for some basic flags, especially LDAP and TEL which have been asked especially how to handle (6) Privacy issues must be described more clearly in the security consideration section which explains that some privacy issues can be resolved via storage in a secondary storage, like an LDAP database, which uses an access protocol which can handle authentication and other needed security mechanisms (7) Loops must be specified how to detect (i.e. a paragraph should be added which explains the traditional need for convergence) (8) Examples must be corrected and made mode clear. For example, there should be absolutely no confusion about full regular expressions are used. I.e. any delimiter and any matchingh mechanism can be used All of this leads to the need for the following document(s) in this wg: - 2916bis - Registration procedure of ENUM flag fields - Flag field registration for whatever needed for TEL URI scheme - Flag field registration for whatever needed for SIP URI scheme - Flag field registration for whatever needed for MAILTO URI scheme - Flag field registration for whatever needed for LDAP URI scheme I will take care of 2916bis, but as wg co-chair I would appreciate people interested in working on the other documents. I suggest we take these 8 issues (and maybe others) as main agenda items on the IETF meeting in Minneapolis. Further, we add the flag field discussions, if we have takes, to the agenda aswell. paf >introductions. > >d/ > >---------- >Dave Crocker >Brandenburg InternetWorking >tel +1.408.246.8253; (new)fax +1.408.850.1850 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 03:56:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27767 for ; Wed, 6 Mar 2002 03:56:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23571 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 03:56:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23143; Wed, 6 Mar 2002 03:47:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23112 for ; Wed, 6 Mar 2002 03:47:50 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27604 for ; Wed, 6 Mar 2002 03:47:46 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g268kltQ001872; Wed, 6 Mar 2002 09:46:48 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Mar 2002 09:21:19 +0100 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , =?iso-8859-1?Q?Patrik_F?= =?iso-8859-1?Q?=E4ltstr=F6m?= Cc: Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Date: Wed, 6 Mar 2002 09:21:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA23113 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi folks, in addition to the list from Patrik, although it may fit into some of the issues also, I would like to see a discussion on the issue of redirection, and also a discussion on the purpose and usage of the tel URI: 1. What is the proper way to redirect an ENUM domain to another domain, or what is the difference in using CNAME and tel? 2. What is the primary purpose of the tel URI? Is it redirection? Or is it the replacement of IN functionality. (Comment: Maybe this issue should be discussed with the brander draft. I am still working on this, but the issue is very complex) 3. In RFC2916bis in Exaple 2, there is: IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . What does this expample show? How a replacemet "\1" may work, or is it a valid use of a tel URI? In the latter case, I do not understand the example. I query a database and get the information back, if sip does not work, I may use the same phone number I queried. But this I knew already. Especially since most proposals for implementation, e.g. the ITAC-T Report or the ETSI TS, require, that a working E.164 termination is available on the GSTN. There is also the "opt-in" principle for the calling user: I do not need to query ENUM in the first place to reach an E.164 number on the GSTN and if I query, I am not obligated to use the results (ITAC-T report 4.4.) 4. A question concerns the relationship between differnt NAPTR records, especially if I have more than one tel URIs or tel and sip URIs together? How does this work especially with phone-contexts? E.g. see the discussion on freephone numbers: One wants the user to choose (depending on his context) between different records, some of them may be tels and some sips? I think there is some more explanation necessary in RFC2916bis (or DDDS Part3 - RFC2915bis) on the order and preference fields. best regards RichardS Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Tuesday, March 05, 2002 6:43 PM > To: Dave Crocker; Patrik Fältström > Cc: Zmolek, Andrew (Andrew); Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] I've seen no comments on the proposed agenda... > > > At 10:33 AM 3/4/2002 -0800, Dave Crocker wrote: > >At 06:32 PM 3/4/2002 +0100, Patrik Fältström wrote: > >>As co-chair, I don't want _presentations_, but use the time > for resolution > >>of issues which have been discussed on this mailing list before the > >>meeting... > >> > >>I know it is a detail in what word to use, but... > >> > >>So, all of you (including myself) which have documents > which have been > >>discussed, please send a list of issues > > > >Patrik is making such a good suggestion -- requirement, > really -- let me > >suggest that folks specify exactly what decisions need to be > made and what > >alternatives are available for the decisions. > > > >That way, we will know what to debate, and the presenters > will know what > >they need to say that is relevant to making decisions, > rather than feeling > >that they must provide more general > > > I certainly concur with this ... the sense I have is that > there are general > issues with the what service fields are appropriate for ENUM > and why and > how in specific cases should records be processed ... aka SIP ... > > What are the requirements for service registration ... what is the > justification for such registrations given issues of privacy > ..what level > of granularity is necessary ... > > this is the beginniing of a general issues resolution list > for the service > drafts etc....any additional suggestions. > > In addition I have not seen much comment and suggestion on > 2916 bis beyond > technicial corrections... Patrik had a list of issues that he wanted > covered ... are we in consensus about these? > > ################ > > -Mailman-Version: 1.0 > Precedence: bulk > List-Id: Enum Discussion List > X-BeenThere: enum@ietf.org > > I have here compiled a list of things to be changed to RFC 2916 when > 2916bis is created. > > (1) It must be made clear that ENUM service is a delegation in the > e164.arpa domain > > (2) It must be explained how ENUM-like mechanisms can be used for for > example private dialing plans even though e164.arpa is the > tree where ENUM > is located > > (3) The use of NAPTR should instead of being some handwaving > be a proper > DDDS specification according to the DDDS documents which > replaces RFC 2915 > > (4) A registration mechanism must be created for the first > part of the flag > field > > (5) Registrations must be made in separate documents for some > basic flags, > especially LDAP and TEL which have been asked especially how to handle > > (6) Privacy issues must be described more clearly in the security > consideration section which explains that some privacy issues can be > resolved via storage in a secondary storage, like an LDAP > database, which > uses an access protocol which can handle authentication and > other needed > security mechanisms > > (7) Loops must be specified how to detect (i.e. a paragraph > should be added > which explains the traditional need for convergence) > > (8) Examples must be corrected and made mode clear. For example, there > should be absolutely no confusion about full regular > expressions are used. > I.e. any delimiter and any matchingh mechanism can be used > > > > All of this leads to the need for the following document(s) > in this wg: > > - 2916bis > - Registration procedure of ENUM flag fields > - Flag field registration for whatever needed for TEL URI scheme > - Flag field registration for whatever needed for SIP URI scheme > - Flag field registration for whatever needed for MAILTO URI scheme > - Flag field registration for whatever needed for LDAP URI scheme > > I will take care of 2916bis, but as wg co-chair I would > appreciate people > interested in working on the other documents. > > I suggest we take these 8 issues (and maybe others) as main > agenda items on > the IETF meeting in Minneapolis. Further, we add the flag field > discussions, if we have takes, to the agenda aswell. > > paf > > > > > > > >introductions. > > > >d/ > > > >---------- > >Dave Crocker > >Brandenburg InternetWorking > >tel +1.408.246.8253; (new)fax +1.408.850.1850 > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 > 1120 Vermont Ave NW Suite 400 Washington DC 20005 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > 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 daemon@optimus.ietf.org Wed Mar 6 04:42:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28556 for ; Wed, 6 Mar 2002 04:42:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26450 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 04:42:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26034; Wed, 6 Mar 2002 04:33:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25978 for ; Wed, 6 Mar 2002 04:33:24 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28409 for ; Wed, 6 Mar 2002 04:33:19 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA02959; Wed, 6 Mar 2002 10:31:04 +0100 (MET) Date: Wed, 06 Mar 2002 10:30:26 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'Richard Shockey'" cc: Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Message-ID: <10828290.1015410626@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-06 09.21 +0100 "Stastny, Richard" wrote: > 3. In RFC2916bis in Exaple 2, there is: > IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > What does this expample show? How a replacemet "\1" may work, or is it a > valid use of a tel URI? In the latter case, I do not understand the > example. I query a database and get the information back, if sip does not > work, I may use the same phone number I queried. Probably a stupid example... I tried to show that (1) the world is not only SIP and (2) one can use the \1 construction. Do you have a better suggestion? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 05:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29150 for ; Wed, 6 Mar 2002 05:13:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28240 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 05:13:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27820; Wed, 6 Mar 2002 05:03:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27789 for ; Wed, 6 Mar 2002 05:03:22 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28880 for ; Wed, 6 Mar 2002 05:03:17 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g26A3BtR009246; Wed, 6 Mar 2002 11:03:13 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Mar 2002 10:47:12 +0100 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "Stastny, Richard" , "'Richard Shockey'" Cc: Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Date: Wed, 6 Mar 2002 10:47:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA27790 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi Patrik, are you working 24x7? ;-) I think we have two issues here: I agree, that we need an example of a tel usage and there should be at least one example of a replacement. The tel is easy, just use another number (any better ideas, LwC?) The replacement is more challenging. I do not see a sense in using "\1", but I have no idea of another example (if I had one, I would have aready come up with one). Mayby somebody else could come up with one. Guys, there must be a reason, why you use this regexp stuff in the first place? ;-) Sorry, if I could not provide much help. regards Richard Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Wednesday, March 06, 2002 10:30 AM > To: Stastny, Richard; 'Richard Shockey' > Cc: Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] I've seen no comments on the proposed agenda... > > > --On 2002-03-06 09.21 +0100 "Stastny, Richard" > > wrote: > > > 3. In RFC2916bis in Exaple 2, there is: > > IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > > What does this expample show? How a replacemet "\1" may > work, or is it a > > valid use of a tel URI? In the latter case, I do not understand the > > example. I query a database and get the information back, > if sip does not > > work, I may use the same phone number I queried. > > Probably a stupid example... > > I tried to show that (1) the world is not only SIP and (2) > one can use the > \1 construction. > > Do you have a better suggestion? > > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 05:27:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29535 for ; Wed, 6 Mar 2002 05:27:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29166 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 05:27:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28687; Wed, 6 Mar 2002 05:16:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28658 for ; Wed, 6 Mar 2002 05:16:52 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29277 for ; Wed, 6 Mar 2002 05:16:47 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA12342; Wed, 6 Mar 2002 11:12:28 +0100 (MET) Date: Wed, 06 Mar 2002 11:12:10 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "Stastny, Richard" , "'Richard Shockey'" cc: Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] I've seen no comments on the proposed agenda... Message-ID: <10978527.1015413130@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-06 10.47 +0100 "Stastny, Richard" wrote: > I think we have two issues here: I agree, that we need an example of a tel > usage and there should be at least one example of a replacement. If people "just" send examples in my direction which they think are interesting, I will insert them into the document. Also, examples might be good for the agenda when I think about it, so hurry hurry! paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 11:22:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15869 for ; Wed, 6 Mar 2002 11:22:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21179 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 11:22:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20091; Wed, 6 Mar 2002 11:09:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20049 for ; Wed, 6 Mar 2002 11:09:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14985; Wed, 6 Mar 2002 11:09:47 -0500 (EST) Message-Id: <200203061609.LAA14985@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 11:09:47 -0500 Subject: [Enum] I-D ACTION:draft-lind-enum-callflows-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Call Flows for VoIP Interworking Author(s) : S. Lind Filename : draft-lind-enum-callflows-03.txt Pages : 17 Date : 05-Mar-02 This document provides illustrations of the use of ENUM [2] functionality within the larger context of service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. Some details are also provided for calls made using the ITU-defined 'Global Services' [3,4,5]. The impact of number portability within the call scenarios is discussed. The objective of this document is to identify areas where gaps exist in the provision of services and suggest where protocol extensions for ENUM, SIP, TRIP, etc. are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lind-enum-callflows-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lind-enum-callflows-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lind-enum-callflows-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-lind-enum-callflows-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 11:26:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16092 for ; Wed, 6 Mar 2002 11:26:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21478 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 11:26:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20302; Wed, 6 Mar 2002 11:10:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20267 for ; Wed, 6 Mar 2002 11:10:18 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15085; Wed, 6 Mar 2002 11:10:13 -0500 (EST) Message-Id: <200203061610.LAA15085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 11:10:13 -0500 Subject: [Enum] I-D ACTION:draft-foster-e164-gstn-npusa-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Number Portability Administration in the U.S. Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-foster-e164-gstn-npusa-03.txt Pages : 10 Date : 05-Mar-02 This document provides a historical as well as practical overview of the implementation of Number Portability (NP) Administration in the United States (U.S.). There are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. This document describes the NP business model and the architecture for NP administration in the North America. It also briefly discusses the functions performed by the NP administrator and the cost recovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-npusa-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-foster-e164-gstn-npusa-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-foster-e164-gstn-npusa-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-foster-e164-gstn-npusa-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-foster-e164-gstn-npusa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134541.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 6 13:55:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27295 for ; Wed, 6 Mar 2002 13:55:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05522 for enum-archive@odin.ietf.org; Wed, 6 Mar 2002 13:55:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04615; Wed, 6 Mar 2002 13:42:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04548 for ; Wed, 6 Mar 2002 13:42:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26303; Wed, 6 Mar 2002 13:42:42 -0500 (EST) Message-Id: <200203061842.NAA26303@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 13:42:42 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-e164-gstn-np-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-03.txt Pages : 27 Date : 05-Mar-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). There are three types of number portability: service provider number portability (SPNP), location portability, and service portability. Service provider portability, the focus of the present draft, is a regulatory imperative in many countries seeking to liberalize local telephony service competition, by enabling end-users to retain pre- existing telephone numbers while changing service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-e164-gstn-np-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305135415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-e164-gstn-np-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-e164-gstn-np-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305135415.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 7 06:47:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17907 for ; Thu, 7 Mar 2002 06:47:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16568 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 06:47:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16145; Thu, 7 Mar 2002 06:37:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16116 for ; Thu, 7 Mar 2002 06:37:50 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17606 for ; Thu, 7 Mar 2002 06:37:46 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g27BbhtQ024394; Thu, 7 Mar 2002 12:37:44 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 12:15:55 +0100 Message-ID: From: "Stastny, Richard" To: "'sdlind@att.com'" , "'paf@cisco.com'" Cc: enum@ietf.org Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction Date: Thu, 7 Mar 2002 12:15:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Dear Colleagues, In section 5.3 Call from a Terminal on an IP-based Network to a phone on the PSTN of draft-lind-enum-callflows-03.txt, Steve explains: In the example, the SIP Client transforms the dialed number into a FQDN of 4.3.2.1.5.5.5.1.0.3.1.e164.arpa. During the transformation, the country and area codes for the destination are added to the number by the client. Step 3 - The DNS returns any NAPTR service records associated with the FQDN. In the example, the DNS returns at least one record containing the URI tel:+13015551234. If no ENUM record exists for the URL, the call should be attempted for termination on the PSTN using the dialed digits as the target for further steps in the call flow. Considering the discussion with Patrik on the examples in RFC2916bis, that a NAPTR with the same number in the tel: URI does not make much sense, and also, that in Steve example exactly the same action takes place, if DNS returns the URI tel:+13015551234 or if no records exist. I suggest to include something like following statement somewhere in RFC2916: Default Action of the client: If the ENUM query for a given AUS does not return a result (404), the action taken by the client SHALL be the same as if the result would have been: IN NAPTR 10 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . This would solve the opt-in problem of the calling user as mentioned in the previous discussions, and also the problem of Patrik to find a place where to use the \1 replacement example ;-) For Steves example, I would suggest to use either another example, or to use e.g. the following wording: Step 3 - The DNS returns either any NAPTR service records associated with the FQDN, which are evaluted according to RFC2915 and RCF2916. E.g a sip, h323 or tel URI. If no ENUM record exists for the URI, as in this example, the call should be attempted for termination on the PSTN using the dialed digits as the target for further steps in the call flow, as if the URI tel:+13015551234 has been returned. best regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 7 08:00:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21409 for ; Thu, 7 Mar 2002 08:00:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20930 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 08:00:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20203; Thu, 7 Mar 2002 07:49:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20144 for ; Thu, 7 Mar 2002 07:49:46 -0500 (EST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20804 for ; Thu, 7 Mar 2002 07:46:55 -0500 (EST) From: M.Muench@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id NAA02109 for ; Thu, 7 Mar 2002 13:46:21 +0100 (MET) Subject: [ENUM] Comments to To: enum@ietf.org Date: Thu, 7 Mar 2002 13:46:20 +0100 Message-ID: X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 03/07/2002 01:46:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I want to make some comments and corrections to the Internet-Draft "Number Portability in the GSTN: An Overview", draft version 03. My comments concentrate on the sections for Europe. (1) Comment to section 5.2 Europe: In Europe the ETSI standards for Number Portability are the basis for realising NP in the fixed network. Item (c) "ISUP triggerless translation" is not standardised in the ETSI standards (and by the way also not standardised in the ITU-T Recommendation and Supplements) and should not be reflected in this NP overview document. If the "ISUP triggerless translation" is used in european countries then this is a network operator matter. ==> delete item (c) in section 5.2 (2) Comment to section 6.2 Europe: The first two sentences explain one possibility to map the RN and DN to the ISUP IAM. In the fourth paragraph a reference is made to ITU-T Rec. Q.769.1. This should be the corresponding baseline for the mapping of the RN and DN to the ISUP protocol. By the way, in Europe ITU-T Rec. Q.769.1 is slightly modified by ETSI EN 302 097 V.1.2.2 (2000-09). Text proposal for the whole section 6.2: [MM] In a number portability environment, the directory number (DN) is not sufficient to route the call. There is a need to derive a routing number (RN) based on the methods defined in [CS1] and [CS2]. Once the RN has been determined, the routing in the network will be based on this RN. As the RN is always a complete address, sending of additional digits in overlap operation applies only to the directory number (DN) information. The DN is transferred along with the call to identify the called ported subscriber. The enhancements in the ISUP protocol to support number portability are briefly described below. Three methods can be used to transport the Directory Number (DN) and the Routing Number (RN): (a) Two separate parameters with the CdPN parameter containing the RN and a new Called Directory Number (CdDN) parameter containing the DN. A new value for the Nature of Address (NOA) indicator in the CdPN parameter is defined to indicate that the RN is in the CdPN parameter. The switches use the CdPN parameter to route the call as is done today. (b) Two separate parameters with the CdPN parameter containing the DN and a new Network Routing Number (NRN) parameter containing the RN. This method requires that the switches use the NRN parameter to route the call. (c) Concatenated parameter with the CdPN parameter containing the RN plus the DN. A new Nature of Address (NOA) indicator in the CdPN parameter is defined to indicate that the RN is concatenated with the DN in the CdPN parameter. Some countries may not use new NOA value because the routing prefix does not overlap with the dialed directory numbers. But if the routing prefix overlaps with the dialed directory numbers, a new NOA value must be assigned. Spain uses "XXXXXX" as the routing prefix to identify the new serving network and uses a new NOA value of 126. As an example, in some european countries, a routing number is prefixed to the dialed directory number. The ISUP CdPN parameter in the IAM will contain the routing prefix and the dialed directory number. For example, United Kingdom uses routing prefixes with the format of 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks use the information in the ISUP CdPN parameter to route the call to the New/Current Serving Network. The routing prefix can identify the Current Serving Network or the Current Serving Switch of a ported number. For the former case, another query to the "internal" NPDB at the Current Serving Network is required to identify the Current Serving Switch before routing the call to that switch. This shields the Current Serving Switch information for a ported number from the other networks at the expense of an additional NPDB query. Another routing number, may be meaningful within the Current Serving Network, will replace the previously prefixed routing number in the ISUP CdPN parameter. For the latter case, the call is routed to the Current Serving Switch without an additional NPDB query. When the terminating switch receives the IAM and sees its own routing prefix in the CdPN parameter, it retrieves the originally dialed directory number after the routing prefix, and uses the dialed directory number to terminate the call. In addition to the addition of the routing prefix to the CdPN parameter, some other information may be added/modified as is listed in the ITU-T Recommendation Q.769.1 [ISUP] or ETSI EN 302 097 [ETSI ISUP].. There is also a network option to add a new ISUP parameter called Number Portability Forwarding Information parameter. This parameter has a four-bit Number Portability Status Indicator field that can provide an indication whether number portability query is done for the called directory number and whether the called directory number is ported or not if the number portability query is done. Please note that all those NP enhancements for a ported number can only be used in the country that defined them. This is because number portability is supported within a nation or only within a network. Within each nation, the telecommunications industry or the regulatory bodies can decide which method or methods to use. [MM]: The sentence in draft 03 "Number portability related parameters and coding are never passed across the national boundaries." is not correct. The passing of a number portability related parameter is dependent on the agreements at the point of interconnections. Modify the sentence: Number Portability related parameters and coding are passed across national boundaries dependent on the agreements at the interconnection interface. [MM] For example, a UK routing prefix can only be used in UK, and would cause routing problem if it appears outside UK. As indicated earlier, an originating wireless network can query the NPDB and concatenate the RN with DN in the CdPN parameter and route the call directly to the Current Serving Network. If NPDBs do not contain information about the wireless directory numbers, the call, originated from either a wireline or a wireless network, will be routed to the Wireless donor network. Over there, an internal NPDB is queried to retrieve the RN that then is concatenated with the DN in the CdPN parameter. If MNP-SRF is supported, the Gateway Mobile Services Switching Center (GMSC) at the wireless donor network, when receiving a call from the wireline network, can send the GSM MAP Send Routing Information (SRI) message to the MNP-SRF. The MNP-SRF interrogates an internal or integrated NPDB for the RN of the MNP-SRF of the wireless Current Serving Network and prefixes the RN to the dialed wireless directory number in the global title address information in the SCCP Called Party Address (CdPA) parameter. This SRI message will be routed to the MNP-SRF of the wireless Current Serving Network, which then responds with an acknowledgement by providing the RN plus the dialed wireless directory number as the Mobile Station Roaming Number (MSRN). The GMSC of the wireless donor network formulates the ISUP IAM with the RN plus the dialed wireless directory number in the CdPN parameter and routes the call to the wireless Current Serving Network. A GMSC of the wireless Current Serving Network receives the call and sends an SRI message to the associated MNP-SRF where the global title address information of the SCCP CdPA parameter contains only the dialed wireless directory number. The MNP-SRF then replaces the global title address information in the SCCP CdPA parameter with the address information associated with a Home Location Register (HLR) that hosts the dialed wireless directory number and forwards the message to that HLR after verifying that the dialed wireless directory number is a ported-in number. The HLR then returns an acknowledgement by providing an MSRN for the GMSC to route the call to the MSC that currently serves the mobile station that is associated with the dialed wireless directory number. Please see [MNP] for details and additional scenarios. The last paragraph of section 6.2 describes only one possibility to realise MNP. This should be clearly stated at the begin of the explanation. [MM] (3) Comment to Section12. Normative References Replace [ISUP] ITU-T COM 11-R 162-E, Draft Recommendation Q.769.1, "Signaling System No. 7 - ISDN User Part Enhancements for the Support of Number Portability," May 1999. With [ISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - ISDN User Part Enhancements for the Support of Number Portability," December 1999. Replace [MNP] Draft GSM 03.66 V7.2.0 (1999-11) European Standard (Telecommunications series) Digital cellular telecommunications system (Phase 2+); Support of Mobile Number Portability (MNP); Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 Release 1998). With [MNP] ETSI EN 301 716 (2000-10) European Standard (Telecommunications series) Digital cellular telecommunications system (Phase 2+); Support of Mobile Number Portability (MNP); Technical Realisation; Stage 2; (GSM 03.66 Version 7.3.1 Release 1998). And add [ETSI] ETSI EN 302 097 V1.2.2 (2000-09) European Standard (Telecommunications series) Integrated Service Digital Network (ISDN); Signalling System No.7 (SS7); ISDN User Part (ISUP); Enhancement for support of Number Portability (NP); [ITU-T Recommendation Q.769.1 (2000), modified] ####################### Here end the comments and corrections to draft 03. Nevertheless I have a general question. What is the aim of this IETF-Draft??? As far as I can see it, this draft once again describes NP and MNP. But this has already been done within ITU-T Recommendations and Supplements, in ANSI standards and in ETSI standards. It could happen that this draft does not correctly describe some issues of NP and MNP and maybe contradicts to the standards. Why don't we say: "NP and MNP are defined in the following standards: ITU-T Rec. .... ANSI standard .... ETSI standard ...." What additional information is missing in those standards which shall be reflected in the IETF-Draft? Is it really necessary to know all the codings of a RN and the codings of the protocol? One issue, for instance, is not even mentioned in the draft, that is NP and Completion of Calls to Busy Subscriber (CCBS) which requires mechanisms for bearer unrelated signalling messages. How should we proceed? Kind regards, Monika ++++++++++++++++++++++++++ Monika Muench Alcatel SEL AG Lorenzstrasse 10 70435 Stuttgart Germany mail: M.Muench@alcatel.de phone: +49 711 821-41417 fax: +49 711 821-40017 ++++++++++++++++++++++++++ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 7 08:06:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21689 for ; Thu, 7 Mar 2002 08:06:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21553 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 08:06:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20551; Thu, 7 Mar 2002 07:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20522 for ; Thu, 7 Mar 2002 07:57:35 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21247 for ; Thu, 7 Mar 2002 07:57:31 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063523; Thu, 07 Mar 2002 12:57:28 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: References: Date: Thu, 7 Mar 2002 12:57:24 +0000 To: "Stastny, Richard" , sdlind@att.com, paf@cisco.com, jon.peterson@neustar.biz From: Lawrence Conroy Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default action Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:15 pm +0100 7/3/02, Stastny, Richard wrote: >Dear Colleagues, > >In section 5.3 Call from a Terminal on an IP-based Network to a phone on the >PSTN >of draft-lind-enum-callflows-03.txt, Steve explains: > >Considering the discussion with Patrik on the examples in RFC2916bis, that a >NAPTR with the same number in the tel: URI does not make much sense, and >also, that in Steve example exactly the same action takes place, if DNS >returns the URI tel:+13015551234 or if no records exist. I suggest to >include something like following statement somewhere in RFC2916: > >Default Action of the client: > >If the ENUM query for a given AUS does not return a result (404), the action >taken by the client SHALL be the same as if the result would have been: > IN NAPTR 10 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > To which I reply: Hi Richard, folks, I'm still not completely sure about whether one SHOULD NOT have a tel: URI that evaluates to the same E.164 number as the domain, or one SHOULD (so that this "tight loop" can indicate that this is the end of a tel: redirect process). It's certainly one of the open issues with the 'tel' ENUMservice that we intended to raise at MSP. It also ties in with Richard's earlier comment on the use of tel: URI parameters, and the possible evaluation of the contents from a local number, qualified with a phone-context, through to a "full" E.164 number (Which is another open issue with use of tel: URIs, also to be raised in MSP). Speaking of tel: URI parameters, is the intention to cover the CPC draft in ENUM or in SIP//SIPPING or both or...? Best Regards, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 7 09:41:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27068 for ; Thu, 7 Mar 2002 09:41:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27427 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 09:41:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26581; Thu, 7 Mar 2002 09:31:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26529 for ; Thu, 7 Mar 2002 09:31:17 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26424 for ; Thu, 7 Mar 2002 09:31:13 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g27EPMtS010122; Thu, 7 Mar 2002 15:31:14 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 14:59:31 +0100 Message-ID: From: "Stastny, Richard" To: "'M.Muench@alcatel.de'" , enum@ietf.org Subject: RE: [ENUM] Comments to Date: Thu, 7 Mar 2002 14:59:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Thank you Monika for this exhausting (eh, exhaustive) explanation. To your question: > Nevertheless I have a general question. What is the aim of this > IETF-Draft??? > As far as I can see it, this draft once again describes NP and MNP. > But this has already been done within ITU-T Recommendations and > Supplements, in ANSI standards and in ETSI standards. > It could happen that this draft does not correctly describe > some issues of > NP and MNP and maybe contradicts to the standards. > > Why don't we say: > "NP and MNP are defined in the following standards: > ITU-T Rec. .... > ANSI standard .... > ETSI standard ...." > Agreed, but: I like the draft as an overview, as long as the correct references are there, even with a warning, that the draft is not complete (they are informational anyway). Contradictions can be removed, as you have shown. This also holds for the related , which could even be more detailed, but nevertheless was intersting to read (for an European). I think, it saves people time to collect and read all the documents and find out the relevant parts. ITU and ETSI documents are not so easy to read, and the draft may serve as a guide. Of course, if you are seriously working, you should read everything necessary, but we all know, how it is reality ;-) And I think there is another reason I have discovered recently: Some IETF people do not like word documents ;-) > What additional information is missing in those standards > which shall be > reflected in the IETF-Draft? good question, anybody any ideas? > Is it really necessary to know all the codings of a RN and > the codings of > the protocol? If I consider the currently starting discussion to use ENUM potentially for everything, it may be not a so bad idea. Even to prove eventually, that you can't use ENUM for everything! BTW, I would like on the other side ONE document explaining and listing up all attributes and parameters currently used or proposed by SIP, PINT, tel: URIs and whatever-other-drafts in one place, just to be on the save side. > One issue, for instance, is not even mentioned in the draft, > that is NP and > Completion of Calls to Busy Subscriber (CCBS) which requires > mechanisms for > bearer unrelated signalling messages. > > How should we proceed? Lets make a list of the information considered missing and input it to the draft, maybe only as references to the correct standards. best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 7 09:43:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27200 for ; Thu, 7 Mar 2002 09:43:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27524 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 09:43:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26711; Thu, 7 Mar 2002 09:32:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26688 for ; Thu, 7 Mar 2002 09:32:53 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26512 for ; Thu, 7 Mar 2002 09:32:49 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g27EPMtV010122; Thu, 7 Mar 2002 15:32:33 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 15:07:28 +0100 Message-ID: From: "Stastny, Richard" To: "'Lawrence Conroy'" , "Stastny, Richard" , sdlind@att.com, paf@cisco.com, jon.peterson@neustar.biz Cc: enum@ietf.org Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction Date: Thu, 7 Mar 2002 15:07:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence wrote: > I'm still not completely sure about whether one SHOULD NOT > have a tel: URI > that evaluates to the same E.164 number as the domain, or one > SHOULD (so > that this "tight loop" can indicate that this is the end of a > tel: redirect > process) I thought, that the "u" flag can do this? If we agree, that there is a redirect of tel: But I agree, we should discuss this at the IETF meeting. Nevertheless, the default action is still valid. best regards Richard Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Thursday, March 07, 2002 1:57 PM > To: Stastny, Richard; sdlind@att.com; paf@cisco.com; > jon.peterson@neustar.biz > Cc: enum@ietf.org > Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, > RFC2916bis default > action > > > At 12:15 pm +0100 7/3/02, Stastny, Richard wrote: > >Dear Colleagues, > > > >In section 5.3 Call from a Terminal on an IP-based Network > to a phone on the > >PSTN > >of draft-lind-enum-callflows-03.txt, Steve explains: > > > > > > >Considering the discussion with Patrik on the examples in > RFC2916bis, that a > >NAPTR with the same number in the tel: URI does not make > much sense, and > >also, that in Steve example exactly the same action takes > place, if DNS > >returns the URI tel:+13015551234 or if no records exist. I suggest to > >include something like following statement somewhere in RFC2916: > > > >Default Action of the client: > > > >If the ENUM query for a given AUS does not return a result > (404), the action > >taken by the client SHALL be the same as if the result would > have been: > > IN NAPTR 10 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > > > > > To which I reply: > Hi Richard, folks, > > I'm still not completely sure about whether one SHOULD NOT > have a tel: URI > that evaluates to the same E.164 number as the domain, or one > SHOULD (so > that this "tight loop" can indicate that this is the end of a > tel: redirect > process). > It's certainly one of the open issues with the 'tel' > ENUMservice that we > intended to raise at MSP. > It also ties in with Richard's earlier comment on the use of tel: URI > parameters, and the possible evaluation of the contents from > a local number, > qualified with a phone-context, through to a "full" E.164 number > (Which is another open issue with use of tel: URIs, also to > be raised in MSP). > > Speaking of tel: URI parameters, is the intention to cover > the CPC draft in > ENUM or in SIP//SIPPING or both or...? > > Best Regards, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Mar 7 09:57:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28012 for ; Thu, 7 Mar 2002 09:57:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28811 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 09:57:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28008; Thu, 7 Mar 2002 09:48:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27911 for ; Thu, 7 Mar 2002 09:48:21 -0500 (EST) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27407 for ; Thu, 7 Mar 2002 09:48:14 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g27Elj103736 for ; Thu, 7 Mar 2002 08:47:46 -0600 (CST) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh1i.attrh.att.com (5.5.029) id 3C83862000035E43; Thu, 7 Mar 2002 09:46:58 -0500 content-class: urn:content-classes:message Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction Date: Thu, 7 Mar 2002 09:46:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcHF5PgUjj5Cr964QUqFfIqd9oyHpQAAIZEg From: "Lind, Steven D, ALASO" To: "Stastny, Richard" , "Lawrence Conroy" , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA27912 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I don't know if this clarifies the discussion or not, but here goes. A. I would think that getting back a tel: URI wouldn't re-invoke ENUM lookups. I don't know if people were saying that but I got that sense. B. While only getting back a tel: URI with the same number would be pretty dumb, the examples in the callflows I-D are _really_ simple. I could envision an application that might receive a series of voice-related URIs (either tel: or sip: or otherwise) that, based on priority might be tried in succession until you got one to answer. For example, querying against my home number, might get you four voice-related URIs, i.e., (1) tel:, (2)sip:, (3)tel:, (4)vpim:. If one number didn't answer within 3 rings, you could try the next; the last would be the failsafe. Steve -----Original Message----- From: Stastny, Richard [mailto:richard.stastny@oefeg.at] Sent: Thursday, March 07, 2002 9:07 AM To: 'Lawrence Conroy'; Stastny, Richard; Lind, Steven D, ALASO; paf@cisco.com; jon.peterson@neustar.biz Cc: enum@ietf.org Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction Lawrence wrote: > I'm still not completely sure about whether one SHOULD NOT > have a tel: URI > that evaluates to the same E.164 number as the domain, or one > SHOULD (so > that this "tight loop" can indicate that this is the end of a > tel: redirect > process) I thought, that the "u" flag can do this? If we agree, that there is a redirect of tel: But I agree, we should discuss this at the IETF meeting. Nevertheless, the default action is still valid. best regards Richard Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Thursday, March 07, 2002 1:57 PM > To: Stastny, Richard; sdlind@att.com; paf@cisco.com; > jon.peterson@neustar.biz > Cc: enum@ietf.org > Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, > RFC2916bis default > action > > > At 12:15 pm +0100 7/3/02, Stastny, Richard wrote: > >Dear Colleagues, > > > >In section 5.3 Call from a Terminal on an IP-based Network > to a phone on the > >PSTN > >of draft-lind-enum-callflows-03.txt, Steve explains: > > > > > > >Considering the discussion with Patrik on the examples in > RFC2916bis, that a > >NAPTR with the same number in the tel: URI does not make > much sense, and > >also, that in Steve example exactly the same action takes > place, if DNS > >returns the URI tel:+13015551234 or if no records exist. I suggest to > >include something like following statement somewhere in RFC2916: > > > >Default Action of the client: > > > >If the ENUM query for a given AUS does not return a result > (404), the action > >taken by the client SHALL be the same as if the result would > have been: > > IN NAPTR 10 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . > > > > > To which I reply: > Hi Richard, folks, > > I'm still not completely sure about whether one SHOULD NOT > have a tel: URI > that evaluates to the same E.164 number as the domain, or one > SHOULD (so > that this "tight loop" can indicate that this is the end of a > tel: redirect > process). > It's certainly one of the open issues with the 'tel' > ENUMservice that we > intended to raise at MSP. > It also ties in with Richard's earlier comment on the use of tel: URI > parameters, and the possible evaluation of the contents from > a local number, > qualified with a phone-context, through to a "full" E.164 number > (Which is another open issue with use of tel: URIs, also to > be raised in MSP). > > Speaking of tel: URI parameters, is the intention to cover > the CPC draft in > ENUM or in SIP//SIPPING or both or...? > > Best Regards, > Lawrence > -- > lwc@roke.co.uk: +44 1794 833666::: > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Mar 7 15:28:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21578 for ; Thu, 7 Mar 2002 15:28:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26465 for enum-archive@odin.ietf.org; Thu, 7 Mar 2002 15:27:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26070; Thu, 7 Mar 2002 15:17:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26039 for ; Thu, 7 Mar 2002 15:17:26 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20773 for ; Thu, 7 Mar 2002 15:17:23 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA04878; Thu, 7 Mar 2002 21:13:06 +0100 (MET) Date: Thu, 07 Mar 2002 21:06:44 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'sdlind@att.com'" cc: enum@ietf.org Subject: RE: [Enum] draft-lind-enum-callflows-03.txt, RFC2916bis default a ction Message-ID: <15649641.1015535204@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-07 12.15 +0100 "Stastny, Richard" wrote: > I suggest to > include something like following statement somewhere in RFC2916: > > Default Action of the client: > > If the ENUM query for a given AUS does not return a result (404), the > action taken by the client SHALL be the same as if the result would have > been: IN NAPTR 10 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . The problem with this is that 2916bis then guess what the definition is of the enumservice indicator "tel", which it doesn't. I.e. I think it is the "tel" specification which should specify what it means to get the same number in a tel URI as the input to the NAPTR algorithm. Now, the $10.000 question is of course what a client which queries the DNS should do if it gets back a NXDOMAIN. Maybe that is _also_ something which should be specified per enumservice specification? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 07:57:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02426 for ; Fri, 8 Mar 2002 07:57:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29247 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 07:57:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27118; Fri, 8 Mar 2002 07:25:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27088 for ; Fri, 8 Mar 2002 07:25:03 -0500 (EST) Received: from localhost ([211.175.225.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01409 for ; Fri, 8 Mar 2002 07:25:00 -0500 (EST) Message-Id: <200203081225.HAA01409@ietf.org> Reply-To: adminggun@gguns.com From: ¼Ò½º¿Õ±¹ To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 8 Mar 2002 21:26:27 +0900 Subject: [Enum] ÀúÈñ »çÀÌÆ®ÀÇ Ç® ¼Ò½º¸¦ ¿ÏÀüÈ÷ °ø°³ ÇÏ¿´½À´Ï´Ù. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org

¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ
¸ÕÀú Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³» Á˼ÛÇÕ´Ï´Ù.
º» ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡ ÃßÃâµÈ ±ÍÇÏÀÇ À̸ÞÀÏÀ» È°¿ëÇÏ¿© ÀúÈñ ȸ»çÀÇ ÁÁÀº Á¦Ç°
È«º¸¸¦ À§ÇÏ¿©º¸³»µå¸®´Â ¸ÞÀÏÀÔ´Ï´Ù.
¿øÄ¡ ¾ÊÀ¸½Ã¸é ¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇÏ¿© Áֽñ⠹ٶø´Ï´Ù.
 
¢Ñ º»¸ÞÀÏÀº µ·¹ú±â µîÀÇ ¸ÞÀÏÀ̳ª, ºÒ¹ý ¼ºÀλçÀÌÆ® ±¤°í ¸ÞÀÏÀÌ ¾Æ´Õ´Ï´Ù.

°¡°Ý : 55,000GM
PHP+Oracle+Java


Ȥ½Ã ±ÍÇϲ²¼­´Â ÀÎÅͳÝÀ» ÀÌ¿ëÇÏ¿© ÀçÅ×Å©¸¦ Çغ¸°íÀÚ Çß´ø »ý°¢À» Çغ¸Áö ¾Ê¾Ò½À´Ï±î?
¶§·Ð ÀÎÅÍ³Ý ¼îÇθôÀ» ¿î¿µÇØ º¸°íÀÚ Çϰųª, µ¿È£È¸, Á¤º¸Á¦°ø »çÀÌÆ®¸¦ ÇѹøÂë ¿î¿µÇØ º¸°í ½ÍÁö´Â ¾Ê¾Ò½À´Ï±î?
±×¶§¸¶´Ù ¾î¶»°Ô ¸¸µé°í, ¾î¶»°Ô ±¸ÇöÇұ °í¹ÎÇÏ¿© ÁÁÀº ¾ÆÀ̵ð¾î¸¦ ±×³É Æ÷±âÇÏÁö´Â ¾Ê¾Ò³ª¿ä?
¼îÇθôÀ» ¸î¸¸¿ø¿¡ ÆǴٰųª, ÀÚ½ÅÀÇ È¨ÆäÀÌÁö¸¦ ¸î¸¸¿ø¿¡ ±¸ÃàÇÏ´Â Á¤µµÀÇ Á¦Ç°ÀÌ ¾Æ´Õ´Ï´Ù.
¾Æ¿¹ ¼ö½Ê¿©Á¾ÀÇ ¹æ´ëÇÑ ¼Ö·ç¼ÇµéÀÌ Æ÷ÇԵǾî ÀÖ´Â Á¦Ç°À» Ç®¼Ò½º¸¦ Æ÷ÇÔÇÏ¿© ÆǸÅÇÏ´Â ±¹³» ÃÖÃÊÀÇ À¥ ¼Ö·ç¼Ç ¿ÏÀü ¿ÀÇ ¼Ò½º ÆǸŠ¹æ½ÄÀ¸·Î Áö±Ý²¯ ¾îµð¿¡¼­µµ ÀÌ·¯ÇÑ Á¤º¸¸¦ ÆǸÅÇÏ´Â »ç·Ê´Â ¾ø¾úÀ¸¸ç,±ÍÇϲ²¼­ ¾î¶°ÇÑ »ç¾÷À̳ª, ÀÎÅÍ³Ý ºñÁö´Ï½º¸¦ ÇÏ°íÀÚ ÇϽǶ§¿¡µµ À¯¿ëÇÏ°Ô ÀÌ¿ëµÉ ¼ö ÀÖ´Â Á¤º¸°¡ ´ã°Ü ÀÖ½À´Ï´Ù.
ÀÌ´Â ÀÎÅͳݻ󿡼­ ¼ÒÇÁÆ®¿þ¾î °³¹ß °ü·Ã Á¤º¸¸¦ Á¦°øÇÏ´Â ¼Ò½º¿Õ±¹(www.codeland.co.kr) ¿¡¼­ À̹ø¿¡ Á¦°øÇÏ´Â "IT Plus Solution ÆÐÅ°Áö" ´Â ÇöÀç ±¹³»¿¡¼­ ¼­ºñ½º µÇ°í ÀÖ´Â ¹æ´ëÇÑ Á¾·ùÀÇ À¥ ¼Ö·ç¼ÇÀ» ÀÚü ±â¼ú·ÂÀ¸·Î °³¹ßÇÏ¿© Àú·ÅÇÑ °¡°ÝÀ¸·Î ÆǸÅÇÏ´Â ±¹³» ÃÖÃÊÀÇ °¡Àå À¯¿ëÇÑ Á¦Ç°ÀÔ´Ï´Ù. ¶ÇÇÑ ±¸¸ÅÇϽô Àü¿ø¿¡°Ô DB ¿ë·® 50M ¸¦ 6°³¿ù°£ ¹«·á·Î Á¦°øÇÏ°í ÀÖ¾î ´õ¿í ÁÁÀº ±âȸ·Î ±ÍÇϸ¸ÀÇ ¼îÇθô, äÆûçÀÌÆ®, Ä¿¹Â´ÏƼ »çÀÌÆ®, Á¤º¸»çÀÌÆ®, °Ô½ÃÆÇ, º¹±Ç, ¿£ÅÍÅ×ÀθÕÆ® µîÀÇ ¼­ºñ½º¸¦ ±¸ÇöÇÒ ¼ö ÀÖ½À´Ï´Ù. ¾Æ·¡ÀÇ Á¦Ç°¿¡´Â ´ÙÀ½°ú °°Àº ±â´ÉÀÇ À¥ ¼Ö·ç¼ÇÀÌ Àüü Ç®¼Ò½º¿Í ÇÔ²² Á¦°øµÇ°í ÀÖ½À´Ï´Ù.
¡Ø Ç®¼Ò½º : Ç®¼Ò½º´Â ÇÁ·Î±×·¥À» ¸¸µé±â À§ÇÏ¿© »ç¿ëµÇ´Â ÇÁ·Î±×·¥ÀÇ ¿ø½Ã ¾ð¾î·Î¼­ À̸¦ °¡°øÇÏ¿© ¾î¶°ÇÑ ÇÁ·Î±×·¥À̵çÁö ¿øÇÏ´Â ¹æ½ÄÀ¸·Î Àç âÁ¶°¡ °¡´ÉÇÑ ÇÁ·Î±×·¥ÀÇ Á¤º¸ÀÔ´Ï´Ù.




¼î ÇÎ ¸ô
 À¥¿¡¼­ ·Î±×Àθ¸À¸·Î ¹Ù·Î ´Ù¸¥ »ç¿ëÀÚ¿Í Ã¤Æà ¹× ÂÊÁö, P2P 1:1ÆÄÀÏ Àü¼Û µîÀ» ÇÒ ¼ö ÀÖ´Â À¥ ¸Þ½ÅÀú ±â´ÉÀÇ Ã¤Æà ¼Ö·ç¼ÇÀ¸·Î ¿ª½Ã ¼Ò½º¿Õ±¹¿¡ ·Î±×ÀÎÀ» ÇϽÅÈÄ ¹Ù·Î ´Ù¸¥ »ç¿ëÀÚ¿Í Å×½ºÆ®¸¦ ÇÒ ¼ö ÀÖ½À´Ï´Ù.ÈçÈ÷ ¾Ë°í °è½Ã´Â
¼¼ÀÌŬ·´,ÇÁ¸®Ã¿ µîÀÇ Ã¤Æðú µ¿ÀÏÇÕ´Ï´Ù.
À¥ ä ÆÃ
 ¿Â¶óÀο¡¼­ ÀÚÀ¯·Ó°Ô °ÔÀÓÀ» ÇÒ ¼öÀÖ´Â ÀÚ¹Ù°ÔÀÓÀ» ÀÚü °³¹ßÇÑ Á¦Ç°À¸·Î ¼Ò½º¿Í ÇÔ²² µî·ÏµÇ¾î ÀÖ½À´Ï´Ù. ·Îº¸Ä°,µÎ´õÁö,Áö··ÀÌ,Å×Æ®¸®½º,Çí»ç,ÆÛÁñ,º®µ¹±ú±âµî
ÀÚ¹Ù °ÔÀÓ8Á¾
 "www.codeland.co.kr/ÀÚ½ÅÀÇ ¾ÆÀ̵ð" ¸¦ ÀÔ·ÂÇÏ½Ã¸é ¹Ù·Î ÀڽŸ¸ÀÇ ÀÛÀº ȨÆäÀÌÁö°¡ ³ªÅ¸³³´Ï´Ù. »çÀÌÆ®¿¡ °¡ÀÔ¸¸À¸·Î ÀÚ½ÅÀÇ È¨ÆäÀÌÁö¸¦ ¸¸µé¾î »ç¿ëÇÒ ¼ö ÀÖ´Â ¼­ºñ½º Á¦Ç°ÀÔ´Ï´Ù.
¸¶ÀÌÀ¥¿¡´Â °Ô½ÃÆÇ,ÀÚ·á½Ç,¾Ù¹ü°ü¸®,½ºÄÉÁì,¸íÇÔ°ü¸®,ȸ¿ø°£ äÆà ±â´É, Àü±¤ÆǵîÀÇ ±â´ÉÀÌ ÀÖ½À´Ï´Ù.
±¸ÀÎ/±¸Á÷
±â¾÷ȸ¿ø°ú °³ÀÎȸ¿ø°£ ÀÚÀ¯·Î¿î ±¸Àα¸Á÷À» ¿¬µ¿ÇÒ ¼ö ÀÖ´Â ¼Ö·ç¼ÇÀÔ´Ï´Ù.
°³ÀÎÀº ÀÚ½ÅÀÇ À̷¼­ °ü¸®¸¦ ÇÒ ¼ö ÀÖÀ¸¸ç, ±â¾÷Àº ±â¾÷ÀÇ ±¸Àΰü¸®¸¦ ½±°Ô ÇÒ ¼ö ÀÖ½À´Ï´Ù.
°ú±Ý ¹æ½ÄÀÇ
À¯·á ¸ÖƼ °Ô½ÃÆÇ
 ´Ü¼øÇÑ ÀÏ¹Ý °Ô½ÃÆÇÀÌ ¾Æ´Õ´Ï´Ù.Á¤º¸¸¦ ÀÚÀ¯·Ó°Ô »ç°í ÆÈ ¼ö ÀÖ´Â °ú±Ý¹æ½ÄÀÇ À¯·á °Ô½ÃÆÇÀÔ´Ï´Ù. ¼Ò½º¿Õ±¹ÀÇ Á¤º¸ °Ô½ÃÆÇ¿¡¼­ È®ÀÎ
º¹±Ç ½Ã½ºÅÛ
ÀÚÀ¯·Ó°Ô ´ç÷Ȯ·üÀ» Á¶À²ÇÏ¿© ±¸ÇöÇÒ ¼ö ÀÖ´Â À¥ º¹±Ç ½Ã½ºÅÛÀÔ´Ï´Ù. ½ÇÁ¦ º¹±ÇÀ» ±Ü´Â µíÇÑ ´À³¦À¸·Î ±¸ÇöÇÒ ¼ö ÀÖ´Â ½Ã½ºÅÛÀ¸·Î
À¯·á ¹æ½ÄÀÇ
¼³¹®Á¶»ç
 µî·ÏÀÚ°¡ ¿øÇÏ´Â ±Ý¾×À¸·Î ¼³¹®Á¶»ç¸¦ µî·ÏÇϸé Âü¿©ÀÚ¿¡°Ô ºÐ¹èµÇ¾î ¹è´ç±ÝÀ» Á¦°øÇÏ´Â À¯·á ¹æ½ÄÀÇ ¼³¹®Á¶»ç ½Ã½ºÅÛÀ¸·Î ¹°·Ð ¹«·á·Îµµ µî·Ï°ú Âü¿©°¡ °¡´ÉÇÕ´Ï´Ù. ¿ª½Ã ¼Ò½º¿Õ±¹¿¡¼­ È®ÀÎÀÌ °¡´ÉÇÕ´Ï´Ù
¾Æ¹ÙŸ¸ô
ÀÚ½ÅÀÌ Á÷Á¢ ¾Æ¹ÙŸ¸¦ ¸¸µé¼ö ÀÖ´Â ¾Æ¹ÙŸ Á¦ÀÛ ÇÁ·Î±×·¥, ¾Æ¹ÙŸ¸¦ ¼îÇθô ¹æ½ÄÀ¸·Î »ç°í ÆÈ ¼ö Àִ¾ƹÙŸ °Å·¡¼Ò µîÀÇ ¼Ö·ç¼ÇÀÔ´Ï´Ù. ¼Ò½º¿Õ±¹ ·Î±×ÀÎÈÄ¿¡ Å×½ºÆ® °¡´ÉÇÕ´Ï´Ù. ÀÌ¿ÜÀÇ È¸¿ø°ü¸® ¹× Æ÷ÀÎÆ® °ü¸®¿Í °¢Á¾ °Ô½ÃÆǵîÀÌ Æ÷ÇԵǾî ÀÖ´Â ¿ÏÀüÇÑ Ç®¼Ò½ºÁ¦Ç°À¸·Î ¾î¶°ÇÑ À¥ ȯ°æ¿¡¼­ ¹Ù·Î È°¿ëÇÏ¿© Àû¿ëÇÒ ¼ö ÀÖ´Â Á¦Ç°À¸·Î Á¦À۵Ǿú½À´Ï´Ù.



À̸ðµç Á¦Ç°ÀÌ 55,000¿øÀÇ °¡°ÝÀ¸·Î Áö±Ý ÇöÀç ÆǸÅÇÏ°í ÀÖ½À´Ï´Ù.
¼Ò½º¿Õ±¹Àº ±¹³» IT °ü·Ã Á¾ÇÕ Á¤º¸¸¦ Á¦°øÇÏ´Â
±¹³» ÃÖ´ëÀÇ Á¤º¸ Á¦°ø »çÀÌÆ®ÀÔ´Ï´Ù.




***¼ö½ÅÀ» ¿øÇÏÁö ¾ÈÀ¸½Ã¸é ¼ö½Å°ÅºÎ ¹öÆ°À» ´­·¯ÁÖ¼¼¿ä***


Copyright¨Ï (ÁÖ)²ÛÄ¿¹Â´ÏÄÉÀÌ¼Ç All Rights Reserved.. Webmaster
 
 
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 13:04:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20995 for ; Fri, 8 Mar 2002 13:04:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21481 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 13:04:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20668; Fri, 8 Mar 2002 12:55:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20634 for ; Fri, 8 Mar 2002 12:55:27 -0500 (EST) Received: from yahoo.com ([211.106.170.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20501 for ; Fri, 8 Mar 2002 12:55:24 -0500 (EST) From: rte294@yahoo.com Message-Id: <200203081755.MAA20501@ietf.org> To: enum@ietf.org Date: 09 Mar 2002 02:55:49 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_4t5Ty3Pm_FK9NkukE_MA" Subject: [Enum] =?ISO-8859-1?B?KMirurgpw9awrcirurjHwbfOsde3pSEhyKu6uLDGwaSzoS4=?= Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ------=_4t5Ty3Pm_FK9NkukE_MA Content-Type: text/plain Content-Transfer-Encoding: 8bit -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- ------=_4t5Ty3Pm_FK9NkukE_MA Content-Type: text/html Content-Transfer-Encoding: 8bit Oº»¸ÞÀÏÀºÁ¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹×Á¤º¸º¸È£µî¿¡°üÇѹý·üÁ¦50Á¶¿¡ÀÇ°ÅÇÑ[±¤°í]¸ÞÀÏÀÔ´Ï´Ù

O º» ¸ÞÀÏÀº Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù
O e-mailÁÖ¼Ò´Â ÀÎÅͳݻ󿡼­ ÃëµæÇÏ¿´À¸¸ç, ÁÖ¼Ò¿Ü ¾î¶°ÇÑ °³ÀÎ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù
¼ö½Å°ÅºÎ¸¦ ¿øÇÏ½Ã¸é ¾Æ·¡¿¡¼­ ¼ö½Å°ÅºÎ ÇØ ÁÖ¼¼¿ä.Á¤º¸¸¦ ¿øÄ¡ ¾Ê´Â ºÐ²²´Â ´ë´ÜÈ÷ ÁË¼Û ÇÕ´Ï´Ù.

¢¿¢¿¢¿ È«º¸ ¶§¹®¿¡ °ÆÁ¤ Çϼ̳ª¿ä? ÀÌÁ¨ °ÆÁ¤ ¸¶¼¼¿ä. ¢¿¢¿¢¿
È«º¸¿¡ ´ëÇÑ ¸ðµç°Í°ú ³ëÇÏ¿ì ¿©±â ´Ù ÀÖ½À´Ï´Ù.
¹«¾úÀ̵çÁö ¹°¾î º¸¼¼¿ä.  sejin14859@yahoo.com

¢º¢º¢º À̹ø¿¡ È«º¸´ëÇà¾÷ À¸·Î ÀüȯÇÔ¿¡µû¶ó
3³âµ¿¾È  ¸ð¾Æ³õÀº È«º¸Çñ׷¥À» ¿°°¡·Î  ´Ùµå¸²´Ï´Ù.¢¸¢¸¢¸

¢¾¢¾¢¾ È«º¸Ãʺ¸¿ë ¢¾¢¾¢¾

¢½À̸áÃßÃâ±â2°³ ¢½À̸áÆíÁý±â1°³ ¢½À̸á¹ß¼Û±â2°³(Á¤Ç°1,µ¥¸ð1)
¢½À̸Ḯ½ºÆ®50¸¸°³ ¢½°Ô½ÃÆǵî·Ï±â1°³ ¢½°Ô½ÃÆǵðDB2000°³

¢Ñ À§ÀÇ ¸ðµç°ÍÀ» 10¸¸¿ø¿¡ ´Ù µå¸³´Ï´Ù. ¢Ð

¢¾¢¾¢¾ È«º¸Áß±Þ¿ë ¢¾¢¾¢¾

¢½À̸áÃßÃâ±â3°³ ¢½À̸áÆíÁý±â1°³ ¢½À̸á¹ß¼Û±â3°³(Á¤Ç°2°³,µ¥¸ð1°³)
¢½À̸Ḯ½ºÆ®100¸¸°³ ¢½°Ô½ÃÆǵî·Ï±â1°³ ¢½°Ô½ÃÆÇDB5000°³

¢Ñ À§ÀÇ ¸ðµç°ÍÀ» 20¸¸¿ø¿¡ ´Ù µå¸³´Ï´Ù. ¢Ð

¢¾¢¾¢¾ È«º¸°í±Þ¿ë(1) ¢¾¢¾¢¾

¢¼¢¼¢¼°³ÀΠȨÆäÁö¿¡ À̸áÃßÃâ,¹ß¼Û±â¸¦ Á÷Á¢ ¼³Ä¡ ÇØ µå¸³´Ï´Ù.¢¼¢¼¢¼

¢½À̸áÃßÃâ±â´É¢½À̸áÁߺ¹»èÁ¦±â´É¢½¼ö½Å°ÅºÎÀÚµ¿±â´É¢½À̸á¹ß¼Û±â´É
¢½¼ö½Å°ÅºÎÀÚÀӽú¸³»±â¢½ÀӽðźÎÀÚ¼ö½Å°ÅºÎÀÚ·Î

¢Ñ¼³Ä¡°¡´ÉÇÑ°÷=ȨÆäÁö¿¡MYSQL°èÁ¤ÀÌ ÀÖ¾î¾ßÇÔ
À¯·áȨÀÌ ¾ø´Â°æ¿ì´Â (200¸Þ°¡,ÀϳâÈ£½ºÆÃ4.4000¿øº°µµÀÓ)

¢Ñ À§ÀÇ ¼³Ä¡¸¦ 20¸¸¿ø¿¡ Çص帳´Ï´Ù. ¢Ð

¢¾¢¾¢¾ È«º¸°í±Þ¿ë(2) ¢¾¢¾¢¾

1000¸¸°³ À̸Ḯ½ºÆ®¸¦ ¿Ã¸°¼­¹ö¸¦ ¸î»ç¶÷¿¡°Ô¸¸ÀÓ´ëÇÔ´Ï´Ù.
(±â°£1³â=°¡°Ý100¸¸¿ø)È«º¸ÇÁ·Î±×·¥°ú ¸ðµç ³ëÇϿ츦 ÀüºÎ Àü¼ö ÇÔ´Ï´Ù.

¢Â¢Â¢Â ÀÌ¸á ±¤°í ´ëÇà ¢Â¢Â¢Â

±×µ¿¾È È«º¸ÀÇ ³ëÇÏ¿ì·Î 2³â¿¡ °ÉÃÄ ¹ß¼Û½Ã¼³À» ¿Ïºñ ÇÏ°í
6000¸¸°³ÀÇ À̸ᵥÀÌŸ¸¦ ±¸ºñÇÏ¿© À̸áÈ«º¸¸¦ ´ëÇàÇØ µå¸³´Ï´Ù.

¢½¹ß¼Û´É·Â= ½Ã°£´ç 1000¸¸Åë
¢½À̸áÁߺ¹ ¿ÏÀüÁ¦°Å, »êÀ̸áäũ=½Ã°£´ç40¸¸ÅëÀÌ»ó
¢½Å¸ÄÏÀ̸Ḹ ºÐ·ù (Áö¿ª,¼ºº°,¾÷Á¾,³ªÀÌµî ¸ðµç°Í °¡´É)

¢Ñ À̸á¹ß¼Û ´ëÇà °¡°ÝÀº 10¸¸Åë ±âÁØ À¸·Î 10¸¸¿ø À̸ç,
»ì¾ÆÀÖ´Â À̸Ḹ äũÇؼ­ º¸³»¸ç, È¿°ú ¾øÀ¸¸é 100% ȯºÒ ÇÕ´Ï´Ù.¢Ð


ÀüÈ­ÆøÁÖ·Î ²ÀÇÊ¿äÇϽźи¸ ¾Æ·¡·Î ¿¬¶ô ÁÖ½Ã¸é ¾È³» Çص帮°Ú½À´Ï´Ù.
 ¢Ñ¹®ÀǸÞÀÏÁֽǰ÷ sejin14859@yahoo.com

¼ö½Å°ÅºÎ

------=_4t5Ty3Pm_FK9NkukE_MA-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 14:04:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25466 for ; Fri, 8 Mar 2002 14:04:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25989 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 14:04:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24321; Fri, 8 Mar 2002 13:49:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24285 for ; Fri, 8 Mar 2002 13:49:17 -0500 (EST) Received: from n12.groups.yahoo.com (n12.groups.yahoo.com [216.115.96.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24385 for ; Fri, 8 Mar 2002 13:49:15 -0500 (EST) X-eGroups-Return: notify-return-enum=ietf.org@yahoogroups.com Received: from [216.115.96.135] by n12.groups.yahoo.com with NNFMP; 08 Mar 2002 18:48:46 -0000 Date: 8 Mar 2002 18:48:36 -0000 Message-ID: <1015613316.4374.95341.w49@yahoogroups.com> From: mplsissues moderator Reply-To: confirm-invite-US08rFPkuJJwFkeJcqcYyuoVOj8-enum=ietf.org@yahoogroups.com To: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Invitation to join the mplsissues group Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hello, You've been invited to join the mplsissues group, an email group hosted by Yahoo! Groups, a free, easy-to-use email group service. JOIN NOW, IT'S EASY: 1) REPLY to this email by clicking "Reply" and then "Send" in your email program -OR- 2) Go to the Yahoo! Groups site at http://groups.yahoo.com/invite/mplsissues?email=enum%40ietf%2Eorg&iref=US08rFPkuJJwFkeJcqcYyuoVOj8 By joining mplsissues, you will be able to exchange messages with other group members. Yahoo! Groups also makes it easy to store photos and files, coordinate events and more. Here's an introductory message from the group moderator: ------------------------------------------------------------------------ This is a group whereby you can share information and assist others with concern to MPLS/GMPLS technology issues, developments, implementations, news etc... ------------------------------------------------------------------------ If you do not wish to join the mplsissues group, please ignore this invitation. SPECIAL NOTE FROM Yahoo! Groups: Because Yahoo! Groups values your privacy, it is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 14:29:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27883 for ; Fri, 8 Mar 2002 14:29:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28483 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 14:29:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27456; Fri, 8 Mar 2002 14:20:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27428 for ; Fri, 8 Mar 2002 14:20:43 -0500 (EST) Received: from public.szptt.net.cn ([202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27188 for ; Fri, 8 Mar 2002 14:20:40 -0500 (EST) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43c892952; Fri, 8 Mar 2002 19:20:21 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm03c86d5f8; Wed, 6 Mar 2002 19:20:19 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA19408 for ietf-123-outbound.01@ietf.org; Wed, 6 Mar 2002 13:35:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id LAA17560 for ; Wed, 6 Mar 2002 11:10:16 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15085; Wed, 6 Mar 2002 11:10:13 -0500 (EST) Message-Id: <200203061610.LAA15085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 11:10:13 -0500 Subject: [Enum] I-D ACTION:draft-foster-e164-gstn-npusa-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Number Portability Administration in the U.S. Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-foster-e164-gstn-npusa-03.txt Pages : 10 Date : 05-Mar-02 This document provides a historical as well as practical overview of the implementation of Number Portability (NP) Administration in the United States (U.S.). There are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. This document describes the NP business model and the architecture for NP administration in the North America. It also briefly discusses the functions performed by the NP administrator and the cost recovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-foster-e164-gstn-npusa-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-foster-e164-gstn-npusa-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-foster-e164-gstn-npusa-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-foster-e164-gstn-npusa-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-foster-e164-gstn-npusa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134541.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 14:33:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28221 for ; Fri, 8 Mar 2002 14:33:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29399 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 14:33:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27796; Fri, 8 Mar 2002 14:23:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27764 for ; Fri, 8 Mar 2002 14:23:04 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27400 for ; Fri, 8 Mar 2002 14:22:59 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 4.00) id 16jPwk-000NAy-00; Fri, 08 Mar 2002 11:22:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mplsissues moderator Cc: enum@ietf.org Subject: Re: [Enum] Invitation to join the mplsissues group References: <1015613316.4374.95341.w49@yahoogroups.com> Message-Id: Date: Fri, 08 Mar 2002 11:22:30 -0800 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit touching to see a mailing list still traditional enough to be a nice source for spam. randy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Mar 8 15:21:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01499 for ; Fri, 8 Mar 2002 15:21:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03323 for enum-archive@odin.ietf.org; Fri, 8 Mar 2002 15:21:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02860; Fri, 8 Mar 2002 15:09:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02824 for ; Fri, 8 Mar 2002 15:09:34 -0500 (EST) Received: from n1.groups.yahoo.com (n1.groups.yahoo.com [216.115.96.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00543 for ; Fri, 8 Mar 2002 15:09:30 -0500 (EST) X-eGroups-Return: notify-return-enum=ietf.org@yahoogroups.com Received: from [216.115.97.163] by n1.groups.yahoo.com with NNFMP; 08 Mar 2002 20:09:02 -0000 Received: (qmail 27853 invoked by uid 7800); 8 Mar 2002 20:08:59 -0000 Date: 8 Mar 2002 20:08:58 -0000 Message-ID: <1015618138.384.27838.m9@yahoogroups.com> From: mplsissues Moderator To: enum@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Welcome to mplsissues Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Hello, Welcome to the mplsissues group at Yahoo! Groups, a free, easy-to-use email group service. Please take a moment to review this message. To learn more about the mplsissues group, please visit http://groups.yahoo.com/group/mplsissues To start sending messages to members of this group, simply send email to mplsissues@yahoogroups.com If you do not wish to belong to mplsissues, you may unsubscribe by sending an email to mplsissues-unsubscribe@yahoogroups.com To see and modify all of your groups, go to http://groups.yahoo.com/mygroups Regards, Moderator, mplsissues Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Mar 9 02:15:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06047 for ; Sat, 9 Mar 2002 02:15:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12816 for enum-archive@odin.ietf.org; Sat, 9 Mar 2002 02:15:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12466; Sat, 9 Mar 2002 02:04:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12440 for ; Sat, 9 Mar 2002 02:04:12 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03360 for ; Sat, 9 Mar 2002 02:04:10 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA02318; Sat, 9 Mar 2002 08:03:39 +0100 (MET) Date: Sat, 09 Mar 2002 08:02:59 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: abuse@yahoogroups.com cc: enum@ietf.org Message-ID: <2758259.1015660979@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA12441 Subject: [Enum] mplsissues group Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Someone managed to subscribe a mailing list in the Internet Engineering Steering Group to one group at Yahoo. This is definitly not appropriate behaviour, and I would appreciate if this subscription was immediately and without further questions revoked. Regards, Patrik Fältström Working Group Chair, ENUM wg in the IETF Area Director, Applications Area, IETF _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sat Mar 9 20:29:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20991 for ; Sat, 9 Mar 2002 20:28:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA20575 for enum-archive@odin.ietf.org; Sat, 9 Mar 2002 20:28:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19933; Sat, 9 Mar 2002 20:06:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19887 for ; Sat, 9 Mar 2002 20:05:37 -0500 (EST) Received: from localhost (s210-221-57-98.thrunet.ne.kr [210.221.57.98]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20153 for ; Sat, 9 Mar 2002 20:05:32 -0500 (EST) Message-Id: <200203100105.UAA20153@ietf.org> Reply-To: adminggun@gguns.com From: ¼Ò½º¿Õ±¹ To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 10 Mar 2002 10:04:39 +0900 Subject: [Enum] ÀúÈñ »çÀÌÆ®ÀÇ Ç®¼Ò½º¸¦ ¿ÏÀüÈ÷ °ø°³ÇÏ¿´½À´Ï´Ù. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org

¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ¢Æ
¸ÕÀú Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³» Á˼ÛÇÕ´Ï´Ù.
º» ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡ ÃßÃâµÈ ±ÍÇÏÀÇ À̸ÞÀÏÀ» È°¿ëÇÏ¿© ÀúÈñ ȸ»çÀÇ ÁÁÀº Á¦Ç°
È«º¸¸¦ À§ÇÏ¿©º¸³»µå¸®´Â ¸ÞÀÏÀÔ´Ï´Ù.
¿øÄ¡ ¾ÊÀ¸½Ã¸é ¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇÏ¿© Áֽñ⠹ٶø´Ï´Ù.
 
¢Ñ º»¸ÞÀÏÀº µ·¹ú±â µîÀÇ ¸ÞÀÏÀ̳ª, ºÒ¹ý ¼ºÀλçÀÌÆ® ±¤°í ¸ÞÀÏÀÌ ¾Æ´Õ´Ï´Ù.

°¡°Ý : 55,000GM
PHP+Oracle+Java


Ȥ½Ã ±ÍÇϲ²¼­´Â ÀÎÅͳÝÀ» ÀÌ¿ëÇÏ¿© ÀçÅ×Å©¸¦ Çغ¸°íÀÚ Çß´ø »ý°¢À» Çغ¸Áö ¾Ê¾Ò½À´Ï±î?
¶§·Ð ÀÎÅÍ³Ý ¼îÇθôÀ» ¿î¿µÇØ º¸°íÀÚ Çϰųª, µ¿È£È¸, Á¤º¸Á¦°ø »çÀÌÆ®¸¦ ÇѹøÂë ¿î¿µÇØ º¸°í ½ÍÁö´Â ¾Ê¾Ò½À´Ï±î?
±×¶§¸¶´Ù ¾î¶»°Ô ¸¸µé°í, ¾î¶»°Ô ±¸ÇöÇұ °í¹ÎÇÏ¿© ÁÁÀº ¾ÆÀ̵ð¾î¸¦ ±×³É Æ÷±âÇÏÁö´Â ¾Ê¾Ò³ª¿ä?
¼îÇθôÀ» ¸î¸¸¿ø¿¡ ÆǴٰųª, ÀÚ½ÅÀÇ È¨ÆäÀÌÁö¸¦ ¸î¸¸¿ø¿¡ ±¸ÃàÇÏ´Â Á¤µµÀÇ Á¦Ç°ÀÌ ¾Æ´Õ´Ï´Ù.
¾Æ¿¹ ¼ö½Ê¿©Á¾ÀÇ ¹æ´ëÇÑ ¼Ö·ç¼ÇµéÀÌ Æ÷ÇԵǾî ÀÖ´Â Á¦Ç°À» Ç®¼Ò½º¸¦ Æ÷ÇÔÇÏ¿© ÆǸÅÇÏ´Â ±¹³» ÃÖÃÊÀÇ À¥ ¼Ö·ç¼Ç ¿ÏÀü ¿ÀÇ ¼Ò½º ÆǸŠ¹æ½ÄÀ¸·Î Áö±Ý²¯ ¾îµð¿¡¼­µµ ÀÌ·¯ÇÑ Á¤º¸¸¦ ÆǸÅÇÏ´Â »ç·Ê´Â ¾ø¾úÀ¸¸ç,±ÍÇϲ²¼­ ¾î¶°ÇÑ »ç¾÷À̳ª, ÀÎÅÍ³Ý ºñÁö´Ï½º¸¦ ÇÏ°íÀÚ ÇϽǶ§¿¡µµ À¯¿ëÇÏ°Ô ÀÌ¿ëµÉ ¼ö ÀÖ´Â Á¤º¸°¡ ´ã°Ü ÀÖ½À´Ï´Ù.
ÀÌ´Â ÀÎÅͳݻ󿡼­ ¼ÒÇÁÆ®¿þ¾î °³¹ß °ü·Ã Á¤º¸¸¦ Á¦°øÇÏ´Â ¼Ò½º¿Õ±¹(www.codeland.co.kr) ¿¡¼­ À̹ø¿¡ Á¦°øÇÏ´Â "IT Plus Solution ÆÐÅ°Áö" ´Â ÇöÀç ±¹³»¿¡¼­ ¼­ºñ½º µÇ°í ÀÖ´Â ¹æ´ëÇÑ Á¾·ùÀÇ À¥ ¼Ö·ç¼ÇÀ» ÀÚü ±â¼ú·ÂÀ¸·Î °³¹ßÇÏ¿© Àú·ÅÇÑ °¡°ÝÀ¸·Î ÆǸÅÇÏ´Â ±¹³» ÃÖÃÊÀÇ °¡Àå À¯¿ëÇÑ Á¦Ç°ÀÔ´Ï´Ù. ¶ÇÇÑ ±¸¸ÅÇϽô Àü¿ø¿¡°Ô DB ¿ë·® 50M ¸¦ 6°³¿ù°£ ¹«·á·Î Á¦°øÇÏ°í ÀÖ¾î ´õ¿í ÁÁÀº ±âȸ·Î ±ÍÇϸ¸ÀÇ ¼îÇθô, äÆûçÀÌÆ®, Ä¿¹Â´ÏƼ »çÀÌÆ®, Á¤º¸»çÀÌÆ®, °Ô½ÃÆÇ, º¹±Ç, ¿£ÅÍÅ×ÀθÕÆ® µîÀÇ ¼­ºñ½º¸¦ ±¸ÇöÇÒ ¼ö ÀÖ½À´Ï´Ù. ¾Æ·¡ÀÇ Á¦Ç°¿¡´Â ´ÙÀ½°ú °°Àº ±â´ÉÀÇ À¥ ¼Ö·ç¼ÇÀÌ Àüü Ç®¼Ò½º¿Í ÇÔ²² Á¦°øµÇ°í ÀÖ½À´Ï´Ù.
¡Ø Ç®¼Ò½º : Ç®¼Ò½º´Â ÇÁ·Î±×·¥À» ¸¸µé±â À§ÇÏ¿© »ç¿ëµÇ´Â ÇÁ·Î±×·¥ÀÇ ¿ø½Ã ¾ð¾î·Î¼­ À̸¦ °¡°øÇÏ¿© ¾î¶°ÇÑ ÇÁ·Î±×·¥À̵çÁö ¿øÇÏ´Â ¹æ½ÄÀ¸·Î Àç âÁ¶°¡ °¡´ÉÇÑ ÇÁ·Î±×·¥ÀÇ Á¤º¸ÀÔ´Ï´Ù.




¼î ÇÎ ¸ô
 À¥¿¡¼­ ·Î±×Àθ¸À¸·Î ¹Ù·Î ´Ù¸¥ »ç¿ëÀÚ¿Í Ã¤Æà ¹× ÂÊÁö, P2P 1:1ÆÄÀÏ Àü¼Û µîÀ» ÇÒ ¼ö ÀÖ´Â À¥ ¸Þ½ÅÀú ±â´ÉÀÇ Ã¤Æà ¼Ö·ç¼ÇÀ¸·Î ¿ª½Ã ¼Ò½º¿Õ±¹¿¡ ·Î±×ÀÎÀ» ÇϽÅÈÄ ¹Ù·Î ´Ù¸¥ »ç¿ëÀÚ¿Í Å×½ºÆ®¸¦ ÇÒ ¼ö ÀÖ½À´Ï´Ù.ÈçÈ÷ ¾Ë°í °è½Ã´Â
¼¼ÀÌŬ·´,ÇÁ¸®Ã¿ µîÀÇ Ã¤Æðú µ¿ÀÏÇÕ´Ï´Ù.
À¥ ä ÆÃ
 ¿Â¶óÀο¡¼­ ÀÚÀ¯·Ó°Ô °ÔÀÓÀ» ÇÒ ¼öÀÖ´Â ÀÚ¹Ù°ÔÀÓÀ» ÀÚü °³¹ßÇÑ Á¦Ç°À¸·Î ¼Ò½º¿Í ÇÔ²² µî·ÏµÇ¾î ÀÖ½À´Ï´Ù. ·Îº¸Ä°,µÎ´õÁö,Áö··ÀÌ,Å×Æ®¸®½º,Çí»ç,ÆÛÁñ,º®µ¹±ú±âµî
ÀÚ¹Ù °ÔÀÓ8Á¾
 "www.codeland.co.kr/ÀÚ½ÅÀÇ ¾ÆÀ̵ð" ¸¦ ÀÔ·ÂÇÏ½Ã¸é ¹Ù·Î ÀڽŸ¸ÀÇ ÀÛÀº ȨÆäÀÌÁö°¡ ³ªÅ¸³³´Ï´Ù. »çÀÌÆ®¿¡ °¡ÀÔ¸¸À¸·Î ÀÚ½ÅÀÇ È¨ÆäÀÌÁö¸¦ ¸¸µé¾î »ç¿ëÇÒ ¼ö ÀÖ´Â ¼­ºñ½º Á¦Ç°ÀÔ´Ï´Ù.
¸¶ÀÌÀ¥¿¡´Â °Ô½ÃÆÇ,ÀÚ·á½Ç,¾Ù¹ü°ü¸®,½ºÄÉÁì,¸íÇÔ°ü¸®,ȸ¿ø°£ äÆà ±â´É, Àü±¤ÆǵîÀÇ ±â´ÉÀÌ ÀÖ½À´Ï´Ù.
±¸ÀÎ/±¸Á÷
±â¾÷ȸ¿ø°ú °³ÀÎȸ¿ø°£ ÀÚÀ¯·Î¿î ±¸Àα¸Á÷À» ¿¬µ¿ÇÒ ¼ö ÀÖ´Â ¼Ö·ç¼ÇÀÔ´Ï´Ù.
°³ÀÎÀº ÀÚ½ÅÀÇ À̷¼­ °ü¸®¸¦ ÇÒ ¼ö ÀÖÀ¸¸ç, ±â¾÷Àº ±â¾÷ÀÇ ±¸Àΰü¸®¸¦ ½±°Ô ÇÒ ¼ö ÀÖ½À´Ï´Ù.
°ú±Ý ¹æ½ÄÀÇ
À¯·á ¸ÖƼ °Ô½ÃÆÇ
 ´Ü¼øÇÑ ÀÏ¹Ý °Ô½ÃÆÇÀÌ ¾Æ´Õ´Ï´Ù.Á¤º¸¸¦ ÀÚÀ¯·Ó°Ô »ç°í ÆÈ ¼ö ÀÖ´Â °ú±Ý¹æ½ÄÀÇ À¯·á °Ô½ÃÆÇÀÔ´Ï´Ù. ¼Ò½º¿Õ±¹ÀÇ Á¤º¸ °Ô½ÃÆÇ¿¡¼­ È®ÀÎ
º¹±Ç ½Ã½ºÅÛ
ÀÚÀ¯·Ó°Ô ´ç÷Ȯ·üÀ» Á¶À²ÇÏ¿© ±¸ÇöÇÒ ¼ö ÀÖ´Â À¥ º¹±Ç ½Ã½ºÅÛÀÔ´Ï´Ù. ½ÇÁ¦ º¹±ÇÀ» ±Ü´Â µíÇÑ ´À³¦À¸·Î ±¸ÇöÇÒ ¼ö ÀÖ´Â ½Ã½ºÅÛÀ¸·Î
À¯·á ¹æ½ÄÀÇ
¼³¹®Á¶»ç
 µî·ÏÀÚ°¡ ¿øÇÏ´Â ±Ý¾×À¸·Î ¼³¹®Á¶»ç¸¦ µî·ÏÇϸé Âü¿©ÀÚ¿¡°Ô ºÐ¹èµÇ¾î ¹è´ç±ÝÀ» Á¦°øÇÏ´Â À¯·á ¹æ½ÄÀÇ ¼³¹®Á¶»ç ½Ã½ºÅÛÀ¸·Î ¹°·Ð ¹«·á·Îµµ µî·Ï°ú Âü¿©°¡ °¡´ÉÇÕ´Ï´Ù. ¿ª½Ã ¼Ò½º¿Õ±¹¿¡¼­ È®ÀÎÀÌ °¡´ÉÇÕ´Ï´Ù
¾Æ¹ÙŸ¸ô
ÀÚ½ÅÀÌ Á÷Á¢ ¾Æ¹ÙŸ¸¦ ¸¸µé¼ö ÀÖ´Â ¾Æ¹ÙŸ Á¦ÀÛ ÇÁ·Î±×·¥, ¾Æ¹ÙŸ¸¦ ¼îÇθô ¹æ½ÄÀ¸·Î »ç°í ÆÈ ¼ö Àִ¾ƹÙŸ °Å·¡¼Ò µîÀÇ ¼Ö·ç¼ÇÀÔ´Ï´Ù. ¼Ò½º¿Õ±¹ ·Î±×ÀÎÈÄ¿¡ Å×½ºÆ® °¡´ÉÇÕ´Ï´Ù. ÀÌ¿ÜÀÇ È¸¿ø°ü¸® ¹× Æ÷ÀÎÆ® °ü¸®¿Í °¢Á¾ °Ô½ÃÆǵîÀÌ Æ÷ÇԵǾî ÀÖ´Â ¿ÏÀüÇÑ Ç®¼Ò½ºÁ¦Ç°À¸·Î ¾î¶°ÇÑ À¥ ȯ°æ¿¡¼­ ¹Ù·Î È°¿ëÇÏ¿© Àû¿ëÇÒ ¼ö ÀÖ´Â Á¦Ç°À¸·Î Á¦À۵Ǿú½À´Ï´Ù.



À̸ðµç Á¦Ç°ÀÌ 55,000¿øÀÇ °¡°ÝÀ¸·Î Áö±Ý ÇöÀç ÆǸÅÇÏ°í ÀÖ½À´Ï´Ù.
¼Ò½º¿Õ±¹Àº ±¹³» IT °ü·Ã Á¾ÇÕ Á¤º¸¸¦ Á¦°øÇÏ´Â
±¹³» ÃÖ´ëÀÇ Á¤º¸ Á¦°ø »çÀÌÆ®ÀÔ´Ï´Ù.




***¼ö½ÅÀ» ¿øÇÏÁö ¾ÈÀ¸½Ã¸é ¼ö½Å°ÅºÎ ¹öÆ°À» ´­·¯ÁÖ¼¼¿ä***


Copyright¨Ï (ÁÖ)²ÛÄ¿¹Â´ÏÄÉÀÌ¼Ç All Rights Reserved.. Webmaster
 

 
_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 10 10:41:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09692 for ; Sun, 10 Mar 2002 10:41:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28835 for enum-archive@odin.ietf.org; Sun, 10 Mar 2002 10:41:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28508; Sun, 10 Mar 2002 10:30:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28467 for ; Sun, 10 Mar 2002 10:30:47 -0500 (EST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09547 for ; Sun, 10 Mar 2002 10:30:41 -0500 (EST) Received: from kana-app.corp.yahoo.com (kana-app.corp.yahoo.com [216.145.51.99]) by mrout3.yahoo.com (8.11.6/8.11.6/y.out) with SMTP id g2AFUL926116 for ; Sun, 10 Mar 2002 07:30:21 -0800 (PST) Message-Id: <200203101530.g2AFUL926116@mrout3.yahoo.com> Date: Sun, 10 Mar 2002 07:32:15 -0800 To: From: Yahoo! Groups Reply-To: Yahoo! Groups MIME-Version: 1.0 Content-Type: text/plain; charset = "us-ascii" X-Mailer: Kana 6.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA28470 Subject: [Enum] Re: Abuse - Unauthorized Subscription - mplsissues (KMM56677099V74197L0KM) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hello, Thank you for writing to Yahoo! Groups. We were able to investigate the situation that you've described and found that your email address is not currently subscribed to the group. If you continue to receive messages please send us a copy of the full headers for one of the messages you receive from that group and we will remove your address from it. To view the full headers for Outlook or Outlook express please follow the directions below. If you are using Outlook Express: The easiest way to get the header in Outlook Express is to open the message and press CTRL F3, you may also view the full header of the message by doing the following: "File->Properties-Details" 1. Open the message. 2. Click on File on the top menu bar. 3. Click on Properties. 4. Click on Details. Please copy the full header and paste it to your reply message. If you are using Outlook: "View->Option - Internet Headers" 1. Open the message. 2. Click on View on the top menu bar. 3. Click on Options. 4. Click on Internet Headers. Please copy the full header and paste it to your reply message. Here is an example of full headers: Return-Path: Delivered-To: email@domain.com Received: (mail 280 invoked from network); 10 Sep 2000 17:58:13 -0000 Received: (QMFILT: 1.0); 10 Sep 2000 18:58:13 -0000 Received: from unknown (HELO mail.domain.com) (5.0.5.0) by server with SMTP; 10 Sep 2000 17:58:12 -0000 X-eGroups-Return: sentto-2223873-0-968608687-mail=domain.com@returns.onelist.com Received: from [10.1.10.1] by mail.domain.com with NNFMP; 10 Sep 2000 17:58:12 -0000 Received: (mail 932 invoked from network); 10 Sep 2000 17:58:07 -0000 Received: from unknown (10.1.10.1) by mail.domain.com with QMQP; 10 Sep 2000 17:58:07 -0000 X-eGroups-Return: mail@domain.net To: groupname@egroups.com Message-ID: <8sgi2c+u5ve@eGroups.com> User-Agent: eGroups-EW/0.82 X-Mailer: eGroups Message Poster X-Originating-IP: 20.21.7.1 From: "Mr. Name" MIME-Version: 1.0 Mailing-List: list group@egroups.com; contact Delivered-To: mailing list groupname@egroups.com Precedence: bulk List-Unsubscribe: Date: Sun, 10 Sep 2000 17:58:04 -0000 Reply-To: groupname@egroups.com Subject: [groupname] Subject Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Thank you again for contacting Yahoo! Customer Care. Regards, Yahoo! Customer Care http://www.yahoo.com/ 29231527 Original Message Follows: ------------------------- Yahoo! ID: Subject: Unauthorized Subscription What Group are you reporting? mplsissues Type your feedback here: A workinggroup in the IETF have been subscribed to the mplsissues group. This is completely inappropriate, so please revoke this asap. Patrik Faltstrom, chair ENUM wg IETF paf@cisco.com While Viewing: http://help.yahoo.com/help/us/groups/groups-35.html Yahoo ID: pfaltstr Browser: Mozilla/4.0 (compatible; MSIE 5.12; Mac_PowerPC) REMOTE_ADDR: 62.95.57.142 REMOTE_HOST: unknown Date Originated: Friday March 8, 2002 - 23:02:38 ------- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 10 18:12:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15661 for ; Sun, 10 Mar 2002 18:12:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA15763 for enum-archive@odin.ietf.org; Sun, 10 Mar 2002 18:12:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15442; Sun, 10 Mar 2002 18:02:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15411 for ; Sun, 10 Mar 2002 18:02:08 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15466 for ; Sun, 10 Mar 2002 18:02:04 -0500 (EST) Received: from user-2iveknr.dialup.mindspring.com ([165.247.82.251] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16kCKM-0005Zi-00 for enum@ietf.org; Sun, 10 Mar 2002 18:02:07 -0500 Message-Id: <5.1.0.14.2.20020308133100.02221580@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Mar 2002 18:05:10 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA15412 Subject: [Enum] Revised #2 IETF 53 Agenda Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I want to solicit opinions one last time on the issues surrounding the documents we have on the plate. The core issues to discuss come down to the revision of 2916 and issues surrounding service field registration IMHO and some recent discussion on call flows etc. I'd like Doug Ranalli to kick off the general issues on service registration since his draft first identified the core issues involved and then go to specifics on SIP, possible presence granularity and then TEL. Doug ...OK with you? I'm of the opinion that we should first discuss the core 2916 revision goals and status then get into the heart of the matter. I want you folks to fill in the Issues lists for these drafts that we need to discuss. I've highlighted possible questions but these are just opinions based on the discussions from the list in the past couple of weeks? Your input is needed NOW!!! The agenda must be submitted before the 13th. We will need to decide in MN what drafts, other than the obvious revision of 2916, should be put on our revised agenda. ####################################### IETF 53 ENUM WG Draft Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … Jay Hilton < applause > . NEW CHARTER REVIEW - Chair’s (5 Min) http://www.ietf.org/html.charters/enum-charter.html Revised Milestones CORE DOCUMENT REVIEW (45 min ??) 2916bis Update - The E.164 to URI DDDS Application A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt Issues: Review of Goals and Objectives for Revision Status of DDDS Requirements for Service Registration ..Privacy? Applicability Statement? SERVICE FIELD DOCUMENTS ( 1 Hour ??) ENUM Service Descriptions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt Issues: What is the goal of this level of granularity in service registrations? The Use of ENUM by SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt Issues: ??? Jon ?? Processing of 2 SIP service fields in one ENUM registration? ENUM Service Resolution A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt Issues: Well what is this draft meant to do? Direction on Presence only Service Field Is presence different from SIP ?? The ENUM TEL enumservice A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt Issues: Why? Is this just for call forwarding or is there carrier specific issues in this ... aka LNP? OTHER DOCUMENTS Extensible Provisioning Protocol and E.164 (10 min +) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-e164-02.txt Issues: Is this the direction the WG wants to go? Possible transport options? Tier 1 and or Tier 2 usages? Relation to PROVREG ENUM Call Flows (10 min) draft-lind-enum-callflows-03.txt Issues: This document has been around a while but let us clarify what direction this is taking. What is the goal and purpose of the document? Is this an accurate picture of possible scenerios? Should Call Flows descriptions be application specific and included in service registration documentation? DOCUMENTS OF NOTE [ NOT ON AGENDA ] US ENUM Forum Overview A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-freilich-overview-enum-forum-00.txt History and Context of ENUM Operational Decisions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt Number Portability in the PSTN Status to Last Call ? draft-ietf-enum-e164-gstn-np-03.txt OPEN DISCUSSION >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 10 18:26:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16000 for ; Sun, 10 Mar 2002 18:26:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16550 for enum-archive@odin.ietf.org; Sun, 10 Mar 2002 18:27:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16113; Sun, 10 Mar 2002 18:18:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16083 for ; Sun, 10 Mar 2002 18:18:02 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15763 for ; Sun, 10 Mar 2002 18:17:56 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g2B4Gwq01075; Sun, 10 Mar 2002 23:16:58 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200203110416.g2B4Gwq01075@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Richard Shockey cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Revised #2 IETF 53 Agenda In-Reply-To: Message from Richard Shockey of "Sun, 10 Mar 2002 18:05:10 EST." <5.1.0.14.2.20020308133100.02221580@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Mar 2002 23:16:58 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I look forward to Jay's scribbles. > Requirements for Service Registration ..Privacy? Applicability Statement? I'd like to see how the SR maps to: o purpose of the data collection (intended use right, not bulk sale or incorporation in reverse directories or link to out-of-band data, etc., o access (write right) of the originator (subscriber or registrant, the end user0| to the collected data, o retention policy of the data collector (delete by date or condition), o recipient(s) of the collected data With a hint or two I might be able to contribute to this bit of the req doc. Comments by email please. Eric _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 10 22:35:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19881 for ; Sun, 10 Mar 2002 22:35:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA27213 for enum-archive@odin.ietf.org; Sun, 10 Mar 2002 22:35:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26259; Sun, 10 Mar 2002 22:22:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26228 for ; Sun, 10 Mar 2002 22:22:05 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18804 for ; Sun, 10 Mar 2002 22:22:01 -0500 (EST) Received: from user-2iveka8.dialup.mindspring.com ([165.247.81.72] helo=dick.ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 16kGNd-0004rX-00; Sun, 10 Mar 2002 22:21:46 -0500 Message-Id: <5.1.0.14.2.20020310221549.023c7c70@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Mar 2002 22:24:48 -0500 To: Eric Brunner-Williams in Portland Maine From: Richard Shockey Subject: Re: [Enum] Revised #2 IETF 53 Agenda Cc: enum@ietf.org, brunner@nic-naa.net In-Reply-To: <200203110416.g2B4Gwq01075@nic-naa.net> References: <5.1.0.14.2.20020308133100.02221580@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:16 PM 3/10/2002 -0500, Eric Brunner-Williams in Portland Maine wrote: >I look forward to Jay's scribbles. > > > Requirements for Service Registration ..Privacy? Applicability Statement? > >I'd like to see how the SR maps to: > o purpose of the data collection (intended use right, not bulk > sale or > incorporation in reverse directories or link to out-of-band > data, etc., Ok makes sense..these are general issues..but see below. > o access (write right) of the originator (subscriber or registrant, > the end user0| to the collected data, > o retention policy of the data collector (delete by date or > condition), > o recipient(s) of the collected data what is national specific and what is general (global) presuming that each nation state is responsible and sovereign is for its portion of the E.164 plan as is currently in force.. how are these segmented in the requirements if at all? I did ask Patrik and Mike to require a Privacy Statement as part of the Service Registration documentation requirement. Could you possibly draft a ENUM Privacy Considerations ID ? What are the issues US, EC, Asia-PAC etc. This is well within scope.. what is specifically missing here? >With a hint or two I might be able to contribute to this bit of the req doc. Hints are given...:-) >Comments by email please. >Eric > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 02:14:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00421 for ; Mon, 11 Mar 2002 02:14:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA17898 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 02:14:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17503; Mon, 11 Mar 2002 02:05:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17472 for ; Mon, 11 Mar 2002 02:05:51 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29900 for ; Mon, 11 Mar 2002 02:05:48 -0500 (EST) Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA00149; Mon, 11 Mar 2002 08:05:08 +0100 (MET) Date: Mon, 11 Mar 2002 08:01:28 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , Eric Brunner-Williams in Portland Maine cc: enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Revised #2 IETF 53 Agenda Message-ID: <10069830.1015833688@localhost> In-Reply-To: <5.1.0.14.2.20020310221549.023c7c70@popd.ix.netcom.com> References: <5.1.0.14.2.20020308133100.02221580@popd.ix.netcom.com> <5.1.0.14.2.20020310221549.023c7c70@popd.ix.netcom.com> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-10 22.24 -0500 Richard Shockey wrote: > Could you possibly draft a ENUM Privacy Considerations ID ? What are the > issues US, EC, Asia-PAC etc. This is well within scope.. what is > specifically missing here? In the IETF we don't write about what is the specific status in various countries. We describe _how_ and _where_ various buttons can be pressed in the protocol so integrity of data, risk of falsification, protection mechanisms, privacy issues are handled according to whatever policy the user might have. We don't describe the policy though. A small difference, but important. I.e. something like this, saying we have five rules (this must be simple): - ENUM is an opt-in mechanism - What is stored in DNS is accessible for anyone - Trolling of DNS makes it possible for post-processing - Integrity protection is made with DNSSEC - Secure authenticated storage is made with LDAP In the case of ENUM, DNS is used, and whatever is stored in DNS is visible for anyone. It only have lookup mechanism for phone number to other URI's and not the other way around. Trolling of the DNS, but can be done, might make it possible for parties to do post-processing of the data. Integrity of the data can be made possible with DNSSEC, the day it is deployed, which is the current strategy IETF has for such issues with the DNS. Sensistive data which is to be protected from access by non-authorized access is to be stored in an external database which support authentication, and we recommend LDAP according to the enumservice specification FOOBAR (which is not yet written). paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 02:31:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00621 for ; Mon, 11 Mar 2002 02:31:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19417 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 02:31:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18221; Mon, 11 Mar 2002 02:22:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18190 for ; Mon, 11 Mar 2002 02:22:30 -0500 (EST) Received: from yahoo.com ([211.202.87.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00486 for ; Mon, 11 Mar 2002 02:22:16 -0500 (EST) Message-Id: <200203110722.CAA00486@ietf.org> Reply-To: pipi1227@yahoo.com From: ¾ÆÅäÇÇ¾Æ To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 11 Mar 2002 16:23:59 +0900 Subject: [Enum] [±¤°í] "¾ÆÅäÇǼº ÇǺο°" ±Øº¹À» À§ÇÑ ½ÎÀÌÆ® ¼Ò°³ Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ±¹³» ÃÖ´ë ±Ô¸ðÀÇ ¾ÆÅäÇÇ È¯ÀÚ¸¦ À§ÇÑ Á¤º¸±³·ùÀå°ú Àü¹®¼îÇθô

 

¾ÆÅäÇÇ¾Æ (www.atopia.co.kr)

 

 

 

¢Ñ ±¹³»ÃÖÃÊ ±¹³» ÃÖ´ë±Ô¸ðÀÇ ¾ÆÅäÇÇ Àü¹® Ä¿¹Â´ÏƼ
¢Ñ ÇÏ·çÆò±Õ ¹æ¹®ÀÚ¼ö 2õ¿©¸í, Ãѹ湮Ƚ¼ö 100¸¸ µ¹ÆÄ!
 ¢Ñ ¾ÆÅäÇÇ ¾Æ±âºÎÅÍ ¼ºÀαîÁö ¾ÆÅäÇÇ Ä¡·á Á¤º¸ ±³È¯
¢Ñ ¾ÆÅäÇÇ °æ·Â 20³âÀÇ ¿î¿µÀÚ°¡ ¸»ÇØÁÖ´Â ¾ÆÅäÇÇ ±Øº¹ ³ëÇÏ¿ì¿Í ¹Ì±¹°ú ÀϺ»ÀÇ ÃֽŠġ·áÁ¤º¸ ¼Ò°³
¢Ñ KBS 2TV ´º½ºÅõµ¥ÀÌ¿¡ ¾ÆÅäÇÇ¾Æ ¼Ò°³ (2001.8.20)

 

 

¾ÆÅäÇǼ¥ (www.atopyshop.com) 

 

 

 

 


¢Ñ ¾ÆÅäÇǾư¡ ¿î¿µÇÏ´Â ±¹³»ÃÖÃÊ ¾ÆÅäÇÇ Àü¹® ¼îÇθô
 ¢Ñ º¸½ÀÁ¦, õ¿¬¿¬°í, ¿°¼ÒÁ¦°Å¿ë »þ¿ö±â, ÀÌ¿ÂÀüÇؼö±â, Áõ»ó°³¼±Á¦, °¡·Á¿ò °³¼±Á¦µî  ¾ÆÅäÇÇ ±Øº¹ ¾ÆÀÌÅÛ ÃÑÁýÇÕ! 
¢Ñ ¾ÆÅäÇÇ °ü·Ã Á¦Ç° ÀÚü ¿¬±¸, °³¹ß
¢Ñ µ¿¾ÆÀϺ¸, °æÇâ½Å¹®, ¼¼°èÀϺ¸µî¿¡ ¾ÆÅäÇǼ¥ ¼Ò°³.

 

  
 
 

¡Ø ÁÖº¯¿¡ ¾ÆÅäÇÇ·Î °í»ýÇÏ´Â ºÐµéÀÌ ÀÖÀ¸¸é À§ÀÇ µÎ ½ÎÀÌÆ®¸¦ ¾Ë·ÁÁÖ¼¼¿ä. ±×ºÐ¿¡°Õ Å« µµ¿òÀÌ µÉ ¼ö ÀÖ½À´Ï´Ù.   

  
* º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å (±¤°í)ÀÓÀ» ¹àÀÔ´Ï´Ù. Çã¶ô¾øÀÌ È«º¸¸ÞÀÏÀ» º¸³»µå·Á ÁË¼Û ÇÕ´Ï´Ù. ±ÍÇÏÀÇ E-MAILÀº °Ô½ÃÆÇ µî ÀÎÅÍ³Ý »ó¿¡¼­ ¾Ë°Ô µÇ¾úÀ¸¸ç, E-mailÀ» Á¦¿ÜÇÑ ¾î¶°ÇÑ Á¤º¸µµ ¾ËÁö ¸øÇÔÀ» ¹àÈü´Ï´Ù. ÇÊ¿ä¾ø´Â ¸ÞÀÏÀÏ °æ¿ì, ºÒÆíÇϽôõ¶óµµ ¹Ý¼ÛÇÏ¿© ÁÖ½Ã¸é ´õ ÀÌ»ó ¹ß¼ÛµÇÁö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù. 
 

 

Copyright © 1998 - 2002 ATOPIA. All rights reserved.

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 03:58:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01913 for ; Mon, 11 Mar 2002 03:58:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24386 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 03:58:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23838; Mon, 11 Mar 2002 03:49:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23812 for ; Mon, 11 Mar 2002 03:49:50 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01750 for ; Mon, 11 Mar 2002 03:49:46 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g2B8nis0011801; Mon, 11 Mar 2002 09:49:45 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Mar 2002 09:25:22 +0100 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Revised #2 IETF 53 Agenda Date: Mon, 11 Mar 2002 09:25:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard Sh, I think, beside the new RFC2916bis, the most important issue of the ENUM WG Meeting in MN is the question of the definition of the ENUM Services, because without defined ENUM Services no clients and therefore no ENUM System can be implemented. But before we can talk about registration, we should have a common understanding which ENUM Services and Resolution Protocols we want to register, and why. To answer the why, we need requirements and scenarios. We also have to decide, if we have only one E2U and different ENUM services, or if we use the Ranalli approach with different applications like E2VOICE (this would also seriously influence RFC2916bis). Also the structure of the documents is dependant on this (e.g. do we have one draft on sip and another on tel, or only one on voice) Also we should come up with a milestone plan and priority list on the services (e.g when to have the drafts on the prio 1 services available (e.g. voice(sip, tel), messages (mail), etc). Since the discussion on the services may have an influence on the core RFC2916bis, maybe the order should be changed insofar, that the service drafts are presented first, than a discussion is held on the principles of service registration (E2U vs E2VOICE) and milestones, and then RFC2916bis is discussed. best regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, March 11, 2002 12:05 AM > To: enum@ietf.org > Subject: [Enum] Revised #2 IETF 53 Agenda > > > > I want to solicit opinions one last time on the issues > surrounding the > documents we have on the plate. > > The core issues to discuss come down to the revision of 2916 > and issues > surrounding service field registration IMHO and some recent > discussion on > call flows etc. > > I'd like Doug Ranalli to kick off the general issues on service > registration since his draft first identified the core issues > involved and > then go to specifics on SIP, possible presence granularity and then > TEL. Doug ...OK with you? > > I'm of the opinion that we should first discuss the core 2916 > revision > goals and status then get into the heart of the matter. > > I want you folks to fill in the Issues lists for these drafts > that we need > to discuss. I've highlighted possible questions but these are > just opinions > based on the discussions from the list in the past couple of > weeks? Your > input is needed NOW!!! The agenda must be submitted before the 13th. > > We will need to decide in MN what drafts, other than the > obvious revision > of 2916, should be put on our revised agenda. > > ####################################### > > IETF 53 ENUM WG Draft Agenda > > Chair(s): > Patrik Faltstrom > Richard Shockey > > > Transport Area Advisor: > Scott Bradner > > Mailing Lists: > General Discussion:enum@ietf.org > To Subscribe: enum-request@ietf.org > In Body: subscribe > Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ > > > > AGENDA BASHING (5 min) > > Scribe Introduction ... Jay Hilton < applause > > . > NEW CHARTER REVIEW - Chair's (5 Min) > > http://www.ietf.org/html.charters/enum-charter.html > > Revised Milestones > > > CORE DOCUMENT REVIEW (45 min ??) > > 2916bis Update - The E.164 to URI DDDS Application > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt > > Issues: > Review of Goals and Objectives for Revision > Status of DDDS > Requirements for Service Registration ..Privacy? > Applicability Statement? > > > SERVICE FIELD DOCUMENTS ( 1 Hour ??) > > ENUM Service Descriptions > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum- > service-01.txt > > Issues: > What is the goal of this level of granularity in service > registrations? > > The Use of ENUM by SIP > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt > > Issues: > > ??? Jon ?? > Processing of 2 SIP service fields in one ENUM registration? > > > ENUM Service Resolution > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt > > Issues: > Well what is this draft meant to do? > Direction on Presence only Service Field > Is presence different from SIP ?? > > The ENUM TEL enumservice > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt > > Issues: > Why? Is this just for call forwarding or is there carrier > specific issues > in this ... aka LNP? > > > OTHER DOCUMENTS > > Extensible Provisioning Protocol and E.164 (10 min +) > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-e164-02.txt > > Issues: > > Is this the direction the WG wants to go? > Possible transport options? > Tier 1 and or Tier 2 usages? > Relation to PROVREG > > ENUM Call Flows (10 min) > draft-lind-enum-callflows-03.txt > > Issues: > > This document has been around a while but let us clarify what > direction > this is taking. > What is the goal and purpose of the document? > Is this an accurate picture of possible scenerios? > Should Call Flows descriptions be application specific and > included in > service registration documentation? > > > DOCUMENTS OF NOTE [ NOT ON AGENDA ] > > US ENUM Forum Overview > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-freilich-overview-en um-forum-00.txt History and Context of ENUM Operational Decisions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt Number Portability in the PSTN Status to Last Call ? draft-ietf-enum-e164-gstn-np-03.txt OPEN DISCUSSION >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 daemon@optimus.ietf.org Mon Mar 11 06:24:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04789 for ; Mon, 11 Mar 2002 06:24:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07513 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 06:24:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06361; Mon, 11 Mar 2002 06:12:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06329 for ; Mon, 11 Mar 2002 06:12:12 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04545 for ; Mon, 11 Mar 2002 06:12:07 -0500 (EST) Message-Id: <200203111112.GAA04545@ietf.org> Received: (qmail 1733 invoked by uid 0); 11 Mar 2002 11:12:08 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 11:12:08 -0000 Date: Mon, 11 Mar 2002 03:23:28 -0800 From: "Jamshid Pashutan" <> To: enum@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [Enum] Urgent! Iran! Can you help? Please also forward. Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 06:37:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05142 for ; Mon, 11 Mar 2002 06:37:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08911 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 06:37:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07880; Mon, 11 Mar 2002 06:28:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07852 for ; Mon, 11 Mar 2002 06:28:22 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04966 for ; Mon, 11 Mar 2002 06:28:18 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063777; Mon, 11 Mar 2002 11:28:19 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Mon, 11 Mar 2002 11:28:19 +0000 To: enum@ietf.org From: Lawrence Conroy Cc: paf@cisco.com, rich.shockey@NeuStar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] 'Scuse - Inappropriate postings Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, Porn is one thing (hey, there's a delete key), gibberish in JIS is another (even better - I have no way of knowing what these idiots are trying to sell before I hit the delete key) but political postings are NOT acceptable. Please, Patrik, Rich, can someone spam-block this before the list is in turn (legitimately) blocked by some ISPs. I know that you both have a lot to do, but ... (Brian Rosen shouldn't be the only one to suffer :) all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 08:08:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06845 for ; Mon, 11 Mar 2002 08:08:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14171 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 08:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13161; Mon, 11 Mar 2002 07:58:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13063 for ; Mon, 11 Mar 2002 07:58:30 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06627 for ; Mon, 11 Mar 2002 07:58:26 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g2BHvVZ01730; Mon, 11 Mar 2002 12:57:31 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200203111757.g2BHvVZ01730@nic-naa.net> To: Richard Shockey cc: Eric Brunner-Williams in Portland Maine , enum@ietf.org, brunner@nic-naa.net Subject: Re: [Enum] Revised #2 IETF 53 Agenda In-Reply-To: Your message of "Sun, 10 Mar 2002 22:24:48 EST." <5.1.0.14.2.20020310221549.023c7c70@popd.ix.netcom.com> Date: Mon, 11 Mar 2002 12:57:31 -0500 From: Eric Brunner-Williams in Portland Maine Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A phrase I coined in the 5th and 4th floors of an office building full of mechanism-free (undistracted by technology) policy-wonks in the capital of some country or another is "jurisdictionalization" (abv. j19n). If there is a requirement for (jurisdictionally) scoped properties of data access or store, something not true in general, but probable in systems in which store is in the form of a "global lookup repository [with perimeter integrity and loose, converging consistency]", and access is not specified in the context of a secure model, e.g., open access ... Then there is a requirement for at least looking for mechanism(s) that support scoped properties of data. To be less theoretical, the US operates under under an opt-out regime, conditional access (legal status), and limited crypto. While each is unfortunate, a problem is to specify fewer distinct mechanisms than jurisdictions, possibly as few as one, that meet this and other instances of policy. Now I mentioned {access,purpose,retention,recipient} because that set of tags has managed to retain utility after three years of active scrutiny in the EU,OECD,FTC policy frameworks, for "interoperable" (or mutually comprehensible) policy language, giving rise to at least one attempt to create a mechanism in a problem domain to provide j19n scoped privacy properties to data collection and publication systems. This suggests the problem is tractible, in theory at least. (Patrik's signature belongs here, as a quotation). Who's problem is this? It may be ours, then again, I don't know of a single US-based for-profit entity that is engaged in privacy as an added-value [1]. > Could you possibly draft a ENUM Privacy Considerations ID ? What are the > issues US ... [putting on Indian Hat] The US issue is institutionalized theft, any data placed "in common" is converted into property by pirates, er, providers, and repurposed to bulk resource for telemarketers. Thanks for the straight line. I agree with Patrik. FOOBAR needs to be written, and WHOIS vigorously depricated (oddly enough, I've a draft on that very subject). Now to cup #2 of coffee. Enjoy Minneapolis. There are two fine casinos in the area with better food than the glass maze. Patronize Indians, and don't forget to tip! Eric [1] Before spending a year layer nine considerations for dns at a nameless beltway dbRON, I spent a year on layer nine considerations for the document object model via http, aka data protection as an economic value, at a US company fetchingly named "Engage". Share price of which is now reduced by three orders of magnitude. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 09:54:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10220 for ; Mon, 11 Mar 2002 09:54:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21281 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 09:54:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20553; Mon, 11 Mar 2002 09:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20517 for ; Mon, 11 Mar 2002 09:44:12 -0500 (EST) Received: from intranet.accuse.co.kr ([61.251.167.135]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09660 for ; Mon, 11 Mar 2002 09:44:05 -0500 (EST) From: notexistingaddress@ohmylotto.com Received: from mail pickup service by intranet.accuse.co.kr with Microsoft SMTPSVC; Mon, 11 Mar 2002 23:45:14 +0900 To: Date: Mon, 11 Mar 2002 17:19:55 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_AB40F_01C1C920.F68544B0" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcHI1YabCImeaa9oTGGqaHsEZmwiNQ== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 11 Mar 2002 14:45:14.0093 (UTC) FILETIME=[5A5CA9D0:01C1C90B] Subject: [Enum] =?ks_c_5601-1987?B?W7GksO1dIMPgx8/H1bTPtNkhIMi4v/iwocDUIDUwMDDG9w==?= =?ks_c_5601-1987?B?wM7Grr+hILTnw7e1x7zMvcC0z7TZLg==?= Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_AB40F_01C1C920.F68544B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 IA0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2FjdGlvbl9sb3R0bzMu YXNwP21fY29kZT02NzQ3Njg+DQoNCiAJDQoJDQogCQ0KIAkNCiAJIAkgDQoNCr7Is+fHz7y8v+Qh DQq9zLHXt6+/7iC6vbnZtve/oSC4tsC9wMwgvLO3ubTCILDowP0hDQq7/ciwvNMgseK73cC7IMOj vsYgx+C6ucC7ILXluK6w7cDaIMfVtM+02S4gDQrB8bDFv+4gu/3IsCEgv8C4tsDMt862xw0KPGh0 dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2FjdGlvbl9sb3R0bzMuYXNwP21f Y29kZT02NzQ3Njg+DQq/zSDH1LKyIMfPvLy/5CEhDQoJDQoJDQrB9rHdIL/AvcO46SwguLbAz7iu wfYgNTAwMMb3wM7Grg0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2Fj dGlvbl9sb3R0bzMuYXNwP21fY29kZT02NzQ3Njg+DQq4piDA+7izx9ggDQq15biztM+02S4guLbA z7iuwfYgurmxx8C4t84gx/ax3bTnw7fAxw0KseLIuLimIMDiwLi8vL/kISEhIA0KKLTcLCDAzCC4 3sDPwLsgxevH2CCwocDUx8+9xSC60L+hIMfRx9QpIAkNCiAJDQogDQo8aHR0cDovL2Rldi5nYXJv c3UuY28ua3IvY2F0ZWdvcnkvbG90dG8vYWN0aW9uX2xvdHRvMy5hc3A/bV9jb2RlPTY3NDc2OD4N Cg0KIA0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2FjdGlvbl9sb3R0 bzMuYXNwP21fY29kZT02NzQ3Njg+DQoNCiANCjxodHRwOi8vZGV2Lmdhcm9zdS5jby5rci9jYXRl Z29yeS9sb3R0by9hY3Rpb25fbG90dG8zLmFzcD9tX2NvZGU9Njc0NzY4Pg0KDQogDQo8aHR0cDov L2Rldi5nYXJvc3UuY28ua3IvY2F0ZWdvcnkvbG90dG8vYWN0aW9uX2xvdHRvMy5hc3A/bV9jb2Rl PTY3NDc2OD4NCg0KIA0KPGh0dHA6Ly9kZXYuZ2Fyb3N1LmNvLmtyL2NhdGVnb3J5L2xvdHRvL2Fj dGlvbl9sb3R0bzMuYXNwP21fY29kZT02NzQ3Njg+DQoNCiANCjxodHRwOi8vZGV2Lmdhcm9zdS5j by5rci9jYXRlZ29yeS9sb3R0by9hY3Rpb25fbG90dG8zLmFzcD9tX2NvZGU9Njc0NzY4Pg0KDQog CQ0KICAgICAgICAgKiC6uyBlLW1haWzAuiDA/LvquMEgurix3siuwOWw+iDAzL/rw8vB+L+hILD8 x9Eguf23/L+hIMDHsMXHz7+pILz2vcXA2rChILDFus64piDIuL3FwLi3ziANCiAgICAgICAgICAg ueDI+SDIxL+htMIgurizu8H2IL7KvcC0z7TZLiBbvPa9xbDFus5dDQo8aHR0cDovL2Rldi5nYXJv c3UuY28ua3IvY2F0ZWdvcnkvbG90dG8vdmV0b19sb3R0bzMuYXNwP21fY29kZT02NzQ3Njg+DQoN CiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICogscOx 3cfPvcUgu+fH18DMIMDWwLi9w7jpIL7wwaa287W1IL+stvTB1ry8v+QuIGxvdHRvQG9obXlsb3R0 by5jb20NCjxtYWlsdG86bG90dG9Ab2hteWxvdHRvLmNvbT4gDQoJDQogCQ0KIDxodHRwOi8vd3d3 Lm9obXlsb3R0by5jb20vbHVjay9sdWNrXzAyLmpzcD4gCSANCiAJIA0K ------=_NextPart_000_AB40F_01C1C920.F68544B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Untitled Document = = = = = = = = =
 
= =
= =
 
=
=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4!
= =BD=CC=B1=D7=B7=AF=BF=EE =BA=BD=B9=D9=B6=F7=BF=A1 = =B8=B6=C0=BD=C0=CC =BC=B3=B7=B9=B4=C2 =B0=E8=C0=FD!
= =BB=FD=C8=B0=BC=D3 =B1=E2=BB=DD=C0=BB =C3=A3=BE=C6 =C7=E0=BA=B9=C0=BB = =B5=E5=B8=AE=B0=ED=C0=DA =C7=D5=B4=CF=B4=D9.
= =C1=F1=B0=C5=BF=EE =BB=FD=C8=B0! =BF=C0=B8=B6=C0=CC=B7=CE=B6=C7=BF=CD = =C7=D4=B2=B2 =C7=CF=BC=BC=BF=E4!!
= =C1=F6=B1=DD =BF=C0=BD=C3=B8=E9, =B8=B6=C0=CF=B8=AE=C1=F6 = 5000=C6=F7=C0=CE=C6=AE=B8=A6 =C0=FB=B8=B3=C7=D8
= =B5=E5=B8=B3=B4=CF=B4=D9. =B8=B6=C0=CF=B8=AE=C1=F6 = =BA=B9=B1=C7=C0=B8=B7=CE =C7=F6=B1=DD=B4=E7=C3=B7=C0=C7
= =B1=E2=C8=B8=B8=A6 =C0=E2=C0=B8=BC=BC=BF=E4!!!
(=B4=DC, =C0=CC =B8=DE=C0=CF=C0=BB =C5=EB=C7=D8 = =B0=A1=C0=D4=C7=CF=BD=C5 =BA=D0=BF=A1 =C7=D1=C7=D4) =
    =      * =BA=BB e-mail=C0=BA =C0=FC=BB=EA=B8=C1 = =BA=B8=B1=DE=C8=AE=C0=E5=B0=FA =C0=CC=BF=EB=C3=CB=C1=F8=BF=A1 = =B0=FC=C7=D1 =B9=FD=B7=FC=BF=A1 =C0=C7=B0=C5=C7=CF=BF=A9 = =BC=F6=BD=C5=C0=DA=B0=A1 =B0=C5=BA=CE=B8=A6 =C8=B8=BD=C5=C0=B8=B7=CE =
           =B9=E0=C8=F9 = =C8=C4=BF=A1=B4=C2 =BA=B8=B3=BB=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9. [=BC=F6=BD=C5=B0=C5=BA=CE] =
  =       =  -------------------------------------------------------------------= -------------------------
         * = =B1=C3=B1=DD=C7=CF=BD=C5 =BB=E7=C7=D7=C0=CC =C0=D6=C0=B8=BD=C3=B8=E9 = =BE=F0=C1=A6=B6=F3=B5=B5 =BF=AC=B6=F4=C1=D6=BC=BC=BF=E4. lotto@ohmylotto.com
 
------=_NextPart_000_AB40F_01C1C920.F68544B0-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 12:44:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17051 for ; Mon, 11 Mar 2002 12:44:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA03913 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 12:44:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03191; Mon, 11 Mar 2002 12:32:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03161 for ; Mon, 11 Mar 2002 12:32:49 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16619 for ; Mon, 11 Mar 2002 12:32:44 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2BHV1f05258; Mon, 11 Mar 2002 12:31:01 -0500 Message-Id: <5.1.0.14.2.20020311092125.02310990@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Mar 2002 12:34:01 -0500 To: "Stastny, Richard" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] Revised #2 IETF 53 Agenda In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09:25 AM 3/11/2002 +0100, Stastny, Richard wrote: >Hi Richard Sh, > >I think, beside the new RFC2916bis, the most important issue of the ENUM WG >Meeting in MN is the question of the definition of the ENUM Services, >because without defined ENUM Services no clients and therefore no ENUM >System can be implemented. But before we can talk about registration, we >should have a common understanding which ENUM Services and Resolution >Protocols we want to register, and why. To answer the why, we need >requirements and scenarios. Which is why I thought it valuable for Doug to lead off here. >We also have to decide, if we have only one E2U and different ENUM services, >or if we use the Ranalli approach with different applications like E2VOICE >(this would also seriously influence RFC2916bis). Also the structure of the >documents is dependant on this (e.g. do we have one draft on sip and another >on tel, or only one on voice) > >Also we should come up with a milestone plan and priority list on the >services (e.g when to have the drafts on the prio 1 services available (e.g. >voice(sip, tel), messages (mail), etc). agreed... this looks like a plan >Since the discussion on the services may have an influence on the core >RFC2916bis, maybe the order should be changed insofar, that the service >drafts are presented first, than a discussion is held on the principles of >service registration (E2U vs E2VOICE) and milestones, and then RFC2916bis is >discussed. This seems reasonable ...its been suggested before... >best regards > >Richard STASTNY >OeFEG >Arsenal Objekt 24 >P.O. Box 147 >A-1103 Vienna, Austria >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 17:13:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27291 for ; Mon, 11 Mar 2002 17:13:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18966 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 17:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18382; Mon, 11 Mar 2002 17:01:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18343 for ; Mon, 11 Mar 2002 17:01:00 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26807 for ; Mon, 11 Mar 2002 17:00:55 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2BM06f12862; Mon, 11 Mar 2002 17:00:06 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 16:00:01 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECED36@dc02.npac.com> From: "Yu, James" To: "'M.Muench@alcatel.de'" Cc: enum@ietf.org Subject: RE: [ENUM] Comments to Date: Mon, 11 Mar 2002 15:59:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Monica, Thanks for your comments. Please see the response marked with [YU]. James > > My comments concentrate on the sections for Europe. > > (1) Comment to section 5.2 Europe: > In Europe the ETSI standards for Number Portability are the basis for > realising NP in the fixed network. Item (c) "ISUP triggerless > translation" > is not standardised in the ETSI standards (and by the way also not > standardised in the ITU-T Recommendation and Supplements) and > should not be > reflected in this NP overview document. If the "ISUP triggerless > translation" is used in european countries then this is a > network operator > matter. > > ==> delete item (c) in section 5.2 [YU] I'll take that one out because it is an implementation instead of a standard. > > (2) Comment to section 6.2 Europe: > The first two sentences explain one possibility to map the RN > and DN to the > ISUP IAM. > In the fourth paragraph a reference is made to ITU-T Rec. > Q.769.1. This > should be the corresponding baseline for the mapping of the > RN and DN to > the ISUP protocol. By the way, in Europe ITU-T Rec. Q.769.1 > is slightly > modified by ETSI EN 302 097 V.1.2.2 (2000-09). [YU] Will update the references. > > Text proposal for the whole section 6.2: > > [MM] > In a number portability environment, the directory number (DN) is not > sufficient to route the call. There is a need to derive a > routing number > (RN) based on the methods defined in [CS1] and [CS2]. Once > the RN has been > determined, the routing in the network will be based on this > RN. As the RN > is always a complete address, sending of additional digits in overlap > operation applies only to the directory number (DN) > information. The DN is > transferred along with the call to identify the called ported > subscriber. > > The enhancements in the ISUP protocol to support number > portability are > briefly described below. > > Three methods can be used to transport the Directory > Number (DN) and > the Routing Number (RN): > > (a) Two separate parameters with the CdPN parameter containing the > RN and a new Called Directory Number (CdDN) parameter containing > the DN. A new value for the Nature of Address (NOA) > indicator in > the CdPN parameter is defined to indicate that the RN is in the > CdPN parameter. The switches use the CdPN parameter to > route the > call as is done today. > > (b) Two separate parameters with the CdPN parameter containing the > DN and a new Network Routing Number (NRN) parameter containing > the RN. This method requires that the switches use the NRN > parameter to route the call. > > (c) Concatenated parameter with the CdPN parameter > containing the RN > plus the DN. A new Nature of Address (NOA) indicator > in the CdPN > parameter is defined to indicate that the RN is > concatenated with > the DN in the CdPN parameter. Some countries may not > use new NOA > value because the routing prefix does not overlap with > the dialed > directory numbers. But if the routing prefix overlaps with the > dialed directory numbers, a new NOA value must be assigned. > Spain uses "XXXXXX" as the routing prefix to identify the new > serving network and uses a new NOA value of 126. > > As an example, in some european countries, a routing number > is prefixed to > the dialed directory > number. The ISUP CdPN parameter in the IAM will contain > the routing > prefix and the dialed directory number. For example, > United Kingdom > uses routing prefixes with the format of 5XXXXX and Italy uses > C600XXXXX as the routing prefix. The networks use the information > in the ISUP CdPN parameter to route the call to the New/Current > Serving Network. > > The routing prefix can identify the Current Serving Network or the > Current Serving Switch of a ported number. For the former case, > another query to the "internal" NPDB at the Current Serving Network > is required to identify the Current Serving Switch before routing > the call to that switch. This shields the Current Serving Switch > information for a ported number from the other networks at the > expense of an additional NPDB query. Another routing > number, may be > meaningful within the Current Serving Network, will replace the > previously prefixed routing number in the ISUP CdPN parameter. For > the latter case, the call is routed to the Current Serving Switch > without an additional NPDB query. > > When the terminating switch receives the IAM and sees its own > routing prefix in the CdPN parameter, it retrieves the originally > dialed directory number after the routing prefix, and uses the > dialed directory number to terminate the call. > > In addition to the addition of the routing prefix to the CdPN > parameter, some other information may be added/modified as > is listed > in the ITU-T Recommendation Q.769.1 [ISUP] or ETSI EN 302 097 [ETSI > ISUP].. > > There is also a network option to add a new ISUP parameter called > Number Portability Forwarding Information parameter. This > parameter > has a four-bit Number Portability Status Indicator field that can > provide an indication whether number portability query is done for > the called directory number and whether the called directory number > is ported or not if the number portability query is done. > > Please note that all those NP enhancements for a ported number can > only be used in the country that defined them. This is because > number portability is supported within a nation or only within a > network. > > Within each > nation, the telecommunications industry or the regulatory > bodies can > decide which method or methods to use. [YU] You have re-arranged some paragraphs in your suggestion in addition to some proposed texts. I'll check and incorp. > > [MM]: > The sentence in draft 03 "Number portability related > parameters and coding > are never passed across the national boundaries." is not correct. The > passing of a number portability related parameter is dependent on the > agreements at the point of interconnections. Modify the sentence: > > Number Portability related parameters and coding are passed > across national > boundaries dependent on the agreements at the interconnection > interface. [YU] Will incorporate. I'd appreciate if you provide any known examples/cases. > [MM] > > For example, a UK routing prefix can only be used in > UK, and would cause routing problem if it appears outside UK. > > > As indicated earlier, an originating wireless network can query the > NPDB and concatenate the RN with DN in the CdPN parameter and route > the call directly to the Current Serving Network. > > If NPDBs do not contain information about the wireless directory > numbers, the call, originated from either a wireline or a wireless > network, will be routed to the Wireless donor network. Over there, > an internal NPDB is queried to retrieve the RN that then is > concatenated with the DN in the CdPN parameter. > > If MNP-SRF is supported, the Gateway Mobile Services Switching > Center (GMSC) at the wireless donor network, when receiving a call > from the wireline network, can send the GSM MAP Send Routing > Information (SRI) message to the MNP-SRF. The MNP-SRF interrogates > an internal or integrated NPDB for the RN of the MNP-SRF of the > wireless Current Serving Network and prefixes the RN to the dialed > wireless directory number in the global title address > information in > the SCCP Called Party Address (CdPA) parameter. This SRI message > will be routed to the MNP-SRF of the wireless Current Serving > Network, which then responds with an acknowledgement by providing > the RN plus the dialed wireless directory number as the Mobile > Station Roaming Number (MSRN). The GMSC of the wireless donor > network formulates the ISUP IAM with the RN plus the > dialed wireless > directory number in the CdPN parameter and routes the call to the > wireless Current Serving Network. A GMSC of the wireless Current > Serving Network receives the call and sends an SRI message to the > associated MNP-SRF where the global title address > information of the > SCCP CdPA parameter contains only the dialed wireless directory > number. The MNP-SRF then replaces the global title address > information in the SCCP CdPA parameter with the address information > associated with a Home Location Register (HLR) that hosts > the dialed > wireless directory number and forwards the message to that > HLR after > verifying that the dialed wireless directory number is a ported-in > number. The HLR then returns an acknowledgement by providing an > MSRN for the GMSC to route the call to the MSC that > currently serves > the mobile station that is associated with the dialed wireless > directory number. Please see [MNP] for details and additional > scenarios. > > > The last paragraph of section 6.2 describes only one > possibility to realise > MNP. This should be clearly stated at the begin of the explanation. > [MM] [YU] Will do. > > > (3) Comment to Section12. Normative References > > Replace > [ISUP] ITU-T COM 11-R 162-E, Draft Recommendation Q.769.1, > "Signaling System No. 7 - ISDN User Part Enhancements for the > Support of Number Portability," May 1999. > With > [ISUP] ITU-T Recommendation Q.769.1, > "Signaling System No. 7 - ISDN User Part Enhancements for the > Support of Number Portability," December 1999. > > Replace > [MNP] Draft GSM 03.66 V7.2.0 (1999-11) European Standard > (Telecommunications series) Digital cellular > telecommunications > system (Phase 2+); Support of Mobile Number Portability (MNP); > Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 > Release 1998). > With > [MNP] ETSI EN 301 716 (2000-10) European Standard > (Telecommunications series) Digital cellular > telecommunications > system (Phase 2+); Support of Mobile Number Portability (MNP); > Technical Realisation; Stage 2; (GSM 03.66 Version 7.3.1 > Release 1998). > > And add > [ETSI] ETSI EN 302 097 V1.2.2 (2000-09) European Standard > (Telecommunications series) Integrated Service Digital Network > (ISDN); Signalling System No.7 (SS7); ISDN User Part (ISUP); > Enhancement for support of Number Portability (NP); > [ITU-T Recommendation Q.769.1 (2000), modified] [YU] Will update the references. > > ####################### > > Here end the comments and corrections to draft 03. > > Nevertheless I have a general question. What is the aim of this > IETF-Draft??? > As far as I can see it, this draft once again describes NP and MNP. > But this has already been done within ITU-T Recommendations and > Supplements, in ANSI standards and in ETSI standards. > It could happen that this draft does not correctly describe > some issues of > NP and MNP and maybe contradicts to the standards. [YU] The purpose of this I-D is to give an overview of NP (including MNP) with the intention to point out the possible impacts of NP on some works in progress in IETF. So the section on "potential implications" provide some discussions. One purpose for the ENUM WG is realize that NP will implact ENUM if the telephony service providers' (TSPs') NAPTR RRs are collocated with the end users' NAPTR RRs under the same tree name, e164.arpa. In the ENUM Forum (U.S.), there is a consensus there that the TSPs should use a different tree name is they want to use ENUM technology for the "network" services. > > Why don't we say: > "NP and MNP are defined in the following standards: > ITU-T Rec. .... > ANSI standard .... > ETSI standard ...." [YU] We hope that people find useful info. in one document. I doubt that someone without any knowledge about NP can collect the documents (ITU-T, ETSI and ANSI, etc.) and sip thru them and get the understanding/feeling about how NP/MNP is done in N.A. and Europe. So this document is for IETF people who don't have the telecom background to know how it works and what may be the impacts on their works at IETF. > > What additional information is missing in those standards > which shall be > reflected in the IETF-Draft? > Is it really necessary to know all the codings of a RN and > the codings of > the protocol? > > One issue, for instance, is not even mentioned in the draft, > that is NP and > Completion of Calls to Busy Subscriber (CCBS) which requires > mechanisms for > bearer unrelated signalling messages. > > How should we proceed? [YU] We know how signaling is done in N.A. and Europe under NP environmnet. We can add some brief discussions about how it is done without spending one full section on that. It is either done by 10-digit GTT or message relaying (this latter one is similar to onward routing). > > Kind regards, > > Monika > > ++++++++++++++++++++++++++ > Monika Muench > Alcatel SEL AG > Lorenzstrasse 10 > 70435 Stuttgart > Germany > > mail: M.Muench@alcatel.de > phone: +49 711 821-41417 > fax: +49 711 821-40017 > ++++++++++++++++++++++++++ > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Mon Mar 11 19:07:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00065 for ; Mon, 11 Mar 2002 19:07:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24584 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 19:07:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23764; Mon, 11 Mar 2002 18:58:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23728 for ; Mon, 11 Mar 2002 18:58:15 -0500 (EST) Received: from localhost ([211.110.216.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29806 for ; Mon, 11 Mar 2002 18:58:10 -0500 (EST) Message-Id: <200203112358.SAA29806@ietf.org> Reply-To: ¹ß½ÅÀü¿ë@yahoo.co.kr From: ´ëÃâÁö¿ø<¹ß½ÅÀü¿ë@yahoo.co.kr> To: enum@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 12 Mar 2002 08:55:14 +0900 Subject: [Enum] [ ±¤ °í ] ¾ðÁ¦-¾î´À ´©±¸¿¡°Ô³ª..(Ä«µå¿¬Ã¼, â¾÷Áö¿ø, ÀϹݴëÃâÀ»...) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org ´©±¸³ª ´ëÃâ(20¼¼ÀÌ»ó)

 

F
                         
        ´©±¸³ª ´ëÃâ(20¼¼ÀÌ»ó)

              060-708-4455

                   ÇÊ¿äÇϽŠÀÚ±ÝÀ» ¿øÇϽô ½Ã°£¿¡                        ´ëÃâÇØ µå¸³´Ï´Ù 
      º»»ç´Â ½ÃÁßÀºÇà°ú ÀúÃàÀºÇàÀÇ ÄÁ¼Ò½Ã¾öÀ»     ±¸¼ºÇÏ¿© ÀºÇàÀ¸·Î ¹Ù·Î ´ëÃâ ¹ÞÀ»¼ö ÀÖ½À´Ï´Ù

                 ÀüÈ­ÇÑÅëÀ¸·Î Çѹ濡 ÇØ°á.....!
 
                       Ä«µå¿¬Ã¼´ë³³, »ç¾÷ÀÚ±Ý, ÇÐÀÚ±Ý,              ÁÖÅñ¸ÀÔÀÚ±Ý,µîµî 3ÀÏÀ̳» ó¸®
 
                            080-708-4455

 ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼­ÇÎÁß, http://www.xxxxxxxx.com/
¿¡¼­ ¾Ë°Ô µÈ°ÍÀ̸ç, E-Mail ÁÖ¼Ò ¿Ü¿¡, ´Ù¸¥ Á¤º¸´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù.
 Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥±âÇÑ ¸ÞÀÏÀÔ´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸¸é ,¼ö½Å°ÅºÎ¸¦ ´­·¯ÁÖ¼¼¿ä   

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 19:11:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00179 for ; Mon, 11 Mar 2002 19:11:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA24768 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 19:11:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24393; Mon, 11 Mar 2002 19:03:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24362 for ; Mon, 11 Mar 2002 19:02:58 -0500 (EST) Received: from intranet.online.de (intranet.online.de [212.227.34.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29895 for ; Mon, 11 Mar 2002 19:02:55 -0500 (EST) From: mark.neufurth@einsundeins.com To: enum@ietf.org Message-ID: Date: Tue, 12 Mar 2002 01:01:19 +0100 X-MIMETrack: Serialize by Router on DOMINO3/1&1/DE(Release 5.0.9 |November 16, 2001) at 12.03.2002 01:02:58 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA24363 Subject: [Enum] Mark Neufurth - 1&1 Internet AG is not in office Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Ich werde ab 11.03.2002 nicht im Büro sein. Ich kehre zurück am 19.03.2002. Hi, thank you very much for your e-mail. Regrettably I can't reply at the moment. You will receive an answer immediately after my reappearance in office. Best regards Mark Neufurth 1&1 Internet AG Mit freundlichem Gruß Mark Neufurth 1&1 Internet AG _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 11 19:27:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00638 for ; Mon, 11 Mar 2002 19:27:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA25429 for enum-archive@odin.ietf.org; Mon, 11 Mar 2002 19:27:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25075; Mon, 11 Mar 2002 19:19:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25046 for ; Mon, 11 Mar 2002 19:19:04 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00352 for ; Mon, 11 Mar 2002 19:19:00 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2C0IWi16690; Mon, 11 Mar 2002 18:18:32 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 18:18:27 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870156@va02.va.neustar.com> From: "Peterson, Jon" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Revised #2 IETF 53 Agenda Date: Mon, 11 Mar 2002 18:18:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I imagine that the discussion of the service field issue could easily encompass this entire hour, and this seems to be the most important thing for us to sort out. I will make up some very few slides (maybe four or so) that summarize what I see the major points of contention on this issue. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Sunday, March 10, 2002 3:05 PM > To: enum@ietf.org > Subject: [Enum] Revised #2 IETF 53 Agenda > > [snip] > > > SERVICE FIELD DOCUMENTS ( 1 Hour ??) > [snip] > > The Use of ENUM by SIP > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt > > Issues: > > ??? Jon ?? > Processing of 2 SIP service fields in one ENUM registration? > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 12 07:50:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20465 for ; Tue, 12 Mar 2002 07:50:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08427 for enum-archive@odin.ietf.org; Tue, 12 Mar 2002 07:50:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07772; Tue, 12 Mar 2002 07:39:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07738 for ; Tue, 12 Mar 2002 07:39:24 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20269 for ; Tue, 12 Mar 2002 07:39:20 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA05844; Tue, 12 Mar 2002 13:38:49 +0100 (MET) Date: Tue, 12 Mar 2002 13:33:53 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org cc: rich.shockey@NeuStar.biz Message-ID: <13041848.1015940033@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Re: 'Scuse - Inappropriate postings Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-11 11.28 +0000 Lawrence Conroy wrote: > Please, Patrik, Rich, can someone spam-block this before the > list is in turn (legitimately) blocked by some ISPs. I know > that you both have a lot to do, but ... This is my ball. I have got requests (thanks) from several people which can help managing the moderation. I have not had time in the preparation for the next week IETF meeting to also set up this. I will do this now. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 12 11:47:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26898 for ; Tue, 12 Mar 2002 11:47:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23587 for enum-archive@odin.ietf.org; Tue, 12 Mar 2002 11:47:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23135; Tue, 12 Mar 2002 11:38:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23108 for ; Tue, 12 Mar 2002 11:38:23 -0500 (EST) Received: from hotmail.com ([210.110.47.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26731 for ; Tue, 12 Mar 2002 11:38:18 -0500 (EST) Message-Id: <200203121638.LAA26731@ietf.org> Reply-To: ncstyle53@hotmail.com From: ´ºÄÚ½º To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 13 Mar 2002 01:38:05 +0900 Subject: [Enum] È­ÀåÇ° ¾²½Ã´Â ¿©¼ººÐ¸¸ º¸¼¼¿ä.±¦ÂúÀº ½ÎÀÌÆ® ¼Ò°³ÇÏ·Á±¸¿ä.Çѹø µé·¯º¸¼¼¿ä.[±¤ _°í] Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org

* ¹ß½ÅÀü¿ëÀ̹ǷΠ¼ö½ÅÀÌ ºÒ°¡ÇÕ´Ï´Ù.

* ¹Ýµå½Ã ÀÌ°÷(ncman@simmani.com)À¸·Î ȸ½Å ¹Ù¶ø´Ï´Ù.

* ºÒÇÊ¿äÇÑ Á¤º¸¶ó¸é Áø½ÉÀ¸·Î Á˼ÛÇÕ´Ï´Ù.

 

¾È³çÇϼ¼¿ä? È­ÀåÇ° ½ÎÀÌÆ®

´ºÄÚ½º(http://www.newcos.co.kr)°¡ »õ·Î ¿ÀÇÂÇÏ¿´½À´Ï´Ù.

Çѹø µé·¯¼Å¼­ ±¸°æÇغ¸¼¼¿ä.

¾Æ¸¶ °¡°ÝÀÌ Àú·ÅÇҰŶó »ý°¢Çϸç,¾ÆÁÖ °£ÆíÇÏ°Ô ±¸¸ÅÇÏ½Ç ¼ö ÀÖÀ»°Ì´Ï´Ù.

óÀ½ÀÌ¶ó ¸¹ÀÌ ºÎÁ·ÇÏÁö¸¸ ÁöÄѺÁÁÖ¼¼¿ä.


µÑ·¯º¸±â(Ŭ¸¯)

 

¡Ø º» ¸ÞÀÏÀº Á¤º¸Åë½Å¸Á¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÏ¿© [±¤ °í]¸ÞÀÏÀÓÀ» ¹àÈü´Ï´Ù.

Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³½Á¡ Áø½ÉÀ¸·Î Á˼ÛÇÕ´Ï´Ù.

ÀÌ ¸ÞÀÏÀº À¥¼­ÇÎ µµÁß °ø°³µÈ ´ÔÀÇ ¸ÞÀÏÀ» º¸°í º¸³»µå¸®´Â ±¤°íÀÔ´Ï´Ù.
°áÄÚ,¸ÞÀÏÁÖ¼ÒÀÌ¿Ü ´Ô¿¡ ´ëÇÑ ¾î¶² Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù.¸Í¼¼ÄÚ...


¿À´Ãµµ Áñ°Ì°í ÇູÇÑ ÇÏ·ç µÇ¼¼¿ä~~~~

 

À̸ÞÀÏÀº ¹ß½ÅÀü¿ëÀ̹ǷΠ¼ö½ÅÀÌ ºÒ°¡ÇÕ´Ï´Ù.Á˼ÛÇÕ´Ï´Ù.

 

¹Ýµå½Ã ¾Æ·¡ÀÇ ¸ÞÀÏ·Î º¸³»Áֽñ⠹ٶø´Ï´Ù. °Åµì Á˼ÛÇÕ´Ï´Ù.

 

[¼ö½Å°ÅºÎ¸ÞÀϺ¸³»±â] 

 

 

_______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 12 15:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04514 for ; Tue, 12 Mar 2002 15:01:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06694 for enum-archive@odin.ietf.org; Tue, 12 Mar 2002 15:01:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05308; Tue, 12 Mar 2002 14:52:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03990 for ; Fri, 1 Mar 2002 17:28:36 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03902 for ; Fri, 1 Mar 2002 17:28:33 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GSB00D01FQTUY@firewall.wcom.com> for enum@ietf.org; Fri, 1 Mar 2002 22:28:05 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GSB00BIDFQSNU@firewall.wcom.com> for enum@ietf.org; Fri, 01 Mar 2002 22:28:05 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GSB00901FQPFS@dgismtp01.wcomnet.com> for enum@ietf.org; Fri, 01 Mar 2002 22:28:03 +0000 (GMT) Received: from rfreilich1 ([166.35.147.76]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GSB00853FQDLP@dgismtp01.wcomnet.com> for enum@ietf.org; Fri, 01 Mar 2002 22:27:50 +0000 (GMT) Date: Fri, 01 Mar 2002 16:15:14 -0600 From: Rob Freilich To: enum@ietf.org Reply-to: robert.freilich@wcom.com Message-id: <003e01c1c16e$90ee8a80$4c9323a6@wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/mixed; boundary="Boundary_(ID_aGsQPlP2WyuIbnnpRA73cg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Enum] FW: [SGA] VeriSign contribution to SG2 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_aGsQPlP2WyuIbnnpRA73cg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit All, Attached is a copy of a proposed contribution by VeriSign to the US Department of State related to ENUM in a multiple root environment. This contribution has raised a significant level of attention with the US National Committee process. In addition, VeriSign has indicated that they intend to present this contribution to the ITU Study Group 2 in the upcoming May '02 meeting. I though that the members of the IETF ENUM Working Group maybe interested in providing comments to the VeriSign contribution. Comments can be directed too: mailto:SGA@ALMSNTSA.LMLIST.STATE.GOV Regards, Rob Freilich -----Original Message----- From: SGA List for EB/CIP/MA [mailto:SGA@ALMSNTSA.LMLIST.STATE.GOV]On Behalf Of Tony Rutkowski Sent: Friday, March 01, 2002 7:46 AM To: SGA@ALMSNTSA.LMLIST.STATE.GOV Subject: [SGA] VeriSign contribution to SG2 Hi Jamie, Marian, Please find attached VeriSign's regular contribution to SG2. The deadline for regular contributions is 7 March, so this must be conveyed to the TSB next week. We expect this may also be useful in your deliberations leading up to the next SG2 meeting. In light of the recent regular contributions on DNS based services and ENUM submitted by US domestic parties, we believe it appropriate to convey a contribution that supports US pro-competitive policies and providers in this sector, as well as clarifies certain technical provisioning aspects based on existing factual information. Describing DNS based RBL services as one of an array of rapidly growing and evolving market driven database services similar to ENUM and using DNS protocols, provides a compelling example and model. Some will doubtless argue distinctions, but the parallels are very close and quite compelling. It seems also worth supporting and advancing in global forums, the highly successful FCC policies and cooperation within the U.S. telecom industry in establishing an open, secure Intelligent Network infrastructure of network element databases among telecommunications carriers as constituting the "authoritative" E.164 namespace - thereby allowing Internet (or any other) computer network based technologies and services emulating that authoritative namespace to evolve substantially unfettered in the marketplace. best regards, Tony Rutkowski --Boundary_(ID_aGsQPlP2WyuIbnnpRA73cg) Content-type: application/zip; name=verisign_ww9.zip Content-disposition: attachment; filename=verisign_ww9.zip Content-Transfer-Encoding: base64 UEsDBBQAAAAIAOhiXCx7D8hNhLMAAABqAQAQAAAAdmVyaXNpZ25fd3c5LmRvY+xbbYxc1Xm+66/1 Gg8YbJxgiHLkGLMLM2N7WQxswGJ2d3Y91DuzzMxaCVCROzNnZq73zr3D/dj1oqoSxY2q9EuVIrel UqRKQNWqIqFQiQopDRJCLYma/EKR2rRxpeZPSYnUFlWViPu87znnzp3ZXWjaP2nFsY7v3nvPPec9 z/v9nt3vfffmH/7hK8euWSPtnLXb+un1CWtf6tku9NPm5pBlTeMyhv7T69ev06NT6E+iX/+k/Z9p 7734plV8ZGKPZf3HLX+ZcBYNjH8YDL3RalxqXHruR8/9yNrSJvYcte5dtKxrvzHG/YmT6vk/jIzb pa/Xr9+UPNvpZ9N+jf9/59NWck3/TO3YbVuvR1IzrOjnl+/Zen0A12/gegeu38H1odT4KwXLEhDr I1nLOor7u/X1kax6P3r9bG7765GzaudHz6r79JU0pYjrl/Za1oufV9e9WPcEnr8wZ1lVfPjBgmX9 De6n8PxWa2sz+/7JmW1eot0OOsDWhB4zzlxp3nQbxdfszzS6/1tczxUUHu/dq56PXmn+lp7ngdQ8 hl5zf0TjYZr5/mdtZj9mPprn02Nb59tzn7ruAh20RUPP/7SZ+cx+9uN6ENeVX/6L53/pW2+OmXFG 7uowl3+a+s607n3qeb2grOsVzRcz7q2iHoj9vJ66H50nr+V/7jbS2q38HL2OtmQd3Qw+tA7xk+Ro Frv6Yt6yfmgN8H0Qwvwarj/GdbdR9Y9oO+mLkUdzNfpI19YBrPE50Dg+mOd1rD8zMo4ajaO2yxpL ePBJ+6R90rZrY+Olcr1YLRfqpUq5cEHUixeK85Xl5dVyaZ6fCfxUKY+jbXl1Q61eKC8Uqgulx9XQ WnG+XqlmavXVhS+KlWK1VFkQ06dPnxE5usyM42sxnfO8XDGzKBtBbAeb9GI6UwmcjuPZ7qwoeh3X Cbvj45nDorg8V1wQxadjO3J8Lz8txJGxW4tifPyxWIb0aDKcmp04I06K6VPTmYxed6laWV0R0+Kq mK+U69XS3CrTVi7TiMpqdb549+zERRBXKy2Vs6JUns9k6qX6heLsRP18USyUa6I6dwF7qV4szRcx TaEsil8o1eql8pKoVuZWa3XcF5ZXLhTFYqUqiouL2HbpYlGU6NlysVxXaFQWxfLqhXqJBi5Ulgsl zMwflFeXM5mnVMtkCo0wCuxmlCm4UdePO10RdWUghY0eOh3PaTtN24uEKzt2c1ME0g59LxRtPxC2 CP1c03Zd2cJQICdFyYtk4MmI9xH4fpTFdE4ounYoPB9fu3Ld9ppSRD4Tkhdi2fY2Rcvv2Q6mxVIi jPt9P4hEJJtdz6H5sazfiENM5tpBR+ZCPJTCaUkvAnkywLyh78bEExHKYN1pylD0A38dQ1qi6ff6 MnIiZ11iJscTWMPvS0/07GBNRn3XBj20nRA76vme3/dpRdmJXTvC941N4bEI2K7AK6e5CaoLnpCX mxJ7Bzbyst3rgyK/DeKbXQJGUSGkt+4EvtdTo5wwCrHzls1kAGeCsUefpXHLNewQy5IUTFal7eYi pyfFnOs31wCyuIBZpgbbJEY0fS8KfNel17G3AXbh+54MQ7sjQxBbipgBdhQFTiOO8FXo9BxgadgA SFqiJbF5EgYawMSB107DcZ1okwfIdls2CUYPUxPVBkiGOgRCREAaVQJbBHbfaQHRZtf2OjQiBUo+ cyY/USLqW3GTMM5clIFTg9xl8eW6hIamWY7VQB52jMVjF6SKrtPp5ux1G7vRlA6JoIEpa8QhVPLI iBEWJDIAoVRfzdVFbWlaoYURDqbxSHzwtivdvmiCEKe9qfCCILNs+H2aIdT4hU3MKUXX3xjwZwvS 0KsESKCSiKmWiDR8LCr5zHR+oo43vB+lZqRZIDKM5Y6alaFPBliwfomyDUmqbYaR7IlJzDdFOwUX Ha8d2GA9eBCT3mvpZfw3QB3ojEkmSdgUwcRHW7Qgi0qksH07sklysQs7EtBaf4Nw7kGooD89Qt4X QMcOQ7/pMHobTtSl5RMyVwI/8pu+KyZLK1PCbrWg2EqA7wqZkLAPA0RQ911/k7WKkMdSwgexXXqn VyYszT7UwuojvQsbqhyR/WDz0gh8+jIIoJkQrZ7d7/MGiatOAF75AAIPofxsCUBTze+xwmOdUFnL ZP5Ew1tgcRAqzmkLh83Uwap+1/ek8OJeA9bLLDdJfGOW0Mtkbk9uDK+dWQkciIkDwmkrDbu5tmEH ytBhiNYDBpdtDs2tuZjQGLIQQC8clnYg6wR2w2WsiNDIZt1V8pYVG7B0uTXP3/CU7GEU5KApabfd gN0GBhsBakEtoagBNN4FE+gHAcqIyfRlR/IEChHxDDYbpqRKKYFCBLsb4A8hhbVUzhgokhpDf3mv ZIuMbmhHZRyQVhBoPaEA0Qx9Ca4oAhRItGJiwmgun1wgpMpfi/spTWbTHiq/lVkEbYncQjkCYMkK nhgaAsRx3cT+yXXfXTdilVZzeRlmzSFpBlw9aXtsXOOQ0RgRFtaitOj2fTCLd6OFzRCl3YghnyGT 4rgdw80HTmST/TkuivkzZ2fYf8YBSAHWftAKWZ41LKBNIUykQMTgo4PAIUpoH/iS/TABU5bRhh+s iaIraTOhFmGmCM6pQ8PMGLLhjHKtdr/QlCqRZEJhQUKJG7gz11kjycUO2YFIvCfbpkOUHtyAQ743 kXSiKgFoFA3mUMJR5U6U12zJIIGwQdiTj+v50JpwG9MMIrCTstLfhOPEJpIoPV4C2jwhRiKu8S8V 5hhUP9Tj02PtoG+bwfOYxUaoq4ncZnTTM2NrUdx3sgJT7ziYpFSPLsu4FsEjDY1VANDwoN2cfvDM 2fQXFeZU2KNQD9e+hP12nWeAp1Jexl5tcJPsL0xWk6IPNlH8Epj3bVqNbFYASGilIVHUkkjisK1X acimHbN3MayH12vGQUBS5VD4xQqk3DEEb2BlNZcm6+UpkqJVhLQUdVWNzJe8FplWSOTkarU0JRqO x4ZIw7eN9GaF9iABC09PkmQ6YY8jiWGBY8uQz9ybnziPSEUAcjZi5KjJQjF+mRKvBBuHoMfbTF4M RcPd0c/TNtKAlFL2LcuRXgwFSg5ZXeNIbNGOPY7AOIolEwntgfACDXKZNtngcBaxDTMzWDcGoEkx IwBi5ElFKZmAOYMyNmESQ78dwTnBhWCgx1EPrd3Ap3BJUTer9JV0it25Nhk7rhCmFazj+o2Ujo+E MUkoZ7uhz/gpB0hhHa3kaYuj/J30CKUsJQAOtmosiYG/T9tio6GsXgsKgw8cxrpobM8WJiU8Bm1N N25JZIXLWVGpLmVFuVjPiqXKxaxYLl3IIrer4L5QXSlQVpgrLCxU8aZQupArIOkr5vmbQuVCnmcg KpZL89VKrbJYp0ejZOSwzS16EW32dUKliRRnTmdPnz6dSqBCegX8gXqLV4ELhFiTOPbgWXM7jQxM vuDKPMeetJOBKJOzNhFkSKET9IlFbAfmJcBfJeeNyASB/QrIVAZaR4bi6RiSZnxbwKvAKjge3Xip DJI8jGNcIKKwSCWtrDOQuMR3GGlVSQfW1FTorAEmDDIQUzivgxfajop3BwFaYqocFXw0pKQIOx2/ 0tsEiU0ESKyx/gZtz4RkYYzM3DZuHsrpYpxw2oSHaMUNx4+hDN3N4fCFLUJb+TljIZp2X+m8o/PF ftwAsUlssTnwiMpoYQ/DtnngpJWV5ni+T7GLp/251D4fCoREncJt2htlQoSfSqMiIxUKvIRr7MeN 4VPLpOE020iIxEoBJ5IUGmBWn9yDIVwTqIIlE0tE5JgMQUyg8kq+5yapeIoylf8hLCMaGhT/Eh9S dYSstgLgZsiRTiqdMHGoCszaMLgkzldTwjNchaBNU4TsQFrZbGU+3nSDw2nLMjSXw5Gn8tFkj6lE 0aG0S+UHwYAXPZ9zPThRMs8uYGwl9g+j0rULLEgysF0kt8Xoko4xNUY2dHwUkD8j4fVoXyTUnRje AlNK8VilZqhqgj3gVKAwHnIGIHc9dslu6EwFhhy7zPntnEn1kGUgHSLGL7JqUgKla1ZZwoASGcZC r0IucJ3yBbCyTVaDiwWsPqPGs4ekjj9vyEHWbrKfxIxddIIoBvIrNG8kDUyhmLy4Ug6nkEp1HeQR NBmxZp0y4W2qGAnjEDzM5CeoGJTIv805+zY0qng1U+CEh7So4ZOsklSQIeKYS88P8IyFha7IgIxJ y2m3leFcQwjEUdSOUUdCTCrNTSd0FDUmSSylsICapdUOSF0xDKrTB6zS8L0V2JTcNUUn8DeQlVEK ZGpZRUzsJhUtManKClylA8VapLHD2kpheYqqc6QDWADJQXY0dGcoYLw2KK6xTQ6O1ThPG5C1Zads 51MlUV4+lD2SRV3LJNHXJQ+IQ0+7B5mKzEg9dyjq6WAOrFbZZYrnWSG5FoMws+W322zhhyFpQMzI zxhdUZtPUhfkddJZN9shsVc8VWWcNvQ3ZXx14mtjGx2wjg3WDMJiaD42htSFvTz5Y+2HVW2nJWnP sJscLzR0BYHNoMq3bS4zdDyu/RxvgBlriCddZKGDSg8hqNdX3hsunjCjVYwvVIVfcussOuCK3o2q ohndUNNoM8IlGWhtg0MJKt3KltIIykoIUGip20rl2xQnpeOifCrrhGLFJAuXkwzE2DjWmiFt3ej6 KoQlCwkMBhXeEQlT5baReiEFsRT+ImggESVy1revC6h6gb3lTVKL2cwqP6gmGeFfUopLHg6+G6Yh Xf8rF1bqVV000LNrIEbmSkkBtJVLOkovlfwOQnU2PbTMcdr9cdagNKEqtuQIgGy1MjBOmC7yD9f1 m8yhVhKU9SiB0WZpHTGyr1iWVqeBmkCvYsel2FQZKYeTfSpVh9lRc5oUYpKSxMBF61SbzxIGVjYl JgP5UVBwyrKF9g4VOZVDtmn7FM/BAga2ytEor5aXZdB0WBQuxcjCkNqyZ1AFas+HfqqKBwlIKp5N fDTwHpQryaYOV4zyxzMFPG6yj3O8XMy2LYK69m1PuiqpHFS0F50ORT9nstiD62+ozSEHA1Uh18nT 1d+aURnFjDRJksbAVfNqrmxyRE7s4MKlbG2LpWIRRFPZ94GHH4QWcGqetv5GLI0DYKlXwqXPd7JJ NEKrmLOIu8DeDQ/WpsnFTvWSxJZTf47kuzSg7QR0gtX2qT6tRAHBA2KfgUAMjAjNxvLiQy2BYzGm QlxC9mqtkM+MZQy6eVFQh4YGwBpjRHxfYa7UmljIAx2RmFwCIDaypGVgjPxT3WXFhaiVn6JKhMl0 ebfa3qlSnTZNKo8w5xlDoOsMREdfCWzbCro6YYwbl9gW+FsOG12E98NpCzw9pJYileFS8JC3Dwd1 +dRaJvse1HuVQSJJIOPi6PM9dZ5ju6MVUXXMpmNGHQqQXihHZA7MOMskxqoYL02CdohS8W+E/mR9 d9OgrqrWG9rSbXs6xOc25HIhueTDkuMLgtvudAKASEUb9kBde51OKNahhX1Ml67hJX5W1TbIKHh8 pqorLl2nr3esMCZa2FVp3wcMyVARCal9MWLbMv6uQVXAJ8mHwBjPH9L5VL9Ldgrd0zXgQQWYLaLB YlBtN4nv0MHiwXmfmB6mDxXpiAJBzXBiT8IQOuokELvMPFH/RWLRcGTtD452ddGIskhPOqwZMC1K vgYHU2GShhOoQwpERPMxl87dNvXryO9D8sGilAXOUrZEwEeBo32m5qLJy9S3DjKrdZWsDweslGiw MzMZoGTzryhzyfLyV8QBWJUsDAb5BKevts0h3JIqs82rwJa/TBPIZ6dZKkK3NsUSMom+mIZhkZ5c t7NiJndmBvaoz7+JgVwEUkXnT/PpA9iF/MzZvKnqf3QNRx9Bcthv3FgiThRjJmgmT5NDSyMm2vBv bpfwbI3O2HOOFli1BQhkUozIahtjwAWeVFmWUgVG+pCHYxY2Qn76iC+Z9iqrzNXhs/inYwe6xakn ucwkdcUgWxfpBpaOw1gqNaXrAjtER1SUjftUCWOSUuEFMGtISs55kO2lVN8WyFm5KJIcY5tyCDtO WmNHrWT/Dz8Uu62BVNoqb2VGqcO1TDVJxjMLcdQkfp4Uy815rOMiRssOgoaFwG5HOmOv0nnfghbL h7pR1J89dUqdP+YdGbXzftA55ZgCfYu+DE/xJddSq+QkguYcnRvmlHjnTp/JR5ejc1nIr1iUDf6F oXym1rd7XcRkYnL1F1TWNJUsuLGxkQ/1e1rxXKZCPKiS5IdI+ZD2UNYjHicRmKxU5x6fwjS1wnbz gA3P6DmqC3NUAxaTC9IjHm4/vNVQwykTbvp9PsXZaXIiUo85l5kLkOpHPQ4KSl4zKybLkvTItUkz tvm6kXxAZ1znROai049dRENV+xk6S6FjFXv0w4De5ZVrBbsR+fPiFIuIQoOCyRWq8XpsFswvKiwX VmrbQ0Sr52z6Tu36qUFL/zx4mMmJw2KlsFQU4sm7xXKxulRcrFSXC3VxZOZWkbsh9StiGbZrT+KJ +v/09JPzT572vGJ+oTI/kclk7mYjhmBpdnwhQAjmRVxLheZX42jN3wjXnPG6dGcn7jkj7j99r3hw 5gExc+/p+zIc3s4KJIR62CPrdGAC/8SnhePjmPxjV0f7+F+v+/lv+yxrbL9l3YU+iT6Ffjd6Hd1F 76FvoF9G/1X0L6P/Lvrvof8++vPof4D+MvrX0b+B/gr6n6G/iv7n6N9B/xf0X5mwrF9H/+wNlnUC /U70B9F3HbSsW9A/g95Fd9D/9Z//6dr3v/vXb73x6huvvnzt+9de+tpvPvvS+trXrr2Mf51m59rL T117ytp3tPvbD/+9Rdd/v/x1vs58FivcerT72FzLum//s/OPTlq984f2hOjppyeSp0d3X1rOPv35 A/vH1Ovi+b+7vrp/zBIjz/Hs4v6x3nlrj4ceY8SN6oWZyLpp9yVCNBk+kayXjDxwMES3bk7emEd6 7Oz+Zw+on+YfPWJZh5Jxs0T0sS1P7uA90xPrgCEfHL1xMAfffypNmXlKm7yT+L9rhPf3aP4T79+n v/B5b49lzbyTsd4/hJujhy1rpbbL+gHdhGDV5W/usp414nRC7rGCtHwF9EcQ9M3Bf9tlSUtP0F36 b/ym+M/WoI1HT4zddqW++/aTK587MXbqyov7Sm36FfCbLOvwCzu+tZ6wrLXWNw/zgE+dGFNPd111 rd0zY/vfXbR2f/X6F/Yu3fY7J7+07629W5bd9/7hrc8e3WIajnyAWY+9S38gcN3024dv7xi+/czw 7cy7+6yxA7tdy/5gt2W1Z8ZugdK0fmLR3v5kp70dMmN22vs48f+JvGXNnrKsh9A//PDDUdI/af8v 25491tjY7p627V8esemvof/ASmn40M230ze+mfH13zpg2eklnqBh/wldcF/fv5WA/0XbxxKtZThz 1sq8vWds/Jh1snUQT1bepsWu049Kt88d+XjdFj+vur2j7h7Hzt++2dr7vV3Hdv/Rnpl9b6q/jfmI 7+47Yd1/wnrghHX+hKWx2/ea9tHvoH9b++r30H+sffZeeNN96JfRN9GfnRj48b9KAPjHCetbxOvn 71Qi8caON6+kb/54x5uX0jcvDN/s2uHNV3e8eS59s2079DDL0Ff2WjddsaybrxCC3bH/Yu89AKJY mkbR2Rlyjip5USQHRSVKBgmSBARRRHKQKEtGEFTMgAEEJBlAxayogDlgIqqAAQwYQUwoCoIor2Zm Fxb1+Pmdc+599933jxbT06Gqurq6qnpCr7E84glJr5VEBUyO8kMdRqG3HAWhQAUDBFpwaDFqgkbi JZzMGVAB8lhHVJYDT7FDCvAaQyGiRXijHzQWcUEJreW4I45QsocD+BC223w/9oGuhvg3f6B+xEmS PEmRp7Fqtg5wInz4ODLir8mg2QsAtMBhngLXoQ1q2AWcsIkiyN3xEFVJQB0pBJkLMEEGQQ5SEWTa RPKLq5kgXUOAjQALFBEkECAb4B24mBHRP2Qeh3YEG71oHlvCxnzBwnzBdIy5aP7Lkn+3zV9fNP7l xR8i+PmAnoPmgL5wSCCscgibHEMric+u/6PO/rJGPMJcYzwea1NhvGUB5AAU6WNPBcs3ESAToBhg PuhBKEA4QAQADSAWIBEgC2AzwBYRUl9wXbkH8BkAnQC4AWYBWAPwiAETAOYACwH8AZYAbATYA9AM cA/gG/6VJsS7cgAGABYAVgCLAHYDVAHUArQAdAEIg26KSJA6iuuiwQ/66EHXyQwliJSVAbcqgkxS JWOfoS/wr6erp6PnHv7vJv53qP56zfWa+pr66yP/LtRfOANQfwb+XR86PnR4aN/hoTI4kYNFj+C1 ONIgxaa0D4/RR1cAsDbgFmVaGzCtWLzGsxHnfvQcce6lfiTOzRHCRCS/UWYhrBw4YY3ByYJf4ysc 5ut1rEFjrmMWbx1zTa486NdsZDlj1WCMz1FekMd41VGZVAG8BFBWQxB3gHUA9QDsICsHdVJmkQBL AAoACgFOAZwGOANwDeAzsx73/tnF2/9NF13MF3/Nzpgv3seUPPnLkgaWYdJarZmBIefwaboJJrFX 7a/dDh/uwrlYRvw33WuTNl8EL+QdKaTsZruAlxMxDmUkxqEgrFRikpvCZKPIMtkMBOIZ/pXHYa4f J+0FWHq+lQ0o/0pJdCGcPeGMiC6gjyMNIBpgHcB6gA0AGUxjew7gKj6uAONgnSAOoKNBfv2Lrx3w vQKGvvR86ens+fL4S9uX2/B36Msve/0/x395/DiHf3FfgQdKeFjw+wqazjcRppsUP96TYNwtgHO5 nQkihM/VDvq4imqQYzseYAKA2C/GWZ++TiTuC0jykW75MX7RIfCLixWMPvQsZUXSGE6+gxv904ul zBeJzFL5w4tfHYCSedZQ6euEHfN+t04YYukR3jMZYQti/Qkf2ye+n/MqBX/M+vfXCQI/2Igr6Fgb 8mO5oWTamHKEdyZ97g7+yOz/HP/3HqM+gjIV4ZyCcE2hiExRlnfkRGSOrFCnHrlkInskmmUiwKSN K1nlACYfAbNwZCo6AeA/4/+f4/8zB37f05zY3wM/uMaUqbDuYK3CKrCfW409+BGWHlc4H2Ph6sHD Egq+2gRUvgh3jxwkWUxwW8NGwTXHiILfvUmjgHEUOE/hQWSQYcjhQISRiR/wvabOA7VUyBHoYSGR p2oi7D0iwCXGEhk/yBImsGPms1KW8L1Xh6YPIz1CZGhjTlTdweklK9HTBXk/1vQA77b2y/Bw/7fh YerQ8HAHNMq8zYNE9fMiJ6E+8j2+7aA7Z3SOxbFD9qkC1HXcBQeOWcbKbt9+jIWNg4Pl2JEIb8FL 49jWhLKtMqEe42hau7dquw6XctVE5Ylc6PLrqVU92SbeE8zHudcMzY15ta37XK5uhP60zpkpjQP2 /QcPfd83+P7QvndeVEHqueDJqUKOtanfVcoVJfpXuAtVeVZX2Wy69mx20OHsqRu3h8nxGZtfaECC dtJsQmYvsdfXE8qRqNJ6zRb2+mruyskX+Xe71uz40r35whN24SLu4aHxRRL9y+av63/LeiI+7NP5 xrRh/8rcygX8ntcmvo4UGH9/vU7zI9MtobPFw77eEiiw/PZ2V7a3ttOi0w4ftvQ9qzp/sNYsbLZ0 2OleP/3swHalM/cyOy3Dlnl6ne6xbbd9MfcLhXvm7e9Fq7ofXKydOq96VdvjZqsCE98wLruTol0m Sazj7x2OLEuWKOmNPOexoHM4wj84xT/GK+bCMT0dJQe2ry+qvSrOiMxUi2DjfrHLa/lSQb/aox2e 1SItubfjV7RcuvAoQyGULcW7twc7jS7qK9bJ+r7ycPvSB97sT++eNCg++lmwdKarCJd4XTl17jk+ thvvvPaF8m69LnFx/n2B0E0xFykJnmFG75O9qs+Jzvissg+pn3TliXKW6BOPqZuUhGTy5SdPmlbm 4ncoO1N1Y811HykVkTruyZd65y47RDVSvDLT7lCPX/WBXvWPE/ivxSQXL9S3+NBiLyk+59inMmXN 9Zv91K7USfskFa9727D0yu6eCK2CG41ek7KWiN2/Luo//u6W91UnCp9JP5LobLW2z9UYMLzfaOeH 3d1oOeCaf9V/8pbZVlwrHtTvLJzV52SdYPK2fofNZuuYUrET2SzdT58s5Qz0P89mlDAkKZm65aJ+ 5MR49Lt0fXrFRY4valbp8aGI6BGe6TW029L8tchSy48frJUuJRxjldn4furDpGdn9DIxPwn7TTOq 5r182quJGmUf+pIx/Vqdk1SdmZAWeuFQbQE2fjmqs+dkCucjp69fL7Itw4fnce27HpXTrOE1Era6 qr42vkrOaMbUCWn7TaY6RnKuW0F7tLlC8aLSmssVjkIaphO/s73YuGPm8mrR2Xk289p0iiMb+3Uz nwrdXanygAMNx2qKRF+t2zGYtLw28JJY4+remdLqe98sz1zoWNS7tLK24IKDB7t9pCj/NdFGpQn2 aToiN4MTVmXWag06Zd42lB102ddzLVG9craMhfr7jaxnLIufYsfWZl3nM1RaPbB56PoSXKiC6rwl 026sXmrv+UTmxZLWgqbVfpLv3TLP1p5w0+23Xsl3feqgzcn9ZztfZatur9O0qUtb0Tu5MMdg+cKM y2hoMNeR3Qkcwg0zz/Bwf1BUvezgPSN8+fglM86s6PXWfnkpLo8z9+ik7DJ5x5J9pgo2nx7pHD51 y+5m3uLLdtnomodPWPjSsDx2macT43lL0jp71OIljVaIxvNwfeBSdV0w+8gp91Vq9SVTWi8PCDUO GC5PDzBSny7zzOylVL324Q6/inHX8hQij7infzszOfCD9ZlFL9wDDPi0Izrm9aZ1J6+bVm9SGJb5 dOaz+Eu6j30Tcq+xfGeLGgiccNnNWyBXu58W1pzpbJv8zmezzmW5qG3lV/q3iYT7nIqc0ZxVl3dx w5Tly5ZvWsqyqscTZJsZWHIzSfrxrVlVpstWyaVIdyu/ezl+h8J5rhUDCyMa3Bs6srZLRKzSOmMd 4zn3oduOPM/VvsdZY2/xEU2fla9fMsHuoEhlyDDbtKIJ3433PHH4xHtgj8GjbRWn1n5HHTYVqw2y vtw8tbkrYFp+t+K7lhRLomH4HsmUMu+XRsEbBvKu5ruJWLQNT+KdGyIG7fRWJ267ku3v2uzVKrb7 1OX6yrbzxvkplVKSbjrFos1hV2XT9hfYeNRNb+lt3fp62/RDEWzKV5UCut6zV5f3Few/UJ05Qzvu 1fvBB/dcOvRtrcO9DjkuBJL2J62v+ry+KSBh5VufLeJBLYrc8uny++cUVcqym1xfJHdfvqbD+32V hWPmo1V3Tu2f1CVyoJTjzXa59xm93b77/LbOUZq2Ut2UNjjO5pbrl/0B+f2RmQEHQ/PS1byqXF++ i7d9d6myVFA9uy1PbUZLrN3nHQH1uZHHGs5+kelT9whZ8CTkJOu5iIKn4e0T+Ntnxdc/2lF59Xne lflt5xf6n/iw8eD6kja2Kotri+Z82xM228NbysGq0mJfmOQhRxqtuK1gS0vd0sOdH2dvC+q7rVpR JK31/rZNxdqteWrTm5aaNtcbiofwOS+jZd+uf7y3SNcso8Fi35MnVYeaKl48qlDfaL3iwGWdxAuN O5aeLpQ+2TRnU/IKz5Ptr5KTUg0rHzdPTdqm3q6SrTgrIs2/uuzBpYdlyvy5bYkldi9Fb2cv2qw/ MOlgnmVphuv901UbAsr0bm57n+ZayKkWzzX95eSbqYtS558R3Rf0SK1p/HYRhcHWqrkWe0uVrgQ+ mfVdSPnjV8eiu6ZhnqU0+YtStbfmVW9TDHR+Eb5TS7z84Kr5H15/TCy/oVKm2bS5ID5b7uO37kAJ pd1tUfYRZUZCbZejb7/bbRbLHVb5OnjXQrume1eOP2jcjhaYOYfK1H6IfDyx0Dmes2CemdqbjJY2 111JoZoxt3NdtdvTEtuls1+p6a5f+Dkmjt+/fdzgvv2WBmH+g0Vqs6XezA0N1PCSeB1vesrIOeZZ pEruNDXdVMOlpq8fp3zZ5bpxxhDPmYvc3gqdl9wesGe+Tn4/0y3d56yau+HkJZuaPif37j5Hc519 32qTXPD5wlobS/v9B1Y+Yg+55B7Obqk7O8IloUfaCH0dL6X6ImxKzvnlqoa7RHnqw5bu59ybthqM Sr+/xVltBV//ZorEtlDbqQn3bqlemV5BaW6QrtfaE5mqZIfZHbvqvO3Oco+M8y/m82vNWUBbsy3e odBykbNE77gYrSyniGlzYpIWb5BvtirSt9GNqleX9Pa8arJbYFq9+RvvQe+k5nEFBXrz6h5sj4vo tNRJ+pzbwZq15WJg4msj9tYp1moPvdl8A89K8E3XeMpydk6D1vmnE51XbC04dLz2eTBbwrqt2xyC 0wLyX82PiLKdWxykPiftvl1dfbNLqZ5D+Ttx5wzXgtlVt5furjx2IvHytoxJduP6ph/ssU+2c5ly 5aK/zr73BxZenC3dmBvpelKIff5qj8LQ00+FGk4tO+kfuefb5C+nDYTkur+ezQ/lPPaidbuxJ8+d uraOjeceHq6dbZIcb9CFtS93x+11+0Wzns7tGjOlpq9s3ddb1W0oeqZ0kObve9PBkEf8xsXtpYVc KUeWVNlVfJ92clJj5a4lBxauSp5ZqPHkwJsFh5T59D+lny3mbysbWlVUk3W/eGazPC0zozO6oazo Tfs2Qa7yfCmTjFCJxaERN1WXoO1t/UcL+q8mnBB7X2HkQ1uQKb7XPqz17EP1ssTYiu5h47j7LO8W F/RQ23N730z3XCzz7HMf76PA/g8afTpuQuyds3VUaAo3nni+858VqTKtRCU/8PO4oeKAD9iQ1tD1 us8vtNkmLpWpsVQ2NX1+IHvd0qcVFheEXwS+e3N2iee3WqnpBc8HVZ08Y8KdHpZa+SuKvtquUfdh MMqD9XHPuC95WZdmqx5ZGbLt6NIs6xeqy7ZJFWoMh/uzsrIO+/i/i1gT86zzcl2VSPFFy46pFjt8 zj01uSJ3RVFKYk2dl6T9HQlbo+SSE3MeLu7Z/Sgz9onYAB//DYshY6GgoiAeG5VtSgZBx8/ZN08u ebfFv2XeovWV1oIPJ/I76w4Y5Nw8uv/keNH2pFebw2Z1hiXrhejfuhurmOwTGLIwcfmdLmmjnZ8X Z541F35rN7Ne69m5vpR3Pgo9D09uLOi+v883juaftHlL6FK5R54dUX2KbseTqnc/rL/Rxxru79aT HKsVV8kfuarBMdO+cP/MgZN6GkdexKf7n6C5hgzNSbz23fS9e0fYyZnvj5+IP9wtdfztwJq3Ddfe TjEM0Z/Wtspj/ubofvU5ZgOr3m092OJ85/YUd3Nn/4lqm3kSbdpuvXZaHWvtPmifcmX9RzfbVIN5 cyOWt3ZMdF2ts4+i7axWtfBxWZyTwRepyZepi/e9v9O30fbVoKvUwYhW90hJt0uGHoffP3DocB/y 7C+bsPuJWkDeObvTvhENc7bY8np42zx7/dIn8vrQuDdTN3ntV0o7vC3qS2nAk9UNb3WuTL914LGr iombrZbYvEcbXIqVBh+pXTAYLE4RLm6R2Nc+vCxu8/evizYNd1rve+NbymN7jU9zXJKSk3+apUZ+ 5ork08btr6Slng8eaO25s5kqxb7GTL5vo/fisDOaDv0TVLeIVOuYyz+lXkH49yQlb43o2yrcEpU1 ga3mXtKFmrw3g6otn8fVhpzxNzHMdLozZwpqaTqOr+dNYy3LG77qe7zyKh9Fuc8eCtmVrK1d+K3+ mq1/3YcN3AZRLls729PbXib5rfI7WHpsHHt+8a2p49kTIvWurz1x61wz57X5S6bY3D82c5evoZRf +YGCCIeQBW+mcl3S3d8a81hS+bWh/KsU8Ydu194dWDPRs1/dvr91b+baV6torvtfD2zYabkhOTUv T7WwYtv2Wxlps05cfZQhvnrudOn91w5MyDgfn2F2M77G60ghZ+KVtqDHDbyBRlOt3E66NHXlNbGU L1a6Uhl43CLr08YD1TzaUs0Gu3yLM5UMn1m0Bz1+5fH44a4Tla4Wvft8300WFtl1NGvDhZRtH9gU E4NirVZPFZ+6Zem4yEjBZxtZt5+f/Xre5u4He09pdxfKFRXslVyScldSMm6x1WN/jpjs6O6DXarC MxPrpog/beecfq+/yF5nTutWtrWXz7ZYnnLUfmVXXvzQ/cbt2gdZq0LmSisPNn6KPPXkQIVE2b7P Iu9Nsg0s/Hl9PnblvV4tfLm69vnNhl1pfYefJKod/zhO2Ux2bnprNkuWs6ji7dM3bBbzzC4XnWkb 5q0ekxrcovTSAssz/SzrMDWj+xJPa1F53DZ3vWVac1N1a+dYTTxUtCtsh2Xrxqg+H381p5Om/LcW lF3X06CFHX8ffemoq3l+7dZnYncTnu9Vbap8fVztI8f+wbBbVQ+3H+2eINXLdjA15Ez9iVvft97c 95jt7Jbwi3JNVVcnWftPPLRw11u2rCN9b/39Hx4IlZhprqUSm5gPSrGHlnzn0LeyDyG2n+9lFXmx x6byHzn4aNeCi/KhB+6EXE488PSg7v4SH9bkay7pD+dhhs1Hv80bz+eVrLP3i7hEzUbx23FWPcPC OeK9R9L6JC6I2X74yJKhrv1y8IlfBkvD7Dml8SqBx8fpy3nEjTvjOqDhFaGbJvVi850sjtgtQttW S52uiBq3ujZBUt3o2ZSBORHI6rnabXx9uKYeTpT8qrwgsCn+3q4KyWt3zhkceLsk65ysOy0nTPHz 5w2ZCYon+nLU22Z9tVcoPK/H87n+7InNZbMdaje+y1Z7+Ik7rtmgYa5tq2SRg9oMS+0VAy0c47oL oo6+fDbZxXpaad0GPvX1OlVrZi+PO7r5ajJvxvrEHkGt2zpBuwPPlxV/dU1UfsgZM0GOElAnWn9z oe3dnD5XnUV6s3XmtBUvWGdmFD6Zv2ehZkF7Hdc79aYlJ0OfH/2o3rSVPz5n5v74beOtBDvrnBpz UGnZhJnGq2irPr00rL2lv2qrbMLJIte1l+23qX0N3rDUwT2q+NTswsR5cwzCSqUtz75Xa2hZId5t rftZ0XSSS8SZwlKxj27zt/e6JugcipyYqF925Yjy1WK2x9f8nph/mtXNv8DAt3/CTpjllXp948Up p4OOd29IOzuYtMtyW8mzwSc191wPLpP43KJ39ay0rnLdhhu7fA/JZJ7QKsRuFHaKFeX4Na7cpxzy bFPnNQ8jyZAbhbtDvxn4zs36riwhvMUS8gologz8T606de7tu/tFV7bNFA9/8cRxawV1jv/aqWcj GxcbpJjutFp/1Eh27VR3nSVtW7hrdnA3bfkaf+74SyMbmmfph4E105+LLn41FZYNanWzy850u9xW dSpQmO0rfXjQt2xSllNm4QQu04+h++ZveDo1/0CxbYep2P7iDBd+9n3jv7U829uvu/mg9AYXB/m9 lgPd92emOI4rb3T6HF8dpZq1JL1CxTlGYWf8RBBIne+xSM3rVIPzz7LDao3ULJ4cEOm+N1Oas/nT pwzn56/fm0gHp2TCHPV/Nj2APTha9+rSLMkc/6vPb029y3+tTda/vTz02UzNEyWcBXNjr09qypLi UlvxpkUjxuru8wnaSZ/c7uflzdQ7Oe04z8c0zYWXv24zOKkkebqiymLa9VnSFI29VwLn9oXaahRW dO9bJhI8ta8r7MKNQ+9jZ9QtCGI/rNTMlnG5c8a7dZ88j66Z5s/Wnz1nSN+6037+E30b4bCI5sec yudN8+c/XF0nuE2Ovdz43E3xoXTXc01KUn1BL+6Z3J9v4sEaI3plh1HLy9C9uzt3aPan2ZxaZyMe kzMwp/zq+hexGb1+ZzuP3zzQsnWPtbJDa+FGhfw2vtbHvnMN3a8F7n0U2qpxM6E3+vvMFwlrmr13 B7wrN3wk+UAsuuvwInWJR64FBS6dM1qT3y5aejR+uOw75fMxI66UMc8rKFsRRDYWwYIoM+6wIhSs hhXOFBR7LwxnFMNseCfFIpQa1kmxFPS98KRYFHL0XLkZzzmIxxPj+wCRyh0Uwf4KB/EQAn8GEjCd 8r+Q/l/iYKY/+1f0KQz6t/lwerf5GDRGCTDKR3DhL8NsNfvrW6HLJ1L4urCuP7oVim/izLgVitFv hU5CuHvwRzksJjgK8pYn4yYniiCpPgh7jxDQZ2MbKvd36VG8LN9rofnoslHam2HknSl5k9OB2AV8 BycSLt3zEvJ+qrnW0d6Sl0sc55zX2srcCVDbQfo9B37j1as57jKcKDQnS1PkUKPkK7jgjLSikAzg 7+LgjwXwh8bEnv/4y2Q4i5wk/wg3Qu5ujb/8xkd0lNwoHn/Ihd9AxV+Uw3efxnnEdwcfj5C7bOOb MosDSCDkbutSANIAMgBUAFmEeJMNBET+jsBkOOPbyCsAKAIoASgD4JtoqwLgm0WrI+TO4t+gPr75 txa9Lb4bNL4ptjbAfIR4qIfoAugB6CPkLu8GCP7bBghiBGAMYAIAskRA9sRdZAuAWQCWAFYA1gA2 ALMBbAFwgdoDOAA4AswBAEEjzgAuAHMB8HvhbgDzANwRkjcG4Dx7Qt4iAC8AbwAfBL9XTu6y7Q8Q ABAIEAQQDIA/wQ0BCAUIAwgHwF+6jARYgiDE+9Y0gGiAGIBYgDiAeIAEhHwemgSwFCAZIAVgGUAq gvMeAf+iYSwsAG804MJb/PkxDmGlMH5LANcPNk7y+dAFsngWc90jWx8QO6PjG4df4CTzzEEC0WPf Gv2vDi4EHaGPH/+5BbnLvqQ7mXaD3keB5M3h7AvSC4MRCCck+WeHONDH58Z/Qx8/ptEl4wCjvxho +gJNR2IsQn/f8IdjHEKh4PMRp83yF3Uiu48TcmfIn7lsEcwQXZgxmgRowfz5Ydv8/3Dg9Bl9J34r ZPzP48+gzzgzt6eABEIJrf97x98Zf/xg/FIEBlK3Jmb/3ztw+rjNJF7H+UP6uABs6WkMLIoFWA6T 3zX4zcHzN/qP23pbuivDbRJKP/8d+4+3E0JGbdyP9h/P+1P7L0evL08//8/xv/6gjP48y986bEdS HEgsDPw0UJ4zoCgrfxEq4eHTfw6h/rsDp4rTpOCaiu0kuiNJlOCaTDojIsiiEC/EIRQUOk3kqFMm EDlTUQq9NjfKaMeDbmf1EsH1Wp6NH2w8LilS3y9Aai8AFQyIFSs5L/A6PIidd3SQS0IkmDIqBefg K5r6neRxI2nxUETAJRjfhtneP47qFBHmHY5Qnwsh5hwfcGdNzC6cLzUKOYM0uToo04m55+IfH43v UkGL7Eb2gWUNgb9exDkH/jLqJrPhdSPCia2BaP4xF4gajNo5REtRet1CHnxek5/XU/3DY/A6KhQS txdRk8TqhY1yQG6AxuCArLUPUiEjdQ0IDoitwYi9oZh5JXnxIrDhdRV4cGEHh4eM9oBllFbEmN5e +Lm3LFuYe0ulRYztrdeYukE8eN1Qb7y3+I7wzL3dR+/JL0YMxUfMOSHMJyIUifsi+ikO14JfjxiF OPdQSHupyXWa8k0IRzGEnKPnpGJkzreRHA+UzHk/kjOLlcz5PpLTwjJaB+8DrmlcCH3eIgidawGE /PTjDKG/FBSdSH64iyCtnoNxqe+EiGg6Eu1fpvNMBElk/RDH0DOSawry9yclBSw1xkX3fT/4ftwH 2AX7RkXguzqO/I4DVVN9CiE6c+eRPGIajf7QA/JJ99iSvyD40/HPDAouQRS5cUEQpNHlKoKIzCUj g+uVIrjNQClcFAxFERYKpNNc0DR/NC0eTYsmElQ0zQ9NC0bTaGhaJJoWgaaFE5c+aFooowKNSMQw csKIv+EEBiqZRn5ADNneaFos8TeYaOc9FiVJBy4TiMvgX+CI+DPm4D8FYp8IiHoj6ZHof3sIgfRw 7cP1lbSS//nA14wB9DRGp2sNUXfA6Kdkf3wI0eMffHb8KX18rcqIlS1gBRVDrEGCgTpYZFjdkVex fxSVUqH/zP70P7cgY081ehQ8FWI/b5DA342B+fDfOULIWfCn9Dcho7/2RCNUg1QyZuX0H9VPBN2a jKB5v15dfAeKrJSfQwjCgLY2tBaqSwhsyeVAVFQHDuE3RvJQMobEy/H1Kx5H4utUHPtGhPS+eQgZ g25HSF3Zi5Dx5BGE9Lf4r2ARvhghxxL/Dg239TcREvc9hLTN3igZ3DxnIWNOnNbor1tYh/uq061H IXnGRYLRceJnK3nyfJCXi6CL0On/6iwtQMbJeFyLb6Qz8jMyjG0x8V027PBdNggn/KtfsCHi4f/w GzaEHH79KzbEFGT8mAxxX+JPflDGnQY6VIMDJUeFD6J000RrcxOXeM+3yckbpO7GPFb9nPPFbO3T 6ZN32h07pp22mWPKDlHTA5dLhY7b+a1plE+jTFwWejE2PXRI9vAmp63CPutFDg+ZbeoIUCtTdg4/ +urr+tTX0YJ6m9tjSmtttU2r/JwVywsO7Dphd0W17VSw5H2RGy/6Cr/OiAt4V1Td+6j+TML7b2wO Le0J/cVJje8Lk5rOdj7Kn7bkyaV0jvECCGoM8V6aoEXHhTW1rEdTETJnCtpDO4JRERbImODP0tE5 y/30Rl4OhAJZHZ1eGN6IQp1Sy3GhKeNYrKwE2epC00U2EoNXtmBqiYT/W1MtEkdqyQpeonHqBcVJ iJF2bVt6KIkDMWKXoDMxZxaSEp59gvs+nYsUPi2iMYLu2oAMPVAMGX+MQuAwPpgSnvQ5reXzl6ui axNuOez2Kl4XOnF/u2PAWQ6P+/EeQRWSt4+5Vut9rhU0X5i3VfOS5IITwazjuBef809PFGhgOyIU zMN/deuxOOVgDvNZAmnzvxVeCHkyvey74N1X6UH7aTZJp944WM7OWDU9VT1GNGbng4VcURmT9l5a ZX7qY/dL1+n6+hIxTeMdlKx0y7Lvb+RJnj7tdFSj1rNd0iF1R/sMxSMsWq+aq0wpLqqLOrT0xcfM I5YextsF0ga/edRfqt+UrtjWtnSu2qvQRzUOm052mB6qviBxesFz86z6nv58f/EVxUVGE1wE0xNN jKuq059d27O+1fxZyy0+JUsP9s6SyQ9VuWdkXJ1BC01nu3vwofbHKzeO9nlfkzU/7nna71K8pnGD umr94ufBSF6RPK2GlYVLMOh204spFcnnJCwqaKvrEpX72y5xVeTNTV9XcnCdY/e+L4s0kZ3flQ8t OLNNyTz5C5eVdpzfqtVVLS6T0+/lZDhfuhGTy3KpvKqML+XqHBPlfT4eEnr1ButUaLkLlSLNp8+r PXCzzVHWR0pXtM+JS2+Zd/UWxxeL25XmK4e/Ut01V6YiW7M41Ch/2zbXZm/PRjsHu8nrVqa9Mb+N 1rMcYH2ro6fMxnu3cXaOF9/jm1NEJLVfdWo2blhtmjCHJSr2hV856/16TQuVK0HbJvDeU889pVkb He6/NaXy4BEJqSddzR81D8uc2CKydG2Ot+NDwfnbWAr28sy3fyhlEefQ0JZpb541uU05XrKh5Pnn zDWKe3KXtO8/frO5rFJvbcfjOwHRtt0bdrYHLpiZf8+wLsXDQmiIo+3Ou5MqunuF7YPzTxfcuhFd eF4kWr22+qRUKEdUV2VAmaxfsn+tWNbzJVE2al3xutozgqdKcx2TkNS0Fc07Uen2pmHTJEFe4W6u TackdysuVEE/f9Vtz78lEGg5/tkao8/R4n02jZoWQSuLpNxanV1O80sXGoVXT7s6h6d16dqb66Oj txZUDEbYP5wvetvm6e2GtS/6Ll6mbd1VkaLIJ73o/rxOzitLphbdqDnXsvh7h9zqnTYWRyTSbNvy 8rcU9Zr7FN0pDtnit/LVvfBxO4u3z3ZsfD9eVmDreDt9VodKZf+Z2y6fvmF4T68mKtzp88vjvQ3R j1Sv39D3UXQ/t0B1V3Djwcu3l5tV6E7sc61pNcqTTd1lG8PR8r5z5bRnYioLm7cUXyidXu+5Stt7 x/KlcUWmRqHf2z4EF5xga8ijTG38qBFaUaFyLShnnEel3pfVKza/ecel/2RNdJdT6Oatp+ptV4xf deW0R1nQXXcdw9WbT4u+ORZbslAqW2XRW6Njtw6LmD+56a80/l4sR5S/ecWrhAL1iJm2W42fSOnt K5zntHrFm+UL2RSywhvneC0PbOzLWVm0rBypF7gwZ7ceS3c/bbmb74LPoWfXWKyaMP1FFHWqYgLf 3p4lqPihyoGWrQ8m8BxeIPX9srH1Kd1p0nUDh2bauzxyz++V8Mme5nt9SodAvW9t27fYyeOjFgc1 vJuxh6qMLdwWNfeklOp8nq2Vrz5enbRKqPu1fq52Y9yWk85sz3neaJbS2sSVVJ9a32PlvrjC9siN 7V5nOaY/79ywpzfsbLbhmomBXov5Qq+MF/pw5MHq+KrLoTFbgy5blSzjPLzgsFObxcLlIXZSNd3u enq6FzdOOn7vRmfCBkm2Y7nr5D8c0xcbDM49Mzdy14O0Y7FZC6/Iq84aig8S3bSWxXzyDprjofqT K8xne3WFnMr+IDf00nVPsx376uUmfRcPHcxb8Vr55sbnjkPUQ7UXDly6YzwJSbs6JJmkJ1jwRj0f sZP80Ln9y6XgkPfqj/jW8u+arN+kyV+5bvnMh9RKW8WNCYkmc8dbyp1pkrBSOZmVsOoub2qs+TpF 7cCi9Ln7A191vSwR7XTQ6b6sP4CGVg9Y99/e3y/muq3F7tziVTKnV544/dZmu2ykUJ+EzOX5eevt b2xPeqBgY9K506MojH3N1paSw6+irvoGrXM30RIR4DqGSb62bb/V+Imr6dnzgNUNT95FS948wFf/ pPLTjo1ey3fKm11UzGNBd2WlLk3cMDHIbPjCDsNNOqYOJzK3W+16vCt7Je+hzqtszhxc4EKsqFTf wu77swyf3rk87dwkSs0RboqR9htxlmHj7Qs51mS0SRevCcsVWS4hdjN7U59LZHX6g+WTNdA1Cy7p jLinC4l/5GqQIclQ0k+xzBKjfKmec0fdDyPcFaWwciXp08CD5OfHvhBofyQ975Tal2rB4xFrWHBs VKO4V7fLjCXVPc9UVVXNCxkwW83HqumcMLVGTWW1CEsaQXu7BUfLq84vZznyS+c3FgykfrLes3rc glJqPju1oOCA0rgrdWqabjc+2cjnpD1JPGKaviL3abOpWbn5ObHaUx438xYbGqwaf/2MhL7H1uLZ yu+c6hU0V+kESXStsrhr8MzX7RPH/vpSv/PlK3etWqv6aNmyy2qrprvtKeEOXpZd29JSorvgTofn 6/20mLUeJ+UpSzUiOj+X+XHNSNvW0RCSkpTj2ScyvsNoj27YlMANr9XXmsx+PjB3/PlJNi/QyvJt iz1uvHi1nMtcJRvLPi4QY7/2gAHvooqKihssCdnW69+9iJyT85DP+L11ubJX6kWfb59vRyg7f3r6 bf1LYdMWdYfHZvuOn+QZ8giZO81ng9qBA2+un1lstuRG7vR3qqo1ZtUTDuh8mLlw4myNF59PHHrb Wvbu0qs3G+QOXc05dt9Fd9fZnQVuxrvfendO3XgxKjGzueBq96Td41++XGWasyJws/BGB4dj39mW HlzosaXE+Lx/bXMupeLRot4TX6vr9N69yLveNlWml6Y13c9acdkG62CuD0VVieHIDa7he5t02bf4 aFXuKFuzdrfEZtqyWnn5dXIhgu6WfrVK584NfLl6dZ+FjZRLLevqJVHjrvsIXfI85y2Yfs3NLV3L VSk6kNJZ8N2+saSwfeZrnSU53hqCL12Whcp1vG3qWrHYQbpzoP9oedUUtYc+4ydFJSuo0gz6lq+V OTA1c9rNtkbT7Ar2i5dQkwN3nYI+9njIbbneeyX83fUnK3OzfCtvT/iYa3I2Zn+23xPM6vC35XJ2 EsW0lVMf9r0JF09WPjyLbWpml6evkzD3g09Vt5dd43FOqdrPvetun1PM1+rwwP6qzF6/p19nDs+d s92q0zHTzKzTNdZpjrTU41u0l+9uD0yyfhrrF3yKNr356a0G3czvjg+shxP9n2VnWqz1yqaxl50W K8rmfdUhMSN74uRm7c3GAaobQjb165cpKZqUD/tdUVBZ1Cb4oZz7WpySf9TuBQVV7uMkpw5W3ez1 3tzkmfokPGbSnbcfo3zyLyW4j8/U4Z/uvLxREYscZ53/0En2bPJJM8HTgZ2d03rYIu9ZbloxbZpu 73sVCaXD8qWG6ls9chY9dwrcs7NwwOeFmh6nU+LCZ10rCyqi32i+9DlU+LDWfJU/f0Ositnd+0Fz xq/Rz7zcwxJs4LfEOspIic3jxJtwiZgtvTJHWe5OHfbfJtblOc2333WaJCdbfdAzce113hZrVdGY r7pSXUvM/eIDzRJUN6XO52lxDVIUfdypunqOJqVMXl2Yp/mKs+/D4byAqHf1NTHz37AYncq7MkdI aWHD9OeT/e9WhLg/nltVJ3vOYJ7mimDtTnYFdgMN+YE36dFb75eftphqP+XQsyW64Zk2m13KO8rY raUXBm2rOGWTYmR/XOqSyzf/Gpbk+bvt3dzOtXyrON7qrt0rV62hk6oSGx2srRCr1JxcnXfZtrL2 /fng5RexNTSXD7HeBvsi2z4djGeViDv6aYLTzbDm0Neezr7XVFcZHjEv/3bGeBum5FpZMtu8rFm2 QAc1vr/veEnU5ZsL55foFUlPmiYbMbU3xzdCZJOzzdvtXbZOkoo32XniT86ovDFQ9qbHZB2nW+hC +bJj1mW6lSHVin41DgIdAq5Pn6ZsSqrmjp+q5HP4njRv+r1bc0qyPklvXX/BxLLndoYc/7SH4ZWH LJyORr8TunTjFte0o/xulQXrA05UxL3h7lO2Hkhsu+X/QHJTrXZA3IIXXyPW2d9Dnr7VCb+s0mZV 9/5LfniB4MLmw0d9t7od3LPqfolKaZ5BwP19K3JBe1eGzJ4nwD9B75MlxYRS+thqXNDgzGnLluoN H3G/dGLyG6tX1pKJmrni+w9MSp/MV6FrLbpthVKHUMmy6an+iYHe/FHjFWvkCgOXWT/JbmxWl6vW NXj4OXvrxTq3g4seWjm5LA5M3631zipK1DZ3zw7XqPwtVHXn5pa3atqdCSsvoYc4FyQ82r/X5MBt rsCvH+1nFoj4JV/1ONngdFJ8Zmq8fmZ7j6bEXiWlwhNDD++sN1Hyrpt4P35gRmL9g8Sdqeeai65W 92jNqyxp5l7WFmD9tq1n1rmopZJBuZJOR25JGnXemK9sblZx38OhZtxBLGj6K9uiJT5P5flMvG9+ ubAmRmdnkNb43nzZnEhnC+XYtU11ExtkNQSdpnNd+LA9N8tasODieWHaw16JK+GZObYX6zIND793 4eIvnOilO22Z07vNiobrrm73ik1Sur6g+lVOoeRLWlbzlcV1scuzb53mXmO9Um9ft+yt9TpnWwSP qcbcpokFLnqXdu6u68JEfhnjQqlrYfE1x6VTa6QPFB/PP8h7bcLEU2GWxUd8vrFwPXK8Fk0zo9yo zXIUd7urpWAp0PK2c9zLnc6S7c+eid6YdNdndag1y3cduXKfDVGLZqVjW5KoB6YITmtyb3ZvrVD7 WHySc85tz5J7XjuMt4Vv9MlvHvSoil1hWBCzWagvZfqbHeF7vixFVpx87D7kfKuwrWKDe+QK36Pd qhuzrL32qKpfzTzUnM+nu/5iXkGDJfvmpVupTpv0ypcYbqKu3mIcv35AbaEpj/eSm7V6/a/nNd7v m1ZRz15YJTyvSSpbdTvv3W9dpsHuiYeosbcbug7fqPoaxZ9RFdq6p18IW3N4kd8sLCDB23/xwnDL vR8ULqYm8eygOUepLsg6wD6HCwna69vmkfftpLGCW98m/epVIa029uuy+hf03ZSQKL/kLaa3X69K oabORjeaJ1dU4IWldNqtY95nHt+eEPrwdfWm92I5XNcdnuxll9AJz29jLT9eXru2NWXcrqhMEwFY 9X4wRl5Xx77KLyl2TMr5pPhoo+rLli1HLl+OPB3NFz5/xYXrBzvv3LE5c23lR9GW+SmpA1wdnfOb r13gIJfcLanI060zUrk2k6vpm+KwPJ+/i2sKSkYzM6ipVf6825fLQfobVeCcw+6+VW+vfjI8+kwh 8eqCmXYi9udllBwrZ3B4GdwVn5sqCNGMHPoi6m7+8TVr61OXOz5VsH+Um1KpLyDDDYivmjYICHFs 4ER1I5AXcXx+vRMzONWfqckPPYh/LXMbS0NYDnwKu/M65Vj+va7M2sMBe9aKWLd2nZiX8GLLwJHo DBfpa4bTZvQUnGnr8+xBeuaULgOcg9cERCCim9TReKvrxuPdH/fPqZ2hMle488h1jZLevUFadgul 225op+7T5t5WM9Hsc3f6Jq19AekrSkLGRRxnY1kllGabOWvZd61NYir5+9Z6rvZwNGTPtt12Kvr+ ymkLSvQCzy6SPWoU+MJa2kYq9VWxYGrJazE9Fxb0WVqqhqVv+Het2Og3kgdd7M6+SJrtL7XE+FCR 2J63jWpFDWdnSnOtzO6hHcEDvHUCkS+D6h0uWu0x3K3kXpSzr7wpO8Ni5kclu0aJm53qnt7TFKcs 5bjQxFvSeGGqQJAIhaZsfkI5anpib+WVAw2S+ZlbWlmzDxsrNqY9t3uQc13RzcSXOnU63iBj3wVF gQk86DvJjEO2oUrfdeyD+HTYsg+bznz16pNv1A2aYgHt49QlSyanXBI/wvWmfTb23iz4cPgFMXL0 P2Uhd2jffDm46KPvCQJt2y8RyUaO/rdJiNFdo1Xb6aHtWwsk5dDZU5RAem0jtOe3jVM7uYjRwa8O mnkFBOyOmZnjHZRUsNnDhXaxae6KSXuJ+Hd+OjJQPTtXnfVY9IenV+BwzTGK7nKk9qZfEahUXcnB Sg+61wgGPWgqe5yjcIT26IBEa9r0+ZWOOc2V00JrVT2X5iy120zdvHeaaseeL8dvOq41qXTzdTkD 8e2N0J1Hj13izk4/x7XC8UFZXu7mr3LH9D4f6TrFtXepWb7mls3fdgtlissfix/+VjZfdcE5kSXO VUuM7koU7J2hyHJgfGvTLPkCt6GtFyLPndQL/MpVye9VVdqyvejgPNPvtMFPrOfqkz4Ebr3yuDtA 5HzjrTkZKtVDy3cUuFHn61pmFC5Yq7dH69DKXZ5zb9x336I9d/PzpVEV2ezXko6+eO7nwBsQiiQ6 fHSlYDzjXh/OTRHmcZlz8crX8Q179qoOh+fuee89996NGc9OmX5JK1FJF+Lqz7pwqba2cZA6q+vR vPEheWVF6enxiuNXtE6tPmFEC/WPDennLejr63aKexId65e1f8nkIr/2fWKuHaXxlKn6WWk8W5tp mkWF59a8Sq+ufnRE6vR8N/X3IoG3QtCcE+tDPgp3VdomDDpdl6muPLF+fPmEb+1abm7vExv5Eu8L 36+buea5pcGEuZYxUyvbrrtWXrY8VmZrHRdq5bbhfu9GpxDBkKjOLepaa6pW8s27WQQhrXvire3h rz9kZLSamJdyhd1dcEHILwedtzU2ufnxjYEttIJDkxeylZnnOX87KrvV9VPmwG5Toy3XEr4nhyrP St0afnR9gu/d+V2ctAVZZ7dnbDO4KlVYmBkaKFubo3zz9KXBg7oJ8eptS+fq68XSLPnaG9vWPZ4v dfP0cofYpnnlwb4bZy/OelSxcIbu4hrXfF4dBZv5D6cZnPGbcD128elJJQ/tMLsXORzLjz/8VvTM bHPapTWxEYm8cTFpnzK2bHnR/rK7+xPNTcv+1ZSsNb0T9r+Ojc163eHgufT89sHqHKkc5zn2ZTFv 9oZs5X3Y0FUa3pXm/DLpzIEu9SKjzc9rLJV3hR+O3l0q9XKbVr7pzoPhNbc1mjZyarxdE9SS/ux0 Ufh2kxN78sb56R613TF0awG3ZSH7NqXegGzOB4I22eoW3fY75D7675vS2Xefz+JNcVHJopeht0qf r3Kdxh4YEI2OZ38qhoe24VHnXPbJRZVXOM+513Lk9qotNYomVUuiLzW46/G9m8G5eUl/y9S3obk7 Qg0Nz+pLnFDs+UJdPf5xw/EnnO8+dZWuyhXB+GgvlE68uj5HW3dYcHbk5EvpEOHmvYuglakt0nSc vrh17/Ni67qcwmT/959szwyvixnUfWnf5JkgcXlldPSna8LXjpbWHrS//PLS1jyf+S26L3KqAzr5 1l/sfld+//qgNHvhdAUPY09DJ/u9RW9ebZ7pcHcFheYv/7HCOY4mlhTkJzfoFtAskk0VzEiVl859 9nLCQ99XHZPZ32ZvNZ/ieOVzfPSOOYtjctgExI6GNE2W72reE7a6QCNm+EBEzJ1nYgucVdqmtx/d Nft0ddTZq/cNrthF5C6Z2NW9Lzb0fqhAYoQej8a6T3kC/Bqur9Vpavc3xRz+kMVvsct1uE/EZkdL iqfiLZPs/c1NH8wDwnuD+tYUX7c8cNhW0nJYwHVhTuYkZPadS9fDFW/tDb8c02ynvEtSI+lUad4q 7qxZ43Wdni1cmBFlHtKlPsnqTdfeJstE/rrJ/GVv6lk0lFR2HxP82sLOCGUPe3ErWKrU1xh6PAzP vOr54o3U1+VnbZzOFcdGi2lfU7c5rC1zRN8rRSI/s+OtprRe/qz7cX7qnXbqL7Rmdhp7C8bc1dzl 6m1559OKq6snBtSqHHXhrTBy2+dq9eQNm+fBBYkwHEJ39Q4GFgnPrjo5047NJdA24c0tWY51G1dd eKPivC67wMCuLTZszqW9z67yCj06dy9rSkOrqP2rIa3DcyYZWPcdV1+Re3j++XVbgl7e5lu500lf ZY9dV7mue9R8J5Vq2zctuxaa3Hi0hVZsqai6cUpp2lPjA06IPx7DpgkPZXfP0BVaGS3m/LB1L+1U V5HZKd4m/Q+uavohn29ums2p73ji7q34xZjGibNuCetjBqs/pbE8u+V3ZNOll4H65w5K3k8Qcuis aW2lxBy1vrRLuYTT8XxU/TmZjYWlVbv2xos3PZicDCJP2D9O5lKjZNVTi42zJsq38/euODB70/13 Axk+2pYzo3qO7Wp67WzAu1xn66QVUVHXnj0fqh+yruCsuy2aYXJi4gX9YxC1Tk9/8CxadcfxeVln x4sKbOE4safwsf9i0ZK13K65eq+qbedK3Wz390iM0xL3VUraO0XhvR3t0NUJ0jf29nM19PhIFNd5 WFi6+gq9VnDktnhmRs1/tG6OseZzDv+IGixEzM2tcsukFDATIrt2mtisKo03u7wyEQ9kl27Rjmju POK7vtdtUf78u9OvyK+9d3cT70GHokbJL3wrF4rQtqx7X7zuZUvircvFrb7Ppbd41U1W0ohNGM5f lnVjq/fJuf73b8XoNcsGTp2gVyFlrZjf0eckF3v2yz3j0okxPrnmkk83Xb5xq1Bhy+srZkS0mjir 7WhhBXtjvr9h+hVXL4M4x2OpV69DtHp2eXvLlb7K+46t513uUBYuvLonzsEtQ3/hmbWLN9k9sJUo 3hgoa3BGbkJk3v6u606X+Q9Y3lmhyLpYSVxm8c199yO4o6P8ZapV6o4l8O0IvXLsxeq337ZKHth+ edvcmcvmj9s3vy4r1WMS1fSgMtuHvklT5mtt6F8gvn4/zeBuSoW06uqhT1mJB5Y/21pukHXxo+u5 z21NPtmBnDMIT74Sgo4V07GP0Yn6m4p5JNos9iUKxeZZTCgV3f72DnVK1OvqEyee9udN+KS0yGR/ rVveYa97Qx4hiSwTKMSNs7QdxsiSuh2Ownks5LU0HpYJ6rhgPxU/W2n8xTC/TeLkxVtfazJLusQi Psg56XxbYpq80v9KYvjKHO5bqRciJzqqxxVZr8+7zqMo5zBUc+PrF2tbD9/VyNCDe+WSKJYmOIva ybt9qDHt4jmnwJVLIiqDemhv7/BXYaiaMTXF+1jR4pv5hnYv3Co8x/t6bsp1M6yu19RoFV5ke+7G aLw6TjFOcl5qiQS7mtks6k129J3LeojYWtbUHp6ldDe6Ozrn8sTzSxsv77o/PSbhmNxjZJ8n+95F hjpvNHy7zNY+WyiaEn7mM/+rNGMBNN9lfXFN2qe+2Zs2KEPM+uikp6Phak799aUV8y7lg6JVPKra eK9kl4f8YHKdieaum9epiJG25r6VVOPt0ixLy8fReiuP7vLtDCpb3K32eIH8LctZVm/rdcLiwl+Z n3qWeARtdZ0IYZ/NiVQl6k1llsLycQ8H2qc/ju723ba51b1828e6fo3DtUTcOrw01fS1QGpJSJHN BQGBoPFoo8v6dzVpnFcDM22v3ehGa92oMzqN27oLhax5prlN3OXBmpFWcxNnZ/o+dJex1xSOKme1 U5pHy74809mh2zHB8RzXh9I9zVk3JjftCG28ca3mSs4XzpALykciNHjP8JeNCT3nNX3OklUk4sdU 4yTQgJAxYe2Qx/CE5Sh5eXw85Ut1XzdbIf3p3zBEzr9tXKzSJWPmSLblS8vPz7/zwWXVjrdva6NY LzXlUKT9iTuvZsvpYatm0n8IWyfsLZl9Xvuwu+Tr4OSkuc9Pief3c9wX0/Ifd1i6RthcaGMLlvKZ LRu/LTuZbe5g4+qrLrMDhDPu82pM4ahzooes62xjW7/M/twdLGOR5Z3VdqSDPeXD96+zg8tCB5xq 7J6kDVY/mndo37jzyw0U8A8uI7cezKGNVy/cYP+Ch3L2lrSV2muLzxWbbrwUPT95SmF5ivMy3gsz nBbfbHRVlR3WTR5EF+0Zf2r2pSVNquvPtzYophTt2iXuFjXAaqZ92LgmIObJA5vnSbOXVMknKunq h3zcXdsd+oqIY+e2nmfb3l9qKzpl++p0z0E7jbaoO+5nlt1aarqm7cWrpHmisVENVYcEUjo6bXaI eHypfVH0NNr9YsusfR14JHvqq8HHsGznA95bY8eNe7rDg8f12vM73+uP5tw/+FA7tLHSLfcU956K aXuqxN1uW588uM2b1X7deIGK3gnXvXQNFJpvvFqf55lXELLr5fzrziGr0pmC2DUqzEFsZ2LmqnUQ kwZXbVQp0Hn5jKv7/geZOYUR87YsmlZ+DAt+t33tfllLtYKdT5qLT7s/fpixW3ynUcKgxqMVh85V yTVcPVfYseaOdvzxuU92XLrnukPW1f2C07t9ls7lL+U7HRrDimMKt9d2qRC3a9eUiXq3u5jHf9Q5 WFJsoCU622R25b0rZ46GqH1aid711QiaHZ61hF1hz6R29zVRZVwu5ZeijsvzN1kUHF5seS383XXv dve6+LNarv63WefY+T466tR8lZrbIn02kI03bc+7aX1fboXsebZE8UoqTbK5cGZKrDbv/hmqkcsa ZYQKuj8/OaR+02bDSAwr985VW8/+1rhtzzdXO7ryiD3K1wqeVv/GsT49pmdPXe/3589zjwlFqEnm y04yLDOznBib/dYqNtJa22WeysvmMte4z7ZmhbH5muLcui25b1ra98WE+1t+eP80X+xV+CyFmOw3 eOQ7e6uF+PEXNZoWIbUUOf9HGzTFaRNWXc8tv1TYHqgvcjQpNiXlPnewl4Oq25uO+g32HU/35n1Y bNr9TL5zdvVJLpsts4uK1h0QcyhrWbF2zvJI4v4s38G6E6E7h9luZjQsuHa8Qirt2MB1wxfdNpmz 1g+67WzWtSwND8y9ptp9SV9ym/3UDvFr13XV3q458jH9GT2cNVBVba6nTpXbNqXKQO7k6btJn5Td ovpyzgp7CcWIlt9vsoBAlPuOrta0uHmZkpk9vO+j9q7h7zwgNP6zivALa57ixFmhc9c9eXL/6Lvl trW2JbQQMcOzOoH7kiRq5+ZIfdWUmODpJH7s9J6ASa+TlL1cc8NEbrfWfl6sbJbmUsLlmcizwnL8 NtYDh24jEyfFvq2uYUkePG7Q81Kn3+bLo+4D16YV73Y9Htzoa5kbS/PJ1Xy4bD1rZcOCbPW7ezwy 9L7m9u+mmd8+GrwtRy30iso8pcw6j7e6fFlhrMtfe07jOXsOAtijl9jddoYbaRsEX1W0Sdn7VHxt Q/LkJEneed37Fnzosd4qcqNIsFiyIWyxaaa0hvz525WzBAfYnwhzhbyI2Ke7X19C2UmuPbbv4+Zj N0OenSzxbipT0hbJPjZN+Ey0BBsjft20e+n50QhWfVtr46OjGvf2y714HWyZu4T2Zqft8ZufHl9i C+0dl17XV267q/H7i3fRLYXtPZoeZc+vy1zTmV60LHjw8s3XDd89dqjXjbse3tF6qsytsqSiZnyn QEOOpEJQz82pLFyW3TY+e/XPSx0taHbWqBbVUO+8P+1t2+1v8uddd2w91prM+2JzVP/yYivRYw/8 KJW7CyWvd7zYn77KZMeRopxm+ePtpdMfnWyxURc2m83jXt7WV1zYO9PUO21lAo8Iu0+Oq057btzT 8tKO1UuWfHp8+8zWbo5Ds4q+1b1OfDDJKQCbMXlVxdby5zH7xKbYcC4Qrz3pZhXWUXayX7nznJKR pWyNDptxwckbORMiuvcH81kO+iqVz+8fWvXi5RvaRA/VaQM+u+4EtgU9UuIWuaOpNr81YbP6e30Q r03XtVbvCasz9TZc9GPlu1KqfDfpBcu0bR8rL5A3WrV4qp8tiUoJ+F76YPKclnVXt9deOcb5USss cbLC20n92WEHotpCRArqy/fvTc0z32vgzr92/ouTa/Cg9c4B56Gut+cnD3yMZcl9VERqy1qbtkmb 35X48Ls6HG44me4r+Sxo1X0vOVF2LoObng6UGxsnZaft/ORaX3XqVJHk0bvZJbs4UiQjPNYJFUgs vpaZpWTYc2GwJfhrjRZ/SVHj8ftP9lSN512q+f1Ggdxi96D75Q/uC7LG0+aJ9LRElVuGSq/r3rNT 96xzV2hLq+MbjfS3MnMVZj18c6VgZnVp4rSdV0PKZuRcRvZffuOjw7OiSchc2Ukh1rqmerJuYZCV RK6Gz3jf9FMHAkul6nSTOgrdXwo7h2bdobFP5u5qfJYSvUN3Ss27arFvMaeX7LHuf7y5UFf/sOX7 d7PUuBq/51QFxxq/EQzGb7Hya/jwa3nHH1piW1iwecXVRD+DNU7UISTx7EjMWh5uuNV6rrjO0duD /Quiopc3Gs39bhznnrF9qSB600XQ9MvZtxwbtvI++7b16iPxBU2fg56ceN/Tf338vjLB1N1ewrjb F04bd7izpTfnUxfPONrb6dINotNbw7+lnnZkmRVuUHnSdUhaGON7oRI0d4CrV/T4vab0Nvla+hNf gZ6JN/uqJruwk/fBjLfL4LcpTfhj6M9r33JQw+/H8qYZUafEcqx8v6X8rLeE7Nld77+sLf4wLotr ZbOMfpels9eBzlnOhzdycfBMHb2hajpU4zCETk4REr57TxbCqFjl1ReMvVYKXk/AFM/TqAXjg1ce TQ0Sp3zRvYfHPqwc8161HyjdeN82NNqSjE8fFZDxaUTb7Je+r6c5Y+dv7A97z7r61YzlEDNNmrJL kDrlDEd8r8apj5XlQ4uzo+zOB7j6S3zw217v8O36dv/mlhcm+UuxvUsl3AoVJn9Gu5+0cupopENb pSrHCRwbFND8ofWPNmy+nSPnPOPW643ctZ3bt1k756oXRAa8du48MH62XF+noui6hLWD8YuXhJat KpFY0GoWSRVYlaqRPHJDtXT+2RdJKo1n9tJvp1qdkZTXt8lgQXtok3bM4qCwLLa4kH9uqsIuucNd L7McnI/pqZS7pgx8H3BLwAYfXHldwu8YJAWVDzpzTkDRt6YX8pdNNdpVKuD18np04QH17UtZnWh8 pQcblbYcmWKiuWnOoeVXjX2CIJKVEJ+bNoc6ZQLLg1cStGk2NrN0f7qhGh0+a6a8+qEah3mYa1py UnBHsuLbVl4d+uLju+CFxEPLeEwo5DP/tvUgmaQYrJGuCiN3rMnLsxCJnnDT7uAhaw9aIim/bdzj YcIIa7fHcNTX1x9ft+ft27QX31eUhORMThUj4tkZHBtLTke/cqIeXD9eQ11d/c787zd3mKXVu3jy LKmrlWU1IbU0SBDFV+chH1beG3lt4Kubo+ac5xe2vm7l8CnrcVo0+5y8tdw92xaxNU6JxpOu7MmJ cJnM9tDTbsez5WSMOqCkvDGskt098dDO+Q5TNSb3W/t9/uR9K6bpyz1Rg0vK05TuRyg/2es9cX3/ 48eR62UbWl91mrbJtGoOpfS/iLW4lrSiLXHOt1C/YwlXIjh59rRFdB+m8ORmix+vEJ19fZl9ybkL d1+lv9s84XjAjzdYXyt1LNaW7F9s09i47Uz5ZmrnloKymTqP9u9Tn4KcVfDfl0phC3nxIJ377KeC xZ8sXca9XzS9RGBnbMKgtGt6kQf3QqkhjzWDjruXsYxzdY298/D9pvcl8Z9FasQDggO9ZaVrr3jF 2Np7BmQerA9/e8678vTZUy0LdYqKHtS0Vm22PxbWqqrseDP887HTivZNN6KjBifuHvfy5bbgpK4F 1VEJe3TWewo7HRp9ecD0+/WzBxeesbrS9fhk9am2bw/8pTVmUvj0X/q+rK6WFR/wnalwR+Sp/pLP D5DNohYV4tEW3jWh4Zc3XxL0reVyuih55OYhtvmpLEuXxswN8s1B593RvKIw+HzoRnVDRaZA+Cz/ tVP2DPqaqR7skuq1S0+Rz+od+nrPZYOm2sOnA18kTt8xzapdU6jRxt227ei1qhVbmje9VTWvvoRW v9UKYNmyunNng9uJXb7acc+PvD1w8MvB6auG1De+cR2JO1fzUxvnTNZ39dPTP7igmUfHckLDjWeB cc3iOz7asODvDVyewDrFUeTWuznDEH0eoTx77jcAvTz1zaOyIsnjWoLmh+Ti4e5UB7fGzwcFGqpz ilyyLYf3dtY/LOu13FzzlqPpuHWj98vt+y2Vpq0OncP04sD5HafFilp4DSJrl7rVCetucuAUCpK+ 7BG6X+JoeG6ucJ1IrczZE5E1YsfK6gvmsHk5uc9XmrhoNxctvOStuUq2nX9KfoWFcD1vegpfY30X izqflP+ZbRsHq24MOOXOP/vo+CE2tVPZ1Ac6ek9eqkr132F9Gl7m23b/++z7S5cmxml1Sxov1Z62 i7J+/2pV6WXXh3dPiMxTOb2/TIpvtmdV5Mxu+U6jwog+d/K+Kf5mQFZMgI4Qz/NMLd6gU7nyz20a zx2LS9yxYE7RqW+FxU/1TLXOVOyYOa6zXChXaqf1lf7gq8dFiuxDE4OfxjmUdwg5ZMQM+267UT1N uERf1fIw/SUBz4UZEsfO7b+QM3vjupbmcE08amULZpn+oUpSW8HbgVXDwObJrfTduvv3T08tPPAw OXuFu+3NPQ7tfNqLuqOeny2TeutqrrvB9k3X7XD7N067v0ZNnXN6wdrbA9+07abEI0sylR/dMs5S nq6y4N46tyMfkBxpszcQaqrgoeYzUa1lx5VWnbgkVNbXqxxaGYW/CvLKOsS1kO9+TV1f2aGjtMo1 D8s+lze/mqppUvh6zhTrBXPItwJu+u2juUhlNZPvBZS/T1zuE2uWP6t6WfeRl5jNxgMCSwSHOU/U nlgwzQSzIG6jHuoqernSKTZgea57GUen9WXbyvYwr00uXJOfhAal599bHXKhQbdd7UrCcPqJXXVV 1UfUN3pvXzpst4lDwvjeDh2NyifVelULHy6sm6CTvrtXw+6x/jzRDK1vKpp5y++XcB+6dXs540WA OA8p7e1rdlxY3a/x4C5qVxIIviPO/oWUv1XVyZVSSvue3txS3TLPX0ppw8dX+gk0zs1qQeJiGb55 SpR0Zz0iRm1emCXv3/Nx7mu3PU6K+8xm625rq5p0Y8Ur+8UWOWuLTtk2SH+J1ogstjyi/XYm+7il b7Uy0KM2KoVv6/Q/hDodEbjDuq5a7c15rbUdlBr9fVW8GhVp257Cgs/lo17rhk9lK9Wu8k3+KLC3 velVulFYRWlsWPykRbqGfMdnyyvdC8os6fVTO3Fu517jQwo+6++wtwXdztd7VlNjJ7n80vbl8YmV Z4K0clmbla7fc5dKazc4P+fNy3k3RM686eodtC/bK5W1ZfoJXaU4a5FiC1/Hg0d6XcMh4lw98OBZ 9FG7QH2T2q6HrGfe3lE+uKVqo3/5luI6l1bWM9/ulvX3UGp0gdWs0jvYxnvcrVu0Kk48mWCms81b a0JwIbfL7O9eolald31ENvLomt5XGbjTur+9Sa3eYo+O0/Wvx+mP9M0FdemP9B/YvU+bEjsxoLji 5bF9gQtKF67UMbdOSvZZkY4GnzK5tdPH6fRFJL2alXOvznyLe4w7obSK9U8cuWQk1rScLGz5Moer r/bJ86DGLTc+o7X217mWLuhMgZCyPSVg60CqcBz6unpFD/o99nXO3c6uiRUWYTYud1g9vt0lHtXT XJZksKneulTbkugzZD2lQ9qs60G2ZN2dSa9NstFvz/ldTyjefVPJqld9LOtB66VoUfMPKXXKjiy8 nq2O1G18dzNrmj84dsVPpN/vVDmUZKBd/NBfsiy8Q/WqziWufIjxuiQoBzoHVwmwtGw58ilSYhzt yCrvWV7P79BCQq68nzqVa9dS1hNbZbzOoV+qvd9t7ZAinf06AeMHxzhkh/jIqPEy/hrhlBD+Mxh5 k0oQzfhaPVR5etzR9Y+BxoRklkuWnK9ZG/QEt6c82fhM4ZtcgM63W9cSVeVCHzRlsO4TEIJgxFBA Mfd0Y6mFrR+bSINCip5lRH6HwtQlGXho5LsnioOHZdYEimWAsZoaU/CYtu1b4TQTF5GyLbfve7O8 Pi0Vz9EwxXK5boXe/eAS22N7M3g/92lMYAEeU1hMkybmOEs12AuXn472vjadJ8/EeOnU+zJf6w2u R3xc3J500Tsmg+q4v6TXv6zW2iaQ820jT2ftcLZx7ZbljaXJO4t9N1u8jW1JmiFxUTwDSdthvt3F wUUqw+nQK+2GfZLjioslOn17vbfYOeeu9vkotaO7YXnU68yo7FJPY4PsbqT5heDe1qaBY04v5Mpm W2+8wdPZIF6mMlihd8MvePIWixxLkRmpFzgmCjwSLlOx3r14513Zr71ny1VXed7UDO6+PVm4MTS5 u/DzqeU13yXLLKZGrJUxETWRM0JPDOou8jn5oDR6lduigKqhIQcT96Joie8zjY/g4ZUI+iJxZ/fD N133dOeXb0us699aq/f05rrYgMKT+pXRWv2a0TOl8fcxz7iXD1m/ctquP+1ydcWsV9tk3YsSrcbN kL6DKKWlSqRJJ04sGszb7Rfjum/3UHG70acauU7eLtr4w8sMjXfE0BFoWr864GIr6ZatqDvtckLF rPuzpy/j0hNzuPX2WtgJew0vDo7jbGmPEicGbinM3NIq2vfApuaFpNWjmoVrN0TlTGefaLbcuCil sSBHuSBbXT1ReduW6isG+U8euO86EOpp4V4Uf1vbLri+a127uFBYmh11CsLyQFc8eaBdlW0k6NUa fYug0/y29ehrBL5nHj+bOf+wQsThnLRpxGcZHQJ7aQbaOuUf579c3dlyOV6yssbkWew+Tg9iVaRs 6iV5l/b81dYWGs0q33WTVBoPEcQe5NiwqyRkv/oF+pckLlkXvlxR2w8Rctrfi5AXz1z98euywWWD nYfDRAx7HsWdyCg7NSBmbRBgUjFDf/PE/tBTk9bOeng2wPFT0p2P2yeE736Y+O1BxNCWkuBZGwLm D2Qs+ypz7eaGoDyJqQYBByeX3b8lXC3TLGUwfZuY+raIMhk17aawLWoTw+/LtQXtl2U5931Z//d2 t/DvN4ar+iwPL0wecHi8s0nG89RgycnHQ0PpEee/KOAZZxI/P5BZ9tpoKFf7/NDnEN4PKwPwL2ME YCJiqHTDnbUXhgfb175Paa+Je5wgkXyu8/RA76H3p94mnX+tf76zUf/dqd7YwZvf3idek3o/1Nh+ fmjGl2q9GZQ24+2suICMOb12LGZ5dCrx2UGJWw1nC5KShJPuThr0OD11SXLE8GDGt7OvowN9IjRO Hb120P6B5pyYZ9thdWp8Gr93n2t4wW4yh8fplC2GEW/tHlAfyxsuffv2fIzB4J3PnINnLA69k0+q wm6lTFZbjr8zdBB/CeTEvmA1Xw2jqZvOPjp/csE6b5Pna3O3xHQFuOuVib892/Ou7avwg4+Pu51M /eZYr/URtaqzW/pieFvYobg5g+VK1bZHNfLr3ApvhSbNfcCvXh0jNVEl+WTLvRAzn8iVTzrZVn87 cnKoo9kn5vj54dtruzZNO1z3XkPVPie3M3+15KQUXc13S3r1Dj4PNxcpLLVo/96QPLBWvqbk6akb lV3nfb7mmn01yDob9OHzR+H+mbGPZy+/+TrQM8mKx41NdIWd6cbckviufOFjtbMVNKPGfwOWJG1a t6a8pPUN+fVzlxw9ukTbouuTn2zw4rDILd96ez5GGPVNlDCbvNFlf7tgmeuDJkuXyDUzIlmkdWny +k/dLrc2FHxN0p70pK7PweBbgTC7fFdvw372e2ctvjYZ9rc0BC0/d3PPEYNX5z2NetcoVZ/ua5mW VThwfcXTqy2XZZY+v6KxqWS2p8ayd/mWhl8i3wzGnR+aH/10jvuLi5YO5oeT7x/a/DXEipbu5OLW sUlYQfqolNTpamEFe5e7F+IdE58/uqdz1expmg2nkbbjF8uDS4q7DT+wpB8tjl++1WTJvFk1wcdC KleXxB4IE5Evvr59Z7mP//tlw2ZN5hqGsVnayCeN4sR1XTeWvfj8gHbeevj7/s6n+v45U058WT5D +PE3p9gZlw+9qtnSx5Vrc2VSe8tZpbt5X0OW0PxZuw4Pnc1KuRkV/fzlzmkyCdPlg181cC15eSCt xiFEeVy40u2JIioPy8Lj1tfMkeQ+aduU0Cw2XuuqKtaymS3neEIPa/bbryWzn9r5TWZVOtmtsa0q c9U1Y7+eW0LUbrHw6z20J/N2+HGgGudi3/d+/epgZKf+5krTUm83lye6590pk9fM7PoQLSI2VM8+ 1+rT56QSoRU8Bw+seekrM7/94cKvGzmGzvRc4taM3caH3LoorGdvvVrNrXioNDTL4+HbyofZ9pmH +A2+c86/fWv8QETT+KTpFY7NLoqqFr7DK8bN8TzysL9YKSaw26B/8rjogfNtZ3QLXucPSKt8FHI9 3HWv4f5rV5WdrzNv6rUv/XBUw0DZreGW73m7bbvr5D/dTs56eJnNWNpof/ii9Zdkb1gdXas2WyPn 3I0w/w12HweeTjuspNIyXWjmF2X5+MTpifKyx6f4CvYs8/5g0LLyjYafmvomUYlxhv22S9Uz5mYl Su5Z3EN7VvpW3m/GEz2uJiVLBdMFa19kXFnT3Dz5Usqdqtr0YHnb0/4Knk93XIwrV6sqWFr0pdXh uk/TUuXYqE+d32sMDdyNJydZplvu7qp/bW1vXnhL+mvSnpJ9r0IPaXY/WemTXvqw8F7Zhifb00ME 5hqwr1NAQpGAfT0dlo1ypmXBlU9CN929vs70zMTYR5/EJGb0Xs/vbN23dPGHG/GPdk/omWs7ReNS i27u1BzJTWFLj81jNZn5Mr2j8+oDZLHIIn1YTLU8yt6v++rVG0UejUidI7vUDVl2ah+Pr3/2QeGo R61jWa980tdu2uu0tQ7F8bdFBr4cTnma2d6y6LhR3LOALI5Iv+4dd4/Ntl5ylfq2ZYtK1fPBjDtK az8vHHS7UXK4Wrr6/eFt+AsUe3RPiNx1nq3Ec5u7Q8ROxSqokVt3zqdHnyYsMHxvqBKjcoRjddTE 8XMuv7fGPzYUPCFLlXpYxxqeuS237jj/wWT3o5eebdO9ka/TdEOwbo29QeSnYyKPb7du2qIyt84t b5br0c110nmzG1/YfavZ6uGjn7n++bByYeGeaptSJQdzvVMnXG5u7rr56JbBokSnfaoJiXtcJild 29qpO1NNb+Gu/t3t97jm9bkHp7n1OarJRikpzskTTC1ZIdWyGtE/dU1652e7xsX2J793NJ/R7s17 dENAtNU+Y6YD1Z7CoRH3cmBPSUoxV2fCqbPJiStTPWOFlgXJvFsr7PDOzvZMwqSdTRmcH6rF0mfO 38hmdYVfas+ls1NnS1/5VDyu2jSkwv5L9YNF3xpa91RPrL10y6Bvnk+EfevapnYWgyUd4UreiM/a Ql/TxnEJ77bbrrmbpOnRcebVVK2A+jdTtvAaZq+d9VVZPn/POougWnWv9qWbrpuIzMGfG7P77hWk VGvDUiKeY/7SR3qnm1Len1jt8uX1jq7JbcsF14uLComcnvw0r2xC9TvrkhelqztrdEU+yJZc4xfY m1zVHl60nd8gwDhzo4f39V2sSqn3HO57t37xCpYPEDPyVF9RYUo15JTtO3Ip5bO2266nXNYVu9Yf a98oJy8lPifx683cd9ztJbTjARLI6tWtuxe5Pjw3LtjZvkDAKFlRYXJjgc/mHE2ttxW7mhS9DwjE 1K84vDN5uDypicUw+olgtaOoouMG5ONHEV8/mw2BbevP3T520/H7jq6BqyWrv70ZiHj8ubE94qzF 3sZtdQtFDbPU5994WHXUYX/1gr5DyR097ZtyFfZIfPJHJp9ya1/nNOFJeZLUjlcnP4j1TivGXNYY HinmNuH0TzRPdbh3N+rTkTyZ+U23VmutDffIet6pZzDTvk67N1Ekca/xOQVWPLCZlAHBvNX+uI2X PhwSt0j6dPHNLPcd1zgV3Si6WjaOVGn1jvXL87/e7dMttV7U9Z13wH7Kl+pZc1dcTTXuBe8+I2sg 77iiZ15rfI3T8qSuh5Wz7h5+t2i479HnyvrAYfFvCWGmKX2HHp6Ke3vh0WeZbxcXXDOXEaiQQ+ee 3VLhV6HoiUGQgb/hu2KWV+LHTMuA90P3S+I7m4Zq9OtXf5+Z+CXso1lSlJH218yB/rO9lvLnaTfr dyZDcNVtsf0RTfHzR0OObpn496fZbr2htpf6cqwIPVd+Mqwhs/S6QcE7q523st1nPLRvmh++7VZA +/5bTTNUOObTP3CidhgjS2bnsZKh3QZN4GPXgYXX6e+H0t+N/cUHwpF8rIyvqbgoiVdQgwCbw3O7 2DedlbhrM/f8izvtdgkpA29q0haEn/52gTLw9ByX+pdqLmMWTiIQDaJGfjsYcf5bWGXMooH9j7/u 0ng/9Hk4ZN7e96fXF4cVDX5hf/f1TmXEvcbDDlodnYMsAq1EqLlrxYUT+yO+P+qTOD389aplygeF 4Ys74rRV75W8/+6QKPHZ4HFSO3vg44VPEvm+0nhfCzYQce38DOTgc8Mh7vdfX/U/2iX8Uqt/WObb jvP9TxblfXsj8/ZB4uswUR8WIzfZPCor0dVwFsV09nSVZYNnnT9ZeCTZpfT19fENX3+swPau6lkm 15KVJfsFbDeiuMB4tNFotpUs93Ytlfkko18tf/hsSMTCs7FvladGdhjnnCu3mX/5oGckPykoNO3S jAevQ7IepXyVcjiXXdGW9OpGu8zCJIMFF+JKJFUS7kokZWvv7+ZOObTY3ISf+Pj6OUdXTmFTxtnv 6ctkkoee0YY/pud+k97kPOH9+0ClL+/Wb/aQTgm/fpD9DbEEXUWhxDo9anJbNBj6qff8RxUjo/4F Guc2O294ES304aF2usosjtfV6yisusQg9EzaGHf1Y06nkfi3pyuMejD+708f7ClxH94399P+10Zx ne2P5A3P9w0kR0V1az9OjlPJ2cVu5KZbSuWgC+n6cOTNW8nJH9JbVy97cvHGt283ln1ykHk89EYm xWJ80ou777/2ZJV8PX3+KyzMjp3fZ/3lXVKXG7/UkMfnvOUTibcu9gpeX9iQnBIT/v2ijIBF5lD9 NS3t47t8h/sfaAyX7pttpGTUefp9WGlUV0enMuNbuknrL4xftFSrbehe1vneQ3EfO7GSzHM9t5o7 3dsOn/veeSvr7Ff2acu/vtNeIzDkscJrlxLR10hqh/7KqO9XHIyGHpQkPyt43FJi9CXo06umZZtO Pk3pKZZZ/33o8LlterOfnl8UmVpmk9fRuc9c+DgxbJNSUzVKv+Q8/tayp9Nw+/Ktx25uWvblaFe1 wzf1olkJj5tSNtyJXZRduUjXevbZAp+spjiZJXWCR0TWkPPGnqVrwrrXtO9xhoO3L5/RDhxOfJ5b khzUuyvQ835WZvT31xXLtJZ1Fr3f2bQn5Utl/LLMyq4z/QYHXfjFPoq6ZCkposTAilBq3XrOOXz/ /vj7xcOCw09b/GnjZ8Q9G1xw95Dnt++LBu8Of3usem7gZcHcExlV/nOtlvMRAjYXCFI3M9lZVvDx cK0JqK2kkwALXW0vPXxQnzTZ5pHS5gdx5c9dnmu9OujVEn5l/JDHldTlkkTre4JVSxYu/PTi6mcJ 3qV7z4bcfbST/4RV19yCw8hX2uXwjR0yuI46iqHHjfp7HZKfvDksk9x0Me7Bg/O6gnY354rFGMke 3do+SaE/d9k37Wuwshr+0P0hYukzibknuI3cRDdvxwgJJbKEe5we1F/0Zb3K4/je3JTu4vy4x615 Mz/65+m7nRsY4l72wezxsrtGC/K+Dt497zn3dQ9triynHvkemWXquLnv479KDb8r00h+mXO+9Mwj 3rre5Lizb1cYfb48PCRjtLT3pdqir2139y2WSjmkLGfCTkysTxw3r96Tinvwoa/yfNH3sy+2Lkjk np9yLW6ppRL1kOcLyaeSsmXRL9n5HC+1qrgdul6Q49FDy7nAMZH+bpMTS+SjY2XrKAvIa0dO9Ifi js75+yYcYSUnfg54aTfODVT6Bxtq+PLs32s8LMMyi//L0yavGgQOawt780OmXssTfrvFbBB9e9hP fOT2sJWC+JavQcQWs5/48C1mKwV/ucXsXzVn3l0W+f/BwYo4E7tehiHexN6fjH14oogcxq44f30o Iiix+wu+78qf7j+zECCPvgEQ6087b/53/Oj8jf0P8T1pr9O3rPk39j/6b+nje9z+95T++vhv6TMf CdQof29aRDiNGhARRfWm0iLUfL1DQ/39qLTg8MBQf6p1eLR/VLh/NNXcHsE33ZmqzglZURF+Mb7E zl345rua6pyMPW/oraIiIqKpwTRajD81yJtGDY8AMqH+sd7hvv7U6Aiqhf1cO2JLnmnqnFbBgRBG +UcB/TCiHEeTGBHuT0PwDYOmq3Pi++jQyH10aMRGOuEEAmpwWCS5hR25r1gYsbsODzCJbyaEY8c3 EXIJjg71J7bxodBz8X1yrPy9/YBTGlHA+WvR/NHBvP/Zj3vf4vtfju5/5hYR5Uc1j/CNwTkm9gqy c8bzIIsQLJ5WZ5Sr6/xXe6D9/SMNYDnACoCVAOkAqwBWA6wBWAuwDmA9wAaADIBMgCyE3K8J36dz M5y3AGQD5ACAjUZyEXIfp3yAbQAFCLHNElIEUAxQgpD7O+0A2AmwC6AUoAxgN8AehNz3qRxgH8B+ gAMABwEOARxGyP2gjgIcA6hA/mfP0L9z/G7/ro70ko8DDkEC+zdxICoKFffx6RgUQO6PhZdvR8j9 tfBxwucRvv8WPvUeIOQ+XhwUcgqKUMj9ZKlwxveUxT0rPudcKOTe4V4Ucu+spRRyP601FHL/rmwK 6Ve2U8g9Zw9QyD28jsMZnzFnKCQvNRRyn7B6ytj9vv5gLy6iHuHooR6elgUwj4n2DfKPUqXa+Zp5 h/uF+tNoqlR5qlNMdEhEHC0kGIE5PdIO6v6Yxvtgj1uzUHW/iGjEDM/DN/0yCY8OighPoNqpM+EC vHg5Lr+pM5AgPI3vD/eD3Zg6RX0KYozTKHZ8jO95TqRtl67OK7lIIdKeRqtVz9HTb1TD8X2WGUYP P1ezkued1NEdE/E9zrP9SNuF53EgXE7faCK85F6qupr46LARHcNHFaNw/LRL6hKJQGHGXqr/YS9K qIkgkp92cEZ5N07ZvlgGwTcAxfMYe1GS7QvpHozcM5XF+Oc9U388mHfgZOzyShhiFNcdTa4D49vp pQjiLRwgQUXUCAlIE5yOYwmQ8MaViLgaIicCysCKEnpozCmL9NCp8SCX+evHN1EYtYcJl0vWxoiz AoXcSZmZJz6CE50J7YCRBdkLfXuPBUgoUzUhFhnbb1Juf95vFmJHOBy3PMrBhNssAtyib7SeFaIJ MZIs/FWFv7Ij0uKlt8rHKEytqFCPwbMGUUNrgiTLBMh7BSJT5gqQMI9Sp/5Kj60Atxj8w+lJAuD/ NODancg1G8m1QhSINC8dexAHhQk7Tn/s2CiDYXiFMcsV502Q3tqNiwVay0Gd9YIBEi7+oXoG0E9J JvxfuChMNajg2ybSS1K4+ZlKVKZStadMo+pO16FOnzZlBsgMHxuyHz+eNUewK/CNxf6jZq0HRuW4 fuSe5OAAcM/MgUWYd3CoHjU6ihQpYoDY0/siSWiJ7BgZTqLjuA/xziiOkGDjWP+oYHyXP3XfiDAq 3sKDPvaS0EoSmUr0QxX+2sOZPkMm7OQf248fR2FsP0iNPfE3ZyrriIaR1LnEfpyfE385P3+UItna 5x+1PvWPWguJ/73WAkTrxdAaY2pt7TIXRkQNAmpeerkbyoxdbWS8FotHjilxgVaMkqIxJR7gSxjU jqLM1Mwc7BB8v3+zkZYe2F9Ri8H+itpO7EdqwvSSkxjrWGpTNH1JevLwj9H+IMuP7RklF8eUmI3M ucXivT+1GU8vYWflYCqZYm9voW7uYCYPVLUQdeAMP4/iiWcbO3bC3IyS9YJ/Z1RJ7WbohjnLn3kd stWv/YwHSxOFLB/1LOTcc/+b3oIN+ZHbsTxVwDxP5Sbz8BqqFIReg/yLR2+DTMEiiYUdYeZSncK8 9/rYPddZKLx0f/dyjPVg/+MecPzRvu6/iiXYf7H/+q9pcNJ3Dh/PepF77P7rM2EUcZuqSvgCSdBk zZG6vrxj91/XpNtrsrYCYXNF6XW/8o3df10S8NoRuCUIG8DAmsTEAbn/OoMD0oaT/oFR15l37P7r qky8kryI0fdfT2J9yIeLMDhccoTWYyZaEWN6S3o+CcJzM+oGM/eWSosY21uxMXXf8Y3dfx2vY4+M ckemfhoxlH10//W/PMgR4yLOPTBy5L7pvKxlAjiKIfB3ZM4Kes63kRxtes77kZxBes73kZwHTHVI DlnoP5dAzjx2pr3W/+pg6BTJIdcv58zoDvKcP+Sz/zDzx9Jn3ut9xbbOuJWhMggOQ/ViCB5jdwc1 ThlLn2OM3WI+k/gX/03LwkG3e0msFMJ6psIiqAKPahC/EdvDqOE/pgYVUR6RAaNG1g81foxHSDvF 3APcDkgRrSPY2ik8BEbS8jJvtWxFzBkFYtbgGisLadmRaDGC7QY21mZ703U4gk2ZhZ2phL5jsxk+ M+zotkBzBMsC1j+1/D/HFC/YfvYbY2ssYP91DXwtwKhJJWo2s/Oy8THVHLu3tA74YiviH94HK5iR VshMoi8Mz9/Mbs7JTGkrlE2il8RyCjDz8MM21WJ0fGZErGpGpBSIHDGCIgO/M+/Ynmj90FdrjiOc v69x/jc1GFpFxgfTONspzPEBYxdtHYIjM/hngIyuTKZxHv9BF2KJ+8Z4iTILJ1PJyCbcLFaAwQyR gbWDDF2ugvQWgmwszLis7c3EiDpmI9Ra2H4c0z/XmXLOP481mFuLEK1luNrpcQE9vrN2sbWAdZQM 9EYfgCERGS6OHyQykaJEL1FmEWHGYGUxes/FwsnV2syCaoDg0iFHX4dYEZoCdjFIGxD6IUPIX2yE VhzHj5qnTy8p56Ayc2FiT7WYZ+3sYm1vSXVyMJ3r7ALXJnaOthbUWQ5OVDH6SBgQNHBqjLHBqZoS 3BjQy61gtapD9FkM0SZGR+yP5LiA4CwHpDCDiTOLWbMszFysXS2o1jg3dhb2LibE9HCYRbWba+ti jbNo7mBnYg2iwlnF72lzGQBlbUImJKc4LzIjfLkjpBytmPphBfXxdbYVUUNmpAdkf6yIejpMPWL0 lJfOtY/A39c8bu6/p3mkVU3jpnAyW9VF5KHHWGUzr7XTuBdx/d4u9nP/aAlGa5CWgHGvhJV3rCVg bJqPywn3B2RkJUvHy8pr/4Pe/2xhPIia+wGvFjPeP9h//+fnL1Yj3kmTvlqXpPNDxkqy9HiSXMtL Ev5LlR5DiRHpqcQ1fvdFlkgpELgUiGvc54nRMTBku5938hjZqkEdB3rJLC41ppK/fDTkTDzxUYWe BtMYT3zEVenxqSrRCwWiH1PpMZ8MPfoj70xJMlkGWUST3hcxekSJc076bTKSFRuR/2SCS1m+doog E5c/PWoykyVokOOqSchEjB7XMmbDAjqm72PmsDqVaucdnkD1g8gnGMYIxo1Ki4mMjIiKpkb7+waF B+MSgTGM8ImhQfdDvaMC/SPECN7dCVoadJ7JeznkKKiOSISh47IjY6dK7z1DdhojEtEkJChGrydL jDIvnev5vD+O3wx6SRKvJFMJDdj1pwb7QSAOWugfBcpHiwiNIR6fKdBpMmRDahRDv2Tp2kTevSNL xo5FHkExF8bCk5ki47ldZFRELBD2o/pGhEX6RwdHB8f6g+SCw/HHeRGR/uHUMO+oEP/oyFBvGDh8 LuB36cMiwiMiI3AJ+wfGhHpHQ3ufBGo48cDPO5TgWXZEXqR+MPRHky5l8l4XY60kSS8hJSs5UoMc JTJlj4zqJQO3Kh23GJ2OKlFv1EpJjsy3qfQ2DL1n6IDqiMxIfWfIbQUhN17+doojk9yg08G+CaB/ JuFU/3hff5h3+FIx3ht/5kmNCAA19A3C7QX9mYZ/eGxwVEQ4uaCMD6ZF00D5/bwJAYP5oWrSx4y0 C4w7tXg/piHM81RyJM8eGV09ytK1lSFRcj07KnlShqQ1Ymj7KC7yzqMCXd6adB5I2ZOjIUafybz8 jnzMMxl/Jox3dsTSmJEWzH6Eq5/tCEOu5H2vFfxj77KBqaJbGl56+S70x7kjTi+pQbmYSny8aaB9 eExD2iJSFow4RpjeJp+F+b6XopO/d6i3LNQiZcyguYT1R5pK9JLNrMyRVDSsvaimoRG+IWBxqbYw rEpUfKTsCZmZIqPzFLesYsAJKWtcMu50jJUc0381H3F34xuBP8kPDcWRx4THgVOCHsJqj+Yd6E8D 3bOOJmz5z7Ns1I+Mjjpjbk1FyLlkhTBW+Iw5pUBIbSodhxgxepLIqG1njNwmgvMBGDl3Js69o6Oj gn1iooF3WnBYMJhahnkHC+JH9fMHW4H7cbwCrvEB4FeDfYJDg6MTiAr+AQH+vrjVCYcO4krFsDsR pPbL0rVTks6NAiFnSYRh/cb6C0bfSe5JS0BKXnUEA0O3GV6YYTcZdp2BgXwyw5iFDB+lMGLPfrZQ DEn5EJKKEGin6DHbDtzU0sBC4uPKbFVxY0uN8o4M9gOL6hvkHR6I12AyHaPWU2FEGuSI/pVNZFhQ spcM38DonSpCenwSx69tBH3VLGDFzTwn1BGxkRJv7rHx189xHfl8LVmQfL7GqDlVfXQtmywoj47F 8oR+vyBZkB1jvl/A/HaLAvHsDOdTB/6p0nVEZwSn4g8r/Z8jQ0mi5iShdgo3U83RX6HyJuYJjlcH YTydESOkTLbbgTG3o8b6RyWQUQZd82TptnRsRDBJyPInCzODXhLE+nNEAPMAJg5YBJgWMaEwiahB wYFBzBGBJsKIQSXpOsn4K0nXejKN94DBwzbOH3kwpJec5pzIPLPxG5ve9Kk6JqhkWCtVhOE/GVEJ Yw79dRz5o9VicIXyM3OF8z2RXiLBz88sa3rEQiODWuTH2IIxw0nP9ierHkWCTj7ogjATHcII44YN D8LAouHPgUZnCmMWMqItcr7JEHaIl46vi+VHOS+jl3Cy2jGVuFCdLTVJsw4dCgZBh+MBGdAM8g+N pPqCXgUHJJAmFWJoItqKiMT5otFNLM0XOPWnBkXEUYPwNaYOPYoYteWSTHJRRUYtFsk3w36I0fVK lugjPo6jdpVhQUfjp9H+KyCjVpPhhWURhp0lvc6fjcUsQkL8wu0UhV95x588DKzdRhxI6E+69Sfe YnT9NtbWSxK//YzzIsIhx8RLwmjITI/hmE05Edypa/yklaOyZkjld5abEYvx0jm4+sP9uD9bzY+1 wlIiY62wJpMVlhL50QojFFdGCabJrKv/9fuEZoSFZp7/ksRTfElkND6VpWuoAr2uDl2ndOg6ydA6 TaKc9GpklIdj9RzpxbcfPJLWf/WEMIvAchnkNO+HHo8aP2LBSbX3hviPvMFPVQRxKOETF+KW4PCA KG8IdsBLxeB3FeiLAMI7xIHKgHuPwaNVPMgzoOvBryzl6LpUjPBD9nSpaBDSUyXibFm6RBmyY0Qj pB8g14SSTBrGuD8xdn0w6qusRvSe1F5GJM2IKf9EkqR90xVtpzDbN3K+4CGNN/78ih4ugt3yjvbG o3eYRN7RVFiwR8TR8GUoBIywlMSfboAK+eDvhdEifIMJsxcXHMQ8r0YjGNLLkT1m2GaGnWJoD2mX GDOQXAWRs91qRH729JiRET+O+hMx+niRESADK4MKLr2J9N6b8TH7q+ggXDNGNAhh2FnNX479n0g5 l6BzGKS8kImOY1REdIRvRChV0dpRiert5xcF8TThVRRohPLRIqP8vXFvERkakUAsSHHnAUKnRoCC BuFl9DHAjRpDd8khENJBGO+5kJ4e1wsZuvYx5jAjNmZ4HUHiiqFXCvQ6o6NC4tMYsyod9aZWyGh0 oznSbuyIMWzpj1rNPF5/ItECQqKTx7VTvJgkSkqKPl29qZER0fj9GeLGkk9UBC6uqChYyUNsFuYd GUnoN+6Ng6PAHUXAjIfM0GBf4p4IDIRzRBhxgwCESyNvOjLLYOxcY3jN0biK7PeoX2FIg5zpjHwx uiyZZwZDmyURhn/TpM94Rk1JZNTvadJHELe89sjoXQbGGDJ85Z9KllztFoBkp/9KsiP3QvzAf0fR SN9Cv6sHuusCziQyKCLcnxoe87O0mD0lY8RJPmXpnDJ8DmNdIznSPzwGGPUqJB6ynj6d42wu5ucZ YT7+USPDrIj7NcLm46wRY2pPp/vzCMiORBujlnqUHkO2vHSqU8bc9feHWgL0Eg8B5vslICp6HwXp 5dcFmJ9lhfvHUXEafxp3yRBYBMe3U3iZsIzR4HF/rS+89NZ3sf8mTmEue4mdFPGlvPzO4Id86n3w b77LxgWRAc5RPcWUZTLkCUG2Fw+sIe1dLJzsicc9JrZUFwtbCzMHO7u59tZm5CMgSDnYj5NEZiLT kWmINpz1IYVf4yn8PRE8X5NeZgP/8BJJuBqtJ0rPw/8yIgteOjenifiEwQ0V+fH5uRcPAqU/jg3Z mgPdyIO3xut0//Lpe7cgjpfRmpTg3r/53gD3yJnEk/038fCMjAijN2N5xmWxn0Lm4TV+fLOJbP13 3mS69TffZCL1nw04/dW7xHz0d61YiRYMqmoU/pFWeLQth7Ei7ZQcSheGQwPWTsEhh/Lr97QEfkmJ vN/aAxQZpcxt+H6ia0/QnYysRGkYDlvRJKwcXYGdQddijWgW9gTdgn1Et2IYloeJYvnYZAAtSFtg WzFnbAvmjWVhYdhaLAFbjq3AkrBULBb+pWAhcOUJ+U5YBmaGbcRmQN3JWDbgyAZcW7BedCPgzsBu Ap2z6EpsP5qC5aOx2Co0jACcF0Y//17PbIieTUKeU/aizykn0BeUS2gXpQl9Q3mEfqS8RgcpAyiK smE8qAg2HpXF5FANbCqqjxmjlpgD6ox5oZ7YEjSY4ATnKBr1w3xRd8wJtcfMUDNsBqqNKaLKmCQq jQmighg7imHfKX3oF8orwN+OvqM0ot2Ui+groP2K4GEv+s96pE70SBRpxoZRHFqwIbQVG0TvYP3o Xewzeh9G6j7Wg7Zhb9B27BWUdQG8hrpvAXrQ2yD1W1CvCfuCNkK7BuwbATiuf8YZQ4sqUFEMh1pU ButAFYEvDYwXxn4Spgv/ZmL2mAHmA+cYTA9bTejRVGwPpoydwCZiF7EJWB3Gg+Hc4FxdxTixM5gw dhSTwsowedA3FWwVNgWLxqYDDm3ApQ04tUCrpmN8mAb0SRl7ik7C6lFx7ATKTwDOy7/TswnoRBQH IXQKKoAaoXyoA5w9URE0HBVDl6GyaBaqgm5HtdAjqBl6AXVCb6K+6GM0Bn2HrkGH0CKUk+AG52o7 yoJtQPvRePQVGoC2o65oHWqFnkX10IOAvRCVRzNQGTQZ8Iah49CFQMMBFUWNgf5UVBqVIwDn5Z/1 TJnomTCiiPIART7AKQi9EEGpQFMKaEvCP3HgA6dEUp0IZTLwVwquxKHNeFQR6iuDTFRBFjief0e/ 68AS4NCIZYOuZoDOrgLdXQYQBxAJ10GQ743WYj5QLxi0JRIgDmAZXKdD/gb0OrYZvYLlEoDj+ne0 oAvdh+IwiB5DubFqmPnnQcMvo8bYNdQJu4H6gOYvAUjDrqOZ2BW0ELuI7sFOoxUw7mexg2gNVkpw g3N1HtuBVoGtPYwdQcuwSnQb1MsAfMuwS4CjBnDVAM7LqAngmIqdgxlVjfJhx0GXDqLdaCkBOC// Ts/CwS7isBjtpwShGBqI8qNBqAQaAuMaCVodi5qCRjqgq1APdBMaDFoaA7RT0Sp0A3oN3YreBd3H ucG5aoPSWnQzehpdDbwuRXegS9Ac1B9dj7qjy1FbNBF0OQadBrkKMHvEQcv5AViAzhdKNNhNHHBe /h39LkCvUrLRG5QMtIGyCr1FSUNbKUloGyUW7aBEgVfAKeEU48A7JKHPKKnoI8pKKF8H9TZC/a1o I6UIraPgeP4d/U4B34FDGqYCIAvpcWgcxo1GYBTUH+ujuGNvKbOx5xRrrJviin2g+GBfKSEYC/gh PjQemwAeeiKAMpqATSMAx/XvcEbFZqI4qIOHM8As0dmYNToPwA+zAu7MgbohQQ2nSsN0wSsaor6Y KdQxh7rmqCFmArpqgE7EtAnAcf07nL1D31JweA36+RqlgFXlQT+BBfoKNosN5CiETSeo4VRFMQ2U C1NAEUwaHQAL1YtyoR9QBOALpRd9TwCO69/hDB8pHAywRxR1rI0ig92nCAOwQ/ob+hioPSeo4VS/ QCQwDDrGgXVAnUdQ9xFFDdJ69NHGAcf173BmiLGiOFiC7szBUHQ+oV8IGo4NU+IAlgGshus12CCk ByBvgBIO4AvX7qBzDtgQZRbENAZQBwcc1z/jjGFttNCZGAmymA6MnwH6BrVAm1F79BQ6H90F9iUD rEQc/PUD6+EIVsYI/KkG+EvwejBbZDFeghucKxmIvFCIwF6CX2oAH3wC1UeLwcqsRReB1YoGu7MO POx21JrAcgvVQV+jmigrNgWwTAUeptJ5+Wc9Y1gbUzQaM4J5YYAGYPoQQeqibtBDRwBr0EwzghJJ 1QzThDxNGJnpMH9moIugPBDqR4AWx2E4nn9HC0xg1HEwgJHVxXoo07Euigb2mKKM3aFMxppAB69T xLFLFFHsKpzrKFTsNuS3QflTqNdNmYb1UrRBG/QxDMUBx/XPOMskOLNAnqLZGA5vwe99gTUAii2F aJGGjcOCMRlYPShgLhDXWUOMZwhxoyZmDlGgDSYOkR8vrD0QzA3i2QXYC5DyPdQLvK4PeFBf8LK+ EGH5gv/3wVag3lgMSDYAXYjNA/23Rl1hVJzAXthhUjAv+InekL0ShGsZ1BZTh9GaibpgNjBy7tAm EGjEQPsVAJuB1nY4H0Q9gNZ88PjzsLvoXOw5jOIHwPkdRpQb+BwPHOMxrwZwrQ/x7Sy4mgOcL8CE MH+MA4MZCGP8GU3FumH2PYa1EA64LP4dLSxHD2HH0APYKbQcoofdwOdOWGmVYHfQAuwBmkdQwim2 wequBc3FGtB87CpaBNHHdqwKLYWIZDe2F9rieP6dGW8ANggHB5i53pgYRDiTwfdNhRWmIdC1BVrz IUoKhigpHqKjVRAlbYU4rxTWL8dhbXMZ4DasczrQB8D7Q0g/hLw26OMdbBfUy4aYbyV6CcapCvNH D2Ku6A7wWFswPTQdU0NjMCp4MBEYd07UCOyZEWHTWP6hFjPWl6oQN2uhbKg5+o0yB+2jeIGdj4CV Xyr6krIJbP0u9CnlJPqEcgPODwhf0EVBwcOLwrxSgnmFc4JzpIJ9pozH3lEwrJPyHuo+BN9xA30A bdsBxwOIRR5SlkHMEg44FgJ+e7SHYowOUKbBKlYBvCHOx78zVixgK3EQgBhNGiJ+DZQXIrYhigtE SUHQk2T0LkRUjZR96HVYU9dQ2tCLlI/oJQoXdoUyEasFK3ObMgd7QHEGC6OP1VMmYTUUbuw81DkD dc/AmvgcpRzqb4aoLAkiLH/onSN4RgPwz8ooB0SEEig3rIS+UywJIPj5V3oWheZgOHiga0E/EsHq LgY9dMdEUQvQDU0YBUmIv1ix9zACryl3gafzAHsgQtyIfqDEg7S9CG5wrj5RPCE/DkY5C0ZkD4z0 eYgm70H9HhgZDrC20jCy08GuWIP+eYCuh0OEtAxsSgasV7YRgPPy7/TsPFhLHCrAUpaCrdmC+WLL Ya0cga0Aq7MRs8C2gTXaCWvscrCcB7FXsO64BVANVmIHrFHWgnXAucG5Wg3rke0wi6rQY1DnBNQ9 gVEAsxh2GNbrezFLbDu2EMvGorA1sCKPh1V8EGCdi1VixtgVsHY44Lz8Oz3DNQmHAPBbSVg/JQP8 fTFEwQfBip8CX1uDzYWVXwjajC0HK5EPVuEoeh8sHm4tbmED6A1MgOAG56oJ7O9dbJCwIo+hzmOo +xDLg/ppsLIMBivijJ4D330MU0R3gVZsBs+Qgn2kLMaeEdqMA87Lf+rZsmXLftMzfBcGOSwNWQZx SQJANEA4QDCAH4AnwDwAJ3QuugANgAgmFspXQd0cNB2io43oUVhhnUfLId45AautSxD7NKEf0Qfo N1iDcYJfEQZfKo3xYYoYO6YKXmkKeErw+6gO9ghijxawN/Xg8a6hpuC97LFO8GT9EBlygraIYQkg p+XgtdZhdthm8ML5kLsDS4Nx34wdAt06jp3ATmFXsYsgyatYA5wvYadh7E9i+7GjUHMfloOVQeti bBloBg1aBWPrAc9K8OYp4L/jMBPAqAO5Gpg3poctwswwD6DljrmCDnmC7gbC1RLMCkvETLHFwMl8 8KKzgSt9jAq9GYdJYTwQAVCgX33oe1hxPkEfQ+zYjF5Br0KMdwpWoYcgAtwB69StcM4BOeXAej0b PYNuQWtgXdoIEryPZqIvYEV6F1akNyDSPI2GwlrVC+JEZ6hlAdLWhghUibi7441ywkh8oVijnWCj 7lCmoJcpcugRyji0iCKG7qJIoeUUWbSCIo+epaiCTdSElaMuWHBj8ARW4BUcwJq5AZ5FYKeD0Omw zjUGirYoPv7/SZPG3kX+UZMmEHOEC/GB9c98WPPMRwWxxQRwYT4QFePnxXD2IUDoP87I31OTJqjx InYQg+PgiPLA3BMEaypEYMepeAJ4ACxEMQAWAvC6/4yyEEGZHSgnoSSw0LEnoQvpef+MghxBQQBZ gMagvmgYYA0jZqUjSiOwk5SWoh5oMszPZKiTjIYQdfEzmcbb/jvj6UtgCyMwhhAQBpT8iXMInH0J +LeoTQSs4kRfYgjM4gBCRB5+JtN4nX+HmjiBLYbAKERADFBKJs5CcBYn4J9SY+jqFBg3HNRgHOVh PKlEv8IIKtIAsgBUGFcq1KHS6/4zygxdnQL6SUISHTsLRqXn/TMKcgipq5NgdkvAvJMFUIR5qAbz cQqdChXmnyzMQxkACQBhoi5+JtN4239nPCXA40wC6jhGYQIEgZIYcRaGswQBnP8SNdzC+QA2CQLE IC1GWDzyTKbxOv+JGnn8FTUtgpoY2FUcMxfYGS6I2zhhXcEBFo8FIAmsQxzqDjrrOTJzGJoVAzFz DCoHIA91FKGuIrSRh7ZygINKjAQOOO7/zOmfyeUl6EAHYO1ABbD3BHCBX0eJ83s44+mX/5oHuA3a hUML9Oc+ygdRhSCBHafyFKVgT1AEgAJpjAC87r/TzzbwmrfR1ehtOuankG5Ds1AynyzD0/+MGmMO vwNMOLQRkAVpBvxTCtMJCtArWOdyYMUoO5YLsJl4MkTB1qDf0ZXoAJqG9qKpKMlFFvoB4paPAL0Q 2XyGOKYPYpp+iHH60Xz0C0Q6CLabOH9BdxNpHPe/I/VhFOdwK4ERx8wOwE9wjZ/JNF7n36HGDuv4 YZhJOEYcMz8WBpT8iTM/nNkJ+Le83xqglApzFceIY04FjxdP5OFnMr3mX/N+qTBea6BfOMZ4AoqB 0m7iHA/nVAL+rXFbBlhXA7ZUAnZDejfoUTH9TKaX/eNxY9xpzAdcOGQDrUzQ3XWgw6ugpyvQDZCz GSCXoIZT3Qg1NwJXm6D2ZviXDakcIgcvyaLDP51lDDmcIJ5EkdzhmA8ClEHeCQKWEWV4+p9RY1iN E2CXSFhNUCmDdBk9759RkENIz78XrPoOsLflYHcPE08FOQnsOJXdYD/2wCwtg/N2sMd5UJc8k+m9 /5rn3w6Way/4GhxjHgECQGkCcc6D83YCOP4larhn6wRs2wmYAOkJhKcjz2Qar/OfqJHHX1Fj3HXo JDBzgRfjxB6CXWhHWbE2kG4bjOc7gI+g158BBmAN+RXNgJX3RrBX2QB5IHvcMuKAWxEc8BmHz/k8 gGyYFxthRmSADq4HzV8Der8GtBLXUBww7CDQ2g+t9wDt7cTo4bz855792SwNxMQxHGiw1l+GjYeV ujCs2HmxEowV24MNoQewD+gh7DlaDFCEvUHzsV50CzaIbsAQWMOzwKqcHVbnnICDiw7i/xJnMkAR B1ngQB77hmpgbJgucGYBHDoCpx7AMck9F+YJHMwFTmyAIxPgTBc4nI59QqcAxxqAQ4OO659xxpjR MlgSSsJzOvYkAvC8f0ZBDiFntChGQ6UIjEvpQGLHqahBmSIWjk7EQqFOCDoZrkUJSCLa4Ol/xgVj jkmB/xMFrcUxTiYgDCjEoGQ+WYan/x1qvoBtAWCTIiCGeM7iDHm+BPgTZXj636G2ACTlC33CMToT QAMKISiZT5Yt+MfjyYiQ3QETA+YR56UEdpziXBhHBywCtYH+WkOeNb3eP6PM0FV3sIIkJNGxdxCA 5/0zCox5GgG2FocQ7B0aiL1FfWDOLcK6UQ+sC52PvQBKzwhqOFUbsFx2UGcOWBE37Au6EOapD1iZ YOw74GDA+3+Js3SgSMIzdAVwkgYcpQBnScBhHHBBA45J7r+jMQBJwEkacLQaOMsADjdBnS3AcQ7g yKHj+ndGJR1GgoQOOvYkAtL/NQsSB/q7DLCtGKFEAk5lM5RlgAVZBdq3DGA1XMcRkES0ifvXLMgy mLNxMLtwjKsJCAMKMSiZT5Yt+9csyGnAVgHYlhEQA+kYdD/knSbAnyg7/a9ZkAqQ1GnoE45xPwE0 oBCCkvlkWcW/ZkEOAaZRWIoeAcCx4xQPggXZA+O5AygWQ14xvd4/o8zQVdz7k5BEx05GA4f+wJ+S x19RSCQo6CO7AVMZzMPtMO/ywXtvAk+/GuPBkjF+LAoTBA8vhC2EsxNcW0K+AZRPh3pqUF8J2ilA ewXgTB6LQyfBmMti0eBBcA+KexQcaGBtosHGx4DliQdIAugAeAF5r1BXmOcLIMpYBHPeH/uMLsb6 wCb0o9FwToDrFMhfAeWrod46qL8B2mVA+wzAsx5orgW86cR8wwHXQRxoIKFodB+U7YE6u6Hu7t9I jLz+cedAxt6HAvSz4A/lozsIkteMnQB5x+Qzn8nvABqwLuIri/0U/FsBcp++X71TPxb76Pv8+Hn0 q0ce+g4fa1BTFpxDxrcJP30bgZJ70uH7x7kgAfAP/1JOmfhrBWcXOPPSMc3iHPuVw+z/+JXD7/ib SGBlx0xZ+JmwOruY2JubOJlbzye4Q2YSnI3+U0ZmMXHGwM1LxxXKMZbDcSPUROg1lnOwMVOzMHNx cCJpWDH1lR0z5BqLSe+PvuhgaIg8gaUY+iY0pm/4foCOFk7WDuZUzSlTplLVkenE9yT41yUaxNcn jG9NlOn/ROkcFWOh7MwcqSES9D1QirHV7KzMvALm6U6jGEieKCN4zH+Q0Z99q0JiYaHTTEU38uA0 Gd+sgEZRNZ1wKXoSXz/x0ms18TJ/2YJ/Kc9HL+nhRZlKwsN1RnZ5SEW9+H5sxShJG1NigZj90LtU tGZMDepPXyqN/Zbmx97JEFj6oHe8TFhm+ftExXhHJeCS1URnIqrE18o6CONrPcaXZmN56UNZ+f8J L+T8DcU28ggyYXGICg4MDvcO1aNahAeGBtOC+BjfvzG+vsa/PDOjpyWJL6/H8hWKxf/A1++/Nxo7 n0nP0UNBie9zRAh/gqeE0QCJ0ZS3MJnCvxdjpBB6CwpCodfzlxhNedHrUZDRFIXeAkVQej0/idHU Ino9FBlNMbgCR0Sv5ysxmvKk18OQ0RRGb4F/Y0fm+UiMphbS67EgoykWegtWhJVez1tiNOVBr8eK jKZY6S3YEDZ6PS+J0dQCej02ZDTFRm/BDmNC5i2SGE3Np9djR0ZT7PQWHAgHvZ6nxGjKnV6PAxlN cdBb4Hv4knkLJUZT8+j1OJHRFCe9BRfCRa/nITGacqPX40JGU1z0FtwIN73eAonRlCu9HjcymuKm t+BBeOj15kuMpubS6/Egoykeegte0G8yz11iNOVCr8eLjKZ46S34wBqRefMkRlPO9Hp8yGiKj96C H+Gn13OTGE050evxI6MpfnoLAUSAXs9VYjQ1h15PABlNCdBbCCKC9HpzJUZTjvR6gshoSpDeQgji QjLPRWI05UCvJ4SMpoSImf4/x/97hwiyCEaBghSChmDEaOAwH0GMPwyjcOYZqckG3pTxO2z4htz4 Xpq8VyEqFcf2sExnu8h+AQ7h0nj8l1zMbCYgDjYIMgdgkRWFJcyKk4MGEG3FyeKHUIwpYBn9mHBz QrTjD3j9kGAkHAlEqAj+GzcauMWVo7DJUfhXimOCK18OCZd2UGbIUbTlKDpyFF1zFsRYHrGSo3hC sRcUg9WZwZFmZiOJQHyEGgsCFb3fUtEkclFEuNSYYiyPeyGcc4it/qDtNCIXg7bXgQ2U3tYKYTGe Cm2tftsWf5aH78LEe5WFIo4h/CufQPdkhozlMU9IekESPCPCamwCmDR/iwnf1Qm358byuB/URNj+ oI0W0YYN2rASbdj/oI020YYd2rARbTj+oI0O0YYD2rATbTj/oI0u0YYT2uDfsJojJsYfh3fAmYfC aDMOrvxhXeCNxIAeRkMbR+K3Ar2hPf43EgmCvFnE7wRGEy1ckWDj3uEKOI9i4YHo2hvxAQz+UHus ZkN07cqNjO+DmUD+HCQjwYWFIt54Nkr8xpMiEoJ8Gr6I7+s0gpedwEVFbKFHNII+Su+vPCKOUCgf 4TzKBStw4QDRESkrlPh1KzzGFqSgFOVf1sO1jg1ss3CpI1FXBJGlCP1FXU2iriBCTErgSxjYnEix /2XdqQQ2IdBIQfp0xmqwuROdJl+4fol/ZQ2o50yYfT2IJ6S9II33Rwz6o0n5dX+0if7g0bk8MgHq mf5FPS2inghRbzzUc/qLejOIeqJEvXFQz+cv6k0n6uH7C5uClHA7Y8pUj534PUk/GPN4Oo/iQJV/ 5U62MVaFMCk72XAc/P8BhxaBYwLgWM36M47VrDgOvv+AYwaBQwxwhLL8jCOUBbdmXAQOvb/EgY+f EGD5sT0CM+G7A26RZo2Zd0Fj5t0iYidBMVjD8a9EEEEA4dLtMAc5PSHptZJoYwo6//t+aBL9kAQc kpSf+yFJwXHw/Acc0wgcUoBDG/0ZhzbE7eqIovFO5AlFnak/3MR8C6fPZfz3Q30gHUWUzYIVCAXZ SZnFRJN3DM2xNgiXo8wv5DgPoeJ+C503xifidiYC5jlJTQmw8V4VGHGJqOn4PZMRVLgU+RkhO6KP +yohBHRXBjALoS5jMDO4YmCWRTA5Cu9VrhHkyK/QesuRXgy3kvLITkQWZbadQiP8htO5piJOhDXF qeC/v+oLf/FfgsMZs7BiAzlKgfQ0UZ8x0vsZiwshS9zeqSGTcK/Ne5UVGlIugEJRQKGGfx5MhAKa hd9dNEQkof+mqCFT/3nH2GTqyHiRNp0LkUPwmAB3/PhvwH538EadUB2m9sz2fRFohz+MrD+BA5ft ZLpNjIKWFMQHjWJqyTWm5Wi/jPDfLbqqiZHi55OkaKPOWDjLOtYyGIsHHF84hbk1eGx4A/jS+JEx h3CpIiICQB8XVzpN1zH6O5ZmMFAMJUYC32EGxp0Mg3ivciDoSu6P/Hig1UERgT7g443hUQ94QRzv ctSRCS8H0Wd8PuDYYgkrIQ/+ajSecvxJg0aCKWQmYExDN6Mzf4MRn/NCoJ38K/ewCK6kffeEsxec wWNC603oTnT6b1rjs50L/A7/yulsngCktfJGj6Gz/nJEGPMCBIuo4LIBweD9EAEYlUYAIY1LaMAY nZoFkg0E+lG/0Ao1RBVhiHnMJBMB1CI/z18WYo7MBzpL0Kcoc6TM8wMd5vFUBDpscsiYkewBAh0/ WUw8+sH7gOLRzwhuoR/mhTf0lLQ+VOLXkRl02MBO4lEt7vdxLE9R+zH23wR6HU7o9iK6BUCQiRBx j+iaSOmEn1jCxYt4Evg+op5j9JcZH3N/5ZEpozjJrv4S72jkjuvNB5Do9DESNYG4LpI+VsFjuEYJ rcZtAAUTwphtAN8vWjHzhhLaO5Pojyk2c4x8SOxj6/OAvmJ4LzpwjjHcfv+yNQdTa4b1EIJ+MWbd 6Awjx8YJsx/T2gJZArrD/GvXkyBGgLUWw6vwCE+Qv3jpZ4WBuUHYFox59cHCNGPw30Ljvco7ot0U dvELv3ROhDzTsM1j5ElKxfcHqbBBHIUPLBs+giASY4KHKMx4jDdjtMS1F5eGDrNWdJAaoE/XAFN8 TmFElDCCgX0EA2PchWGt8MNMjUdGuLChzx2bMZLwJWYNHuPLQSw1urbEo51f2UEM0YIxNiRwTaQw +ydW6D/+u+VUBP9VXFFEH/qDjmHHWw6l26J5iAZMxEvYvDG8jK4QZoAWjYkaytgcOC6A53TgEFx5 tP9nxhw4vCAfYczF25jnGEkxfjPdj+AQgTE3GDvq61gB+TpWwZWxg78afU8o84IyhO5TnmKOYzgn 11s450ogmzGcD7GUseGcl7EJrlwwgC+NPSHtBWmEnC+kLD9ihmMw2tPjCPyugtHYuwrGcBCLHWbv ibIwe08OZDa0TUDiCMvoB1JFwDMYAx42FEcyMvH+2tXBLMXxCrHEE/eTyYMV7Icz8KZOWBgT+Md7 VXGEMS5tNBx6+4BDmNuGN42/SvC9sPy4CyPHL6eVEGnlRJAwK4QlHCCGg0LGIBNZmGMQ/p9swI/e ShdmxxjJf4U45BKT5H/l2OkjwbA7miz2YzR6DswMhk5Oxn+biBn/NIhx8JF9ADop1+8JZy840zVc C/famA+mNUYPw4Bbf6IHZFzNB56MCAvrJMENTEHxmJoYzTEzg2OMLyHthTzIY4y9EPlF/8bYEBfw 9vj8d/nLlQa+UlQBTz1G2/Bq/CudsZ9l54wRfEjA2jOK5ddrT/zeBUr8qrItQq65bMdYzx/XXMEI Quwd+FdrLsKWgQHSBGxzWCZizHdOuH/h20hZodBLvP+k13f5oQ0+bxf9tOKRBDtJ92y/9c2/sqps I1hJ+pL4c9jf4GKMEN22jIlXOUdwMXsYSZAjRkYPv+VOHTAeZUER9TFaaAZyx+8KjcrHjq61U6D+ RZan6BSm+lxM9cfGCvh7nqR/vY1ajek/c7SHR1EOzFFU/C+XaISGfADazBoi8kPcGEfQDwKuYwiZ MMd3nCA/iCNFSokfDFUmNASFM3PPGXZ6tOdz4K8qPb5SHTPnRuuOxlVO8HcKEVdNZB0ro9HaY2Xk jOD3+SDux56immPwM7y3OWHTyDWmC+4zcTdJxHwmrGNjPrINbUwbFJnLWDdPwGNpPEZB4fxjpEFj 6rPrCE9OrJpj5MOoOdpjNybs6kQUEsXKrE2cI23G9nseQkoKH4OxknIm+j1qxRlc4fuV6tFnAPN9 Zt6fWoylNJ/wg5L0tmPvUbNB2whCe8hVPA+ygJw3VtiYeeIE1CEeYXUacz/UnIgWYgirja+yqTBP 8HmAR1oeiJo5lWJ3Ff8dT1ixp5ItHGxYkDkAngBayFzjncgtVq0x0rICr4zbqCjCs4QjIUQ7Q2WK qTIaGYTjskLygZenrFYEL/6eKkQNU3qcFkHIgPnuAgoxjwhIQGAMdW8bAYIi3h0DBeKtpWHympFi HBTkVweeO+L3OUZb4LhYEGKzeAITXg/l+Lk9Xm/0wB8u43v947/pgu+vgffJBSAMweMMBFkFkAeQ D7AN4DjACYBagDqAeoA3AG8B3gGwUvB3oaAtQAJAGsBygPUA+MtC+LsTk1kRZAGAFriwU8ChNgxV FwwFGy+C3OWHCFUY6ogiyFyACeMR5CBo+DRxoC0BKyApBDEE2AiwgIoggQDZALwTIR6Tg/oAkwCq AF4CKE9GEHeAdQD1AOzyCOIAsAAgEqAAoBDgFMBpgDMA1wA6AD4DiIK0xgGMB5gAIAYgDqADoAug B6APYAhQjgt0Cl2wqThQ6INI/dtl+b8qY6G3o/51u7/G+Xf5/F273+P8XR9w3dIaU4aMHL/EiZDt focTV/q/wjmW3gmE+fhd2Z/jrEeYj9+V4TgNfoNztOwdwnz87y77HZ9/XZb6H/uH/KadxN9o90MZ K8J0/Bdlf5OXrFFn8lMZ8hs+6e0iycs/pxcrjDAd//eVIf8/7vv/qeMAumv8l2XseJnsj2VfRst+ h5P6V+MOZf89L+A7fiob9R1/r+z3OPN/VcZClv2n/v3vLvsreRLBIqOMfmx8XIw/8Wb/j/ZMgLlM CjFc0z+FghCvRf4fGWP+r44v/8+KB7f/Bmfqb8r+brvf4/zrPmwn9ODXcdZf4ETIdr/D+dexW+oP 9Jhjvt+X/TlO5pjv92W/i6XykL+Kz/73l/2OT66/LmP/XTt83o+OXxfzq5bsfx0T/diOOa5L/dFm MZf96OPGlP0O5+94GYtzDVM8+CPOMWX/Bc7Vgkzt/q8oGyuXMWXs/7f3/f8r44D/HfcbMKGDFx0e ATzBG7EhSDBo+gJ1mPcaCPGlIf79H5VeFgaKfxxgPSf4WAgQrkG9mRpkXTGoAu6Y+N0S/LdP8a9L ZBGE+PIJb4vXA5dN8H0I4AhC3tkS1ssezlmJU4IKxLMwnBNhWZHhnFRw+z06CIGgB6+B3x3DYxMc KHTADY8xIv1BAMHvouF1h5HU1FSkH49w+BG0ZzOCpzh6OOgN8ICDH8F6cNnxIyw9ikQ+Z48A8vOB IlxEO4SF/KADr2+K4I+YyXzi+zQ+BHFGuHtwQZ2n4LTqCC+H38/jQFgwkBVihFEI2oI9LAjzjUR8 MNiQc7d9WPDcUEUZuDpPvzpAXF2AK7xti4ksXF2kX2UTV5foNf2OSsPVZUa7u/hVDb3mG+LqCr1M 9R5+dZV+9ZxNCq6u0Wuaz8DpXaeXrSSubtDLaoirWnoZixZ+VUcvO2OMX9XTy4aIqwZ62UwT/KqR XraUuGpitCOubtLLPBZOgqtb9LJC4uo2vewBcdVML5P0nEQo1SxuEuwAFEHjtOmwXw5BLtGBczIJ 0+kQQIdCOrTTQVWeBEP6rVYKXc0IfSFUjPzRSfIjHRTXZ/jLTuRwEGlOUluIv9zEXx7iLy/xl4/4 y0/8FSD+ChJ/hYi/wsRfEeKvKPEXZ2M2oHGggzr0S48OJ6FfNXTgmUyCPh2C6bCHDh100JAngdE/ vGeMyYP3C+8V3ie8R3h/8N7gfcF7gvcD7wXeB7wHOP849zjvOOc436J0HPhDSlynlVNjosL1aL5B /mHeNLWwYN+oCFpEQLSab0SYXkRAQLCvvx4tzDsqOto7kMaaSvzoKJKqQyfw3zRmSfXzjqa3Ffmv 25oFRycgqbr0jvx3TDtHE4RN6RL5bxrzpfpGxIRHRyWoRfkHBkeEI6kgYwqFPgaUVE00VXMKSyr+ AR6Wau6dwJpqFxEeHcSS6u7vHYWLlxQy2WOSd0YO+Zc0ZfzE8JIKSw41ToIFQX6q+W+l8eMowDEA cdCdiQDRAEkAb4DZHhHyPj7jXj4OS+RH78vj6ol/28UOXmQUWAjApxs55ch1aBxCrkXT6TQrAA6C +pwFmANrxHnjyXWhJYAVQJYUuQ6slPs1D/gzhWp58lmBtsKveGLAtF/AKI+MWsy84utl3O/ha2B8 3buOQsoHN1+MNa4HlVy7fpxErlkZPEb8wCcNIANgm/zY5x7jfsvzj8BC/4v+VMLg+z+P09hxGR7G tRF/wuhLvG+DP+MzJb6Z8CPet8DfM+ZHbKAsiHjqZoaoI/hX1aHEE0Ea8QTvf1cNVoJH/C1HGnEV gwQSzwT9EXyeeEMJzi03tLODmmaQg78HEUo8ncVbiBBvkZBPz8P/n/auJiSqKAp/7/nmJzMKA7VN jiJDfwvzLwjCn9QksMgxcTGlzx/wd8bM0gJpSjGoRUHgMihoUZvWbcJttBGCVlFBP4uWVrSK6Zxz 33XejDOTlkmL+Yar7913zrnv3Xvuefecey8PV8CzmVxOh8ylj1LuNNGNyhoM7p3c59isfoICm87e Yi9qSrfhVXS3zEw+bm/E3dJz2DF7HmeaBnDLM4QbtbO4NLII7/4n+D7zFD/M5/hc/AJVoWXcOfYW XwMr2FX+TWSmi9mw7vEYMjVOo9uV9Z3n0dxzaHr+jNtYXm1GIt2nd7/7fJHONc2i89FEtjG+A+o5 U/mZJt4QDrdO2v1T9lj4uB2JRgKhuspKnBqsrDqK6eHIxYlodAyuK2H6tYoi8cQ1N1PYaRI1fRtC HY2D9Uh4LQzL9L/BvJXXc11GYV/yo/70lFPQS+03C2rk4MRR0mCeqqzpZHO7nvbdR8Q9UEmDebs6 gYpx9WHBGNH0nialGll7vl66brPbLAFvIVZ+exmlB8iMZlLtRmqFziw0W4GQdM4JqI1Vh3/P8B9C v4yTN6fqljBk7Kl/Bsy0umMg4fz4kJCVSc+0Hmq46QaQrGNGmnPNm0l+Ku65jkvyEzJT+d35qYsp 8rE+ZLsnfS1ZcmrdZ8e/sD8D4C06P+Pm6tPzAsyttz+NB5de5+xrzr5q5OwrHKqcfdXI2dfMWI99 zYsZ6KCBNaeK+iMG3yMfM/R/U/vPHBZsYHe6gSuVxfpwVtY2RsSriEiu274qKtUEpo6Auo7Z/z9R xN+P5q8LeyyPmWfdvEr1ShZLy3FEyGrQcfFyeKfrIJXHPo3ylNhvqiU55DF6DNPweU2Pz2F3R05j /CdEPhHvko3KbpjqoJS+3WuZjIyl8+rsYahd8tUbvmO6u9VyiMmScsqSeQyHxxbPjZ8KKDcsUiE/ ugqWqSWHhGT8ZV+w6EPfwspte2EnBinvGVXjwwA3tPLn5tCC1NwWp5yw2VWAeeTwR3jkXfLNYAYx o7CGVWuPGFCeXWgLqvQ3SBhpf9XcBW6n+Lss5GhTtO/jO6nb1gMfLTGk1zIl9uTj8UKHey/p2pC8 SpupP4WkNzWRKQrIOuxJXCbt7ZfrtvQ5GxxJiMoukjFHBvNyVKFfJE3ikNCsjUpwfhDpYhAbiVZs Ln4BUEsBAhQAFAAAAAgA6GJcLHsPyE2EswAAAGoBABAAAAAAAAAAAQAgALaBAAAAAHZlcmlzaWdu X3d3OS5kb2NQSwUGAAAAAAEAAQA+AAAAsrMAAAAA --Boundary_(ID_aGsQPlP2WyuIbnnpRA73cg)-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 12 15:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05206 for ; Tue, 12 Mar 2002 15:17:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08239 for enum-archive@odin.ietf.org; Tue, 12 Mar 2002 15:17:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07224; Tue, 12 Mar 2002 15:08:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07172 for ; Tue, 12 Mar 2002 15:08:01 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04758 for ; Tue, 12 Mar 2002 15:07:56 -0500 (EST) Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA21032 for ; Tue, 12 Mar 2002 21:07:27 +0100 (MET) Date: Tue, 12 Mar 2002 21:07:16 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <14653720.1015967236@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Enum] Moderated list Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The enum@ietf.org list is now open for postings from subscribed email addresses only. The other email have to be approved. I went through the list of rejected messages...and ended up getting a surprised....there were hundreds of messages rejected. About 99% of them were subscribe/unsubscribe messages of course, but some other were real messages. Out of the "real" ones, only one was from this century, or rather, from year 2002. That was the one from Rob Freilich which was too large at first. I approved the message, and that's why you now saw a message from March 1... We have three people which moderate the list, and part from them, I also have enough password(s) to fix issues. Reasons for having three people is that at least one should be "awake enough" so messages can be approved within 24 hours. Crosspostings between wg's are important in some cases, and people working on some other issues should NOT have to subscribe to the ENUM mailing list to be able to post here. The moderators are the first three ones saying they are happy to help. Other people were slower...but I know who you are if I need someone else :-) Thank you all for helping! The three people are: Eric Brunner-Williams Jaap Akkerhuis Dan Wing paf, wg chair, ENUM wg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Mar 12 15:21:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05374 for ; Tue, 12 Mar 2002 15:21:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08466 for enum-archive@odin.ietf.org; Tue, 12 Mar 2002 15:21:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07775; Tue, 12 Mar 2002 15:12:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07734 for ; Tue, 12 Mar 2002 15:12:47 -0500 (EST) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05044; Tue, 12 Mar 2002 15:12:42 -0500 (EST) Received: from user-37kas1r.dialup.mindspring.com ([207.69.112.59] helo=dick.ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16ksM5-0008Ai-00; Tue, 12 Mar 2002 14:54:42 -0500 Message-Id: <5.1.0.14.2.20020311092521.02310990@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Mar 2002 14:49:34 -0500 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA07735 Subject: [Enum] Final Agenda for ENUM WG IETF 53 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit WEDNESDAY, March 20, 2002 0900-1130 Morning Sessions Salon E/F TSV enum Telephone Number Mapping WG IETF 53 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … Jay Hilton < applause > . NEW CHARTER REVIEW - Chair’s (5 Min) http://www.ietf.org/html.charters/enum-charter.html Revised Milestones - SERVICE FIELD DOCUMENTS ( 1 Hour ??) ENUM Service Descriptions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-walter-ranalli-enum-service-01.txt Issues: General framework of the problem statement. What is the goal if any of granularity in service registrations? What services do we want to register and why? Should registrations be 1 RFC per protocol? The Use of ENUM by SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt Issues: Processing of 2 SIP service fields in one ENUM registration? Order and Preference issues? Is this a ENUM WG document? Coordination with SIPPING WG? ENUM Service Resolution A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zmolek-enum-pointer-00.txt Issues: What is this draft meant to do? Direction on Presence only Service Field Is Presence different from SIP ?? The ENUM TEL enumservice A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt Issues: Why? Is this just for call forwarding or is there carrier specific issues in this ... aka LNP? Is this a ENUM WG document? CORE DOCUMENT REVIEW (45 min ??) 2916bis Update - The E.164 to URI DDDS Application A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-00.txt Issues: Review of Goals and Objectives for Revision Status of DDDS Requirements for Service Registration ..Privacy? Applicability Statement? OTHER DOCUMENTS Extensible Provisioning Protocol and E.164 (10 min +) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-e164-02.txt Issues: Is this the direction the WG wants to go? Possible transport options? Tier 1 and or Tier 2 usages? Relation to PROVREG ENUM Call Flows (10 min) draft-lind-enum-callflows-03.txt Issues: This document has been around a while but let us clarify what direction this is taking. What is the goal and purpose of the document? Is this an accurate picture of possible scenarios? Should Call Flows descriptions be application specific and included in service registration documentation? DOCUMENTS OF NOTE [ NOT ON AGENDA ] US ENUM Forum Overview A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-freilich-overview-enum-forum-00.txt History and Context of ENUM Operational Decisions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt Should these documents be made Informaitonal RFC's Number Portability in the PSTN draft-ietf-enum-e164-gstn-np-03.txt Issues: Status to Last Call OPEN DISCUSSION >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Mar 13 06:02:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02219 for ; Wed, 13 Mar 2002 06:02:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07979 for enum-archive@odin.ietf.org; Wed, 13 Mar 2002 06:02:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07007; Wed, 13 Mar 2002 05:51:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06982 for ; Wed, 13 Mar 2002 05:51:01 -0500 (EST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02060 for ; Wed, 13 Mar 2002 05:50:57 -0500 (EST) From: M.Muench@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id LAA17219; Wed, 13 Mar 2002 11:50:21 +0100 (MET) Subject: RE: [ENUM] Comments to To: "Yu, James" Cc: enum@ietf.org Date: Wed, 13 Mar 2002 11:50:19 +0100 Message-ID: X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 03/13/2002 11:50:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hello James, my general concern to the draft is that many examples for the RN coding and the transfer of RN are listed. >From my experience of all the NP and MNP customers of Alcatel I can say that for every customer certain solutions for NP or MNP have to be analysed and the detailed coding of the NP/MNP related parameters has to be defined and checked if they all fit to the existing network requirements. It is not so easy to provide you with detailed RN codings due to the fact that there are so many realisations which uses sometimes different RN codings dependent of the NP scenario, like Service Provider Portability (SPP) for Geographic Numbers, SPP for Non-Geographic Numbers, Location Portability, etc. Maybe certain operators can provide you with detailed information. Nevertheless, there is an easy way out of this situation. My proposal is that we should use in the draft the logical terms of the NP related parameters: Directory Number (DN), and Network Routing Number (RN). They are used in the other standards as well (e.g. ITU-T Q.769.1). As you can see in ITU-T Q.769.1, there are 3 different signalling methods to map these logical terms to protocol parameters. This had been necessary because within the ITU-T members it was not possible to get an agreement to restrict the signalling enhancements for NP or MNP to only one solution. This gives an impression how complicate it is to find a solution which fits for all operators in the world. Therefore how the RN and DN are signalled in the network and between networks is dependent on the involved operators. For an ENUM environment it is sufficient to mention RN and DN, and as an option the network specific parameter (network option). That should be enough. With regard to the complete description of all NP or MNP cases in this draft I see the problem that, as mentioned in my previous email, some scenarios in detailed descrption are missing, like SPP for Non-Geographic Numbers, Location Portability, different scenarios for MNP (call related and non-call related (e.g. for SMS)), ... A lot of work has to be spent if the draft should reflect all scenarios in the same kind of detailed descrption. You mentioned in you answer that NP be realised based on "...10-digit GTT". I think this is the realisation for U.S. I would say don't limit the GTT to a certain value, because in some networks fewer digits could be enough and other networks could need more digits for the GTT. You mentioned in you answer that the bearer unrelated signalling can be realised based on "...message relaying (this latter one is similar to onward routing)." I do not agree that this is similar to onward routing, in my opinion it is similar to All Call Query because every SCCP message is analysed. Kind regards, Monika _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Mar 13 12:08:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11430 for ; Wed, 13 Mar 2002 12:08:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28854 for enum-archive@odin.ietf.org; Wed, 13 Mar 2002 12:08:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26612; Wed, 13 Mar 2002 11:59:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26301 for ; Wed, 13 Mar 2002 11:51:23 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10919 for ; Wed, 13 Mar 2002 11:51:19 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2DGooi01187; Wed, 13 Mar 2002 10:50:50 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 10:50:45 -0600 Message-ID: <23309E398D84D5119D0F00306E075139ECED52@dc02.npac.com> From: "Yu, James" To: "'M.Muench@alcatel.de'" Cc: enum@ietf.org Subject: RE: [ENUM] Comments to Date: Wed, 13 Mar 2002 10:50:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Monika, Again, I want to emphasize that the purpose of the I-D is give the IETF members an idea how NP is supported in Global Switched Telephone Network (GSTN). We tried to provide some "useful" information to show how NP is done. It took some efforts to collect the RN coding information and we are sure that many readers may find the info. useful in understanding how RNs vary in different countries. We have no intention to list all the implementations worldwide and discuss them in details. As you pointed out, we did not describe NP for non-geographical numbers. Because our focus is to give a good NP overview on geographical number. We can certainly clarify this in the introduction. In terms of ENUM and NP, ENUM is not impacted by RN and DN. It is just that the new telephony service provider's (TSP's) NAPTR RRs for its network-related services need to be used when NP happens and when the TSPs' NAPTR RRs also use the same "golden tree," e164.arpa (e.g., the old TSP's NAPTR RRs should be replaced by the new TSP's NAPTR RRs). RN and DN do matter for iptel (TRIP) because the RN, instead of DN, should be used for routing (e.g., check against the TRIP routing table). So NP may impact some current works-in-progress at IETF (e.g., ENUM and TRIP). With a understanding of NP, one can see the potential implications of NP on some of them. Some may be related to RN/DN and some others may be just that there is the new TSP to be dealt with. In responding to your comments about non-call related signaling message routing - the reason I said that Signaling Relay Function (SRF) was similar/analogous to "onward routing" was because the signaling message is first routed to the "donor network," which then relays/forwards the signaling message to the current serving network. Yes, 10-digit GTT is a US implementation. When we describe that, we'll certainly mention it as a U.S. implementation and also mention the shorter/longer than 10 digits for GTT. As a matter of fact, in some cases in the U.S., the application (TCAP) message is examined to look up the DN in order to derive the RN because only the first six digits (NPA+NXX in U.S.) of the DN are available in the global title address info. But it is too low-level for the readers to know. Hope this address your comments/concerns. This document is an "informational" document, not a "standard track" document. We hope that the readers can learn the NP concept after reading the document and be able to understand the potential implications on some of the works-in-progress at the IETF, which is the objective of the document. Again, thanks for your valuable comments. James > -----Original Message----- > From: M.Muench@alcatel.de [mailto:M.Muench@alcatel.de] > Sent: Wednesday, March 13, 2002 5:50 AM > To: Yu, James > Cc: enum@ietf.org > Subject: RE: [ENUM] Comments to > > > Hello James, > > my general concern to the draft is that many examples for the > RN coding and > the transfer of RN are listed. > From my experience of all the NP and MNP customers of Alcatel > I can say > that for every customer certain solutions for NP or MNP have > to be analysed > and the detailed coding of the NP/MNP related parameters has > to be defined > and checked if they all fit to the existing network > requirements. It is not > so easy to provide you with detailed RN codings due to the > fact that there > are so many realisations which uses sometimes different RN codings > dependent of the NP scenario, like Service Provider > Portability (SPP) for > Geographic Numbers, SPP for Non-Geographic Numbers, Location > Portability, > etc. > Maybe certain operators can provide you with detailed information. > > Nevertheless, there is an easy way out of this situation. My > proposal is > that we should use in the draft the logical terms of the NP related > parameters: Directory Number (DN), and Network Routing Number > (RN). They > are used in the other standards as well (e.g. ITU-T Q.769.1). > As you can see in ITU-T Q.769.1, there are 3 different > signalling methods > to map these logical terms to protocol parameters. This had > been necessary > because within the ITU-T members it was not possible to get > an agreement to > restrict the signalling enhancements for NP or MNP to only > one solution. > This gives an impression how complicate it is to find a > solution which fits > for all operators in the world. Therefore how the RN and DN > are signalled > in the network and between networks is dependent on the > involved operators. > > For an ENUM environment it is sufficient to mention RN and > DN, and as an > option the network specific parameter (network option). > That should be enough. > > With regard to the complete description of all NP or MNP cases in this > draft I see the problem that, as mentioned in my previous email, some > scenarios in detailed descrption are missing, like SPP for > Non-Geographic > Numbers, Location Portability, different scenarios for MNP > (call related > and non-call related (e.g. for SMS)), ... > A lot of work has to be spent if the draft should reflect all > scenarios in > the same kind of detailed descrption. > > > You mentioned in you answer that NP be realised based on > "...10-digit GTT". > I think this is the realisation for U.S. I would say don't > limit the GTT to > a certain value, because in some networks fewer digits could > be enough and > other networks could need more digits for the GTT. > > You mentioned in you answer that the bearer unrelated > signalling can be > realised based on "...message relaying (this latter one is similar to > onward routing)." I do not agree that this is similar to > onward routing, in > my opinion it is similar to All Call Query because every SCCP > message is > analysed. > > > Kind regards, > > Monika > > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Mar 13 14:11:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15432 for ; Wed, 13 Mar 2002 14:11:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06469 for enum-archive@odin.ietf.org; Wed, 13 Mar 2002 14:11:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05613; Wed, 13 Mar 2002 14:01:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05574 for ; Wed, 13 Mar 2002 14:01:33 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15159 for ; Wed, 13 Mar 2002 14:01:29 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA19109; Wed, 13 Mar 2002 20:00:39 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA04275; Wed, 13 Mar 2002 20:00:26 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 20:00:53 +0100 Message-ID: From: Brandner Rudolf To: "'Peterson, Jon'" , "'Richard Shockey'" , enum@ietf.org Subject: AW: [Enum] Revised #2 IETF 53 Agenda Date: Wed, 13 Mar 2002 20:00:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Great. Besides other discussion topics, I have compiled a list of issues. Some of them might fit into Jon's presentation. At least I would like to have them discussed at MSP. * What to do with service field, i.e. E2U+SIP2VIDEO and that like - implications on # of entries - implications on protocols * What to do with NXDOMAIN? DNSSEC stuff * What to do with NAPTR priority and preferences, what's the default behaviour? * Service Resolution Service, implications like - new protocol or HTTP(s) with something on top (SOAP)? New WG? I see ENUM as a basic service, pres: might be an additional service with additional cost * tel: enumservice should be part of this working group - is useful for LNP - should be registered to make it single specific service, regardless of operator or 'public' ENUM - blongs to WG as ENUM resolves to telephone network, too * Privacy issues regarding users and telephone service provider (tsp) Regarding documents, I'd like to ask, whether there should be more focussed documents on * ENUMservice registration document (how, why, register sip: tel: pres: etc.) * TEL: enumservice registration * TEL: enumservice usage (only tel: URI with parameters, scenarios, usage) this might include usage of non E.164 numbers in tel:, looping, tsp parameter, CPC parameters, phone context (out of area, locality to call centers (Automatic Call Distribution)), etc. * ENUM scenarios as public/operator/(private) service * Common features and pitfalls elaborating on RegExp, CNAME, exhaustive lookups (detection, reaction), priority and preferences * Document on all current parameters of SIP, PINT, TEL URI's That's it so far. If there had already been consensus on a topic above on the list and I'm out of sync, so pardon me. Please let me know anyway. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Mar 14 03:25:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12511 for ; Thu, 14 Mar 2002 03:25:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA07184 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 03:25:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06592; Thu, 14 Mar 2002 03:16:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06561 for ; Thu, 14 Mar 2002 03:16:53 -0500 (EST) Received: from fallback.nextra.at (qsm1.nextra.at [195.170.70.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12409 for ; Thu, 14 Mar 2002 03:16:49 -0500 (EST) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [194.118.12.23]) by fallback.nextra.at (8.12.1/8.12.1) with ESMTP id g2E8F9s1001397; Thu, 14 Mar 2002 09:16:49 +0100 (MET) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Mar 2002 09:00:32 +0100 Message-ID: From: "Stastny, Richard" To: "'Yu, James'" , "'M.Muench@alcatel.de'" Cc: enum@ietf.org Subject: RE: [ENUM] Comments to Date: Thu, 14 Mar 2002 09:00:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi James, You wrote: > In terms of ENUM and NP, ENUM is not impacted by RN and DN. > It is just that > the new telephony service provider's (TSP's) NAPTR RRs for its > network-related services need to be used when NP happens and > when the TSPs' > NAPTR RRs also use the same "golden tree," e164.arpa (e.g., > the old TSP's > NAPTR RRs should be replaced by the new TSP's NAPTR RRs). > > RN and DN do matter for iptel (TRIP) because the RN, instead > of DN, should > be used for routing (e.g., check against the TRIP routing table). > > So NP may impact some current works-in-progress at IETF > (e.g., ENUM and > TRIP). With a understanding of NP, one can see the potential > implications > of NP on some of them. Some may be related to RN/DN and some > others may be > just that there is the new TSP to be dealt with. Now I am confused. Is ENUM and the current works-in-progress impacted by NP or not? First, I think new TSP's cannot use the "golden tree" e164.arpa for NP or other network-specific NAPTR RR's, because of the ENUM End User opt-in principle. If the operators want to use a common tree for network-specific RR, they may use e.g. the e164op.arpa "platinum tree"? Anyway, if the TSP's use a "public" tree, there either needs to be a special service and/or URI defined and registered e.g or the tel: URI is used with additional attributes to indicate if the tel: URI is a DN or RN. regards Richard STASTNY OeFEG Arsenal Objekt 24 P.O. Box 147 A-1103 Vienna, Austria Tel: +43 664 420 4100 Fax: +43 1 79780 13 richard.stastny@oefeg.at richard@stastny.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 10:49:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20241 for ; Thu, 14 Mar 2002 10:49:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06904 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 10:49:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05804; Thu, 14 Mar 2002 10:36:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05773 for ; Thu, 14 Mar 2002 10:36:07 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19619 for ; Thu, 14 Mar 2002 10:36:04 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA23064 for ; Thu, 14 Mar 2002 16:36:01 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA00045 for ; Thu, 14 Mar 2002 16:35:53 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 16:36:20 +0100 Message-ID: From: Brandner Rudolf To: enum@ietf.org Cc: Conroy Lawrence Date: Thu, 14 Mar 2002 16:36:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] Questions on domain contents Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, we were discussing these issues in-house and wonder if anybody has opinions on these: * What RR except NAPTRs can exist within the golden tree? * Can there be NAPTRs in non leaf domains within the golden tree? - E.g. can 2.5.5.5.2.1.2.1.e164.arpa include a NAPTR * Can there be NAPTRs outside the golden tree? - We believe, that no one is stopping you including a NAPTR under e.g. e164.foo - Could be useful for tel: NAPTRs E.g. carrier selection prefix within wcom.com or dtag.de Opinions gratefully recieved. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 11:18:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21100 for ; Thu, 14 Mar 2002 11:18:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10011 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 11:18:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08846; Thu, 14 Mar 2002 11:09:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08815 for ; Thu, 14 Mar 2002 11:09:15 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20744 for ; Thu, 14 Mar 2002 11:09:11 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id IAA26658; Thu, 14 Mar 2002 08:08:40 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 08:08:40 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B10E4@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Brandner Rudolf'" , enum@ietf.org Cc: Conroy Lawrence Subject: RE: [Enum] Questions on domain contents Date: Thu, 14 Mar 2002 08:08:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Rudi: My comments in line....... > -----Original Message----- > From: Brandner Rudolf [mailto:Rudolf.Brandner@icn.siemens.de] > Sent: Thursday, March 14, 2002 9:36 AM > To: enum@ietf.org > Cc: Conroy Lawrence > Subject: [Enum] Questions on domain contents > > > Hi all, > > we were discussing these issues in-house and wonder if > anybody has opinions on these: > > * What RR except NAPTRs can exist within the golden tree? Can you give us an example of what you are thinking of doing? > > * Can there be NAPTRs in non leaf domains within the golden tree? > - E.g. can 2.5.5.5.2.1.2.1.e164.arpa include a NAPTR More details please? If I read this right, you want to stop the delegation at the partial read of the phone number past the CC, NPA, and NXX. From my understanding, at Tier 1 the fully qualified E.164 number will be read before referral is done to the Tier 2. > > * Can there be NAPTRs outside the golden tree? > - We believe, that no one is stopping you including a NAPTR > under e.g. e164.foo > - Could be useful for tel: NAPTRs > E.g. carrier selection prefix within wcom.com or dtag.de At TIER 1 the delegation to Tier 2 is done by NS record so you should be able to store the NAPTR records in any zone. Yes, NAPTRs will exist outside of the 'Golden Tree'. > > Opinions gratefully recieved. Kevin........ > > Rudi > > _______________________________________________ > 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 daemon@ns.ietf.org Thu Mar 14 11:24:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21293 for ; Thu, 14 Mar 2002 11:24:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10828 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 11:24:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09363; Thu, 14 Mar 2002 11:15:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08658 for ; Thu, 14 Mar 2002 11:07:23 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20711 for ; Thu, 14 Mar 2002 11:07:20 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2EG6of08786; Thu, 14 Mar 2002 11:06:50 -0500 Message-Id: <5.1.0.14.2.20020314105922.025c0110@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 11:01:12 -0500 To: Brandner Rudolf , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Questions on domain contents Cc: Conroy Lawrence In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 04:36 PM 3/14/2002 +0100, Brandner Rudolf wrote: >Hi all, > >we were discussing these issues in-house and wonder if anybody has >opinions on these: > >* What RR except NAPTRs can exist within the golden tree? any valid DNS RR .. >* Can there be NAPTRs in non leaf domains within the golden tree? > - E.g. can 2.5.5.5.2.1.2.1.e164.arpa include a NAPTR What would be the purpose of this ? >* Can there be NAPTRs outside the golden tree? > - We believe, that no one is stopping you including a NAPTR under e.g. > e164.foo > - Could be useful for tel: NAPTRs > E.g. carrier selection prefix within wcom.com or dtag.de Could you elaborate on this scenerio a bit? >Opinions gratefully recieved. > >Rudi > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 11:24:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21311 for ; Thu, 14 Mar 2002 11:24:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10842 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 11:24:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09335; Thu, 14 Mar 2002 11:15:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07691 for ; Thu, 14 Mar 2002 10:59:56 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Thu, 14 Mar 2002 10:59:53 -0500 (EST) Received: from dick.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2EFxGf08210; Thu, 14 Mar 2002 10:59:19 -0500 Message-Id: <5.1.0.14.2.20020314103956.042f6ec0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 10:56:59 -0500 To: Brandner Rudolf , "'Peterson, Jon'" , enum@ietf.org From: Richard Shockey Subject: Re: AW: [Enum] Revised #2 IETF 53 Agenda In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08:00 PM 3/13/2002 +0100, Brandner Rudolf wrote: >Great. Excellent set of questions BTW ..let me offer up some personal views but you are correct..by general consensus the discussion of NAPTR service field will be the #1 topic of discussion in Minneapolis and I'd like the 4 presenters to consider presentations of outstanding issues of no more that 10-minutes each so we can start a general discussion of the common problems etc and come to consensus on next steps. >Besides other discussion topics, I have compiled a list of issues. Some of >them might fit into Jon's presentation. At least I would like to have them >discussed at MSP. > >* What to do with service field, i.e. E2U+SIP2VIDEO and that like > - implications on # of entries > - implications on protocols agreed ... the issue of level of granularity has plagued me for quite some time ..I do favor a minimalist approach in that authors of service registration documents should be very careful to write a detailed applibility statement ... so in the case you describe ... the ID should justify in detail why there should be E2U+SIP2VIDEO vs just E2U+SIP >* What to do with NXDOMAIN? DNSSEC stuff yes ..any one that would like to do a ID on"Implications of DNSSEC for RFC 2916" would have a welcome audience ..especially among our colleagues in the ITU who have asked similar questions. >* What to do with NAPTR priority and preferences, what's the default >behaviour? I think Patrik and Michael have been looking into that >* Service Resolution Service, implications like > - new protocol or HTTP(s) with something on top (SOAP)? New WG? > I see ENUM as a basic service, pres: might be an additional service > with additional cost Could you elaborate here . what are you suggesting .. I'm hoping Andy can clarify the direction he wants to take with his draft ... but yes ENUM is the basic service etc. >* tel: enumservice should be part of this working group > - is useful for LNP > - should be registered to make it single specific service, > regardless of operator or 'public' The WG will need to come to consensus on making this a WG document ..but I certainly support it. Yes it is useful for LNP ..but there is question of how this would work ..is this informaiton revealed in a query to e164.apra or is this more appropriate to some private service provider system. >ENUM > - blongs to WG as ENUM resolves to telephone network, too >* Privacy issues regarding users and telephone service provider (tsp) What privacy issues do you mean ... those involving 2916 itself or those involving specific services such as SIP? Again I believe each service registration document needs a strong privacy considerations document ..but on the issue of privacy in e164.arpa ..there is no privacy since it is a global service and totally open to anyone or any network element on the internet. >Regarding documents, I'd like to ask, whether there should be more >focussed documents on > >* ENUMservice registration document (how, why, register sip: tel: pres: etc.) These questions should be answered in the core 2916bis.. how to register a service and what requirements or tests should be applied to those registration documents. >* TEL: enumservice registration >* TEL: enumservice usage (only tel: URI with parameters, scenarios, usage) > this might include usage of non E.164 numbers in tel:, looping, > tsp parameter, CPC parameters, > phone context (out of area, locality to call centers (Automatic > Call Distribution)), etc. These questions are better discussed in the eventual TEL registration document. >* ENUM scenarios as public/operator/(private) service >* Common features and pitfalls elaborating on RegExp, CNAME, exhaustive >lookups (detection, reaction), > priority and preferences >* Document on all current parameters of SIP, PINT, TEL URI's Here ... Richard mentioned this as well what are the core services that need IANA registration? I certainly think we need to come to consensus on what those are.. SIP? H323? (hint) TEL ... but what about FAX? and VPIM?... I will personally be visiting both of those WG's next week to alert them to our activity and listen to their opinions and possible directions in this area. >That's it so far. If there had already been consensus on a topic above on >the list and I'm out of sync, so pardon me. Please let me know anyway. > >Rudi >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 12:09:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22864 for ; Thu, 14 Mar 2002 12:09:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16574 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 12:09:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14058; Thu, 14 Mar 2002 11:56:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14026 for ; Thu, 14 Mar 2002 11:56:15 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22487 for ; Thu, 14 Mar 2002 11:56:10 -0500 (EST) Received: from [193.118.192.80] ([193.118.192.80] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063873; Thu, 14 Mar 2002 16:56:11 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <5.1.0.14.2.20020314105922.025c0110@popd.ix.netcom.com> References: <5.1.0.14.2.20020314105922.025c0110@popd.ix.netcom.com> Date: Thu, 14 Mar 2002 16:56:07 +0000 To: Richard Shockey , Brandner Rudolf , enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] Questions on domain contents Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:01 am -0500 14/3/02, Richard Shockey wrote: >At 04:36 PM 3/14/2002 +0100, Brandner Rudolf wrote: >>Hi all, >> >>we were discussing these issues in-house and wonder if anybody has >>opinions on these: >> >>* What RR except NAPTRs can exist within the golden tree? > >any valid DNS RR .. > >>* Can there be NAPTRs in non leaf domains within the golden tree? >> - E.g. can 2.5.5.5.2.1.2.1.e164.arpa include a NAPTR > >What would be the purpose of this ? > >>* Can there be NAPTRs outside the golden tree? >> - We believe, that no one is stopping you including a NAPTR under >>e.g. e164.foo >> - Could be useful for tel: NAPTRs >> E.g. carrier selection prefix within wcom.com or dtag.de > >Could you elaborate on this scenerio a bit? > >>Opinions gratefully recieved. >> >>Rudi >> To which I add: Hi Rich, Folks, Thanks for the clarification: "a domain can contain any legal RR". Re. non-leaf domain NAPTRs. We raised this point a while ago - Possible uses for these RRs in "mid-tree":: You might have a NAPTR associated with a number block (and so not a leaf domain), for example to identify the initial Operator to which the block was originally assigned. Perhaps a URI with an http: URI, or ... I wonder if one might have "pilot numbers", but Richard St pointed out that he was not comfortable with these in Tier 1. However, in Munich Siemens has a 10K number block - this will be in T2, I guess. I think that we might put in a NAPTR at this number block "level" (2.2.7.9.8.9.4.e164.arpa.) - This might be a tel NAPTR for the reception desk, for example. Re. prefix... Beware that I'm still unsure whether or not we should have a parameter to show that a tel: URI content is a Non-Dialable-Number (on its own)...in the following it's shown as ';NDN=PR' [such a parameter could also have the value 'NP' for routing number]. Let's say that there's a tel NAPTR in the domain 0.7.3.8.4.2.2.7.9.8.9.4.e164.arpa. This could be Now, I could go look in the DNS domain dtag.de for tel NAPTRs (yes, I know that they aren't in the golden tree so there might need to be another spec, but bear with me for now): There, I might find this: This might be used by a dialer as a prefix to prepend to the phone number it has been given from the previous query within the golden tree. Thus, within Germany, phone '0103308972251003' to get to Rudi via DT's fine network. It's not an ENUM issue as such, but it might be a neat featurette. OK, that's my EUR 0,02. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 13:37:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25038 for ; Thu, 14 Mar 2002 13:37:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23119 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 13:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21990; Thu, 14 Mar 2002 13:26:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21961 for ; Thu, 14 Mar 2002 13:26:04 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24768 for ; Thu, 14 Mar 2002 13:26:01 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2EIOXI01516 for ; Thu, 14 Mar 2002 13:24:33 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2EIOWk01497 for ; Thu, 14 Mar 2002 13:24:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AW: [Enum] Revised #2 IETF 53 Agenda Date: Thu, 14 Mar 2002 11:26:39 -0700 Message-ID: Thread-Topic: AW: [Enum] Revised #2 IETF 53 Agenda Thread-Index: AcHLfzFStXIaPN9lQQGRKfUvfqaLlQABCd1A From: "Zmolek, Andrew (Andrew)" To: "Richard Shockey" , "Brandner Rudolf" , "Peterson, Jon" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA21962 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit >>* Service Resolution Service, implications like >> - new protocol or HTTP(s) with something on top (SOAP)? New WG? >> I see ENUM as a basic service, pres: might be an additional >> service with additional cost > > Could you elaborate here . what are you suggesting .. I'm hoping Andy > can clarify the direction he wants to take with his draft ... but yes > ENUM is the basic service etc. Let me address the second issue, namely the direction I hope to take with my draft. Right now, the draft merely outlines the reasons why service resolution services add value to ENUM and how their use could help us avoid service field tag hell. Assuming we agree that it would be a good thing to better define how ENUM and service resolution services should behave, my draft could move toward an informational RFC or become absorbed into bis somehow. Outside the draft, there's the issue of finding a signaling-agnostic presence service, preferably one that can run over HTTP for brainless firewall traversal and simplicity. And one that allows for pre-call media selection based on the current capabilities of available devices for both the potential caller and party to be called. Perhaps SIMPLE could be extended to do this, or a separate working group could tackle this notion of an independent presence service. IMHO, such a service could also go a long way to solving the geopriv problem effectively (but that's not a concern for this group, so I'll leave it at that). In any case, most of this work is outside of ENUM so I haven't focused on this in the draft. Given that the latter issue is tangential to the group, I intend to mention it only in passing, keeping the WG discussion limited to the specific charter-related issue of how we want to treat service resolution services and how that should affect our guidelines for service field tags. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu Mar 14 14:34:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27506 for ; Thu, 14 Mar 2002 14:34:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28871 for enum-archive@odin.ietf.org; Thu, 14 Mar 2002 14:34:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27238; Thu, 14 Mar 2002 14:22:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27207 for ; Thu, 14 Mar 2002 14:22:16 -0500 (EST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26991 for ; Thu, 14 Mar 2002 14:22:13 -0500 (EST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g2EJIPd03416 for ; Thu, 14 Mar 2002 14:18:25 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200203141918.g2EJIPd03416@nic-naa.net> To: enum@ietf.org Date: Thu, 14 Mar 2002 14:18:25 -0500 From: Eric Brunner-Williams in Portland Maine Subject: [Enum] administrivia -- to items Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Oki all, Three of us are now hoarding all the SPAM. Urk. Spam is expensive. #1 For each item of mail sent to enum@ietf.org, above a dozen subscriber unreachable messages clutter my inbox. Fortunately, I use mh, but I intend to prune out the dead, the clutter from the dearly departed is rediculous. Bringing out the dead yeilds: pmele@ipverse.com, prakasha.ramachandra@wipro.com, chrism@cartman.sea.checkpoint.com, ann.wong@compaq.com enum@ttimail.com, kevins@corp.afternic.com dave.hewins@marconi.com, james.quigley@cwcom.co.uk, paul.rosbotham@cwcom.co.uk, pconley@netsol.com, usama.mansoor@level3.com, nmeyer@mail.integralaccess.com, lcox@neta.com, ietf@niconet.tzo.com, justin.sanford@cbeyond.net, pmele@ipverse.com, mmaleski@acumensolutions.com #2. Each item sent by someone with a subscriber address of Luser@FooBaar.com who now posts from Luser@FooBarr.baz, or some other "neuveau TLD" should either send a (decent) bottle of neuveau Beaujolis to this address, _or_ change their subscription address to the TLA of their current pursuasion. (co-chair and former cubie-neighbor, this means you and Yu too) Finaly, with above 400 subscribers, this is a big list to keep clean. Kitakitamatsinopowaw (Siksika Indian for dial tone), Eric "pong" is the sound an icmp echo request makes when serviced by a device performing ENUM interposed flow sink. this is in the host requirements. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Sat Mar 16 00:05:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20333 for ; Sat, 16 Mar 2002 00:05:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA18141 for enum-archive@odin.ietf.org; Sat, 16 Mar 2002 00:05:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17158; Fri, 15 Mar 2002 23:53:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA17127 for ; Fri, 15 Mar 2002 23:53:48 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20139 for ; Fri, 15 Mar 2002 23:53:43 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GT100K01UWR2T@firewall.wcom.com> for enum@ietf.org; Sat, 16 Mar 2002 04:53:16 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GT100J4PUWRLT@firewall.wcom.com> for enum@ietf.org; Sat, 16 Mar 2002 04:53:15 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GT100301UWPEG@dgismtp01.wcomnet.com> for enum@ietf.org; Sat, 16 Mar 2002 04:53:15 +0000 (GMT) Received: from ajohnston ([166.42.32.185]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GT100LDFUWKHQ@dgismtp01.wcomnet.com> for enum@ietf.org; Sat, 16 Mar 2002 04:53:09 +0000 (GMT) Date: Fri, 15 Mar 2002 22:52:39 -0600 From: Alan Johnston To: "'ENUM'" Message-id: <002001c1cca6$66cb9520$b9202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Enum] Comments on draft-lind-enum-callflows-03.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit All, I have a number of comments on this draft. At a very high level, I feel that this document misses the key aspects of IP and PSTN interworking enabled by ENUM, namely: - the main benefit of ENUM is that it allows IP devices to avoid interworking with the PSTN. - both IP and PSTN networks currently have routing capabilities today that work without ENUM even in interworking scenarios - ENUM is a routing optimization, not a requirement for successful interoperation between the two networks. It is important to realize that ENUM is primarily for the Internet and Internet devices. If the PSTN can make some use of it in optimizing routing, that's good, but not the main goal. Secondly, if service specific call flows are needed (and I am far from convinced that they are), I think they should be done in the relevant working group rather than ENUM where they will get expert review. Finally, the document claims to point out necessary changes to other protocols such as SIP. If this were true (which it isn't), the document should be submitted to SIPPING. However, the changes discussed relate to TEL URL parameters instead. Detailed comments are further down this email. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com - - - - - - Detailed comments: Section 4 - I don't think mailto:+1-973-236-6787 a valid mailto URI based on RFC2378 - it should be clearly labeled as a potential extension. Section 5.1 - This call flow breaks at Step 2 as there is no reason given for the PSTN to route the call to a Gateway, and no adequate explanation for the selection of this gateway. The PSTN will route the call based on dialed digits, unless the PSTN queries ENUM (which is not shown in any of these flows, but is an interesting idea). The real call flow here is that the call routes over the PSTN and does reach a Gateway, but the PSTN does not know that it is a Gateway - it just looks like a Class 5 switch. In Figure 1, all the boxes are functional elements except the one labeled "IP-based Network". Since none of the other networks involved in this flow are labeled this way, it should be removed, or reworked as a network "cloud". Step 5 indicates that an A record is used to locate a SIP server when it is much more likely a SRV record will be used. Ditto for Step 5 in Section 6. Section 5.2 - The options discussed here are just awful. Separate E.164 numbers for IP devices kind of defeats the purpose of ENUM. Hairpinning every PSTN call through a Gateway on the off chance the call terminates in the IP world also is not good. The one obvious solution to this problem is not even mentioned - the only way the PSTN can know if the call should be routed to a gateway is to query ENUM to see if a URI is returned. If no, URI, route in PSTN, if URI (SIP or similar) route to Gateway. Section 5.3 - Step 3 of returning a tel URL identical to the E.164 number used to make the lookup is bad as others have pointed out. If there is no IP endpoint, there should be no URIs returned by the ENUM query. In Section 8 under Conclusions and Future work. The first open issue, identifying when a PSTN call should route to IP - this is done using ENUM. The open issue is how and where the PSTN should query ENUM. The second open issue states that extensions to SIP are needed to support LNP - this has not been shown by this document. As stated earlier, any changes to SIP must go through SIPPING. Any LNP information can be carried as URI parameters, best in tel URLS which have nothing to do with the SIP protocol, which is incorrectly stated in the third open issue. Comments on the Call Flows: The SIP signaling is incorrect throughout, with the response codes (18x, 200, etc.) missing. Also, ACKs are also missing. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Mar 17 20:36:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14776 for ; Sun, 17 Mar 2002 20:36:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA20507 for enum-archive@odin.ietf.org; Sun, 17 Mar 2002 20:36:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19552; Sun, 17 Mar 2002 20:26:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19524 for ; Sun, 17 Mar 2002 20:26:27 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14531 for ; Sun, 17 Mar 2002 20:26:24 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 3F7E03190C; Sun, 17 Mar 2002 17:25:53 -0800 (PST) To: enum@ietf.org, discuss@apps.ietf.org Cc: tony.ar.holmes@bt.com, Alwyn.Thomas@dti.gsi.gov.uk Date: Sun, 17 Mar 2002 17:25:53 -0800 Message-ID: <38421.1016414753@shell.nominum.com> From: Jim Reid Subject: [Enum] Invitation for ENUM applications/service providers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I apologise in advance as this is somewhat off-topic for these lists but I hope the moderators will indulge me. This is probably the most effective way of reaching out to the audience that's being sought. The UK Government intends to start a national trial of ENUM. This should hopefully start in the summer and last for 6 months. It will be operated by an ad-hoc group drawn from industry: telcos, registry and registrar providers, etc. The objective of the trial is to determine the viability and desirability of operating a production ENUM service for the UK. Participation in the trial is open to all, especially developers of ENUM-capable software or ASPs who can offer ENUM-aware services. Anyone interested in taking part in the trial should contact Alwyn Thomas at the Department of Trade and Industry. His email address is Alwyn.Thomas@dti.gsi.gov.uk. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Mar 18 12:18:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12021 for ; Mon, 18 Mar 2002 12:18:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19247 for enum-archive@odin.ietf.org; Mon, 18 Mar 2002 12:18:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18402; Mon, 18 Mar 2002 12:09:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18371 for ; Mon, 18 Mar 2002 12:09:09 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11611 for ; Mon, 18 Mar 2002 12:09:04 -0500 (EST) Received: from sdn-ap-008neomahp1168.dialsprint.net ([63.189.12.152] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16n0ch-0007L3-00; Mon, 18 Mar 2002 12:08:40 -0500 Message-Id: <5.1.0.14.2.20020318114441.023322a0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Mar 2002 12:07:26 -0500 To: Jim Reid , enum@ietf.org, discuss@apps.ietf.org From: Richard Shockey Subject: Re: [Enum] Invitation for ENUM applications/service providers Cc: tony.ar.holmes@bt.com, Alwyn.Thomas@dti.gsi.gov.uk In-Reply-To: <38421.1016414753@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:25 PM 3/17/2002 -0800, Jim Reid wrote: >I apologise in advance as this is somewhat off-topic for these lists >but I hope the moderators will indulge me. This is probably the most >effective way of reaching out to the audience that's being sought. First this note is not off-topic for the ENUM WG..indeed it is totally in scope with the WG's revised charter. "3. The Working Group will continue to maintain appropriate contact and liaison with standards bodies and groups, specifically ITU-T SG2, in order to provide technical or educational information as needed, such as the appropriate use of DNS. The Working Group will encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations or administration of RFC 2916." >The UK Government intends to start a national trial of ENUM. This should >hopefully start in the summer and last for 6 months. It will be >operated by an ad-hoc group drawn from industry: telcos, registry and >registrar providers, etc. The objective of the trial is to determine >the viability and desirability of operating a production ENUM service >for the UK. Participation in the trial is open to all, especially >developers of ENUM-capable software or ASPs who can offer ENUM-aware >services. Anyone interested in taking part in the trial should contact >Alwyn Thomas at the Department of Trade and Industry. His email >address is Alwyn.Thomas@dti.gsi.gov.uk. Is there any restriction on the geographic location of participants? I'd specifically like this ad-hoc group to maintain contact and liaison with the chairs and we would welcome ID's documenting the organization of this trial, scope and results. As you may know we will eventually want to take 2916 from proposed to draft in the usual IETF manner manner. http://www.ietf.org/rfc/rfc2026.txt The requirement for taking a RFC from proposed to draft standard require 2 demonstrations of inter operability and this trial could be useful in documenting that process. Thank you for making the list aware of this opportunity! >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 18 15:12:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18357 for ; Mon, 18 Mar 2002 15:12:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02558 for enum-archive@odin.ietf.org; Mon, 18 Mar 2002 15:12:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02063; Mon, 18 Mar 2002 15:03:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02031 for ; Mon, 18 Mar 2002 15:03:36 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18109 for ; Mon, 18 Mar 2002 15:03:31 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA07467; Mon, 18 Mar 2002 21:02:54 +0100 (MET) Date: Mon, 18 Mar 2002 13:36:56 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Eric Brunner-Williams in Portland Maine , enum@ietf.org Subject: Re: [Enum] administrivia -- to items Message-ID: <26805393.1016458616@localhost> In-Reply-To: <200203141918.g2EJIPd03416@nic-naa.net> References: <200203141918.g2EJIPd03416@nic-naa.net> X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-14 14.18 -0500 Eric Brunner-Williams in Portland Maine wrote: > pmele@ipverse.com, prakasha.ramachandra@wipro.com, > chrism@cartman.sea.checkpoint.com, ann.wong@compaq.com > enum@ttimail.com, kevins@corp.afternic.com > dave.hewins@marconi.com, james.quigley@cwcom.co.uk, > paul.rosbotham@cwcom.co.uk, pconley@netsol.com, > usama.mansoor@level3.com, nmeyer@mail.integralaccess.com, > lcox@neta.com, ietf@niconet.tzo.com, justin.sanford@cbeyond.net, > pmele@ipverse.com, mmaleski@acumensolutions.com These addresses are now unsubscribed from the ENUM mailing list. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 18 15:33:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19063 for ; Mon, 18 Mar 2002 15:33:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04405 for enum-archive@odin.ietf.org; Mon, 18 Mar 2002 15:33:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03353; Mon, 18 Mar 2002 15:24:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19845 for ; Mon, 18 Mar 2002 12:27:20 -0500 (EST) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12369 for ; Mon, 18 Mar 2002 12:27:15 -0500 (EST) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA18102; Mon, 18 Mar 2002 12:26:49 -0500 (EST) Received: from arutkowski-desk.verisign.com (ARUTKOWSKI-DESK [10.131.128.39]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G5SBKQT0; Mon, 18 Mar 2002 12:26:48 -0500 Message-Id: <5.1.0.14.2.20020318121932.0215abb8@vsvapostal1.prod.netsol.com> X-Sender: trutkowski@vsvapostal1.prod.netsol.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Mar 2002 12:26:41 -0500 To: Richard Shockey , enum@ietf.org, discuss@apps.ietf.org From: Tony Rutkowski Subject: Re: [Enum] Invitation for ENUM applications/service providers Cc: tony.ar.holmes@bt.com, Alwyn.Thomas@dti.gsi.gov.uk In-Reply-To: <5.1.0.14.2.20020318114441.023322a0@popd.ix.netcom.com> References: <38421.1016414753@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Richard, >I'd specifically like this ad-hoc group to maintain contact and liaison >with the chairs and we would welcome ID's documenting the organization of >this trial, scope and results. As you may know we will eventually want to >take 2916 from proposed to draft in the usual IETF manner manner. Cool. DTI is an agency of the United Kingdom government. Do the chairs intend to maintain this liaison activity with respect to other government agencies and trials? Representing ISOC IETF or ISOC IAB? Is this just for the e164.arpa service brand? --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Mon Mar 18 17:14:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22424 for ; Mon, 18 Mar 2002 17:14:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12256 for enum-archive@odin.ietf.org; Mon, 18 Mar 2002 17:14:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11373; Mon, 18 Mar 2002 17:04:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11325 for ; Mon, 18 Mar 2002 17:04:05 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22065 for ; Mon, 18 Mar 2002 17:03:58 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 124B03190C; Mon, 18 Mar 2002 14:03:32 -0800 (PST) To: Richard Shockey Cc: enum@ietf.org, discuss@apps.ietf.org, tony.ar.holmes@bt.com, Alwyn.Thomas@dti.gsi.gov.uk Subject: Re: [Enum] Invitation for ENUM applications/service providers In-Reply-To: Message from Richard Shockey of "Mon, 18 Mar 2002 12:07:26 EST." <5.1.0.14.2.20020318114441.023322a0@popd.ix.netcom.com> Date: Mon, 18 Mar 2002 14:03:32 -0800 Message-ID: <64428.1016489012@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "Richard" == Richard Shockey writes: Richard> First this note is not off-topic for the ENUM WG..indeed Richard> it is totally in scope with the WG's revised charter. OK. However my posting (and this reply) also goes to the IETF apps mailing list, where it may be off-topic. I sent the announcement there to try and reach out to developers or ASPs who may have ENUM-aware products that could be used in the trial. Richard> Is there any restriction on the geographic location of Richard> participants? No. Though for the obvious practical reasons it would help if participants had a presence in the UK (or in roughly the same time zone). It's also likely that participants will be bound by UK and EU law on data protection and privacy. That could present constraints on what participants in other jurisdictions can and cannot do. Richard> I'd specifically like this ad-hoc group to maintain Richard> contact and liaison with the chairs and we would welcome Richard> ID's documenting the organization of this trial, scope Richard> and results. As you may know we will eventually want to Richard> take 2916 from proposed to draft in the usual IETF manner Richard> manner. Although I can't speak for the UK trial group, I'm sure it will be happy to do that. Though obviously this will need to be discussed first. Pretty much everything surrounding the trial will be in the public domain. The trial will appoint a manager/co-ordinator and one of their responsibilities will be liaising with other trials, IETF WG chairs, ITU SG2 and so on. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 10:02:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23623 for ; Tue, 19 Mar 2002 10:02:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21623 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 10:02:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20455; Tue, 19 Mar 2002 09:53:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20427 for ; Tue, 19 Mar 2002 09:53:11 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23373 for ; Tue, 19 Mar 2002 09:53:08 -0500 (EST) Received: from whale.cnnic.net.cn ([127.0.0.1]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GT86Q800.A12 for ; Tue, 19 Mar 2002 22:54:08 +0800 From: "bill" To: enum@ietf.org Message-ID: Date: Tue, 19 Mar 2002 06:54:08 -0800 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: zh-CN X-Accept-Language: zh-CN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA20428 Subject: [Enum] How long will it take to update a NAPTR record? Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Folks: There is machanism which make DNS to update a record in about several hours. The time to be used is determined by the TTL, refresh time, caching and etc. Have anybody consider the following question: When an ENUM subscriber want to change his NAPTR record in real-time, i.e. two mininute, like call transfer function provide by the telcom system, how to reflect changes into the DNS servers? There are many cases that need the ENUM DNS response in real-time to satisfy the user's demand. Any comments? Bill CNNIC bill@cnnic.net.cn 2002/03/19 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 10:14:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24020 for ; Tue, 19 Mar 2002 10:14:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22551 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 10:14:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21877; Tue, 19 Mar 2002 10:06:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21848 for ; Tue, 19 Mar 2002 10:06:01 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23719 for ; Tue, 19 Mar 2002 10:05:59 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA03958; Tue, 19 Mar 2002 16:05:24 +0100 (MET) Date: Tue, 19 Mar 2002 09:05:17 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bill , enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? Message-ID: <28998186.1016528717@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 06.54 -0800 bill wrote: > When an ENUM subscriber want to change his NAPTR record in real-time, > i.e. two mininute, like call transfer function provide by the telcom > system, how to reflect changes into the DNS servers? The mechanism that can be used is called DNS Dynamic Update. Since an interoperability test which was run in January this year, we know secure dynamic update is possible with both the TKEY and SIG(0) mechanisms. It is used at the IETF meeting here in Minneapolis for IPv4 addresses, and I for example is using it myself (you can have a look at the IP-address for zx81.paf.se which is the address my laptop have, or rather, last address it had). > There are many cases that need the ENUM DNS response in real-time to > satisfy the user's demand. The update with dynamic update is instanatous, but, one still need to have a TTL on the record itself. It is recommended that the TTL is around 60 seconds, and not shorter. That means that someone which queried for the record 1 second before you changed the record will have the wrong data for another 59 seconds. This is the reason why I in 2916 wrote that DNS can not be used for "real time updates". It can be used if you with "real time" accept around 30 seconds of instability for _that_ DNS record. If you have suggested wording for 2916bis which clearifies this, please send the information in my direction. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 10:50:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24879 for ; Tue, 19 Mar 2002 10:50:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24754 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 10:50:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24357; Tue, 19 Mar 2002 10:41:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24311 for ; Tue, 19 Mar 2002 10:40:58 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24681 for ; Tue, 19 Mar 2002 10:40:56 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id C4AFD3190C; Tue, 19 Mar 2002 07:40:27 -0800 (PST) To: "bill" Cc: enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? In-Reply-To: Message from "bill" of "Tue, 19 Mar 2002 06:54:08 PST." Date: Tue, 19 Mar 2002 07:40:27 -0800 Message-ID: <87391.1016552427@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "bill" == bill writes: bill> Folks: There is machanism which make DNS to update a record bill> in about several hours. The time to be used is determined by bill> the TTL, refresh time, caching and etc. This is straightforward on a UNIX system. Tools like at or cron can be used to arrange for things to be done at a specific time. For instance they could run scripts that call nsupdate to make a Dynamic Update request. The trick will be to ensure that the update gets propagated quickly to all the zone's name servers and that any stale data for the name that gets updated doesn't get cached for too long by other name servers. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 11:02:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25246 for ; Tue, 19 Mar 2002 11:02:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25998 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 11:02:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24898; Tue, 19 Mar 2002 10:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24867 for ; Tue, 19 Mar 2002 10:53:53 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24934 for ; Tue, 19 Mar 2002 10:53:50 -0500 (EST) Received: from whale.cnnic.net.cn ([127.0.0.1]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GT89JE00.810; Tue, 19 Mar 2002 23:54:50 +0800 From: "bill" To: Patrik_F=E4ltstr=F6m , enum@ietf.org Message-ID: Date: Tue, 19 Mar 2002 07:54:50 -0800 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: zh-CN Subject: Re: [Enum] How long will it take to update a NAPTR record? X-Accept-Language: zh-CN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA24868 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > > The mechanism that can be used is called DNS Dynamic Update. Since an > interoperability test which was run in January this year, we know > securedynamic update is possible with both the TKEY and SIG(0) > mechanisms. I am not familiar with the DNS Dynamic Update, and I will take time to study it later. But one thing I am sure now is that DNS can be used in some services which need to update the route parameters in so-called real-time. > If you have suggested wording for 2916bis which clearifies this, > pleasesend the information in my direction. I'd like to think about this matter. In telcom world, there's some time limit on the update of call routing parameter. So I recommend that we should consider the problem seriously and write some word for both DNS requirements and ENUM service requirement. I will try my best. Thank you. Bill CNNIC 2002/03/19 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 11:14:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25698 for ; Tue, 19 Mar 2002 11:14:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27008 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 11:14:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26396; Tue, 19 Mar 2002 11:05:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26364 for ; Tue, 19 Mar 2002 11:05:53 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25348 for ; Tue, 19 Mar 2002 11:05:50 -0500 (EST) Received: from whale.cnnic.net.cn ([127.0.0.1]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GT8A3B00.R15; Wed, 20 Mar 2002 00:06:47 +0800 From: "bill" To: Jim Reid , enum@ietf.org Message-ID: Date: Tue, 19 Mar 2002 08:06:46 -0800 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: zh-CN Subject: Re: [Enum] How long will it take to update a NAPTR record? X-Accept-Language: zh-CN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA26365 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > > This is straightforward on a UNIX system. Tools like at or cron > can be > used to arrange for things to be done at a specific time. Thanks, Jim. May you give me more information about the tools you mentioned and I can study in depth. >For instance > they could run scripts that call nsupdate to make a Dynamic Update > request. The trick will be to ensure that the update gets propagated > quickly to all the zone's name servers and that any stale data for the > name that gets updated doesn't get cached for too long by other name > servers. I think for DNS itself Dynamic Update machnism can solve some problems of the real time updating requirement brought by telcom service. Patrik has give me data about how soon it will be. Can you give me some quantitified evidence how fast the DNS update can be? Bill CNNIC 2002/03/19 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 11:48:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26675 for ; Tue, 19 Mar 2002 11:48:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29178 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 11:48:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28706; Tue, 19 Mar 2002 11:39:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28673 for ; Tue, 19 Mar 2002 11:38:59 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26412 for ; Tue, 19 Mar 2002 11:38:56 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 36A423190E; Tue, 19 Mar 2002 08:38:29 -0800 (PST) To: "bill" Cc: enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? In-Reply-To: Message from "bill" of "Tue, 19 Mar 2002 08:06:46 PST." Date: Tue, 19 Mar 2002 08:38:29 -0800 Message-ID: <88402.1016555909@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "bill" == bill writes: bill> I think for DNS itself Dynamic Update machnism can solve bill> some problems of the real time updating requirement brought bill> by telcom service. Patrik has give me data about how soon it bill> will be. Can you give me some quantitified evidence how fast bill> the DNS update can be? I don't have any numbers and I'm not aware of any benchmarking that's been done in this area. You could maybe adapt the Dynamic DNS stuff from the BIND9 test suite to get some rough benchmarks. I'd expect a decent name server to handle at least tens of dynamic update requests per second, possibly much more than that. It'll depend on things like how the requests are authenticated, how the zone is represented in stable storage, the OS and hardware platform, etc. If Secure Dynamic Update is used, throughput will obviously be lower because the server will need to compute signatures and juggle NXT records. Even so, it's not just the throughput of DDNS requests that need to be considered. Propagation of the updates via AXFR or IXFR to the zone's slave servers will have to be taken into account too. This is probably more of a limiting factor on the throughput of dynamic updates. For ENUM I don't think there are any serious performance constraints here provided the server and zone setups are sensibly engineered. ie Updating 1 RR should not cause everything in a 2Gb zone file to be re-signed or mean the whole zone gets sent to its slaves with AXFR. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 12:34:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28418 for ; Tue, 19 Mar 2002 12:34:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04433 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 12:34:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03388; Tue, 19 Mar 2002 12:24:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03358 for ; Tue, 19 Mar 2002 12:24:56 -0500 (EST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28077 for ; Tue, 19 Mar 2002 12:24:52 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2JHOJ912849 for ; Tue, 19 Mar 2002 12:24:22 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C8382B0004A9625 for enum@ietf.org; Tue, 19 Mar 2002 12:24:12 -0500 content-class: urn:content-classes:message Subject: RE: [Enum] How long will it take to update a NAPTR record? Date: Tue, 19 Mar 2002 12:24:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <62DA45D4963FA747BA1B253E266760F901B5AFB9@OCCLUST04EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Enum] How long will it take to update a NAPTR record? Thread-Index: AcHPV8SFGWUHyJQMQGKuYBfH+ZCbAQAEsrdg From: "Pfautz, Penn L, ALVAP" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA03359 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit It's nice to know about this mechanism, but does it change the view that at least some hold that ENUM is still not the place to handle realtime updates and that, at least for SIP, the ENUM should just hold a relatively static address of record? Penn -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, March 19, 2002 10:05 AM To: bill; enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? --On 2002-03-19 06.54 -0800 bill wrote: > When an ENUM subscriber want to change his NAPTR record in real-time, > i.e. two mininute, like call transfer function provide by the telcom > system, how to reflect changes into the DNS servers? The mechanism that can be used is called DNS Dynamic Update. Since an interoperability test which was run in January this year, we know secure dynamic update is possible with both the TKEY and SIG(0) mechanisms. It is used at the IETF meeting here in Minneapolis for IPv4 addresses, and I for example is using it myself (you can have a look at the IP-address for zx81.paf.se which is the address my laptop have, or rather, last address it had). > There are many cases that need the ENUM DNS response in real-time to > satisfy the user's demand. The update with dynamic update is instanatous, but, one still need to have a TTL on the record itself. It is recommended that the TTL is around 60 seconds, and not shorter. That means that someone which queried for the record 1 second before you changed the record will have the wrong data for another 59 seconds. This is the reason why I in 2916 wrote that DNS can not be used for "real time updates". It can be used if you with "real time" accept around 30 seconds of instability for _that_ DNS record. If you have suggested wording for 2916bis which clearifies this, please send the information in my direction. paf _______________________________________________ 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 daemon@ns.ietf.org Tue Mar 19 12:36:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28515 for ; Tue, 19 Mar 2002 12:36:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04687 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 12:36:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03567; Tue, 19 Mar 2002 12:28:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03527 for ; Tue, 19 Mar 2002 12:28:00 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28125 for ; Tue, 19 Mar 2002 12:27:56 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA29195; Tue, 19 Mar 2002 18:27:20 +0100 (MET) Date: Tue, 19 Mar 2002 11:22:29 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Jim Reid , bill cc: enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? Message-ID: <29336334.1016536949@localhost> In-Reply-To: <88402.1016555909@shell.nominum.com> References: <88402.1016555909@shell.nominum.com> X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 08.38 -0800 Jim Reid wrote: > Even so, it's not just the throughput of DDNS requests that need to be > considered. Propagation of the updates via AXFR or IXFR to the zone's > slave servers will have to be taken into account too. This is probably > more of a limiting factor on the throughput of dynamic updates. As each number most certainly will be it's own zone (where the NAPTR's are) this is not a problem. You have a problem if you have large amount of updates to the _same_ zone. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 12:36:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28508 for ; Tue, 19 Mar 2002 12:36:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04673 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 12:36:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03598; Tue, 19 Mar 2002 12:28:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03535 for ; Tue, 19 Mar 2002 12:28:01 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28127 for ; Tue, 19 Mar 2002 12:27:57 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA29208; Tue, 19 Mar 2002 18:27:24 +0100 (MET) Date: Tue, 19 Mar 2002 11:26:16 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: bill , enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? Message-ID: <29349943.1016537176@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 07.54 -0800 bill wrote: > I am not familiar with the DNS Dynamic Update, and I will take time to > study it later. But one thing I am sure now is that DNS can be used in > some services which need to update the route parameters in so-called > real-time. In short, it is a normal DNS packet which is sent from the client to a DNS server requesting to do update the DNS zone. Because of security reasons, the request is normally signed, and the signing is in SIG(0) done using SIG resource record just like DNSSEC is signing DNS records. For example if you look at the KEY resource record for zx81.paf.se you see the public key for the key which is allowed (according to configuration of the master server for the zone zx81.paf.se) to update the record zx81.paf.se (RR type A). This means that if I on my laptop, which is where I have the private key, do a dnsupdate using a signature, the request is verified by the server, and accepted if the request is signed correctly. This is one of the number one reasons why ENUM is only using DNS as a mechanism for storing data, and why ENUM should not try to describe how DNS works. One can when doing ENUM "services" use any DNS functionality which is needed. At the moment, dynamic updates are being deployed. Good thing! That also ENUM can take advantage of. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 14:09:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00780 for ; Tue, 19 Mar 2002 14:09:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09646 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 14:09:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08619; Tue, 19 Mar 2002 14:00:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08583 for ; Tue, 19 Mar 2002 14:00:08 -0500 (EST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00517 for ; Tue, 19 Mar 2002 14:00:05 -0500 (EST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 21C5531925; Tue, 19 Mar 2002 10:59:30 -0800 (PST) To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: bill , enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Tue, 19 Mar 2002 11:22:29 CST." <29336334.1016536949@localhost> Date: Tue, 19 Mar 2002 10:59:30 -0800 Message-ID: <91605.1016564370@shell.nominum.com> From: Jim Reid Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: >> Even so, it's not just the throughput of DDNS requests that >> need to be considered. Propagation of the updates via AXFR or >> IXFR to the zone's slave servers will have to be taken into >> account too. This is probably more of a limiting factor on the >> throughput of dynamic updates. paf> As each number most certainly will be it's own zone (where paf> the NAPTR's are) this is not a problem. I'm not sure I agree with you, though I accept that in principle dynamic updates to small zones should propagate quickly to the zone's slave servers. A server's ability to propagate new copies of the zone can be orthogonal to the rate at which it can dynamically update the zone: commit the update to stable storage and bump up the SOA serial number, send out NOTIFYs and then hope the slaves respond quickly enough with an IXFR or AXFR that doesn't run forever. There's not much point in some master server processing a dynamic update in say 10ms if it takes days for the slave servers to converge on the new zone data. [I exaggerate for effect.] I have heard of slave servers that have been unable to converge on new zone data, usually because they have too many zones (100K+) and get swamped with NOTIFYs or refresh queries or inbound zone transfers. paf> You have a problem if you have large amount of updates to the paf> _same_ zone. Oh yeah -- too true. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 14:28:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01400 for ; Tue, 19 Mar 2002 14:28:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10976 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 14:28:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10430; Tue, 19 Mar 2002 14:19:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10403 for ; Tue, 19 Mar 2002 14:19:58 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01146 for ; Tue, 19 Mar 2002 14:19:55 -0500 (EST) Received: from [166.63.186.229] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA15094; Tue, 19 Mar 2002 20:19:21 +0100 (MET) Date: Tue, 19 Mar 2002 13:18:56 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Pfautz, Penn L, ALVAP" , enum@ietf.org Subject: RE: [Enum] How long will it take to update a NAPTR record? Message-ID: <29369005.1016543936@localhost> In-Reply-To: <62DA45D4963FA747BA1B253E266760F901B5AFB9@OCCLUST04EVS1.ugd.att.com> References: <62DA45D4963FA747BA1B253E266760F901B5AFB9@OCCLUST04EVS1.ugd.att. com> X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 12.24 -0500 "Pfautz, Penn L, ALVAP" wrote: > It's nice to know about this mechanism, but does it change the view that > at least some hold that ENUM is still not the place to handle realtime > updates and that, at least for SIP, the ENUM should just hold a > relatively static address of record? Simple answer: No. ENUM is not a replacement for SIP registrations or LDAP access to an SCP or whatever. ENUM is a directory service where one can translate from an E.164 numbers to a set of URI's. That mapping should not change too often. "False positives" regarding URI's MUST be accepted. With that I mean that an E.164 can map to a SIP URI, but noone might be registered at that address at the time when the call setup happens. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 14:30:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01459 for ; Tue, 19 Mar 2002 14:30:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11137 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 14:30:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10495; Tue, 19 Mar 2002 14:21:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10467 for ; Tue, 19 Mar 2002 14:21:16 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01224 for ; Tue, 19 Mar 2002 14:21:13 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28795 for ; Tue, 19 Mar 2002 14:19:42 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28791 for ; Tue, 19 Mar 2002 14:19:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] How long will it take to update a NAPTR record? Date: Tue, 19 Mar 2002 12:21:52 -0700 Message-ID: Thread-Topic: [Enum] How long will it take to update a NAPTR record? Thread-Index: AcHPV8SFGWUHyJQMQGKuYBfH+ZCbAQAEsrdgAAQKrzA= From: "Zmolek, Andrew (Andrew)" To: "Pfautz, Penn L, ALVAP" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA10468 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Even if the real-time update problem is solved, the notion of adding tailorable privacy/authentication/authorization/policy to any given request/response transaction is still not appropriately solved in DNS (nor should it be). In other words, there's still room for an enum SRS or "presence" service. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Pfautz, Penn L, ALVAP [mailto:ppfautz@att.com] Sent: Tuesday, March 19, 2002 10:24 AM To: enum@ietf.org Subject: RE: [Enum] How long will it take to update a NAPTR record? It's nice to know about this mechanism, but does it change the view that at least some hold that ENUM is still not the place to handle realtime updates and that, at least for SIP, the ENUM should just hold a relatively static address of record? Penn -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, March 19, 2002 10:05 AM To: bill; enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? --On 2002-03-19 06.54 -0800 bill wrote: > When an ENUM subscriber want to change his NAPTR record in real-time, > i.e. two mininute, like call transfer function provide by the telcom > system, how to reflect changes into the DNS servers? The mechanism that can be used is called DNS Dynamic Update. Since an interoperability test which was run in January this year, we know secure dynamic update is possible with both the TKEY and SIG(0) mechanisms. It is used at the IETF meeting here in Minneapolis for IPv4 addresses, and I for example is using it myself (you can have a look at the IP-address for zx81.paf.se which is the address my laptop have, or rather, last address it had). > There are many cases that need the ENUM DNS response in real-time to > satisfy the user's demand. The update with dynamic update is instanatous, but, one still need to have a TTL on the record itself. It is recommended that the TTL is around 60 seconds, and not shorter. That means that someone which queried for the record 1 second before you changed the record will have the wrong data for another 59 seconds. This is the reason why I in 2916 wrote that DNS can not be used for "real time updates". It can be used if you with "real time" accept around 30 seconds of instability for _that_ DNS record. If you have suggested wording for 2916bis which clearifies this, please send the information in my direction. paf _______________________________________________ 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 daemon@ns.ietf.org Tue Mar 19 14:47:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02042 for ; Tue, 19 Mar 2002 14:47:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12719 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 14:47:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12039; Tue, 19 Mar 2002 14:38:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12012 for ; Tue, 19 Mar 2002 14:38:39 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01663 for ; Tue, 19 Mar 2002 14:38:36 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA17469; Tue, 19 Mar 2002 20:37:56 +0100 (MET) Date: Tue, 19 Mar 2002 13:28:16 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Jim Reid cc: bill , enum@ietf.org Subject: Re: [Enum] How long will it take to update a NAPTR record? Message-ID: <29402593.1016544496@localhost> In-Reply-To: <91605.1016564370@shell.nominum.com> References: <91605.1016564370@shell.nominum.com> X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 10.59 -0800 Jim Reid wrote: > I'm not sure I agree with you, though I accept that in principle > dynamic updates to small zones should propagate quickly to the zone's > slave servers. We agree Jim. My point was that if you have a large number of records, you will also have a large number of updates to a zone. This is based on the fact that I think that each record will be updated say 1 time / week. If each record is updated once a week, if you have one record in your zone, that leads to one change a week. If you have 600k records, that means one update a second. I rather have a server which have one update a week than once a second. Just think about the serial number, and how often the authoritative servers are in sync. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 15:05:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02447 for ; Tue, 19 Mar 2002 15:05:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13945 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 15:06:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13167; Tue, 19 Mar 2002 14:57:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13138 for ; Tue, 19 Mar 2002 14:57:13 -0500 (EST) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02267 for ; Tue, 19 Mar 2002 14:57:10 -0500 (EST) Received: from zx81.paf.se.ietf53.cw.net (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA19721; Tue, 19 Mar 2002 20:56:32 +0100 (MET) Date: Tue, 19 Mar 2002 13:54:14 -0600 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , "Pfautz, Penn L, ALVAP" , enum@ietf.org Subject: RE: [Enum] How long will it take to update a NAPTR record? Message-ID: <29472105.1016546053@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-03-19 12.21 -0700 "Zmolek, Andrew (Andrew)" wrote: > Even if the real-time update problem is solved, the notion of adding > tailorable privacy/authentication/authorization/policy to any given > request/response transaction is still not appropriately solved in DNS > (nor should it be). What Secure Dynamic Updates help you with is to give the ability for someone to in a secure and authenticated way update the record. Before this happens, a "normal" verification of a public key must happen. During this key verification phase, the authorization can be done. I.e. I agree with the statement above if you with the above mean (which I think and hope) that E.164 issues are handled on one layer, and DNS issues on onother. DNS issues are with for example the mechanism I specified ok. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 15:11:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02613 for ; Tue, 19 Mar 2002 15:11:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14092 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 15:11:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13797; Tue, 19 Mar 2002 15:01:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13754 for ; Tue, 19 Mar 2002 15:01:44 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02375 for ; Tue, 19 Mar 2002 15:01:40 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2JK0CB09674 for ; Tue, 19 Mar 2002 15:00:12 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2JK0BB09663 for ; Tue, 19 Mar 2002 15:00:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Enum] How long will it take to update a NAPTR record? Date: Tue, 19 Mar 2002 13:02:20 -0700 Message-ID: Thread-Topic: [Enum] How long will it take to update a NAPTR record? Thread-Index: AcHPgEZzQMRjvdDgQ/SBG8HMuYlzqQAAF7gQ From: "Zmolek, Andrew (Andrew)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Pfautz, Penn L, ALVAP" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA13755 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Yes, I was speaking on the E.164 issues as being separate from the DNS issues. --Andy -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, March 19, 2002 12:54 PM To: Zmolek, Andrew (Andrew); Pfautz, Penn L, ALVAP; enum@ietf.org Subject: RE: [Enum] How long will it take to update a NAPTR record? --On 2002-03-19 12.21 -0700 "Zmolek, Andrew (Andrew)" wrote: > Even if the real-time update problem is solved, the notion of adding > tailorable privacy/authentication/authorization/policy to any given > request/response transaction is still not appropriately solved in DNS > (nor should it be). What Secure Dynamic Updates help you with is to give the ability for someone to in a secure and authenticated way update the record. Before this happens, a "normal" verification of a public key must happen. During this key verification phase, the authorization can be done. I.e. I agree with the statement above if you with the above mean (which I think and hope) that E.164 issues are handled on one layer, and DNS issues on onother. DNS issues are with for example the mechanism I specified ok. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue Mar 19 17:32:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06426 for ; Tue, 19 Mar 2002 17:32:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22797 for enum-archive@odin.ietf.org; Tue, 19 Mar 2002 17:33:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22077; Tue, 19 Mar 2002 17:24:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22046 for ; Tue, 19 Mar 2002 17:24:01 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06210 for ; Tue, 19 Mar 2002 17:23:58 -0500 (EST) Received: from whale.cnnic.net.cn ([127.0.0.1]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP id GT8RLM00.R1H; Wed, 20 Mar 2002 06:24:58 +0800 From: "bill" To: Kevin McCandless , enum@ietf.org Cc: patrik@cisco.com Message-ID: Date: Tue, 19 Mar 2002 14:24:58 -0800 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: zh-CN Subject: Re: RE: [Enum] How long will it take to update a NAPTR record? X-Accept-Language: zh-CN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA22047 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Thanks, Kevin, You make things more clear. Different time limit will be determined for each tiers of DNS registry of ENUM: *for Tier 0, it will be a couple of days; *for Tier 1, it will be several hours; *for Tier 2, it will be less than a minute; So the so-called "real-time" update must be understood and implemented under each tier of DNS provision of ENUM system. I proposed that a informational draft on ENUM service related DNS question be produced before next IETF meeting. I think such work will benefit the long term implementation of ENUM. Bill CNNIC 2002/03/19 ----- Original Message ----- From: Kevin McCandless Date: Tuesday, March 19, 2002 11:37 am Subject: RE: [Enum] How long will it take to update a NAPTR record? > Bill: > > The NAPTR records are hosted by the Tier 2 provider. Therefore, > the records > reside within their local servers. So, if I changed or added a > NAPTR record > the information should be availble to new query within minutes. > Now, if I > just signed up for ENUM or changed my Tier II provider which would > requireNS records update/changes then this would take more time to > be accessable by > the query. > > My thoughts......... > > Kevin > -----Original Message----- > From: bill > To: enum@ietf.org > Sent: 3/19/2002 6:54 AM > Subject: [Enum] How long will it take to update a NAPTR record? > > Folks: > > There is machanism which make DNS to update a record in about > several > hours. The time to be used is determined by the TTL, refresh time, > caching and etc. Have anybody consider the following question: > > When an ENUM subscriber want to change his NAPTR record in real- > time, > i.e. two mininute, like call transfer function provide by the > telcom > system, how to reflect changes into the DNS servers? > > There are many cases that need the ENUM DNS response in real-time > to > satisfy the user's demand. > > Any comments? > > Bill > > CNNIC > bill@cnnic.net.cn > > 2002/03/19 > > > _______________________________________________ > 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