From enum-bounces@ietf.org Thu Mar 01 08:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMkvU-0001JL-BV; Thu, 01 Mar 2007 08:02:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMkvS-0001JF-UN for enum@ietf.org; Thu, 01 Mar 2007 08:02:26 -0500 Received: from mailgw.nic.or.kr ([202.30.50.169] helo=nida.or.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMkvQ-0000OZ-6l for enum@ietf.org; Thu, 01 Mar 2007 08:02:26 -0500 X-HELO: ehlo mail.nic.or.kr X-RECEIVED-IP: 202.30.50.51 Received: from 202.30.50.51(202.30.50.51) at Thu, 01 Mar 2007 22:00:39 +0900 by nida.or.kr with ESMTP CrediShield X-MAIL-FROM: jhlim@nida.or.kr Received: from sr71 (localhost [127.0.0.1]) by mail.nic.or.kr (v3smtp 8.11.6.9/8.11.0) with ESMTP id l21CvnV14548 for ; Thu, 1 Mar 2007 21:57:49 +0900 (KST) From: "JoonHyung Lim" To: Date: Thu, 1 Mar 2007 21:57:49 +0900 Message-ID: <003801c75c01$37d86640$4a32a8c0@sr71> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C75C4C.A7C00E40" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdcATdh2OiQSdKTSlC6t4V258Jsdg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Subject: [Enum] Requesting comments on draft-lim-kim-enum-based-softswitch-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C75C4C.A7C00E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Since last meeting in San Diego, I had revised "ENUM-based softswitch requirement" draft with some comments from WG people. - purpose of document changed to provide information about Infra ENUM trial in Korea - 'Rcode' story in "Section 4" is more expanded to describe the ENUM implementation on softswitch. - Korean BCP material newly described in "Section 3" and "Section 5" Before it will be announced, if you don't mind, I'd like to have comments in advance, from people who interested in ENUM-based softswitch issue. Any comments will be helpful for our work. it will be announced on I-D list within next few days. Thanks. JoonHyung Lim, NIDA ------=_NextPart_000_0039_01C75C4C.A7C00E40 Content-Type: text/plain; name="draft-lim-kim-enum-based-softswitch-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-lim-kim-enum-based-softswitch-01.txt" =20 ENUM J. Lim=20 Internet Draft W. Kim=20 Intended Status: Informational C. Park=20 Expires: August 27, 2007 NIDA=20 February 23, 2007=20 =20 =20 ENUM-based Softswitch Requirement=20 =20 =20 =20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, each author represents that any =20 applicable patent or other IPR claims of which he or she is aware =20 have been or will be disclosed, and any of which he or she becomes =20 aware will be disclosed, in accordance with Section 6 of BCP 79. =20 =20 Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF), its areas, and its working groups. Note that =20 other groups may also distribute working documents as Internet-=20 Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six =20 months and may be updated, replaced, or obsoleted by other documents = at any time. It is inappropriate to use Internet-Drafts as =20 reference material or to cite them other than as "work in progress". = =20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/1id-abstracts.html =20 =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html=20 =20 This Internet-Draft will expire on August 27, 2007=20 =20 Copyright Notice =20 =20 Copyright (C) The IETF Trust (2007).=20 =20 =20 Abstract=20 =20 This document describes operational requirement and several=20 considerations for ENUM-based softswitch, which can route a call=20 between 2 Korean VoIP carriers during the ENUM pre-commercial trial=20 hosted by National Internet Development Agency of Korea(NIDA) in = 2006.=20 This experience can be one of interim solution to maintain stability=20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 1]=20 =20 =20 of on-going commercial softswitch system while initial stage of ENUM=20 service that does not have sufficient data.=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Call Routing on Softswitch.....................................3=20 3. Infrastructure ENUM trial in Korea.............................3=20 4. Requirement for ENUM-based Softswitch..........................4=20 4.1 call routing cases for DNS response code...................4=20 4.2 type of domain routing.....................................4=20 5. Trial Results..................................................5=20 6. 'e164.arpa' consideration......................................6=20 7. Security consideration.........................................6=20 8. IANA Considerations............................................7=20 9. References.....................................................7=20 10. Acknowledgments...............................................7=20 Author's Addresses................................................8=20 =20 =20 1.Introduction=20 =20 ENUM[1] is a mapping system based on DNS[3] that converts from=20 E.164[2] number to domain name using 'Naming Authority=20 Pointer(NAPTR)' resource record, which is able to store different=20 service types such as fax, email, homepage, and etc., for every E.164 = number. It originally focused on how end-user could access to other=20 end-user's information through the Internet. =20 =20 Recently, various discussions are needed about RFC3761, because=20 infrastructure ENUM that provides routing information between=20 carriers.=20 =20 In case of VoIP service, VoIP carrier that wants to integrate various = protocols uses softswitch. However, It is still inefficient for=20 interconnection, number portability, and protocol information among=20 carriers because softswitch does not have end-to-end routing=20 information for all carriers. These informations can be stored in = DNS,=20 as a ENUM-basis. Therefore, carriers can expect many benefits If they = use a ENUM for call routing on softswitch. =20 =20 To make sure these benefits and to verify the performance of ENUM- enabled softswitch, NIDA had cooperated with 2 Korean VoIP service=20 providers for Infrastructure ENUM trial in 2006. NIDA is a non-profit = organization with a mandate to manage 2.8.e164.arpa domain name=20 representing +82 country code of Korea, and also promote a Internet- related things in national wide, including a ENUM. so, NIDA provides=20 ENUM DNS to each VoIP service provider for call routing and ENUM DNS=20 was able to access publicly.=20 =20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 2]=20 =20 =20 2.Call Routing on Softswitch=20 =20 In the PSTN(Public Switched Telephone Network), Only hardware-typed=20 switch rules the network. Softswitch is the switch implemented on=20 computer system by software. It usually controls various signaling=20 protocols which are SIP[7], H.323[8], MGCP[9], and etc., to make call = connections for VoIP service on the boundary point between circuit=20 and packet network. =20 =20 To make a call, first of all, softswitch must discover routing=20 information associating with the E.164 number comes from caller, on=20 its own routing table, and then caller can connect the callee=20 directly.=20 =20 Today, call routing based on prefix of number has used not only for=20 legacy PSTN switch, but also for softswitch very widely. So, if=20 softswitch can use ENUM DNS for call routing, in the beginning, most=20 of calls queried to ENUM DNS would be failed in case of small group=20 of carriers, however it will be getting more answer from ENUM DNS if=20 group of carriers is getting bigger.=20 =20 3.Infrastructure ENUM trial in Korea=20 =20 As described on section 1, NIDA and 2 VoIP Service Provider built up=20 ENUM-based softswitch and made a interconnection using centralized=20 ENUM DNS operated by NIDA. Provisioning the E.164 number based on EPP = described in RFC4114 is also implemented and update the ENUM DNS=20 instantly, using Dynamic Update(RFC2136).=20 =20 Call routing = =20 +---------------------------------------------+ = =20 | | = | | =20 +-----+------+ +-----------------+ +------+-----+ =20 |Softswitch A|------| ENUM DNS(+82) |------|Softswitch B| =20 +-----+------+ | (Tier1,2) | +------+-----+ =20 | +--------+--------+ | =20 +-----+------+ | +------+-----+ = =20 | IP Phone A | |Dynamic update | IP Phone B | = =20 +------------+ |(RFC2136) +------------+ =20 |=20 +------------+ +--------+--------+ +------------+ =20 | EPP Client | | Registration | | EPP Client | =20 | |------| server |------| | = =20 +------------+ +-----------------+ +------------+ = =20 Provisioning E.164 Numbers(RFC4114) = =20 = =20 Carrier A NIDA Carrier B = =20 = =20 Figure 1 : Infrastructure ENUM Trial system topology=20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 3]=20 =20 =20 =20 4.Requirement for ENUM-based Softswitch=20 =20 4.1 Call routing cases for DNS response code=20 =20 To use ENUM DNS, softswitch need to have ENUM module that converts=20 from E.164 number to ENUM domain name defined in RFC3761 and process=20 a query to ENUM DNS. ENUM module MUST follow the RFC3761.=20 =20 However, initial stage of ENUM DNS shares call routing information=20 from limited carriers, so It makes problem that softswitch can't find = all of call routing information on ENUM DNS. To solve this problem,=20 ENUM-based softswitch MUST follow the below. =20 =20 (1) ENUM module of softswitch converts E.164 number comes from=20 the VoIP subscriber to domain name defined RFC3761.=20 =20 (2) ENUM module of softswitch as a stub resolver, send a query=20 to recursive name server.=20 =20 (3) if the ENUM module receives the answer, call routing process = may branch off several way. It depends on Rcode value in=20 answer section of DNS messages[4] as shown below.=20 =20 a. Rcode=3D0 (No error condition)=20 There is a answer to coressponding query. However call=20 routing process must different for following conditions. = =20 i. If there is not a certain URI that can initiate a call = such as SIP, H.323, and etc, call must fail=20 immediately.=20 ii. if there are more than 2 SIP or H.323 URI, softswitch = can pick one based on the preference and order value=20 in NAPTR RR.=20 =20 b. Rcode=3D3(Name error), 1(Format Error), 2(Server Failure), = 4(Not Implemented) or 5(Refused)=20 There is no valid answer for NAPTR RR. So, softswitch must = convert the number with its vendor specific method=20 subsequently such as prefix-based method. In this case, it = means call must be delivered through PSTN for call = routing.=20 =20 4.2 Type of domain routing =20 =20 If the DNS response has valid URI such as SIP and H.323, softswitch=20 can resolve a domain name of certain URI to route a call by=20 searching two different sources. One is recursive nameserver, and=20 the other is fixed routing table in softswitch, storing domain name=20 and its corresponding IP address.=20 =20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 4]=20 =20 =20 If there are many points of interconnection, recursive nameserver is = useful for resolving a domain name, But if there are just few known=20 carriers and they do not change the interconnection information=20 frequently, a fixed routing table maps domain name to corresponding=20 IP address is more efficient rather than querying to recursive=20 nameserver everytime. In addition, carriers would like to charge a=20 interconnection fee for all received call, so they tend to make=20 interconnection only with trusted carriers based on sort of=20 agreement between carriers. =20 =20 These two types of domain routing are also affected on Rcode=3D0 = case=20 described on section 4.1=20 =20 (1) Case for using fixed routing table=20 a. If domain name part of URI is able to find on fixed routing=20 table, softswitch can use it. =20 b. If domain name part of URI does not exist on fixed routing=20 table, it gets forwards to PSTN.=20 =20 (2) Case for using recursive nameserver=20 a. If domain name part of URI is able to resolve on recursive=20 nameserver, softswitch can use it.=20 b. If domain name part of URI is not able to resolve on=20 recursive nameserver due to any condition such as Rcode=3D1, = 2,=20 3, 4, or 5, call must get forward to PSTN.=20 =20 Case '(1)' seems like inefficient because administrator maintains=20 two management points of numbers which are ENUM DNS and softswitch=20 itself. However it will be able to minimize failure ratio of call=20 routing from transition period of ENUM. So case '(1)' implemented on = softswitch for trial and hereafter if ENUM will be filled, case=20 '(2)' will be reasonable choice.=20 =20 With these requirements, 2 carriers could use ENUM DNS for call=20 routing without any affect on their on-going commercial VoIP = service.=20 =20 5.Trial Results=20 =20 To provide a stable commercial service, ENUM-based Softswitch must=20 have certain performance as much as Non-ENUM Softswitch has. Only=20 difference between 2 types of softswitch is searching mechanism for=20 call routing information which can be stored in softswitch itself or=20 external DNS. Therefore delay time for call routing, is important to=20 guarantee quality of Service. During the trial, each carrier measured = this delay time based on SIP protocol, so called "Answer Delay time"=20 defined as elapsed time between requesting a call('INVITE' message)=20 and receiving a response('200OK'message)[7]. =20 =20 =20 =20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 5]=20 =20 =20 Call Type ENUM Non-ENUM=20 Carrier A->A 2.33 2.28=20 Carrier A->B 2.23 2.25=20 Carrier A->other(PSTN) 4.11 3.79=20 Carrier B->B 2.18 2.05=20 Carrier B->A 2.19 2.19=20 Carrier B->other(PSTN) 3.95 3.41=20 =20 Table 1 : Average Answer Delay time (sec)=20 =20 As it shown on Table 1, there are few difference for time(under a=20 sec) between ENUM and Non-ENUM case. Therefore a caller of each=20 carrier is hard to feel the difference as aspect of quality when a=20 call initiates. It means ENUM definitely works well with softswitch=20 on commercial basis.=20 =20 To make the trial more realistic, The resolver that was used by ENUM- based softswitch was a recursive nameserver can be accessed publicly, = just because a tough condition would be better for verify the fact=20 that a ENUM-based softswitch works as much as Non-ENUM softswitch=20 providing a commercial VoIP service.=20 =20 6.'e164.arpa' consideration=20 =20 During the trial, Infrastructure ENUM deployed on ?.8.e164.arpa? zone that could be accessible from public internet. With this=20 condition, each carrier had a question whether the centralized number = management under the ENUM DNS is a realistic or not. Sometimes it is=20 ambiguous to draw the line among carriers in the aspect of=20 responsibility for number management. =20 =20 In addition, they also had a question why Infrastructure ENUM needs=20 to be accessible publicly. To prevent disclosure of telephone number, = they prefer to access the ENUM DNS privately. Therefore ENUM module=20 embedded on softswitch is need to be flexible to adopt these=20 considerations during the interim period of ENUM.=20 =20 7.Security consideration=20 =20 This document basically follows the same security consideration of=20 RFC3761 and 'draft-ietf-enum-infrastructure-05.txt'[6] because the=20 ENUM DNS could be accessed from public internet.=20 =20 In addition, If the recursive DNS handles ENUM queries coming from=20 softswitch is compromised by attacker, It will be able to fail a call = or occur delay to call. Therefore, recursive DNS may let in the=20 local network as same as softswitch, and restrict access from outside = with proper access-list policy.=20 =20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 6]=20 =20 =20 8.IANA Considerations=20 =20 This document is only advisory, and does not include any IANA=20 considerations.=20 =20 9.References=20 =20 9.1. Normative References=20 =20 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource=20 Identifiers (URI) Dynamic Delegation Discovery System (DDDS)=20 Application (ENUM)", RFC 3761, April 2004.=20 =20 [2] International Telecommunication Union-Telecommunication=20 Standardization Sector, "The International Public=20 Telecommunication Numbering Plan", Recommendation E.164",=20 February 2005.=20 =20 [3] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", =20 RFC 1034, November 1987.=20 =20 [4] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND=20 SPECIFICATION", RFC 1035, November 1987.=20 =20 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform=20 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,=20 January 2005.=20 =20 [6] J. Livingood, Pfautz, P., R. Stastny, "The E.164 to Uniform=20 Resource Identifiers (URI) Dynamic Delegation Discovery System = (DDDS) Application for Infrastructure ENUM", draft-ietf-enum- infrastructure-05, Jan 2007. =20 =20 9.2. Informative References=20 =20 [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,=20 J.Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:=20 Session Initiation Protocol", RFC 2119, June 2002.=20 =20 [8] "Packet-based multimedia communications systems", ITU-T=20 Recommendation H.323, 2003.=20 =20 [9] F. Andreasen, B. Foster, "Media Gateway Control Protocol(MGCP) = Version 1.0", RFC 3435, January 2003=20 =20 10.Acknowledgments=20 =20 Thanks to Richard Shockey, Jason Livingood and Karsten Fleischhauer=20 who helped guide the direction of this document.=20 =20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 7]=20 =20 =20 Author's Addresses=20 =20 JoonHyung Lim=20 National Internet Development Agency of Korea(NIDA)=20 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu=20 Seoul, Korea=20 Phone: +82-2-2186-4548=20 Email: jhlim@nida.or.kr=20 URI: http://www.nida.or.kr =20 =20 Weon Kim=20 National Internet Development Agency of Korea(NIDA)=20 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu=20 Seoul, Korea=20 Phone: +82-2-2186-4502=20 Email: wkim@nida.or.kr=20 URI: http://www.nida.or.kr =20 =20 ChanKi Park=20 National Internet Development Agency of Korea(NIDA)=20 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu=20 Seoul, Korea=20 Phone: +82-2-2186-4504=20 Email: ckp@nida.or.kr=20 URI: http://www.nida.or.kr =20 =20 Full Copyright Statement=20 =20 Copyright (C) The IETF Trust (2007).=20 =20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 =20 This document and the information contained herein are provided on an = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS = OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND = =20 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS = OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF = THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Intellectual Property=20 =20 The IETF takes no position regarding the validity or scope of any =20 Intellectual Property Rights or other rights that might be claimed to = pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; nor does it represent that it has=20 made any independent effort to identify any such rights. Information=20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 8]=20 =20 =20 on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 =20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of = such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository at = http://www.ietf.org/ipr.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at ietf- ipr@ietf.org.=20 =20 Acknowledgment=20 =20 Funding for the RFC Editor function is provided by the IETF=20 Administrative Support Activity (IASA).=20 =20 =20 Lim, et.al. Expires - August 27, 2007 [Page 9]=20 ------=_NextPart_000_0039_01C75C4C.A7C00E40 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_0039_01C75C4C.A7C00E40-- From enum-bounces@ietf.org Thu Mar 01 08:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMl41-0004aJ-81; Thu, 01 Mar 2007 08:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMl3z-0004ZJ-FF for enum@ietf.org; Thu, 01 Mar 2007 08:11:15 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMl3w-0001Ri-Op for enum@ietf.org; Thu, 01 Mar 2007 08:11:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 14:10:33 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C8F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Thread-Index: Acdbk3B+eBxgZ/hISQK0w7VN3XKTywAbcyD/ References: From: "Stastny Richard" To: , , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dear ADs and WG-chairs, =20 this I-D is the follow up from draft-ietf-enum-void-02.txt, which was already in IESG evaluation (and still is). (so it is basically draft-ietf-enum-void-03.txt) =20 Since we did extensive changes, we renamed it to draft-ietf-enum-unused-01.txt=20 This I-D is now back to status ID exists. =20 Can you please clarify the correct status of this draft =20 =20 Richard ________________________________ Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Gesendet: Do 01.03.2007 00:50 An: i-d-announce@ietf.org Cc: enum@ietf.org Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt=20 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 : IANA Registration for Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-01.txt Pages : 25 Date : 2007-2-28 =20 This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-unused-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant 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. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 09:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmP4-0003zw-Is; Thu, 01 Mar 2007 09:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmP3-0003w9-9I for enum@ietf.org; Thu, 01 Mar 2007 09:37:05 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMmOt-0004dU-Fx for enum@ietf.org; Thu, 01 Mar 2007 09:37:05 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1172759814!15432676!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24702 invoked from network); 1 Mar 2007 14:36:54 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-10.tower-121.messagelabs.com with SMTP; 1 Mar 2007 14:36:54 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21EaoiH025470; Thu, 1 Mar 2007 09:36:50 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21EaZ57025340; Thu, 1 Mar 2007 09:36:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 09:36:41 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ED97250@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C8F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Thread-Index: Acdbk3B+eBxgZ/hISQK0w7VN3XKTywAbcyD/AAMknPA= From: "PFAUTZ, PENN L, TCORP" To: "Stastny Richard" X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard: I guess I'm still left wondering about the real need for this = functionality other than in the case of ENUM only number ranges (and = even then, with proper design in the circuit switched network I don't = see that it should be a problem.) Users should know the number they want to call including how many digits = it has; if they dial a non-working number the call won't go through and = will fail somewhere in the ENUM query process or the CSN. Are misdials = to vacant codes and numbers not in service frequent enough to justify = the provisioning effort proposed in Section 7.4? I'd much prefer to see = this functionality limited to the ENUM only number range case or maybe = where CREU (not that I'm in favor of it) is deployed.=20 Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, March 01, 2007 8:11 AM To: fluffy@cisco.com; jon.peterson@neustar.biz; = richard.schockey@neustar.bit; Patrik F=E4ltstr=F6m Cc: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt=20 Dear ADs and WG-chairs, =20 this I-D is the follow up from draft-ietf-enum-void-02.txt, which was already in IESG evaluation (and still is). (so it is basically draft-ietf-enum-void-03.txt) =20 Since we did extensive changes, we renamed it to draft-ietf-enum-unused-01.txt=20 This I-D is now back to status ID exists. =20 Can you please clarify the correct status of this draft =20 =20 Richard ________________________________ Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Gesendet: Do 01.03.2007 00:50 An: i-d-announce@ietf.org Cc: enum@ietf.org Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt=20 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 : IANA Registration for Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-01.txt Pages : 25 Date : 2007-2-28 =20 This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-unused-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant 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. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 09:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmgs-0007m0-Bc; Thu, 01 Mar 2007 09:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmgq-0007lo-HW for enum@ietf.org; Thu, 01 Mar 2007 09:55:28 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMmgp-0006i2-QH for enum@ietf.org; Thu, 01 Mar 2007 09:55:28 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B26C29E295; Thu, 1 Mar 2007 14:55:01 +0000 (GMT) In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0ED97250@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0ED97250@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 14:55:00 +0000 To: "PFAUTZ, PENN L, TCORP" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.5 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Penn, I don't see place where this draft (or VOID before it) says that AT&T -MUST- do anything. This draft is a protocol tool thatpeople can use if they believe it is convenient for them. If a Carrier decides not to use it, that's fine. Nothing breaks, but there may be inter-carrier signalling on the SS7 network for the failed call; just the same as now. As the draft says in the abstract - 'When such an indication is provided, an ENUM client can detect calls that will fail "early"' If you don't use it, they can't. If you do they can. It is OF COURSE your choice on whether or not to provision this data. all the best, Lawrence On 1 Mar 2007, at 14:36, PFAUTZ, PENN L, TCORP wrote: > Richard: > I guess I'm still left wondering about the real need for this =20 > functionality other than in the case of ENUM only number ranges =20 > (and even then, with proper design in the circuit switched network =20 > I don't see that it should be a problem.) > Users should know the number they want to call including how many =20 > digits it has; if they dial a non-working number the call won't go =20 > through and will fail somewhere in the ENUM query process or the =20 > CSN. Are misdials to vacant codes and numbers not in service =20 > frequent enough to justify the provisioning effort proposed in =20 > Section 7.4? I'd much prefer to see this functionality limited to =20 > the ENUM only number range case or maybe where CREU (not that I'm =20 > in favor of it) is deployed. > > > Penn Pfautz > AT&T Global Access Management > +1-732-420-4962 > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 01, 2007 8:11 AM > To: fluffy@cisco.com; jon.peterson@neustar.biz; =20 > richard.schockey@neustar.bit; Patrik F=E4ltstr=F6m > Cc: enum@ietf.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > Dear ADs and WG-chairs, > > this I-D is the follow up from draft-ietf-enum-void-02.txt, > which was already in IESG evaluation (and still is). > (so it is basically draft-ietf-enum-void-03.txt) > > Since we did extensive changes, we renamed it to > draft-ietf-enum-unused-01.txt > This I-D is now back to status ID exists. > > Can you please clarify the correct status of this draft > > > Richard > > ________________________________ > > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Do 01.03.2007 00:50 > An: i-d-announce@ietf.org > Cc: enum@ietf.org > Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > > > 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 =20 > Group of the IETF. > > Title : IANA Registration for Enumservice UNUSED > Author(s) : R. Stastny, et al. > Filename : draft-ietf-enum-unused-01.txt > Pages : 25 > Date : 2007-2-28 > > This document registers the Enumservice "unused" using the URI scheme > "data:" as per the IANA registration process defined in the ENUM > specification, RFC 3761. This Enumservice may be used to indicate > that the E.164 number (or E.164 number range) tied to the domain in > which the enclosing NAPTR is published is not allocated or assigned > for communications service. When such an indication is =20 > provided, an > ENUM client can detect calls that will fail "early". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-enum-unused-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need =20 > "munpack" or > a MIME-compliant mail reader. Different MIME-compliant =20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been =20 > split > up into multiple messages), so check your local =20 > 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. > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 09:59:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmks-0001T3-QT; Thu, 01 Mar 2007 09:59:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmkr-0001SP-CS for enum@ietf.org; Thu, 01 Mar 2007 09:59:37 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMmkp-00079T-W6 for enum@ietf.org; Thu, 01 Mar 2007 09:59:37 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1172761174!19472044!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 710 invoked from network); 1 Mar 2007 14:59:34 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-13.tower-121.messagelabs.com with SMTP; 1 Mar 2007 14:59:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21ExV80008343; Thu, 1 Mar 2007 09:59:31 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l21ExQoX008298; Thu, 1 Mar 2007 09:59:26 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 09:59:25 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ED972B3@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Thread-Index: AcdcEaAAragScdEQSnuNZxbb1LWenQAAFKWA From: "PFAUTZ, PENN L, TCORP" To: "lconroy" X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: enum@ietf.org, Stastny Richard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Lawrence: I took Section 7.4 a recommending course of action for providers and = NRAs. If it's not then I have no issue. Regards, Penn=20 Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk]=20 Sent: Thursday, March 01, 2007 9:55 AM To: PFAUTZ, PENN L, TCORP Cc: Stastny Richard; enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt=20 Hi Penn, I don't see place where this draft (or VOID before it) says that AT&T -MUST- do anything. This draft is a protocol tool thatpeople can use if they believe it is convenient for them. If a Carrier decides not to use it, that's fine. Nothing breaks, but there may be inter-carrier signalling on the SS7 network for the failed call; just the same as now. As the draft says in the abstract - 'When such an indication is provided, an ENUM client can detect calls that will fail "early"' If you don't use it, they can't. If you do they can. It is OF COURSE your choice on whether or not to provision this data. all the best, Lawrence On 1 Mar 2007, at 14:36, PFAUTZ, PENN L, TCORP wrote: > Richard: > I guess I'm still left wondering about the real need for this =20 > functionality other than in the case of ENUM only number ranges =20 > (and even then, with proper design in the circuit switched network =20 > I don't see that it should be a problem.) > Users should know the number they want to call including how many =20 > digits it has; if they dial a non-working number the call won't go =20 > through and will fail somewhere in the ENUM query process or the =20 > CSN. Are misdials to vacant codes and numbers not in service =20 > frequent enough to justify the provisioning effort proposed in =20 > Section 7.4? I'd much prefer to see this functionality limited to =20 > the ENUM only number range case or maybe where CREU (not that I'm =20 > in favor of it) is deployed. > > > Penn Pfautz > AT&T Global Access Management > +1-732-420-4962 > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 01, 2007 8:11 AM > To: fluffy@cisco.com; jon.peterson@neustar.biz; =20 > richard.schockey@neustar.bit; Patrik F=E4ltstr=F6m > Cc: enum@ietf.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > Dear ADs and WG-chairs, > > this I-D is the follow up from draft-ietf-enum-void-02.txt, > which was already in IESG evaluation (and still is). > (so it is basically draft-ietf-enum-void-03.txt) > > Since we did extensive changes, we renamed it to > draft-ietf-enum-unused-01.txt > This I-D is now back to status ID exists. > > Can you please clarify the correct status of this draft > > > Richard > > ________________________________ > > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Do 01.03.2007 00:50 > An: i-d-announce@ietf.org > Cc: enum@ietf.org > Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > > > 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 =20 > Group of the IETF. > > Title : IANA Registration for Enumservice UNUSED > Author(s) : R. Stastny, et al. > Filename : draft-ietf-enum-unused-01.txt > Pages : 25 > Date : 2007-2-28 > > This document registers the Enumservice "unused" using the URI scheme > "data:" as per the IANA registration process defined in the ENUM > specification, RFC 3761. This Enumservice may be used to indicate > that the E.164 number (or E.164 number range) tied to the domain in > which the enclosing NAPTR is published is not allocated or assigned > for communications service. When such an indication is =20 > provided, an > ENUM client can detect calls that will fail "early". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-enum-unused-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need =20 > "munpack" or > a MIME-compliant mail reader. Different MIME-compliant =20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been =20 > split > up into multiple messages), so check your local =20 > 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. > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 10:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnev-0000Be-8s; Thu, 01 Mar 2007 10:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnet-0000A7-Hm for enum@ietf.org; Thu, 01 Mar 2007 10:57:31 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMnes-000208-4x for enum@ietf.org; Thu, 01 Mar 2007 10:57:31 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l21FvKcG011992 for ; Thu, 1 Mar 2007 07:57:26 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Thu, 1 Mar 2007 10:57:15 -0500 Message-ID: <048901c75c1a$48e300d0$81201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdbTHFPOpW40j7TS+WVqUZApNKu4AAzdKsg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Enum] FW: secdir review of draft-ietf-enum-vcard-05 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Monday, February 19, 2007 8:54 PM > To: secdir@mit.edu > Cc: ietf@ietf.org > Subject: secdir review of draft-ietf-enum-vcard-05 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall, I found this document to be fairly straightforward and easy to > understand. This document registers the Enumservice "vCard" with three > subtypes; it is to be used to refer from an ENUM domain name to a vCard > instance. > As such, the security considerations of ENUM (RFC 3761, Section 6) apply; > the reference > covers DNS security issues in some depth. > > Section 6 of this document provides for discussion of additional security > considerations, > including privacy. I believe that this additional discussion combined > with > the security > considerations section of RFC 3761, covers the security issues. > > Note that the ENUM record itself need not contain personal information; it > just points > to a location where access to that information could be obtained. > > The use of HTTP in this Enumservice allows for authentication and > authorization to > be utilized to provide access control to user information. The document > requires use of > standard HTTP authentication (RFC 2617) for this, typically protected > within > HTTPS. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 11:03:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnkl-0005C8-Dh; Thu, 01 Mar 2007 11:03:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnkj-00058m-Ee for enum@ietf.org; Thu, 01 Mar 2007 11:03:33 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMnkg-00035Q-IW for enum@ietf.org; Thu, 01 Mar 2007 11:03:33 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l21G34No013287; Thu, 1 Mar 2007 08:03:12 -0800 From: "Richard Shockey" To: "'Stastny Richard'" , , , , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" References: <32755D354E6B65498C3BD9FD496C7D462C4C8F@oefeg-s04.oefeg.loc> Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 11:02:59 -0500 Message-ID: <049f01c75c1b$16480700$81201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdbk3B+eBxgZ/hISQK0w7VN3XKTywAbcyD/AAZrnmA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C8F@oefeg-s04.oefeg.loc> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a ENUM WG document. That has not changed. I'll send a note to the ID editors. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 01, 2007 8:11 AM > To: fluffy@cisco.com; jon.peterson@neustar.biz; > richard.schockey@neustar.bit; Patrik F=E4ltstr=F6m > Cc: enum@ietf.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt >=20 > Dear ADs and WG-chairs, >=20 > this I-D is the follow up from draft-ietf-enum-void-02.txt, > which was already in IESG evaluation (and still is). > (so it is basically draft-ietf-enum-void-03.txt) >=20 > Since we did extensive changes, we renamed it to > draft-ietf-enum-unused-01.txt > This I-D is now back to status ID exists. >=20 > Can you please clarify the correct status of this draft >=20 >=20 > Richard >=20 > ________________________________ >=20 > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Do 01.03.2007 00:50 > An: i-d-announce@ietf.org > Cc: enum@ietf.org > Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt >=20 >=20 >=20 > 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. >=20 > Title : IANA Registration for Enumservice UNUSED > Author(s) : R. Stastny, et al. > Filename : draft-ietf-enum-unused-01.txt > Pages : 25 > Date : 2007-2-28 >=20 > This document registers the Enumservice "unused" using the URI scheme > "data:" as per the IANA registration process defined in the ENUM > specification, RFC 3761. This Enumservice may be used to indicate > that the E.164 number (or E.164 number range) tied to the domain in > which the enclosing NAPTR is published is not allocated or assigned > for communications service. When such an indication is provided, = an > ENUM client can detect calls that will fail "early". >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-unused-01.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" = or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been = split > up into multiple messages), so check your local documentation = on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 01 11:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMntK-0004fE-R0; Thu, 01 Mar 2007 11:12:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMntJ-0004cB-M0 for enum@ietf.org; Thu, 01 Mar 2007 11:12:25 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMntG-0004Fc-HE for enum@ietf.org; Thu, 01 Mar 2007 11:12:25 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l21GC5LN015537; Thu, 1 Mar 2007 08:12:13 -0800 From: "Richard Shockey" To: "'PFAUTZ, PENN L, TCORP'" , "'lconroy'" References: <34DA635B184A644DA4588E260EC0A25A0ED972B3@ACCLUST02EVS1.ugd.att.com> Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt Date: Thu, 1 Mar 2007 11:11:59 -0500 Message-ID: <04bf01c75c1c$58c56680$81201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdcEaAAragScdEQSnuNZxbb1LWenQAAFKWAAAJY9uA= In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0ED972B3@ACCLUST02EVS1.ugd.att.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: enum@ietf.org, 'Stastny Richard' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I don=92t like this either. We should not make any assumption on how a protocol should be used = Public Private Infrastructure.=20 A reminder that what we did in RFC 4769 was to note that there "may be restrictions" on how such data should be used which is not saying how = such data should be used. > -----Original Message----- > From: PFAUTZ, PENN L, TCORP [mailto:ppfautz@att.com] > Sent: Thursday, March 01, 2007 9:59 AM > To: lconroy > Cc: enum@ietf.org; Stastny Richard > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt >=20 > Lawrence: > I took Section 7.4 a recommending course of action for providers and = NRAs. > If it's not then I have no issue. > Regards, > Penn >=20 >=20 > Penn Pfautz > AT&T Global Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Thursday, March 01, 2007 9:55 AM > To: PFAUTZ, PENN L, TCORP > Cc: Stastny Richard; enum@ietf.org > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt >=20 > Hi Penn, > I don't see place where this draft (or VOID before it) says that > AT&T -MUST- do anything. > This draft is a protocol tool thatpeople can use if they believe it > is convenient for them. If a Carrier decides not to use it, that's = fine. > Nothing breaks, but there may be inter-carrier signalling on the SS7 > network for the failed call; just the same as now. >=20 > As the draft says in the abstract - > 'When such an indication is provided, an ENUM client can detect calls > that will fail "early"' > If you don't use it, they can't. If you do they can. > It is OF COURSE your choice on whether or not to provision this data. >=20 > all the best, > Lawrence >=20 > On 1 Mar 2007, at 14:36, PFAUTZ, PENN L, TCORP wrote: > > Richard: > > I guess I'm still left wondering about the real need for this > > functionality other than in the case of ENUM only number ranges > > (and even then, with proper design in the circuit switched network > > I don't see that it should be a problem.) > > Users should know the number they want to call including how many > > digits it has; if they dial a non-working number the call won't go > > through and will fail somewhere in the ENUM query process or the > > CSN. Are misdials to vacant codes and numbers not in service > > frequent enough to justify the provisioning effort proposed in > > Section 7.4? I'd much prefer to see this functionality limited to > > the ENUM only number range case or maybe where CREU (not that I'm > > in favor of it) is deployed. > > > > > > Penn Pfautz > > AT&T Global Access Management > > +1-732-420-4962 > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, March 01, 2007 8:11 AM > > To: fluffy@cisco.com; jon.peterson@neustar.biz; > > richard.schockey@neustar.bit; Patrik F=E4ltstr=F6m > > Cc: enum@ietf.org > > Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > > > Dear ADs and WG-chairs, > > > > this I-D is the follow up from draft-ietf-enum-void-02.txt, > > which was already in IESG evaluation (and still is). > > (so it is basically draft-ietf-enum-void-03.txt) > > > > Since we did extensive changes, we renamed it to > > draft-ietf-enum-unused-01.txt > > This I-D is now back to status ID exists. > > > > Can you please clarify the correct status of this draft > > > > > > Richard > > > > ________________________________ > > > > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Gesendet: Do 01.03.2007 00:50 > > An: i-d-announce@ietf.org > > Cc: enum@ietf.org > > Betreff: [Enum] I-D ACTION:draft-ietf-enum-unused-01.txt > > > > > > > > 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 : IANA Registration for Enumservice UNUSED > > Author(s) : R. Stastny, et al. > > Filename : draft-ietf-enum-unused-01.txt > > Pages : 25 > > Date : 2007-2-28 > > > > This document registers the Enumservice "unused" using the URI = scheme > > "data:" as per the IANA registration process defined in the ENUM > > specification, RFC 3761. This Enumservice may be used to = indicate > > that the E.164 number (or E.164 number range) tied to the domain = in > > which the enclosing NAPTR is published is not allocated or = assigned > > for communications service. When such an indication is > > provided, an > > ENUM client can detect calls that will fail "early". > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body = of > > the message. > > You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-enum-unused-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-enum-unused-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the = "FILE" > > command. To decode the response(s), you will need > > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > > split > > up into multiple messages), so check your local > > documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Mar 02 12:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBWO-00071Q-CV; Fri, 02 Mar 2007 12:26:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBWN-00071I-V7; Fri, 02 Mar 2007 12:26:19 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNBWN-00087D-N4; Fri, 02 Mar 2007 12:26:19 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9CA08176A8; Fri, 2 Mar 2007 17:25:49 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HNBVt-00027O-CF; Fri, 02 Mar 2007 12:25:49 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 02 Mar 2007 12:25:49 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: enum@ietf.org Subject: [Enum] Last Call: draft-ietf-enum-im-service (A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14543&rfc_flag=0 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Mar 02 17:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGMJ-0001DM-Bq; Fri, 02 Mar 2007 17:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGMI-0001D8-7Q for enum@ietf.org; Fri, 02 Mar 2007 17:36:14 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGMD-00051T-NM for enum@ietf.org; Fri, 02 Mar 2007 17:36:14 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l22MZt9M013568 for ; Fri, 2 Mar 2007 14:36:01 -0800 From: "Richard Shockey" To: Date: Fri, 2 Mar 2007 17:35:50 -0500 Message-ID: <02de01c75d1b$21ea4590$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02DF_01C75CF1.39143D90" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcddDRawHe8tkVNcTsavpybAuzolEQADgO7w X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Enum] FW: I-D ACTION:draft-lim-kim-enum-based-softswitch-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02DF_01C75CF1.39143D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, March 02, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-lim-kim-enum-based-softswitch-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : ENUM-based Softswitch Requirement > Author(s) : J. Lim, et al. > Filename : draft-lim-kim-enum-based-softswitch-01.txt > Pages : 9 > Date : 2007-3-2 > > This document describes operational requirement and several > considerations for ENUM-based softswitch, which can route a call > between 2 Korean VoIP carriers during the ENUM pre-commercial trial > hosted by National Internet Development Agency of Korea(NIDA) in 2006. > This experience can be one of interim solution to maintain stability > of on-going commercial softswitch system while initial stage of ENUM > service that does not have sufficient data. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lim-kim-enum-based-softswitch- > 01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-lim-kim-enum-based-softswitch-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lim-kim-enum-based-softswitch-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_02DF_01C75CF1.39143D90 Content-Type: Message/External-body; name="draft-lim-kim-enum-based-softswitch-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-lim-kim-enum-based-softswitch-01.txt" Content-Type: text/plain Content-ID: <2007-3-2125954.I-D@ietf.org> ------=_NextPart_000_02DF_01C75CF1.39143D90 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------=_NextPart_000_02DF_01C75CF1.39143D90-- From enum-bounces@ietf.org Wed Mar 07 15:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36Q-0002kZ-DV; Wed, 07 Mar 2007 15:51:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35P-0001OO-7Z; Wed, 07 Mar 2007 15:50:11 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35M-0001RM-UX; Wed, 07 Mar 2007 15:50:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C6BA132AE5; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35H-00032P-LD; Wed, 07 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Guide and Template for IANA Registrations of Enumservices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-03.txt Pages : 19 Date : 2007-3-7 This document provides a guide to and template for the creation of new IANA registration of ENUM (E.164 Number Mapping) services. i It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-enumservices-guide-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-enumservices-guide-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: <2007-3-7143026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-enumservices-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-enumservices-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7143026.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Mar 07 15:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36Z-0002zT-Nb; Wed, 07 Mar 2007 15:51:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35Q-0001PG-4G; Wed, 07 Mar 2007 15:50:12 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35M-0001QS-5s; Wed, 07 Mar 2007 15:50:11 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4579326ED4; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030y-Qy; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-calendar-service-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Author(s) : R. Mahy Filename : draft-ietf-enum-calendar-service-02.txt Pages : 6 Date : 2007-3-7 This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-calendar-service-02.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-calendar-service-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7122022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-calendar-service-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-calendar-service-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7122022.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Mar 07 17:46:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP4su-0001Zt-OT; Wed, 07 Mar 2007 17:45:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36E-0002Up-VP; Wed, 07 Mar 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP36E-0007PH-Ba; Wed, 07 Mar 2007 15:51:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 479F52ACE0; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-00030s-PK; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-im-service-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Author(s) : R. Mahy Filename : draft-ietf-enum-im-service-02.txt Pages : 5 Date : 2007-3-7 This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-im-service-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-im-service-02.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-im-service-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7121907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-im-service-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-im-service-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7121907.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Mar 08 11:09:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLAg-0001ok-9S; Thu, 08 Mar 2007 11:08:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLAe-0001oJ-11; Thu, 08 Mar 2007 11:08:48 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPLAc-0004Ia-Ld; Thu, 08 Mar 2007 11:08:48 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.59]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HPL9N-00017z-Mb; Thu, 08 Mar 2007 17:07:30 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at> Content-Transfer-Encoding: quoted-printable From: Michael Haberler Date: Thu, 8 Mar 2007 17:07:26 +0100 To: iab@ietf.org, iesg@ietf.org, enum@ietf.org X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 83.136.33.3 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: Lendl Otmar , Paul Erkkila , Conroy Lawrence , Bernie Hoeneisen , Wilhelm Wimmreuter , Mayrhofer Alexander , Stastny Richard , Bartosiewicz Andrzej , Daley Jay , Reid Jim , Niall O'Reilly Subject: [Enum] statement by ENUM WG members in response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP" we make the following statement. 1. Consensus We are disappointed that the chairs of the ENUM working group have =20 chosen to ignore the consensus of the working group and are attempting to =20 reverse decisions that were made only after considerable debate. To summarise the actual consensus, we refer to the "Dallas Treaty" as signed by Richard Shockey, Alexander Mayrhofer, Jason Livingood, Penn Pfautz, Lawrence Conroy, Michael Haberler, and Richard Stastny on 22 =20 March 2006. The text of the agreement is here: http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-=20 infrastructure-enum.html This agreement was for the long-term solution of a public infrastructure ENUM apex, as well as an interim solution that can be used by individual countries to implement an interoperable public infrastructure ENUM =20 tree as soon as possible, independently of negotiations with the ITU. This interim solution has been shown to work and is supported by running =20 code. There is no reason to downgrade the proposed drafts to "Experimental" status and to do so would devalue the consensus intention. This agreement, which gives a clear picture of working group =20 consensus and direction, contained a commitment that "All parties to this agreement =20= will support this in good faith, in its entirety". We feel this memo substantially deviates from this and does so by citing reasons that have already been discussed and resolved. We are, to say the least, surprised to discover from this memorandum =20 that at IETF67 there were private discussions resulting in an "alternate =20 set of ideas" which the WG chairs say they support, but which have so far not been communicated to the ENUM WG. We find it extraordinary that these alternate ideas are described in the memorandum as "consensus". 2. Public infrastructure ENUM is an imposition The portrayal of public infrastructure ENUM as a means to force a particular interconnection model upon carriers is not accurate, in fact the reverse is true. With public infrastructure ENUM a carrier will =20 have the choice of where to publish their data. They can choose to use the public tree or they can use a private system, or both. In the same way that public user ENUM is 'opt-in' for end users, public infrastructure ENUM is 'opt-in' for carriers. There is nothing in the provision of public infrastructure ENUM that would prevent the development, use and growth of private systems. Beyond being opt-in at the carrier level, public infrastructure ENUM =20 does not imply a particular model such as "need to interconnect with =20 everybody else in the same tree" or "zero settlement between all =20 participants". In fact, it does not imply "interconnecting" at all except for those explicitly wishing to do so on the terms they require. Such interconnection might be keyed on numbers, SIP domains, federations, or mechanisms yet to be conceived - a question directed at the Speermint =20= WG. The movement from PSTN to NGN networks has seen a large increase in such private systems. The combination of new technologies and liberalising regulatory environments has meant that carriers are increasingly =20 required to use the services that such systems provide. Without public infrastructure ENUM, carriers can only use a private system that may not provide them with the access and services they require. This would =20 appear to benefit only those whose business is to supply services or =20 equipment to power such private systems. The attempt to prevent public =20 infrastructure ENUM would appear to do exactly what the authors claim they wish to =20 avoid, which is to impose a specific interconnection model on carriers. In a landscape without public infrastructure ENUM and only private systems, there remains the problem of inter-networking between the =20 private systems. As an N-squared problem this cannot be resolved at the same level as the private systems and a solution would require the =20 creation of a central, global directory. This is of course the problem that public infrastructure ENUM aims to solve. 3. Innovation of protocols The memorandum questions the need for public infrastructure ENUM in =20 light of the many private ENUM initiatives. We regard this argument as a variant on the claims that the existence of multiple private DNS roots removes the need for the public DNS tree. As with all new standards that are produced by the IETF, the =20 introduction of public infrastructure ENUM will provide a platform for innovation =20 that may lead to a change in the current landscape for service providers. =20= This might raise business concerns for some WG members, but until this memorandum it has not affected their participation in the consensus. At no time has the IETF ever felt this was a reason to prevent the development of new standards and it should not start now. We cannot =20 allow the protection of position by the stifling of innovation. It is our view that public infrastructure ENUM is unquestionably a protocol matter and this has to be an IETF concern. Every telephony-standards body (ITU-T, ETSI, etc) defers to the IETF on =20 matters of Internet protocols and it would be inappropriate for the IETF to abdicate its responsibilities here, or leave a vacuum for other organisations to fill. 4. Publication of interconnection points Whilst we recognise the legitimate concerns of some carriers who are concerned by publication of their points of interconnection in the DNS, this is not something they are forced to do. Public infrastructure ENUM does not suggest, nor require exposure of a network's points of interconnection. The WG has clearly documented the consensus on this issue at the Dallas IETF as "DNS entries in I-ENUM must resolve in the DNS. There is no requirement that the result of the resolution process will be a public IP address." Again innovation is possible and the way in which interconnection =20 data is described or access to interconnection points are granted may develop quickly to the point that the fears of these carriers are allayed and =20= they are ready to 'opt-in'. Certainly the pressure of their requirements =20 will be a further driver of innovation. There are already applications of public infrastructure ENUM that do not even resolve to "points of interconnection", such as draft-enum-teluri-e212-00.txt. We maintain =20= that the IETF has no business in effect restricting use of such ad-hoc =20 mappings to "private DNS only" by following such arguments. There are proposals in the Speermint WG that use the concept of federations of carriers to optionally divert the URI-to-ingress-point mapping to private interconnection arrangements, for instance in RFC1918 space (see draft-lendl-speermint-federations-03 and draft-lendl-domain-policy-ddds-02). This method has not only been outlined in ID's, but implemented in running code and shown to work. As a final point we note that there are many carriers who do not =20 share the view in the memorandum and who see public infrastructure ENUM as putting control back into their hands, freeing them from the need to work with closed, proprietary systems. 5. Architectural issues with e164.arpa The two I-D's, draft-ietf-enum-branch-location-record-02 and draft-ietf-enum-combined-03, emerged after two years of intense discussions in various fora as the best possible interim solution given the constraints. These drafts enable deployment of a fully-backwards compatible solution which can be seamlessly transitioned to the long =20 term solution of a separate public infrastructure ENUM apex, based on a national decision. There may be other potential solutions that the working group could consider, but the memorandum would appear to =20 preclude all such work. Experts from both the dnsext and dnsop WG were consulted to provide =20 input, and the EBL draft incorporated their suggestions. Expert review is =20 already progressing according to draft-ietf-dnsext-rfc2929bis. There may be some minor adjustments resulting from that review. Therefore, due process =20= has been followed, and no credible argument has been provided for a =20 downgrade to "Experimental" status. 6. The role of the IAB, IESG and ITU-T in defining an apex for public infrastructure ENUM We do not suggest the IETF define a specific domain. We do, however, suggest that IETF propose a domain, for instance i164.arpa, but leave =20= the final decision to the ITU-T. We also suggest the IETF propose the adoption of a similar, or even identical process like the "Interim Procedures" to delegate under this domain. We would argue such a proposal could be very lightweight, and impose no foreseeable long-term liaison or discussion requirements upon the IETF. 7. Next steps We believe that the ID's draft-ietf-enum-branch-location-record-02 and draft-ietf-enum-combined-03 remain "Standards track" and that the IESG should take no action in support of the memorandum. Further, we would ask that the IESG make the proposals to the ITU-T as described above. Michael Haberler Alexander Mayrhofer Otmar Lendl Jay Daley Jim Reid Lawrence Conroy Richard Stastny Wilhelm Wimmreuter Bernie H=F6neisen Andrzej Bartosiewicz Niall O'Reilly Paul Erkkila _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 08 13:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNUe-0007qz-HP; Thu, 08 Mar 2007 13:37:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNUd-0007qg-KN; Thu, 08 Mar 2007 13:37:35 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNUc-0007n1-DF; Thu, 08 Mar 2007 13:37:35 -0500 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l28IbZhA009823; Thu, 8 Mar 2007 13:37:35 -0500 Received: from dul1trutkow-l1.verisign.com ([10.26.0.226]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 13:37:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Mar 2007 13:37:19 -0500 To: Michael Haberler , iab@ietf.org, iesg@ietf.org, enum@ietf.org From: Tony Rutkowski Subject: Re: [Enum] statement by ENUM WG members in response to the "MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP" In-Reply-To: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at> References: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 08 Mar 2007 18:37:26.0875 (UTC) FILETIME=[D200BAB0:01C761B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Lendl Otmar , Paul Erkkila , Conroy Lawrence , Bernie Hoeneisen , Wilhelm Wimmreuter , Daley Jay , Stastny Richard , Bartosiewicz Andrzej , Mayrhofer Alexander , Reid Jim , Niall O'Reilly X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Michael, >It is our view that public infrastructure ENUM is unquestionably a >protocol matter and this has to be an IETF concern. Every Aren't you implementing an ITU-T namespace standard for global public telecommunication identifier resolution and routing purposes subject to extensive international, regional, and national law to meet a variety of different mandates? Seems like somewhat more than just a protocol matter. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 08 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYp-0006nI-Vl; Thu, 08 Mar 2007 15:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYo-0006kt-P4; Thu, 08 Mar 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYo-0007aV-Gx; Thu, 08 Mar 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 77AA032938; Thu, 8 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007Ec-CH; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-06.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-06.txt Pages : 32 Date : 2007-3-8 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-06.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-experiences-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8100033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-experiences-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-experiences-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8100033.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Mar 09 04:07:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb2J-0002HO-Ns; Fri, 09 Mar 2007 04:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPQEa-0005F8-0R for enum@ietf.org; Thu, 08 Mar 2007 16:33:12 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPQEG-00034p-7D for enum@ietf.org; Thu, 08 Mar 2007 16:33:11 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9AACC9FBAD for ; Thu, 8 Mar 2007 21:32:37 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C4975CC-B9B9-456E-A2A5-7F9D6DB1E7FB@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-experiences-06.txt Date: Thu, 8 Mar 2007 21:32:36 +0000 To: IETF ENUM WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, Fujiwara-san and I have tried to tag the different comments in this version to make it clear which ones we believe are: - related to STanDards (i.e. related to candidate topics of 3761bis), - ones that SHOULD be re-stating standards text (but don't seem to be, from what we've seen :) - these are labelled STBO - ones that are ADVice on things we have seen "out there", and - ones that are proposals to help INTerworking. We have also removed the entire section on DNS issues. There is a draft sitting around doing nothing that covers the most pressing issue (EDNS0 support in ENUM). The rest can be discovered by analysis. all the best, Lawrence On 8 Mar 2007, at 20:50, Internet-Drafts@ietf.org wrote: > Title : ENUM Implementation Issues and Experiences > Author(s) : L. Conroy, K. Fujiwara > Filename : draft-ietf-enum-experiences-06.txt > Pages : 32 > Date : 2007-3-8 > http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-06.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Mar 09 05:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcZN-0008Kw-9I; Fri, 09 Mar 2007 05:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcZK-0008KB-VL; Fri, 09 Mar 2007 05:43:26 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPcZJ-0001eg-Ee; Fri, 09 Mar 2007 05:43:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2007 11:42:52 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646C8B@oefeg-s04.oefeg.loc> In-Reply-To: <45F132D8.5070603@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: statement by ENUM WG members in response to Thread-Index: AcdiM0USID2UERngSSWE3bOrQin0kgAA1x6w From: "Stastny Richard" To: "Brian E Carpenter" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: enum@ietf.org, Lendl Otmar , Paul Erkkila , Conroy Lawrence , Bernie Hoeneisen , Wilhelm Wimmreuter , Daley Jay , Bartosiewicz Andrzej , iesg@ietf.org, Mayrhofer Alexander , iab@ietf.org, Reid Jim , Niall O'Reilly Subject: [Enum] RE: statement by ENUM WG members in response to X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Brian E Carpenter wrote: >Open discussion in a WG meeting and on > the mailing list is generally a better approach when there is > dispute about what the consensus actually is. Agree FYI: See the meeting minutes from IETF 66 at http://www3.ietf.org/proceedings/06mar/minutes/enum.txt=20 Here are the relevant lines: # Patrik - Some individuals violently disagree - can they go off to the bar and report back to the working group? On the Mailing list, this week. The outcome of bar discussions was later posted as the "Dallas Treaty": http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html So it was disputed in a WG meeting and on the mailing list The pointer to my arbitrary web page was just for convenience to show the picture of the signatures. Both "memos" where also sent over the ENUM mailing list Richard > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Friday, March 09, 2007 11:12 AM > To: Michael Haberler > Cc: iab@ietf.org; iesg@ietf.org; enum@ietf.org; Lendl Otmar; Paul Erkkila; > Conroy Lawrence; Bernie Hoeneisen; Wilhelm Wimmreuter; Mayrhofer > Alexander; Stastny Richard; Bartosiewicz Andrzej; Daley Jay; Reid Jim; > Niall O'Reilly > Subject: Re: statement by ENUM WG members in response to case letters> >=20 > ,snip> >=20 > > To summarise the actual consensus, we refer to the "Dallas Treaty" as > > signed by Richard Shockey, Alexander Mayrhofer, Jason Livingood, Penn > > Pfautz, Lawrence Conroy, Michael Haberler, and Richard Stastny on 22 > March > > 2006. The text of the agreement is here: > > > > http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure- > enum.html >=20 > I would like to point out that signed documents posted to some > arbitrary web site have no significance whatever with respect to > the IETF process or to the question of what may or may not be > the rough consensus of a WG or of the IETF as a whole. >=20 > This is entirely without comment on the technical merits of one > approach or another, about which I have no opinion. >=20 > It's also the case that debate by competing memos has a very poor > success rate in the IETF. Open discussion in a WG meeting and on > the mailing list is generally a better approach when there is > dispute about what the consensus actually is. >=20 > Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Mar 09 09:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfwx-0006G2-EV; Fri, 09 Mar 2007 09:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPc4b-0008Ki-Rq; Fri, 09 Mar 2007 05:11:41 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPc4a-00051O-D5; Fri, 09 Mar 2007 05:11:41 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l29ABdNp307800; Fri, 9 Mar 2007 10:11:39 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l29ABdO01654884; Fri, 9 Mar 2007 11:11:39 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l29ABcaO029245; Fri, 9 Mar 2007 11:11:39 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l29ABcCa029192; Fri, 9 Mar 2007 11:11:38 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA178624; Fri, 9 Mar 2007 11:11:36 +0100 Message-ID: <45F132D8.5070603@zurich.ibm.com> Date: Fri, 09 Mar 2007 11:11:36 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Michael Haberler References: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at> In-Reply-To: <1418FA90-61AA-4BC6-9C78-07A0ECE20DF0@inode.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 09 Mar 2007 09:20:02 -0500 Cc: enum@ietf.org, Lendl Otmar , Paul Erkkila , Conroy Lawrence , Bernie Hoeneisen , Wilhelm Wimmreuter , Daley Jay , Stastny Richard , Bartosiewicz Andrzej , iesg@ietf.org, Mayrhofer Alexander , iab@ietf.org, Reid Jim , Niall O'Reilly Subject: [Enum] Re: statement by ENUM WG members in response to X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org ,snip> > To summarise the actual consensus, we refer to the "Dallas Treaty" as > signed by Richard Shockey, Alexander Mayrhofer, Jason Livingood, Penn > Pfautz, Lawrence Conroy, Michael Haberler, and Richard Stastny on 22 March > 2006. The text of the agreement is here: > > http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure-enum.html I would like to point out that signed documents posted to some arbitrary web site have no significance whatever with respect to the IETF process or to the question of what may or may not be the rough consensus of a WG or of the IETF as a whole. This is entirely without comment on the technical merits of one approach or another, about which I have no opinion. It's also the case that debate by competing memos has a very poor success rate in the IETF. Open discussion in a WG meeting and on the mailing list is generally a better approach when there is dispute about what the consensus actually is. Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 11:04:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ3zv-0002ch-Ph; Sat, 10 Mar 2007 11:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ3zt-0002UN-P2 for enum@ietf.org; Sat, 10 Mar 2007 11:00:41 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ3zs-0006zM-Ae for enum@ietf.org; Sat, 10 Mar 2007 11:00:41 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2AG0Tbg007472 for ; Sat, 10 Mar 2007 08:00:36 -0800 From: "Richard Shockey" To: Date: Sat, 10 Mar 2007 11:00:24 -0500 Message-ID: <016901c7632d$382622d0$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdjLTZrts/i5N6nQKmYRholh1gnXQ== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Enum] Tentative ENUM WG Agenda X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Any additions etc... I need to post the final Tue TENTATIVE TENTATIVE TENTATIVE IETF 68 Prague Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson Review of Agenda 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 2 Review status RFC 3761 update. 3. Review Status of ENUMservice registration draft Title : Guide and Template for IANA Registrations of Enumservices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-03.txt Pages : 19 Date : 2007-3-7 This document provides a guide to and template for the creation of new IANA registration of ENUM (E.164 Number Mapping) services. i It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-03.tx t 4. Review Status (short) Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-06.txt Pages : 32 Date : 2007-3-8 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-06.txt Title : IANA Registration for Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-01.txt Pages : 25 Date : 2007-2-28 This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt 5. New Business Title : E.212 ENUMService Type Definition Author(s) : E. Lewis Filename : draft-lewis-enum-enumservice-e212-00.txt Pages : Date : 2007-2-20 This document registers the Enumservice "e212" using the URI scheme "tel:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate International Mobile Subscriber Information with a telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lewis-enum-enumservice-e212-00.txt Title : E.212 Parameters for the "tel" URI Author(s) : E. Lewis Filename : draft-lewis-enum-teluri-e212-00.txt Pages : Date : 2007-2-20 Parameters are defined in the "tel" Uniform Resource Identifier (URI) to carry ITU E.212-related information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lewis-enum-teluri-e212-00.txt 6. ENUM Softswitch requirements. Title : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-lim-kim-enum-based-softswitch-01.txt Pages : 9 Date : 2007-3-2 This document describes operational requirement and several considerations for ENUM-based softswitch, which can route a call between 2 Korean VoIP carriers during the ENUM pre-commercial trial hosted by National Internet Development Agency of Korea(NIDA) in 2006. This experience can be one of interim solution to maintain stability of on-going commercial softswitch system while initial stage of ENUM service that does not have sufficient data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lim-kim-enum-based-softswitch-01.t xt Open Session : WG Future and the Memorandum of the WG Chairs to the IAB/IESG. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 18:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBM0-0004Ja-CL; Sat, 10 Mar 2007 18:52:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBLz-0004JV-Ng for enum@ietf.org; Sat, 10 Mar 2007 18:51:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQBLy-0006lU-Fw for enum@ietf.org; Sat, 10 Mar 2007 18:51:59 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 15:51:58 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399828206:sNHT45682492" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2ANpvnv025457 for ; Sat, 10 Mar 2007 15:51:57 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2ANpua5007797 for ; Sat, 10 Mar 2007 23:51:57 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 15:51:38 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=256; t=1173570718; x=1174434718; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-lewis-enum-enumservice-e212-00 |Sender:=20; bh=Sbz6w0aKDUnCWYUx5LTdzABlSHItrihq4jfwb7yKrKc=; b=Z6OW9BLucAS6FqRmvNIf3J9e5aTOuZ4xLW8fdCuRqE9/opKIbrzbubfZ/PGrvRAG4OBd3+7h p8CvjFySRQwOMmmjSdbmKEj0+4Gx/TR6MKf3X7RUODScwpB294ReJNAM; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Enum] draft-lewis-enum-enumservice-e212-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This draft is pretty hard to understand for someone that does not know what 212, mcc, mnc, MSIN, IMSI etc. I don't think folks will understand what it is, what it is for, or why the IETF should work on it. Cullen _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 18:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBLz-0004JP-4a; Sat, 10 Mar 2007 18:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBLy-0004JK-Fj for enum@ietf.org; Sat, 10 Mar 2007 18:51:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQBLx-0006lS-7H for enum@ietf.org; Sat, 10 Mar 2007 18:51:58 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2007 15:51:57 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="399828203:sNHT43116684" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2ANpuVd001950 for ; Sat, 10 Mar 2007 15:51:56 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2ANpua4007797 for ; Sat, 10 Mar 2007 23:51:56 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: enum@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 15:51:32 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=811; t=1173570716; x=1174434716; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-lewis-peppermint-enum-reg-if-00 |Sender:=20; bh=YiZOmI7dZ9q0l3JknXuS2UM7TdxAbG2fCq1i9dejPmI=; b=wJdDZcAx0a/zvNzAm+Cr17plNbhN0UUShtvk2L1nGO2Iy7HPI3kfyY+PigMSYWJqvHAtrvy8 T4JLdCQqk5Sivcwf/k77DwtR/Qo1rMO8IU8fB1EMp/dabO5A8j84GPhd; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Enum] draft-lewis-peppermint-enum-reg-if-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Ok, so i read this and got the idea that EPP is really bad but I got no idea of what the problem folks want to solve is. I certainly have no idea how to design a reasonable protocol to support it. I understand that there are some requirements for provisioning peering services (whatever a peering service provider is). However, this draft does not help me understand what is is the semantic level information that needs to be provisioned, why, and what constraints the trust and administrative boundaries place on the protocol. I think this can be evolved into a draft that covers all that information well but my suggestion would be to focus on the high level models and requirements then we can figure out design that meets the needs. Cullen _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 18:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBM4-0004K4-KV; Sat, 10 Mar 2007 18:52:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQBM3-0004Jz-2b for enum@ietf.org; Sat, 10 Mar 2007 18:52:03 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQBM1-0006mE-RL for enum@ietf.org; Sat, 10 Mar 2007 18:52:03 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2007 15:52:01 -0800 X-IronPort-AV: i="4.14,270,1170662400"; d="scan'208"; a="47300997:sNHT38460816" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2ANq1tC007493 for ; Sat, 10 Mar 2007 15:52:01 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2ANpua6007797 for ; Sat, 10 Mar 2007 23:52:01 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7654063E-6542-4F9B-8D4C-460ACAB5BD1D@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: enum@ietf.org From: Cullen Jennings Date: Sat, 10 Mar 2007 15:51:42 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=51; t=1173570721; x=1174434721; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-lewis-enum-teluri-e212-00 |Sender:=20; bh=ioBcxk5Bti01F01rk2sgL2zvOQCn3aE9k7nHno7p08Q=; b=hXGF9sEFLCQqKr381mEWIDXn1XwWQMqLMUQqfOmMVm/bMrRpGP11troG70TcKuGRo+v8yF0F hfLJV6/FegTCtKhElpU1Z0uybh39lvHdVXFbaLLRNqCU/su4PnBToywh; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Enum] draft-lewis-enum-teluri-e212-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org this draft needs to be moved to iptel Cullen _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 21:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQDrc-0002TB-7b; Sat, 10 Mar 2007 21:32:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQDrb-0002Sq-3v; Sat, 10 Mar 2007 21:32:47 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQDrZ-0008Hb-PA; Sat, 10 Mar 2007 21:32:47 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2B2WHem005902; Sat, 10 Mar 2007 18:32:26 -0800 From: "Richard Shockey" To: "'Cullen Jennings'" References: <7654063E-6542-4F9B-8D4C-460ACAB5BD1D@cisco.com> Subject: RE: [Enum] draft-lewis-enum-teluri-e212-00 Date: Sat, 10 Mar 2007 21:32:09 -0500 Message-ID: <007b01c76385$7b769e40$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7654063E-6542-4F9B-8D4C-460ACAB5BD1D@cisco.com> Thread-Index: Acdjbxzbhzf9OxZ4R36tToC6cMdjwAAFitFg X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: enum@ietf.org, iptel@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org That was always the intent...BTW what is the status of the TEL parameter registry? > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, March 10, 2007 6:52 PM > To: enum@ietf.org > Subject: [Enum] draft-lewis-enum-teluri-e212-00 > > > this draft needs to be moved to iptel > > Cullen > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 10 21:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQDvk-00019O-16; Sat, 10 Mar 2007 21:37:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQDvh-00011E-Vt; Sat, 10 Mar 2007 21:37:01 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQDvg-0000hN-Ja; Sat, 10 Mar 2007 21:37:01 -0500 Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2B2aXr9006411; Sat, 10 Mar 2007 18:36:40 -0800 From: "Richard Shockey" To: "'Cullen Jennings'" References: Subject: RE: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Sat, 10 Mar 2007 21:36:28 -0500 Message-ID: <007f01c76386$138ec680$22f0a544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcdjbxsR9MGELiRBRFOZOS/BS+xB6QAFmk4g X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: enum@ietf.org, peppermint@ietf.org, 'Andrew Newton' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Well ..I guess that is why we are not having a formal PEPPERMINT BOF right? Cullen there is a community that wants to flush out the issues you correctly point out here before Chicago. I want a meeting room in Prague to do this. If I ask the Secretariat for a non official BOF will you approve it? > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Saturday, March 10, 2007 6:52 PM > To: enum@ietf.org > Subject: [Enum] draft-lewis-peppermint-enum-reg-if-00 > > > Ok, so i read this and got the idea that EPP is really bad but I got > no idea of what the problem folks want to solve is. I certainly have > no idea how to design a reasonable protocol to support it. > > I understand that there are some requirements for provisioning > peering services (whatever a peering service provider is). However, > this draft does not help me understand what is is the semantic level > information that needs to be provisioned, why, and what constraints > the trust and administrative boundaries place on the protocol. > > I think this can be evolved into a draft that covers all that > information well but my suggestion would be to focus on the high > level models and requirements then we can figure out design that > meets the needs. > > Cullen > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 11 08:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNJY-0006Nm-FO; Sun, 11 Mar 2007 08:38:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNJW-0006NW-8G; Sun, 11 Mar 2007 08:38:14 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQNJU-0007tK-OO; Sun, 11 Mar 2007 08:38:14 -0400 Received: from [65.74.225.212] ([::ffff:65.74.225.212]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 11 Mar 2007 08:35:35 -0400 id 01588682.45F3F797.00007F28 In-Reply-To: <0CF0F006-A469-4027-A368-028E57F02D6B@hxr.us> References: <0CF0F006-A469-4027-A368-028E57F02D6B@hxr.us> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [PEPPERMINT] Fwd: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Sun, 11 Mar 2007 08:37:59 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: enum@ietf.org, peppermint@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1035823587==" Errors-To: enum-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1035823587== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-32554-1173616546-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-32554-1173616546-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cullen, I think the info you want is actually in some other drafts: Provisioning Extensions in Peering Registries for Multimedia Interconnection (PEPPERMINT) Problem Statement http://www.ietf.org/internet-drafts/draft-newton-peppermint-problem- statement-00.txt and E.164 Number Provisioning - Data Set Requirements http://www.ietf.org/internet-drafts/draft-schwartz-peppermint-e164- provisioning-data-set-00.txt As for EPP being bad, that is a matter of taste. I do think there is a strong preference toward SOAP by many. While I'm not wild about it, a SOAP based standard is far better than what we have today. -andy On Mar 11, 2007, at 8:25 AM, Andrew Newton wrote: > > > Begin forwarded message: > >> From: Cullen Jennings >> Date: March 10, 2007 6:51:32 PM EST >> To: enum@ietf.org >> Subject: [Enum] draft-lewis-peppermint-enum-reg-if-00 >> >> >> Ok, so i read this and got the idea that EPP is really bad but I >> got no idea of what the problem folks want to solve is. I >> certainly have no idea how to design a reasonable protocol to >> support it. >> >> I understand that there are some requirements for provisioning >> peering services (whatever a peering service provider is). >> However, this draft does not help me understand what is is the >> semantic level information that needs to be provisioned, why, and >> what constraints the trust and administrative boundaries place on >> the protocol. >> >> I think this can be evolved into a draft that covers all that >> information well but my suggestion would be to focus on the high >> level models and requirements then we can figure out design that >> meets the needs. >> >> Cullen >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint --=_zeke.ecotroph.net-32554-1173616546-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
Cullen,

I think the info you want is actually = in some other drafts:

Provisioning Extensions in Peering Registries for Multimedia=A0In= terconnection (PEPPERMINT) Problem Statement

and=A0

E.164 Number Provisioning - Data Set Requirements


As for EPP being bad, that is a matter of taste.=A0 I do thin= k there is a strong preference toward SOAP by many.=A0 While I'm not wild = about it, a SOAP based standard is far better than what we have today.

-andy

<= DIV>
On Mar 11, 2007, at 8:25 AM, Andrew Newton wrote:



Begin forwarded message:

<= BLOCKQUOTE type=3D"cite">
From: Cullen Jennings <flu= ffy@cisco.com>
Date: March 10, 2007 6:51:32 PM EST
Subject: [Enum] draft-lewis-peppermint-enum-= reg-if-00

<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg= in-left: 0px; min-height: 14px; ">
Ok, so i rea= d this and got the idea that EPP is really bad but I got no idea of what = the problem folks want to solve is. I certainly have no idea how to desig= n a reasonable protocol to support it.

I understand that there are some require= ments for provisioning peering services (whatever a peering service provi= der is). However, this draft does not help me understand what is is the s= emantic level information that needs to be provisioned, why, and what con= straints the trust and administrative boundaries place on the protocol.

I think t= his can be evolved into a draft that covers all that information well but = my suggestion would be to focus on the high level models and requirements = then we can figure out design that meets the needs.

Cullen <with my individua= l hat on>

_______________________________________________
enum mailing list

_________________________= ______________________
PEPPERMINT mailing list
--=_zeke.ecotroph.net-32554-1173616546-0001-2-- --===============1035823587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1035823587==-- From enum-bounces@ietf.org Sun Mar 11 09:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNmL-0006XC-EL; Sun, 11 Mar 2007 09:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNmK-0006Ws-Ng for enum@ietf.org; Sun, 11 Mar 2007 09:08:00 -0400 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQNmJ-0000fk-Bg for enum@ietf.org; Sun, 11 Mar 2007 09:08:00 -0400 Received: from [192.168.1.100] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l2BD7bY3092949; Sun, 11 Mar 2007 08:07:37 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 11 Mar 2007 09:03:17 -0400 To: Cullen Jennings From: Edward Lewis Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.61 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 15:51 -0800 3/10/07, Cullen Jennings wrote: >Ok, so i read this and got the idea that EPP is really bad but I got no idea >of what the problem folks want to solve is. I certainly have no idea how to >design a reasonable protocol to support it. > >I understand that there are some requirements for provisioning peering >services (whatever a peering service provider is). However, this draft does >not help me understand what is is the semantic level information that needs >to be provisioned, why, and what constraints the trust and administrative >boundaries place on the protocol. > >I think this can be evolved into a draft that covers all that information >well but my suggestion would be to focus on the high level models and >requirements then we can figure out design that meets the needs. I won't argue with the comment, but I'll add some background to say why your comments are valid. The background for the document was discussed on the PEPPERMINT list. My goal in writing this was a first step towards a community-vetted set of requirements for the interfaces for an ENUM registry. The document is based upon work we did in-house, reverse engineering what we say as design considerations into this draft. The intent was not to document our work, but in the spirit of "running code" use it as a basis for requirements. In fact, one of the requirements in the -00 is/was not met by our system when I submitted the draft. That requirement I pulled form a mail list discussion elsewhere. The reason this is based on "our" experience is that it is an individual submission. If all of the pieces fall into place and this becomes adopted as a WG document, the scope of input will be broadened. Until then though, I can only document from my group's experience. As far as the semantic level - that wasn't something I set out to cover here, and Andy Newton has also answered this. There are other documents on this now. If, when all this happens to become a WG (if, if, if), then the documents can be assembled according to the community's tastes. And as far as the EPP discussion, again, that is written from one point of view. If there is a more optimistic view of EPP, then that is what ought to be recorded. Still, what is in the document is bases on our observation. (And if we didn't care to hear otherwise, we wouldn't have brought this to the IETF. ;)) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 11 09:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNmL-0006Wx-6i; Sun, 11 Mar 2007 09:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQNmK-0006Wn-MQ for enum@ietf.org; Sun, 11 Mar 2007 09:08:00 -0400 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQNmJ-0000fl-BY for enum@ietf.org; Sun, 11 Mar 2007 09:08:00 -0400 Received: from [192.168.1.100] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id l2BD7bY5092949; Sun, 11 Mar 2007 08:07:45 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 11 Mar 2007 09:07:06 -0400 To: Cullen Jennings From: Edward Lewis Subject: Re: [Enum] draft-lewis-enum-enumservice-e212-00 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.61 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org At 15:51 -0800 3/10/07, Cullen Jennings wrote: >This draft is pretty hard to understand for someone that does not know what >212, mcc, mnc, MSIN, IMSI etc. I don't think folks will understand what it >is, what it is for, or why the IETF should work on it. I purposefully skimped on this. Part of the reason is that I didn't want to rewrite or copy what is in the ITU publication E.212. That document is short and to the point, clear enough for an IETF'er like me to read and understand in one sitting. (No need to wade though a sea of telephony terms.) I didn't want to put any "tutorial" material in a draft. As far as "why the IETF should work on it" that is something that can be improved in the next round. I plan to add a "use case" to show what the data is good for and also emphasize that this is a use of ENUM, which is an IETF problem domain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 11 12:25:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQQol-0004Yu-Qv; Sun, 11 Mar 2007 12:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQQok-0004Ug-CX for enum@ietf.org; Sun, 11 Mar 2007 12:22:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQQoi-0008Hu-1x for enum@ietf.org; Sun, 11 Mar 2007 12:22:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2007 09:22:41 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="399965443:sNHT48732256" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2BGMdwe008295; Sun, 11 Mar 2007 09:22:39 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l2BGMX1U015339; Sun, 11 Mar 2007 16:22:33 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7674CB16-D7DF-4A3A-85D6-84643270B31E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Sun, 11 Mar 2007 09:22:10 -0700 To: Edward Lewis X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2945; t=1173630159; x=1174494159; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Enum]=20draft-lewis-peppermint-enum-reg-if-00 |Sender:=20; bh=vl+5CTAwZPjjQdvzV9yyibmxk4BYgoEw66T5lmAc2T8=; b=j7hsxe9IY52Ql5xfyRJe/EKbg6UBj3a5oZQlMuBsp1ClhV4BehFLtPlnFZFN/1ILJARm3nu2 d7T+28OufeSS/gUEEla5zMXhItgN9BlHZjxLrxL0vXHx0MSPCPGNd9Gu; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Fair enough - I am reading all this stuff in sort of a random order very quickly and understand this is a 00 draft. On Mar 11, 2007, at 6:03 AM, Edward Lewis wrote: > At 15:51 -0800 3/10/07, Cullen Jennings wrote: > >Ok, so i read this and got the idea that EPP is really bad but I > got no idea > >of what the problem folks want to solve is. I certainly have no > idea how to > >design a reasonable protocol to support it. > > > >I understand that there are some requirements for provisioning > peering > >services (whatever a peering service provider is). However, this > draft does > >not help me understand what is is the semantic level information > that needs > >to be provisioned, why, and what constraints the trust and > administrative > >boundaries place on the protocol. > > > >I think this can be evolved into a draft that covers all that > information > >well but my suggestion would be to focus on the high level models and > >requirements then we can figure out design that meets the needs. > > I won't argue with the comment, but I'll add some background to say > why your comments are valid. The background for the document was > discussed on the PEPPERMINT list. > > My goal in writing this was a first step towards a community-vetted > set of requirements for the interfaces for an ENUM registry. The > document is based upon work we did in-house, reverse engineering what > we say as design considerations into this draft. > > The intent was not to document our work, but in the spirit of > "running code" use it as a basis for requirements. In fact, one of > the requirements in the -00 is/was not met by our system when I > submitted the draft. That requirement I pulled form a mail list > discussion elsewhere. > > The reason this is based on "our" experience is that it is an > individual submission. If all of the pieces fall into place and this > becomes adopted as a WG document, the scope of input will be > broadened. Until then though, I can only document from my group's > experience. > > As far as the semantic level - that wasn't something I set out to > cover here, and Andy Newton has also answered this. There are other > documents on this now. If, when all this happens to become a WG (if, > if, if), then the documents can be assembled according to the > community's tastes. > > And as far as the EPP discussion, again, that is written from one > point of view. If there is a more optimistic view of EPP, then that > is what ought to be recorded. Still, what is in the document is > bases on our observation. (And if we didn't care to hear otherwise, > we wouldn't have brought this to the IETF. ;)) > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > Sarcasm doesn't scale. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 12 07:51:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQj2k-0007KW-DV; Mon, 12 Mar 2007 07:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQj2i-0007K1-LH for enum@ietf.org; Mon, 12 Mar 2007 07:50:20 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQj1P-0002IN-I7 for enum@ietf.org; Mon, 12 Mar 2007 07:49:00 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l2CBn0MZ001566; Mon, 12 Mar 2007 07:49:00 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 07:48:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Mon, 12 Mar 2007 07:48:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0701BA8DCE@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-lewis-peppermint-enum-reg-if-00 Thread-Index: Acdjb7sZ9fZIU0vRQWehwkb8KD7d4QBK9Dtw From: "Hollenbeck, Scott" To: "Cullen Jennings" , X-OriginalArrivalTime: 12 Mar 2007 11:48:56.0201 (UTC) FILETIME=[6A27AF90:01C7649C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Saturday, March 10, 2007 6:52 PM > To: enum@ietf.org > Subject: [Enum] draft-lewis-peppermint-enum-reg-if-00 >=20 >=20 > Ok, so i read this and got the idea that EPP is really bad but I got =20 > no idea of what the problem folks want to solve is. I certainly have =20 > no idea how to design a reasonable protocol to support it. That's not the idea that *I* got out of reading the draft. What I read: the current EPP ENUM RFC 4114 doesn't solve Ed's provisioning problem. He has worked with a SOAP-based legacy system that does the job. It doesn't make much sense to build an EPP-based system when the SOAP-based system is already in place and working. That's not the same thing as "SOAP good, EPP bad". -Scott- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 12 10:02:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQl5p-00077V-8g; Mon, 12 Mar 2007 10:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQl5n-00074c-HU for enum@ietf.org; Mon, 12 Mar 2007 10:01:39 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQl5i-0003SB-ON for enum@ietf.org; Mon, 12 Mar 2007 10:01:39 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2CE1Kqo018402; Mon, 12 Mar 2007 06:01:28 -0800 From: "Richard Shockey" To: "'Hollenbeck, Scott'" , "'Cullen Jennings'" , References: <046F43A8D79C794FA4733814869CDF0701BA8DCE@dul1wnexmb01.vcorp.ad.vrsn.com> Subject: RE: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Mon, 12 Mar 2007 10:01:07 -0400 Message-ID: <022e01c764ae$e4325760$84201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdjb7sZ9fZIU0vRQWehwkb8KD7d4QBK9DtwAATAxiA= In-Reply-To: <046F43A8D79C794FA4733814869CDF0701BA8DCE@dul1wnexmb01.vcorp.ad.vrsn.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Precicely ..plus the data sets for telephone number peering registries are significantly different from what we anticipated in 4114. No one is saying EPP is bad only that the vast majority of data provisioning systems within carriers are based on SOAP transport and not EPP. > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Monday, March 12, 2007 7:49 AM > To: Cullen Jennings; enum@ietf.org > Subject: RE: [Enum] draft-lewis-peppermint-enum-reg-if-00 > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Saturday, March 10, 2007 6:52 PM > > To: enum@ietf.org > > Subject: [Enum] draft-lewis-peppermint-enum-reg-if-00 > > > > > > Ok, so i read this and got the idea that EPP is really bad but I got > > no idea of what the problem folks want to solve is. I certainly have > > no idea how to design a reasonable protocol to support it. > > That's not the idea that *I* got out of reading the draft. > > What I read: the current EPP ENUM RFC 4114 doesn't solve Ed's > provisioning problem. He has worked with a SOAP-based legacy system > that does the job. It doesn't make much sense to build an EPP-based > system when the SOAP-based system is already in place and working. > That's not the same thing as "SOAP good, EPP bad". > > -Scott- > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 12 17:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrzN-0005rv-Sw; Mon, 12 Mar 2007 17:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrzM-0005rU-9S; Mon, 12 Mar 2007 17:23:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQrzE-0004Fq-M0; Mon, 12 Mar 2007 17:23:28 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Mar 2007 14:23:20 -0700 X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="47598305:sNHT44528166" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l2CLNKK7019520; Mon, 12 Mar 2007 14:23:20 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l2CLNIa4029456; Mon, 12 Mar 2007 21:23:18 GMT In-Reply-To: <007f01c76386$138ec680$22f0a544@cis.neustar.com> References: <007f01c76386$138ec680$22f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Mon, 12 Mar 2007 14:22:55 -0700 To: X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1024; t=1173734600; x=1174598600; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Enum]=20draft-lewis-peppermint-enum-reg-if-00 |Sender:=20; bh=rT1q5m8LY/tcCCMFQoT3WpDhJqUpqZbMI669gW7t16I=; b=Fxg7PlQKsraxb3mR8KCMDanCMha1eqdTezy8wOZor5wZiFCZ0iNeXHhq9goWWUcVJ582VICm 4wDSy6VDvKJDc8c1T3oEUPG+LKLp5cGSJ6fKSNf3CxPPLLXi7V8HJfGT; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, peppermint@ietf.org, Jon Peterson , Andrew Newton X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 10, 2007, at 6:36 PM, Richard Shockey wrote: > > Well ..I guess that is why we are not having a formal PEPPERMINT > BOF right? > > Cullen there is a community that wants to flush out the issues you > correctly > point out here before Chicago. > > I want a meeting room in Prague to do this. If I ask the > Secretariat for a > non official BOF will you approve it? Hi, I feel that this work area--or at least the requirements phase--is in- scope for SPEERMINT and we'd like to see it pursued there, at least to the point where there's a consensus that it's likely to be necessary to form a new working group. However, if you feel that this discussion can't be had in the main SPEERMINT WG meeting and the chairs agree, I think the best way forward would be for the SPEERMINT chairs to request an Ad-hoc meeting. Ultimately this is Jon's decision but if the chairs were in favor and there was a slot where both Jon and I could make it, I would be supportive. Cullen _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 12 17:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsC7-0003Jl-DE; Mon, 12 Mar 2007 17:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsC5-0003Iy-TP; Mon, 12 Mar 2007 17:36:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQsC4-0007QO-I1; Mon, 12 Mar 2007 17:36:37 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2CLa9Jc012787; Mon, 12 Mar 2007 13:36:16 -0800 From: "Richard Shockey" To: "'Cullen Jennings'" References: <007f01c76386$138ec680$22f0a544@cis.neustar.com> Subject: RE: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Mon, 12 Mar 2007 17:36:03 -0400 Message-ID: <013401c764ee$7042d290$84201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdk7LG3ajCzSW/aQWCKmRtyjjDH8gAADLig In-Reply-To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: enum@ietf.org, 'Jon Peterson' , peppermint@ietf.org, "'Livingood, Jason'" , 'Andrew Newton' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, March 12, 2007 5:23 PM > To: richard@shockey.us > Cc: enum@ietf.org; peppermint@ietf.org; Jon Peterson; Andrew Newton > Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 > > > On Mar 10, 2007, at 6:36 PM, Richard Shockey wrote: > > > > > Well ..I guess that is why we are not having a formal PEPPERMINT > > BOF right? > > > > Cullen there is a community that wants to flush out the issues you > > correctly > > point out here before Chicago. > > > > I want a meeting room in Prague to do this. If I ask the > > Secretariat for a > > non official BOF will you approve it? > > Hi, > > I feel that this work area--or at least the requirements phase--is in- > scope for SPEERMINT and we'd like to see it pursued there, at least > to the point where there's a consensus that it's likely to be > necessary to form a new working group. > > However, if you feel that this discussion can't be had in the main > SPEERMINT WG meeting and the chairs agree, I think the best way forward > would be for the SPEERMINT chairs to request an Ad-hoc meeting. > Ultimately this is Jon's decision but if the chairs were in > favor and there was a slot where both Jon and I could make it, I > would be supportive. Well the thought was and I think the SPEERMINT WG chairs would agree, that they have a very very full plate of issues they need to deal with and PEPPERMINT development would be better off with an Ad-Hoc. In that case I'll let Jason and Dave add their views. I'm pretty sure they agree with the Ad-Hoc solution but I'm perfectly amenable to whatever they feel is best. > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 13 10:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7u3-0006To-RM; Tue, 13 Mar 2007 10:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7u2-0006Tc-DL for enum@ietf.org; Tue, 13 Mar 2007 10:23:02 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7tz-00086o-UQ for enum@ietf.org; Tue, 13 Mar 2007 10:23:02 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2DEMmLl001023 for ; Tue, 13 Mar 2007 06:22:54 -0800 From: "Richard Shockey" To: Date: Tue, 13 Mar 2007 10:22:44 -0400 Message-ID: <004e01c7657b$11b62140$84201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdlexCHdF6CunlaQDWH9HZ9cdKlYA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [Enum] ENUM WG Agenda Final X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org FINAL FINAL FINAL IETF 68 Prague Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz MONDAY, March 19, 2007 0800-1800 IETF Registration - Congress Hall Foyer 0800-0900 Morning Beverages - Congress Hall Foyer 1130-1300 Break 1300-1500 Afternoon Session I enum Congress III Telephone Number Mapping WG Review of Agenda 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 2 Review status RFC 3761 update. 3. Review Status of ENUMservice registration draft Title : Guide and Template for IANA Registrations of Enumservices Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-enumservices-guide-03.txt Pages : 19 Date : 2007-3-7 This document provides a guide to and template for the creation of new IANA registration of ENUM (E.164 Number Mapping) services. i It is also to be used for updates of existing IANA registrations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-03.tx t 4. Review Status (keep it short) Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-06.txt Pages : 32 Date : 2007-3-8 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-06.txt Title : IANA Registration for Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-01.txt Pages : 25 Date : 2007-2-28 This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-01.txt 5. New Business Title : E.212 ENUMService Type Definition Author(s) : E. Lewis Filename : draft-lewis-enum-enumservice-e212-00.txt Pages : Date : 2007-2-20 This document registers the Enumservice "e212" using the URI scheme "tel:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate International Mobile Subscriber Information with a telephone number. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lewis-enum-enumservice-e212-00.txt Title : E.212 Parameters for the "tel" URI Author(s) : E. Lewis Filename : draft-lewis-enum-teluri-e212-00.txt Pages : Date : 2007-2-20 Parameters are defined in the "tel" Uniform Resource Identifier (URI) to carry ITU E.212-related information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lewis-enum-teluri-e212-00.txt 6. ENUM Softswitch requirements. Title : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-lim-kim-enum-based-softswitch-01.txt Pages : 9 Date : 2007-3-2 This document describes operational requirement and several considerations for ENUM-based softswitch, which can route a call between 2 Korean VoIP carriers during the ENUM pre-commercial trial hosted by National Internet Development Agency of Korea(NIDA) in 2006. This experience can be one of interim solution to maintain stability of on-going commercial softswitch system while initial stage of ENUM service that does not have sufficient data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lim-kim-enum-based-softswitch-01.t xt Open Session : WG Future and the Memorandum of the WG Chairs to the IAB/IESG. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 13 13:26:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAkY-0003yf-B3; Tue, 13 Mar 2007 13:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAkX-0003yT-QV for enum@ietf.org; Tue, 13 Mar 2007 13:25:25 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRAkW-0004we-Gm for enum@ietf.org; Tue, 13 Mar 2007 13:25:25 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net?[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070313172512m11009ppnje>; Tue, 13 Mar 2007 17:25:17 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2DHOKGJ007019 for ; Tue, 13 Mar 2007 12:24:20 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2DHOKsE007015; Tue, 13 Mar 2007 12:24:20 -0500 Date: Tue, 13 Mar 2007 12:24:20 -0500 Message-Id: <200703131724.l2DHOKsE007015@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Enum] Response codes and multiple paths to a destination X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org As our organization starts looking into serious ENUM implementation, it looks like we're going to have a problem with response codes. The most likely method for a PBX to use ENUM is as a way to route dialogs that are being sent to outside telephone numbers. First, look up the number in ENUM and attempt to connect to the URI using SIP. If that fails, then send the dialog to a PSTN gateway. This gives the right result in most cases. The problem is that when a dialog routed using ENUM fails, what the proxy does next needs to depend on how the dialog failed. If it failed with a Busy, Declined, or Ring No Answer status (that is, the call reached the UA and then failed), no attempt should be made using the PSTN. But if the dialog failed before reaching the UA, the dialog should attempt to connect using the PSTN. Most response codes can be classified into "failure in transit" and "failure at the UA" groups. Unfortunately, but several response codes can be returned in either situation, and they make it hard for the proxy to fail-over from ENUM/SIP to PSTN connectivity. I've written an I-D, http://www.ietf.org/internet-drafts/draft-worley-sip-redundancy-response-00.txt, to enumerate the failure response codes and propose a few new ones to allow reliably separating failures into transit and end-system responses. Has anyone else encountered these problems? Are there any other solutions proposed? I'd like to know what people think. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 13 14:10:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRBQx-0004xO-7I; Tue, 13 Mar 2007 14:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRBQv-0004up-Oz for enum@ietf.org; Tue, 13 Mar 2007 14:09:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRBQt-0000Yv-Bz for enum@ietf.org; Tue, 13 Mar 2007 14:09:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Mar 2007 14:09:09 -0400 X-IronPort-AV: i="4.14,280,1170651600"; d="scan'208"; a="54665488:sNHT47667616" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2DI98qo012100; Tue, 13 Mar 2007 14:09:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2DI94Zx010913; Tue, 13 Mar 2007 18:09:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:09:06 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 14:09:05 -0400 Message-ID: <45F6E8C1.1050505@cisco.com> Date: Tue, 13 Mar 2007 14:09:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Enum] Response codes and multiple paths to a destination References: <200703131724.l2DHOKsE007015@dragon.ariadne.com> In-Reply-To: <200703131724.l2DHOKsE007015@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2007 18:09:05.0945 (UTC) FILETIME=[B03C2890:01C7659A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2522; t=1173809348; x=1174673348; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20Response=20codes=20and=20multiple=20paths=20 to=20a=20destination |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=B9+1+4FCTARsI21/YtWiWw9+T1lIWSx5t+TefsvcKOI=; b=wK7SFFO3o9gCqUOaKdRBM6ZVAWcpXd0lhrXIE6Mru3OE0sWDhqkKW6q4bSDj/U7TuY/4wBbM RSedHXiRsAz/DXYKHdsV8wJJKiHJJPlBNanV0/pr7zeVVWVhKrHqlxcj; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dale, I'm sympathetic to the general issue you are raising. But I think some of the codes you have issue with can be explained away as non-issues: 402: does it really matter who needs to be paid? If the UAC is willing and able to pay, then go ahead and try that. If not, then go ahead and try the pstn. (Maybe you will get lucky and its free on the pstn and only charged via sip. (NOT)) 420: again - does it really matter? Either way you can't talk via sip, but still have a chance via the pstn. 422: There is no reason for a UAC to ever *request* a session timer. So assume it didn't. In that case a proxy on the path presumably did, and then the UAS or some other proxy along the path didn't like it. The pstn is a viable option in this case. Paul Dale.Worley@comcast.net wrote: > As our organization starts looking into serious ENUM implementation, > it looks like we're going to have a problem with response codes. > > The most likely method for a PBX to use ENUM is as a way to route > dialogs that are being sent to outside telephone numbers. First, look > up the number in ENUM and attempt to connect to the URI using SIP. If > that fails, then send the dialog to a PSTN gateway. This gives the > right result in most cases. > > The problem is that when a dialog routed using ENUM fails, what the > proxy does next needs to depend on how the dialog failed. If it > failed with a Busy, Declined, or Ring No Answer status (that is, the > call reached the UA and then failed), no attempt should be made using > the PSTN. But if the dialog failed before reaching the UA, the dialog > should attempt to connect using the PSTN. > > Most response codes can be classified into "failure in transit" and > "failure at the UA" groups. Unfortunately, but several response codes > can be returned in either situation, and they make it hard for the > proxy to fail-over from ENUM/SIP to PSTN connectivity. > > I've written an I-D, > http://www.ietf.org/internet-drafts/draft-worley-sip-redundancy-response-00.txt, > to enumerate the failure response codes and propose a few new ones to > allow reliably separating failures into transit and end-system > responses. > > Has anyone else encountered these problems? Are there any other > solutions proposed? > > I'd like to know what people think. > > Dale > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 05:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPt9-0004JM-JC; Wed, 14 Mar 2007 05:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPt8-0004JG-Cr for enum@ietf.org; Wed, 14 Mar 2007 05:35:18 -0400 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRPt5-0006IJ-9H for enum@ietf.org; Wed, 14 Mar 2007 05:35:18 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=[10.10.0.59]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HRPt4-0006zT-0S for enum@ietf.org; Wed, 14 Mar 2007 10:35:14 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3D13BECA-F490-4E94-92B3-FF16C272341C@inode.at> Content-Transfer-Encoding: quoted-printable From: Michael Haberler Date: Wed, 14 Mar 2007 10:35:08 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 83.136.33.3 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Wed, 07 Mar 2007 15:40:54 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Enum] Fwd: You know guys we are really not that far off consensus here. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org [I'm taking the growing offline thread to the list now. Let's =20 continue here. -mah] Anfang der weitergeleiteten E-Mail: > Von: Patrik F=E4ltstr=F6m > Datum: 12. M=E4rz 2007 17:50:03 GMT+01:00 > An: Jim Reid > Kopie: , , "'Jay Daley'" =20 > , "'Wilhelm Wimmreuter'" =20 > , "'Stastny Richard'" =20 > , "'Niall O'Reilly'" =20 > , "'Conroy Lawrence'" =20 > , "'Bartosiewicz Andrzej'" =20 > > Betreff: Re: You know guys we are really not that far off consensus =20= > here. > > On 12 mar 2007, at 17.32, Jim Reid wrote: > >> These are very good questions Patrik. And I believe they are for =20 >> the WG to consider and work on. Because there's nowhere else where =20= >> these discussions could take place in a constructive, neutral manner. > > This is why I have asked a few times for what the requirements =20 > REALLY are for things like infrastructure ENUM is (in the IETF). =20 > The document that the wg have consensus on is, I think personally, =20 > not enough. I told the authors that, but I saw myself being in the =20 > minority, and as a wg chair I of course should accept that (as =20 > everyone else). > > Here is a note I have kept for myself so far, but I share it with =20 > you all. So you can understand that I do not see the requirements =20 > and answers are on the table... I do not see I can pick which =20 > solution is the best given the requirements document. Once again =20 > from a personal perspective... > >> 1. >> >> Problem: >> >> A zone in DNS is in reality a monopoly, so only one party can run =20 >> the DNS for the zone of a specific E.164 number. >> >> Who is affected: >> >> This is not good enough for people that run a service the NAPTR =20 >> refer to a service they run themselves. They want to both run =20 >> service and DNS for the NAPTRs. >> >> Suggested solution(s): >> >> A. Create a new domain i164.arpa under which certain =20 >> (infrastructure) services can be found. >> >> B. Create a new domain below the CC in the e164.arpa tree under =20 >> which certain (infrastructure) services can be found. >> >> C. Use the URI resource record type so that it is possible to =20 >> delegate from the zone of the number to the provider of the service. >> >> D. Use non-terminal NAPTR and refer to a different owner in DNS =20 >> where the NAPTR RR are stored. >> >> Note: >> >> Solution A and B only allow for one (1) service beside the User =20 >> ENUM that already exists today. If there are two service providers =20= >> that want to run their own DNS for the zone, it can not be done =20 >> without creating a new domain for each kind of service. >> >> Solution C require the party running the zone for the E.164 be =20 >> neutral. See 2 below. >> >> Solution D require support for non-terminal NAPTR, and there is =20 >> hesitation to require that. This further make it possible for the =20 >> service provider to have all his numbers in one zone, and not =20 >> multiple zones. >> >> Solution C and D both make it easier to implement a system without =20= >> opt-in (see 3 below) if the zone of the E.164 is run by a neutral =20 >> party. Addition of delegations can be done without impacting =20 >> existing delegations. >> >> 2. Problem: >> >> A provider of a service (and potentially DNS for that service, see =20= >> 1 above), do not accept delegation from a party that is not under =20 >> regulative control. >> >> Who is affected: >> >> Anyone that for example believe their service is under regulative =20 >> control with requirements on for example uptime. In principle =20 >> everyone that also is affected of 1 above. Parties that want to =20 >> run both service and DNS for the E.164 that refer to the service. >> >> Suggested solution(s): >> >> Have the party running DNS for the CC (that is believed to be =20 >> under regulative control and because of that neutral and accepted) =20= >> run DNS for also the full E.164, and not only for (for example) =20 >> some blocks of E.164. >> >> Note: >> >> In the case of 1.A and 1.B the delegations could be made on =20 >> blocks, but number portability might create problems. Question of =20 >> course is how number portability is implemented in reality. >> >> 3. Problem: >> >> ENUM of today require opt-in by the holder of the E.164 number. >> >> Who is affected: >> >> Anyone that want to run ENUM (or use ENUM) for services or E.164 =20 >> numbers they control. >> >> Solution(s): >> >> A. Make it clear in RFC3761bis that whether opt-in or not is used =20 >> is a policy issue defined by the local CC (regulation). >> >> B. Use solution 1.A or 1.B where opt-in can be said is not needed =20 >> while it is still needed in e164.arpa. >> >> Note: Regardless of whether 3.A or 3.B is in use, the end result =20 >> will be a combination of local and global policy. >> >> 4. Problem: >> >> Make it possible to have "private" ENUM that is only usable for =20 >> parties that one have contractual agreements with. >> >> Solution(s): >> >> A. Have the DNS for the numbers visible only to the parties that =20 >> one have agreements with. >> >> B. Have separate VPNs where the IP addresses of the DNS servers =20 >> are visible, and use "normal" route announcements to announce the =20 >> IP addresses over separate networks for parties one have =20 >> agreements with. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 12:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWAb-0007qD-Uq; Wed, 14 Mar 2007 12:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRWAa-0007pE-J8 for enum@ietf.org; Wed, 14 Mar 2007 12:17:44 -0400 Received: from mailgw.nic.or.kr ([202.30.50.169] helo=nida.or.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRWAY-0006Kk-Uq for enum@ietf.org; Wed, 14 Mar 2007 12:17:44 -0400 X-HELO: ehlo mail.nic.or.kr X-RECEIVED-IP: 202.30.50.51 Received: from 202.30.50.51(202.30.50.51) at Thu, 15 Mar 2007 01:20:55 +0900 by nida.or.kr with ESMTP CrediShield X-MAIL-FROM: jhlim@nida.or.kr Received: from userbase (localhost [127.0.0.1]) by mail.nic.or.kr (v3smtp 8.11.6.9/8.11.0) with SMTP id l2EGHIV03448; Thu, 15 Mar 2007 01:17:18 +0900 (KST) Message-ID: <001b01c76654$56be8140$b632a8c0@userbase> From: "JoonHyung Lim" To: Subject: Re:[Enum] Response codes and multiple paths to a destination Date: Thu, 15 Mar 2007 01:18:01 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263675295==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1263675295== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C7669F.C60B48D0" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C7669F.C60B48D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxzbyBhZ3JlZSB0aGF0IHRoaXMgd29yayBoYXMgYSBsb3Qgb2YgZXhjZXB0aW9u YWwgY29uZGl0aW9ucyB3aGVuIGl0IGltcGxlbWVudHMgb24gcmVhbCB3b3JsZCBwcmFjdGljYWxs eS4gQnV0IEkgYmVsaWV2ZSB0aGF0IHRoaXMgY29uc2lkZXJhdGlvbiBpcyB2ZXJ5IHdvcnRoeSBm b3IgZWFybHkgaW1wbGVtZW50b3Igd2hvIHdhbnRzIHRvIGFkZCBFTlVNIG9uIGV4aXN0aW5nIHN5 c3RlbS4NCg0KPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gYSBkaWFsb2cgcm91dGVkIHVzaW5n IEVOVU0gZmFpbHMsDQo+IHdoYXQgdGhlIHByb3h5IGRvZXMgbmV4dCBuZWVkcyB0byBkZXBlbmQg b24gaG93IHRoZSBkaWFsb2cNCj4gZmFpbGVkLiAgSWYgaXQgZmFpbGVkIHdpdGggYSBCdXN5LCBE ZWNsaW5lZCwgb3IgUmluZyBObw0KPiBBbnN3ZXIgc3RhdHVzICh0aGF0IGlzLCB0aGUgY2FsbCBy ZWFjaGVkIHRoZSBVQSBhbmQgdGhlbg0KPiBmYWlsZWQpLCBubyBhdHRlbXB0IHNob3VsZCBiZSBt YWRlIHVzaW5nIHRoZSBQU1ROLiAgQnV0IGlmDQo+IHRoZSBkaWFsb2cgZmFpbGVkIGJlZm9yZSBy ZWFjaGluZyB0aGUgVUEsIHRoZSBkaWFsb2cgc2hvdWxkDQo+IGF0dGVtcHQgdG8gY29ubmVjdCB1 c2luZyB0aGUgUFNUTi4NCg0KSW4gdGhpcyBzaXR1YXRpb24sIElmIEkgdW5kZXJzdGFuZCBpdCBj b3JyZWN0bHksIHByb3h5IGFscmVhZHkgaGFzIGEgU0lQIFVSSSBmcm9tIEVOVU0oaXQgbWVhbnMg UmNvZGU9MCksIGJ1dCBpdCBjYW4ndCB0ZXJtaW5hdGUgdGhlIGNhbGwgYnkgc2V2ZXJhbCByZWFz b24uDQoNClNvLCBoZXJlIGlzIG15IHF1ZXN0aW9uLg0KIA0KSWYgYSBjYWxsIGZhaWxlZCBiZWZv cmUgcmVhY2hpbmcgVUEsICBkb2VzIHRoZSBwcm94eSBoYXZlIHRvIHNlbmQgYSBjYWxsIHRvIFBT VE4/IFdoYXQgaGFwcGVuIGlmIHN1Y2ggYSBjYWxsIG11c3QgZmFpbD8gSU1ITywgSWYgcHJveHkg Y2FuJ3QgcmVhY2ggdG8gVUEgdXNpbmcgU0lQIFVSSSB0aHJvdWdoIElQIG5ldHdvcmssIGl0IGlz IGFsc28gaGFyZGx5ICB0byB0ZXJtaW5hdGUgYSBjYWxsIHRocm91Z2ggUFNUTi4gSWYgSSdtIHdy b25nIGxldCBtZSBrbm93Li4uDQoNCkFjdHVhbGx5IHdlIGRpZG4ndCBtdWNoIGNhcmUgYWJvdXQg dGhpcyBpc3N1ZSBvbiBvdXIgRU5VTSBzb2Z0c3dpdGNoIHRyaWFsIGluIDIwMDYsICBiZWNhdXNl IFBTVE4gY291bGQgYmUgdXNlZCBvbmx5IHdoZW4gIlJjb2RlPTMoTlhET01BSU4pIg0KDQpKb29u SHl1bmcgTGltLCBOSURB ------=_NextPart_000_0018_01C7669F.C60B48D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjYwMDAuMTY0MTQiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8 L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBz aXplPTI+SGksPEJSPjxCUj5JIGFsc28gYWdyZWUmbmJzcDt0aGF0IHRoaXMgd29yayBoYXMgYSAN CmxvdCBvZiBleGNlcHRpb25hbCBjb25kaXRpb25zJm5ic3A7d2hlbiBpdCBpbXBsZW1lbnRzIG9u IHJlYWwgd29ybGQgcHJhY3RpY2FsbHkuIA0KQnV0IEkgYmVsaWV2ZSB0aGF0IHRoaXMgY29uc2lk ZXJhdGlvbiBpcyB2ZXJ5IHdvcnRoeSBmb3IgZWFybHkgaW1wbGVtZW50b3Igd2hvIA0Kd2FudHMg dG8gYWRkIEVOVU0mbmJzcDtvbiBleGlzdGluZyBzeXN0ZW0uPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48QlI+PEZPTlQgZmFjZT1WZXJkYW5hPiZn dDsgVGhlIHByb2JsZW0gaXMgDQp0aGF0IHdoZW4gYSBkaWFsb2cgcm91dGVkIHVzaW5nIEVOVU0g ZmFpbHMsPEJSPiZndDsgd2hhdCB0aGUgcHJveHkgZG9lcyBuZXh0IA0KbmVlZHMgdG8gZGVwZW5k IG9uIGhvdyB0aGUgZGlhbG9nPEJSPiZndDsgZmFpbGVkLiAmbmJzcDtJZiBpdCBmYWlsZWQgd2l0 aCBhIA0KQnVzeSwgRGVjbGluZWQsIG9yIFJpbmcgTm88QlI+Jmd0OyBBbnN3ZXIgc3RhdHVzICh0 aGF0IGlzLCB0aGUgY2FsbCByZWFjaGVkIHRoZSANClVBIGFuZCB0aGVuPEJSPiZndDsgZmFpbGVk KSwgbm8gYXR0ZW1wdCBzaG91bGQgYmUgbWFkZSB1c2luZyB0aGUgUFNUTi4gJm5ic3A7QnV0IA0K aWY8QlI+Jmd0OyB0aGUgZGlhbG9nIGZhaWxlZCBiZWZvcmUgcmVhY2hpbmcgdGhlIFVBLCB0aGUg ZGlhbG9nIHNob3VsZDxCUj4mZ3Q7IA0KYXR0ZW1wdCB0byBjb25uZWN0IHVzaW5nIHRoZSBQU1RO LjxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT5JbiB0aGlzIHNpdHVh dGlvbiwgSWYgSSB1bmRlcnN0YW5kIGl0IA0KY29ycmVjdGx5LCZuYnNwO3Byb3h5IGFscmVhZHkg aGFzIGEmbmJzcDtTSVAgVVJJIGZyb20gRU5VTShpdCBtZWFucyBSY29kZT0wKSwgDQpidXQgaXQg Y2FuJ3QgdGVybWluYXRlIHRoZSBjYWxsIGJ5IHNldmVyYWwgcmVhc29uLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hPlNvLCBoZXJlIGlzIG15Jm5ic3A7cXVlc3Rpb24uPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+Jm5ic3A7PC9GT05UPjwvRElWPjwvRk9OVD4NCjxESVY+ PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj5JZiBhIGNhbGwgZmFpbGVkIGJlZm9yZSBy ZWFjaGluZyBVQSwgDQombmJzcDtkb2VzIHRoZSBwcm94eSBoYXZlIHRvJm5ic3A7c2VuZCBhIGNh bGwmbmJzcDt0byZuYnNwO1BTVE4/IFdoYXQgaGFwcGVuIGlmIA0Kc3VjaCBhIGNhbGwgbXVzdCBm YWlsPyZuYnNwOzwvRk9OVD48Rk9OVCBzaXplPTI+SU1ITywgSWYgcHJveHkgY2FuJ3QgcmVhY2gg dG8gVUEgDQp1c2luZyBTSVAgVVJJIHRocm91Z2ggSVAgbmV0d29yaywgaXQmbmJzcDtpcyBhbHNv IGhhcmRseSZuYnNwOyB0byZuYnNwO3Rlcm1pbmF0ZSANCmEgY2FsbCB0aHJvdWdoIFBTVE4uIElm IEknbSB3cm9uZyBsZXQgbWUga25vdy4uLjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PVZlcmRhbmEgc2l6ZT0yPkFjdHVhbGx5IHdlIGRpZG4ndCBtdWNoIGNhcmUgYWJvdXQgdGhpcyBp c3N1ZSBvbiANCm91ciBFTlVNIHNvZnRzd2l0Y2ggdHJpYWwgaW4gMjAwNiwmbmJzcDsgYmVjYXVz ZSZuYnNwO1BTVE4gY291bGQgYmUgdXNlZCBvbmx5IA0Kd2hlbiAiUmNvZGU9MyhOWERPTUFJTiki PC9GT05UPjxGT05UIHNpemU9Mj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPkpvb25IeXVuZyBMaW0sIE5J REE8L0ZPTlQ+PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0018_01C7669F.C60B48D0-- --===============1263675295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1263675295==-- From enum-bounces@ietf.org Wed Mar 14 15:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRYiV-0001kb-Av; Wed, 14 Mar 2007 15:00:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRYiT-0001kL-CV; Wed, 14 Mar 2007 15:00:53 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRYiN-0004J5-25; Wed, 14 Mar 2007 15:00:53 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 14 Mar 2007 14:57:26 -0400 id 01588444.45F84596.000067F5 In-Reply-To: References: <007f01c76386$138ec680$22f0a544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D607B8C-A484-45CF-872C-7EC658EF261E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Wed, 14 Mar 2007 15:00:23 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, peppermint@ietf.org, Jon Peterson , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 12, 2007, at 5:22 PM, Cullen Jennings wrote: > I feel that this work area--or at least the requirements phase--is > in-scope for SPEERMINT and we'd like to see it pursued there, at > least to the point where there's a consensus that it's likely to be > necessary to form a new working group. Considering that SPEERMINT mentions nowhere in its charter provisioning issues and that ENUM wg has atleast taken on EPP work before, having this work done in ENUM is just as reasonable an idea.... which is to say that either make only as much sense because they reuse the same acronyms. > However, if you feel that this discussion can't be had in the main > SPEERMINT WG meeting and the chairs agree, I think the best way > forward > would be for the SPEERMINT chairs to request an Ad-hoc meeting. > Ultimately this is Jon's decision but if the chairs were in > favor and there was a slot where both Jon and I could make it, I > would be supportive. The idea that work needs to get requirements agreed upon in one working group only so it can then go off to get a BoF to spin up another working group to actually do the real work is daft. Pretty please, can we also be required to fill out some forms in triplicate to be approved by the Chair of the Committee for Nevermind once it has been notarized by the Under Secretary of Busywork? Given this, it is simply stunning that the IETF feels smugly superior to organizations like the ITU. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 15:34:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZDP-00030N-Dr; Wed, 14 Mar 2007 15:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZDO-00030F-96 for enum@ietf.org; Wed, 14 Mar 2007 15:32:50 -0400 Received: from fw-d-whp.denic.de ([81.91.160.27] helo=denic.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZDM-00038N-VV for enum@ietf.org; Wed, 14 Mar 2007 15:32:50 -0400 Received: by unknown.office.denic.de (Postfix, from userid 501) id 23FDF45E6CD; Wed, 14 Mar 2007 20:32:44 +0100 (CET) Date: Wed, 14 Mar 2007 20:32:43 +0100 From: Peter Koch To: IETF ENUM WG Message-ID: <20070314193243.GK1233@unknown.office.denic.de> Mail-Followup-To: IETF ENUM WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Enum] review of draft-ietf-enum-enumservices-guide-03.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Here's a short review of draft-ietf-enum-enumservices-guide-03.txt, some nits are already in the editors' inboxes: 3.1: my latest recollection is that IANA prefers to have a general reference into registries, not a URL for a particular one. There are precedents to the contrary and I consider it useful the way it is, but you might want to check with IANA. Should the enum WG be closed, the URL could become invalid. It might be useful here to keep the list open or start a new one similar to that dealing with mime-types. 4.7: the DNS section is declared OPTIONAL, but the text says MUST. I think the latter is correct and the section should be MANDATORY. 6: This section explains that a service registration should not blindly repeat general ENUM (or DNS?) security considerations. However, the example in Appendix seems to do exactly that. 7: The IANA considerations section should define or reference the existing policy for registering new ENUM services in sections 3 and 7 of RFC 3761 (which this draft updates) as outlined in 2434 or 2434bis. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 18:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbsh-0005Z0-RQ; Wed, 14 Mar 2007 18:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRbsh-0005Yv-4Y for enum@ietf.org; Wed, 14 Mar 2007 18:23:39 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRbsd-0000zZ-T8 for enum@ietf.org; Wed, 14 Mar 2007 18:23:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070314222334m1200illiqe>; Wed, 14 Mar 2007 22:23:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2EMNDGJ004752 for ; Wed, 14 Mar 2007 17:23:13 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2EMNDv0004748; Wed, 14 Mar 2007 17:23:13 -0500 Date: Wed, 14 Mar 2007 17:23:13 -0500 Message-Id: <200703142223.l2EMNDv0004748@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Enum] Concerning future manifestos X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Would people who publish manifestos in the future please put the names of the manifestors (?) at the *top* of the document, so that we can more easily know who is speaking while reading it. Thanks, Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 18:56:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRcNM-0007iE-QK; Wed, 14 Mar 2007 18:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRcNL-0007gI-4S; Wed, 14 Mar 2007 18:55:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRcNI-0005xE-QC; Wed, 14 Mar 2007 18:55:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2007 15:55:12 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2EMtC5o011274; Wed, 14 Mar 2007 15:55:12 -0700 Received: from [128.107.100.34] (dhcp-128-107-100-34.cisco.com [128.107.100.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2EMt7wn027836; Wed, 14 Mar 2007 22:55:07 GMT In-Reply-To: <9D607B8C-A484-45CF-872C-7EC658EF261E@hxr.us> References: <007f01c76386$138ec680$22f0a544@cis.neustar.com> <9D607B8C-A484-45CF-872C-7EC658EF261E@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Wed, 14 Mar 2007 15:55:01 -0700 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2061; t=1173912912; x=1174776912; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Enum]=20draft-lewis-peppermint-enum-reg-if-00 |Sender:=20; bh=Vta4kxOu4OBz6d1E21ZHPy6Buz8lidEOoYEO69NtKKc=; b=LwDaEDr7lDnnyHuCqkcly5K8UzxP2fGpXyqfEqsaYMzo5DyqPVQfLDHQWaOyQLCLBw1iOdFE JqGkjJa8b7eBnh4OmK13oV3CZtBbxg7BsCHVURNjEk7l2RK8uVbn55CJ; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: enum@ietf.org, peppermint@ietf.org, Jon Peterson , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The protocol proposal produced are not convincing that there is a bunch of folks that have a common shared version of what the problem is. Without this you have no chance of consensus at a widely useful protocol. The number of people that replied positively to my question about should we have a BOF could be counted on one hand. You need to build better consensus of what is the work that needs to happen. I'm glad to help you do this. On Mar 14, 2007, at 12:00 PM, Andrew Newton wrote: > > On Mar 12, 2007, at 5:22 PM, Cullen Jennings wrote: > > I feel that this work area--or at least the requirements phase--is > > in-scope for SPEERMINT and we'd like to see it pursued there, at > > least to the point where there's a consensus that it's likely to be > > necessary to form a new working group. > > Considering that SPEERMINT mentions nowhere in its charter > provisioning issues and that ENUM wg has atleast taken on EPP work > before, having this work done in ENUM is just as reasonable an > idea.... which is to say that either make only as much sense because > they reuse the same acronyms. > > > However, if you feel that this discussion can't be had in the main > > SPEERMINT WG meeting and the chairs agree, I think the best way > > forward > > would be for the SPEERMINT chairs to request an Ad-hoc meeting. > > Ultimately this is Jon's decision but if the chairs were in > > favor and there was a slot where both Jon and I could make it, I > > would be supportive. > > The idea that work needs to get requirements agreed upon in one > working group only so it can then go off to get a BoF to spin up > another working group to actually do the real work is daft. Pretty > please, can we also be required to fill out some forms in triplicate > to be approved by the Chair of the Committee for Nevermind once it > has been notarized by the Under Secretary of Busywork? Given this, > it is simply stunning that the IETF feels smugly superior to > organizations like the ITU. > > -andy > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 21:17:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HReZq-0005p8-N2; Wed, 14 Mar 2007 21:16:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HReZp-0005lR-KZ; Wed, 14 Mar 2007 21:16:21 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HReZo-00008f-DW; Wed, 14 Mar 2007 21:16:21 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 14 Mar 2007 21:13:06 -0400 id 0158817B.45F89DA3.0000666F In-Reply-To: References: <007f01c76386$138ec680$22f0a544@cis.neustar.com> <9D607B8C-A484-45CF-872C-7EC658EF261E@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Enum] draft-lewis-peppermint-enum-reg-if-00 Date: Wed, 14 Mar 2007 21:16:05 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: enum@ietf.org, peppermint@ietf.org, Jon Peterson , richard@shockey.us X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 14, 2007, at 6:55 PM, Cullen Jennings wrote: > > The protocol proposal produced are not convincing that there is a > bunch of folks that have a common shared version of what the > problem is. Without this you have no chance of consensus at a > widely useful protocol. The number of people that replied > positively to my question about should we have a BOF could be > counted on one hand. You need to build better consensus of what is > the work that needs to happen. I'm glad to help you do this. First, what protocol proposal are you talking about? I think those of us who want something NOW are being very patient by not putting forth 5 different protocol proposals, and instead documenting requirements, use cases, and problem statements so that there is a common understanding. You seemed to indicate this is exactly what we should do by getting requirements passed in one working group before trying for a BoF. However, if you feel we should just start taking a stab at protocols, I'm all for it. On an issue as simple as this, requirements only serve the IESG.... nobody else reads them. Second, mailing list traffic and show of hands in a meeting are not the same ratios in all communities, even within RAI. I realize that some RAI working groups seem to have volumes of list traffic compared to hands in the meeting (I know, I co-chair one), but if you look at SPEERMINT you'll see that it is not the same. At the last SPEERMINT meeting, the item that got the most agreement at the open discussion period was this issue. Or do you expect that all RAI efforts must have as big an audience and as far reaching an impact as the SIP WG? What's the magic number we need, because I have not found it in any RFC where it should be documented? I realize this is not your half of RAI and appreciate your willingness to dive through new drafts and issues, especially given your load for the working groups where you are AD. We'd have a better IETF if only more ADs worked as hard as you. But I'm baffled by your recommended course of action and cannot understand why you do not feel it is a couple of process hurdles too many. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Mar 14 23:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgCm-0001X6-TF; Wed, 14 Mar 2007 23:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgCl-0001Ui-Vu for enum@ietf.org; Wed, 14 Mar 2007 23:00:39 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRgCk-0006Su-OO for enum@ietf.org; Wed, 14 Mar 2007 23:00:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070315030037m1100eq4pqe>; Thu, 15 Mar 2007 03:00:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2F30aGJ024898 for ; Wed, 14 Mar 2007 22:00:36 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2F30awJ024894; Wed, 14 Mar 2007 22:00:36 -0500 Date: Wed, 14 Mar 2007 22:00:36 -0500 Message-Id: <200703150300.l2F30awJ024894@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <001b01c76654$56be8140$b632a8c0@userbase> (jhlim@nida.or.kr) Subject: Re: [Enum] Response codes and multiple paths to a destination References: <001b01c76654$56be8140$b632a8c0@userbase> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "JoonHyung Lim" If a call failed before reaching UA, does the proxy have to send a call to PSTN? It is not a requirement of ENUM that if an attempt using SIP fails, then the call must be routed through the PSTN. But many of our customers would like that behavior. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 15 16:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwNx-0007aF-C4; Thu, 15 Mar 2007 16:17:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwNw-0007a9-HA for enum@ietf.org; Thu, 15 Mar 2007 16:17:16 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRwNu-0006hJ-Sx for enum@ietf.org; Thu, 15 Mar 2007 16:17:16 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007031520171401300p092ge>; Thu, 15 Mar 2007 20:17:14 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l2FKHEGJ003804 for ; Thu, 15 Mar 2007 15:17:14 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l2FKHEuK003800; Thu, 15 Mar 2007 15:17:14 -0500 Date: Thu, 15 Mar 2007 15:17:14 -0500 Message-Id: <200703152017.l2FKHEuK003800@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45F6E8C1.1050505@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Enum] Response codes and multiple paths to a destination References: <200703131724.l2DHOKsE007015@dragon.ariadne.com> <45F6E8C1.1050505@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Paul Kyzivat I'm sympathetic to the general issue you are raising. But I think some of the codes you have issue with can be explained away as non-issues: 402: does it really matter who needs to be paid? If the UAC is willing and able to pay, then go ahead and try that. If not, then go ahead and try the pstn. (Maybe you will get lucky and its free on the pstn and only charged via sip. (NOT)) Or we could just say that since the implementation of 402 is reserved for future standardization, handling this problem for the 402 response is reserved for that same standardization. 420: again - does it really matter? Either way you can't talk via sip, but still have a chance via the pstn. That's true if one path is SIP and the other path is PSTN. But there is also the case where both paths are SIP. If one SIP path rejects you based on the failure of a Proxy-Require, you want to try the other path. But there's no point in retrying if the failure is due to Require. OTOH, as long as the Require and the Proxy-Require options do not duplicate names, the Unsupported header in the response will distinguish the two cases 422: There is no reason for a UAC to ever *request* a session timer. OK, I was not aware of that. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 15 18:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyTz-00034K-Tg; Thu, 15 Mar 2007 18:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyTx-00033c-On for enum@ietf.org; Thu, 15 Mar 2007 18:31:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRyTv-0006Tq-Ge for enum@ietf.org; Thu, 15 Mar 2007 18:31:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2007 18:31:36 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2FMVZor009703; Thu, 15 Mar 2007 18:31:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2FMVZGd000783; Thu, 15 Mar 2007 22:31:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:31:35 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 18:31:34 -0400 Message-ID: <45F9C946.6030307@cisco.com> Date: Thu, 15 Mar 2007 18:31:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Enum] Response codes and multiple paths to a destination References: <200703131724.l2DHOKsE007015@dragon.ariadne.com> <45F6E8C1.1050505@cisco.com> <200703152017.l2FKHEuK003800@dragon.ariadne.com> In-Reply-To: <200703152017.l2FKHEuK003800@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 22:31:34.0445 (UTC) FILETIME=[AFE60DD0:01C76751] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=563; t=1173997895; x=1174861895; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20Response=20codes=20and=20multiple=20paths=20 to=20a=20destination |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=qM9wcnKFteRQyYOejJD+uuIKU+wk1SPjBcWITr+YzXc=; b=CUq+4+cW0V1HmStNtoIEvjAu271RrSDQb8LlyWqHEQtJlJ+JmYUJnYdhqAzWeU0OrbFDu4Ty dg0GfbuTJsX9xDgeH/VIf44nsVsDQDpEaeUE4A8z204mEGkRQe7cKkdD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dale.Worley@comcast.net wrote: > 422: There is no reason for a UAC to ever *request* a session timer. > > OK, I was not aware of that. The session timer is there so a proxy in the middle can ask one of the UAs to do reinvites, so that the proxy can tell the session is still active. The UAC can send its own reinvites any time it wants - it doesn't have to set up a session timer to do so. The only advantage would be to convince the UAS to do the reinvites, rather than the UAC doing its own. What kind of advantage is that? Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Mar 16 15:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHkf-0007WI-Je; Fri, 16 Mar 2007 15:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSHkd-0007W6-Na for enum@ietf.org; Fri, 16 Mar 2007 15:06:07 -0400 Received: from zinal.switch.ch ([2001:620:0:14:203:baff:fe37:d128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSHkV-0005L4-2l for enum@ietf.org; Fri, 16 Mar 2007 15:06:07 -0400 Received: from [130.59.6.129] (helo=machb.switch.ch) by zinal.switch.ch with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1HSHk9-0001B9-OY for enum@ietf.org; Fri, 16 Mar 2007 20:05:37 +0100 Date: Fri, 16 Mar 2007 20:05:35 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@machb To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SWITCH-SCANNER: bypassed X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Enum] New I/D on Experimental Enumservice Registrations X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi! I just made up a new I-D, containing an early draft version for the registration of experimental Enumservice registrations. Until it appears in the archives, you can find it on: http://ietf.hoeneisen.ch/draft-hoeneisen-enum-x-service-regs-00.txt http://ietf.hoeneisen.ch/draft-hoeneisen-enum-x-service-regs-00.html This I-D complements "Guide and Template for IANA Registrations of Enumservices", as experimental Enumservices do not fully fit into the concept of the latter. Have fun! cheers, Bernie _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Mar 17 11:28:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSanT-0002O1-8c; Sat, 17 Mar 2007 11:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSanS-0002Ns-6c; Sat, 17 Mar 2007 11:26:18 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSanQ-00067y-TB; Sat, 17 Mar 2007 11:26:18 -0400 Received: from [192.168.190.45] (148.116.broadband4.iol.cz [::ffff:85.71.116.148]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Sat, 17 Mar 2007 16:25:50 +0100 id 00008256.45FC087E.00000AA8 Message-ID: <45FC0871.9010409@enum.at> Date: Sat, 17 Mar 2007 16:25:37 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: enum@ietf.org, speermint@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Enum] Please send in your presentations for Prague X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org If you're going to present during the ENUM or SPEERMINT sessions in Prague, please send me your presentations asap, so that i can upload them to the Meetings Material site. (Yes, can replace them with an updated version later, so no need to "keep it back") thanks, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 10:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwIl-00036d-4q; Sun, 18 Mar 2007 10:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwIi-00035v-Df; Sun, 18 Mar 2007 10:24:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSwIg-0008Ug-0f; Sun, 18 Mar 2007 10:24:00 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2007 15:23:58 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2IENtKf001198; Sun, 18 Mar 2007 15:23:56 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2IENtlZ002328; Sun, 18 Mar 2007 14:23:55 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 15:23:55 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 15:23:55 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Sun, 18 Mar 2007 15:23:50 +0100 To: enum@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Mar 2007 14:23:55.0559 (UTC) FILETIME=[0F7B9B70:01C76969] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2501; t=1174227836; x=1175091836; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20My=20view=20of=20where=20we=20are=20in=20ENUM |Sender:=20; bh=IpePFhqUNLoRVksIKvWD+yb4hb1YEF3yBU+tMdHJz0Y=; b=J7PDYCQ3f+t3O8JOqDLHSx3PuOvyLygB9gXmgJ2iY6apLDMsZNMSjYGb17a8Vh/2dtgoTEkX hCHQgKHrjMHMNhbjNXAb7HaH76xVagfY4IHEab5h3qeJMXVjpkyD5SZm; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: iab@ietf.org, The IESG Subject: [Enum] My view of where we are in ENUM X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: enum@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Note: My co-chair have seen this, think the wording is correct, but these are my words I identify regarding ENUM 4 different camps: [A] User ENUM The Public ENUM where the end user, holder of the E.164, is controlling the DNS and URIs. [B] Public Infrastructure ENUM ENUM that is in the public DNS, where lame delegation is not allowed, but the "carrier" responsible for the number (one and only one organisation, not the end user) is controlling the data in a way similar to A. [C] Private Infrastructure ENUM ENUM that is NOT in the public DNS, where groups of organisations on bilateral agreements can make information about the number public. Only parties signing up to the agreements can access the data in the DNS. [D] Non-telephony users of ENUM B (and possibly C - dependent on the agreements) treat "providers of telephony" special, using the regulative/legal definition of carrier as the special entity that part from the end user (as covered in solution A) can add data to the DNS. Category D include other providers of services, not the end user, that argue for them to get the same treatment as the carrier in solutions like B and/or C. ---- o ----- Out of these four, B is very vocal in the IETF. A participates, but is relatively silent (their problem is solved already). C is not participating in IETF but have their own conferences. D does not really exist, but I am nervous about the day when D get members, and what impact D might have on the solutions. The solutions advocated for in the IETF related to B require a branch in the DNS tree, so that solutions for A and B are stored under different domain names, or apexes. How that branch is created, where it is created, and whether it is to be created, is based on arguments that I personally feel we in the IETF are not capable of discussing. Especially as alternative C people are present in the discussions. Those discussions are such that I think (for example) ITU-T in SG2 should discuss. What you should read of the note (that I stand behind that many of you objected to) is that I as co-chair tell IAB and IESG that I do not feel capable recommending the IETF to create a branch, or where some apex should be, of a specific kind without support from a combination of IAB and IESG. Plus a recommendation that many discussions that have been held in ENUM should be held outside of the IETF. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 16:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2Ma-0007J9-Jh; Sun, 18 Mar 2007 16:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2MZ-0007CP-2F; Sun, 18 Mar 2007 16:52:23 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT2MX-0008ML-SK; Sun, 18 Mar 2007 16:52:23 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 18 Mar 2007 14:16:19 -0400 id 0158CC7C.45FD81F3.00002C3C In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: From: Andrew Newton Subject: Re: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 14:19:55 -0400 To: enum@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 18, 2007, at 10:23 AM, Patrik F=E4ltstr=F6m wrote: > [C] Private Infrastructure ENUM > > ENUM that is NOT in the public DNS, where groups of organisations =20 > on bilateral agreements can make information about the number =20 > public. Only parties signing up to the agreements can access the =20 > data in the DNS. Actually, they could very well be in the public DNS but reside in =20 private trees. > C is not participating in IETF but have their own conferences. That's not true, they just don't participate in the ENUM working =20 group because their problem is already solved. > How that branch is created, where it is created, and whether it is =20 > to be created, is based on arguments that I personally feel we in =20 > the IETF are not capable of discussing. Especially as alternative C =20= > people are present in the discussions. Those discussions are such =20 > that I think (for example) ITU-T in SG2 should discuss. I don't understand how C fits into your conclusion, but I suspect =20 that you are right. -andy= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 16:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2N4-0007Pr-3E; Sun, 18 Mar 2007 16:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2N2-0007PY-Sv; Sun, 18 Mar 2007 16:52:52 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT2N1-0008Pq-Gl; Sun, 18 Mar 2007 16:52:52 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1174251170!17396212!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15814 invoked from network); 18 Mar 2007 20:52:50 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-4.tower-146.messagelabs.com with SMTP; 18 Mar 2007 20:52:50 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) wiFrom enum-bounces@ietf.org Sun Mar 18 16:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2Ma-0007J9-Jh; Sun, 18 Mar 2007 16:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2MZ-0007CP-2F; Sun, 18 Mar 2007 16:52:23 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT2MX-0008ML-SK; Sun, 18 Mar 2007 16:52:23 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 18 Mar 2007 14:16:19 -0400 id 0158CC7C.45FD81F3.00002C3C In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: From: Andrew Newton Subject: Re: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 14:19:55 -0400 To: enum@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 18, 2007, at 10:23 AM, Patrik F=E4ltstr=F6m wrote: > [C] Private Infrastructure ENUM > > ENUM that is NOT in the public DNS, where groups of organisations =20 > on bilateral agreements can make information about the number =20 > public. Only parties signing up to the agreements can access the =20 > data in the DNS. Actually, they could very well be in the public DNS but reside in =20 private trees. > C is not participating in IETF but have their own conferences. That's not true, they just don't participate in the ENUM working =20 group because their problem is already solved. > How that branch is created, where it is created, and whether it is =20 > to be created, is based on arguments that I personally feel we in =20 > the IETF are not capable of discussing. Especially as alternative C =20= > people are present in the discussions. Those discussions are such =20 > that I think (for example) ITU-T in SG2 should discuss. I don't understand how C fits into your conclusion, but I suspect =20 that you are right. -andy= _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 16:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2N4-0007Pr-3E; Sun, 18 Mar 2007 16:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2N2-0007PY-Sv; Sun, 18 Mar 2007 16:52:52 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT2N1-0008Pq-Gl; Sun, 18 Mar 2007 16:52:52 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1174251170!17396212!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15814 invoked from network); 18 Mar 2007 20:52:50 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-4.tower-146.messagelabs.com with SMTP; 18 Mar 2007 20:52:50 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2IKqosY010119; Sun, 18 Mar 2007 16:52:50 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2IKqiBc010116; Sun, 18 Mar 2007 16:52:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 16:52:42 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] My view of where we are in ENUM Thread-Index: Acdpakamh1sF+/SrQhS0Nhp1y4JYAgALr+UQ From: "PFAUTZ, PENN L, ATTCORP" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Patrik: I would tend to agree with your parsing of the different varieties of = ENUM with the possible exception of D. The real world and its regulatory framework for numbers (more or less = explicitly recognized in the IAB's initial agreements with the ITU that allowed work to move forward with = e164.arpa) clearly recognizes number assignee and carrier rights with respect to numbers and these are reflected in (A) and (B). = Indeed, some of us recall initial ENUM discussions that explicitly = considered a role for carriers. These were abandoned more for lack of = interest and technical complexity than a consensus that carriers had no = rights. User and Carrier roles are often codified with some variations = in law. While other categories, such as resellers, exist, these are = usually handled through either the user or the carrier framework. And = indeed, one could argue that putative parties in (D) could get ENUM RRs = populated either through the user tree (A) or through the underlying = network service provider (B).=20 >From the beginning, the fact that ENUM would be used in private = arrangements (C) was always understood. So, while I understand the logical concept of (D), I don't see it as a = reason to deny carriers a tree moving forward any more than I would see = it as a reason to deny users their tree. If countries should accord = specific rights with respect to parties that are neither users nor = carriers of record, I suspect countries would have it in their power, as = part of delegation rights for any global user or carrier tree to require = specific administrative arrangements to provide those rights in the = carrier and/or user trees. I believe that the concern with the memo that you and Rich distributed = previously was that it suggested reservations about going forward with a = request to the ITU to consider establishing a global apex for (B). Many = of us had thought that the WG had come to a consensus to do this. = Realistically, establishing a global regime for (B) may be the best way = of protecting the interests of those concerned with D following the = logic stated above that national authorities would then have a way of = enforcing whatever rights they chose to accord such parties.=20 The alternative to (B) is not further work towards some sort arrangement = to provide for (D) but simply that carriers will organize private = national or global trees under which the parties whose interests you are = concerned about re (D) would have no standing. This is the course that = the GSMA is taking, for example. Penn =20 -----Original Message----th ESMTP id l2IKqosY010119; Sun, 18 Mar 2007 16:52:50 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2IKqiBc010116; Sun, 18 Mar 2007 16:52:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 16:52:42 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] My view of where we are in ENUM Thread-Index: Acdpakamh1sF+/SrQhS0Nhp1y4JYAgALr+UQ From: "PFAUTZ, PENN L, ATTCORP" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Patrik: I would tend to agree with your parsing of the different varieties of = ENUM with the possible exception of D. The real world and its regulatory framework for numbers (more or less = explicitly recognized in the IAB's initial agreements with the ITU that allowed work to move forward with = e164.arpa) clearly recognizes number assignee and carrier rights with respect to numbers and these are reflected in (A) and (B). = Indeed, some of us recall initial ENUM discussions that explicitly = considered a role for carriers. These were abandoned more for lack of = interest and technical complexity than a consensus that carriers had no = rights. User and Carrier roles are often codified with some variations = in law. While other categories, such as resellers, exist, these are = usually handled through either the user or the carrier framework. And = indeed, one could argue that putative parties in (D) could get ENUM RRs = populated either through the user tree (A) or through the underlying = network service provider (B).=20 >From the beginning, the fact that ENUM would be used in private = arrangements (C) was always understood. So, while I understand the logical concept of (D), I don't see it as a = reason to deny carriers a tree moving forward any more than I would see = it as a reason to deny users their tree. If countries should accord = specific rights with respect to parties that are neither users nor = carriers of record, I suspect countries would have it in their power, as = part of delegation rights for any global user or carrier tree to require = specific administrative arrangements to provide those rights in the = carrier and/or user trees. I believe that the concern with the memo that you and Rich distributed = previously was that it suggested reservations about going forward with a = request to the ITU to consider establishing a global apex for (B). Many = of us had thought that the WG had come to a consensus to do this. = Realistically, establishing a global regime for (B) may be the best way = of protecting the interests of those concerned with D following the = logic stated above that national authorities would then have a way of = enforcing whatever rights they chose to accord such parties.=20 The alternative to (B) is not further work towards some sort arrangement = to provide for (D) but simply that carriers will organize private = national or global trees under which the parties whose interests you are = concerned about re (D) would have no standing. This is the course that = the GSMA is taking, for example. Penn =20 -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 Sent: Sunday, March 18, 2007 10:24 AM To: enum@ietf.org Cc: iab@ietf.org; The IESG Subject: [Enum] My view of where we are in ENUM Note: My co-chair have seen this, think the wording is correct, but =20 these are my words I identify regarding ENUM 4 different camps: [A] User ENUM The Public ENUM where the end user, holder of the E.164, is =20 controlling the DNS and URIs. [B] Public Infrastructure ENUM ENUM that is in the public DNS, where lame delegation is not allowed, =20 but the "carrier" responsible for the number (one and only one =20 organisation, not the end user) is controlling the data in a way =20 similar to A. [C] Private Infrastructure ENUM ENUM that is NOT in the public DNS, where groups of organisations on =20 bilateral agreements can make information about the number public. =20 Only parties signing up to the agreements can access the data in the =20 DNS. [D] Non-telephony users of ENUM B (and possibly C - dependent on the agreements) treat "providers of =20 telephony" special, using the regulative/legal definition of carrier =20 as the special entity that part from the end user (as covered in =20 solution A) can add data to the DNS. Category D include other =20 providers of services, not the end user, that argue for them to get =20 the same treatment as the carrier in solutions like B and/or C. ---- o ----- Out of these four, B is very vocal in the IETF. A participates, but =20 is relatively silent (their problem is solved already). C is not =20 participating in IETF but have their own conferences. D does not =20 really exist, but I am nervous about the day when D get members, and =20 what impact D might have on the solutions. The solutions advocated for in the IETF related to B require a branch =20 in the DNS tree, so that solutions for A and B are stored under =20 different domain names, or apexes. How that branch is created, where it is created, and whether it is to =20 be created, is based on arguments that I personally feel we in the =20 IETF are not capable of discussing. Especially as alternative C =20 people are present in the discussions. Those discussions are such =20 that I think (for example) ITU-T in SG2 should discuss. What you should read of the note (that I stand behind that many of =20 you objected to) is that I as co-chair tell IAB and IESG that I do =20 not feel capable recommending the IETF to create a branch, or where =20 some apex should be, of a specific kind without support from a =20 combination of IAB and IESG. Plus a recommendation that many =20 discussions that have been held in ENUM should be held outside of the =20 IETF. _______________________________________________ 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: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 Sent: Sunday, March 18, 2007 10:24 AM To: enum@ietf.org Cc: iab@ietf.org; The IESG Subject: [Enum] My view of where we are in ENUM Note: My co-chair have seen this, think the wording is correct, but =20 these are my words I identify regarding ENUM 4 different camps: [A] User ENUM The Public ENUM where the end user, holder of the E.164, is =20 controlling the DNS and URIs. [B] Public Infrastructure ENUM ENUM that is in the public DNS, where lame delegation is not allowed, =20 but the "carrier" responsible for the number (one and only one =20 organisation, not the end user) is controlling the data in a way =20 similar to A. [C] Private Infrastructure ENUM ENUM that is NOT in the public DNS, where groups of organisations on =20 bilateral agreements can make information about the number public. =20 Only parties signing up to the agreements can access the data in the =20 DNS. [D] Non-telephony users of ENUM B (and possibly C - dependent on the agreements) treat "providers of =20 telephony" special, using the regulative/legal definition of carrier =20 as the special entity that part from the end user (as covered in =20 solution A) can add data to the DNS. Category D include other =20 providers of services, not the end user, that argue for them to get =20 the same treatment as the carrier in solutions like B and/or C. ---- o ----- Out of these four, B is very vocal in the IETF. A participates, but =20 is relatively silent (their problem is solved already). C is not =20 participating in IETF but have their own conferences. D does not =20 really exist, but I am nervous about the day when D get members, and =20 what impact D might have on the solutions. The solutions advocated for in the IETF related to B require a branch =20 in the DNS tree, so that solutions for A and B are stored under =20 different domain names, or apexes. How that branch is created, where it is created, and whether it is to =20 be created, is based on arguments that I personally feel we in the =20 IETF are not capable of discussing. Especially as alternative C =20 people are present in the discussions. Those discussions are such =20 that I think (for example) ITU-T in SG2 should discuss. What you should read of the note (that I stand behind that many of =20 you objected to) is that I as co-chair tell IAB and IESG that I do =20 not feel capable recommending the IETF to create a branch, or where =20 some apex should be, of a specific kind without support from a =20 combination of IAB and IESG. Plus a recommendation that many =20 discussions that have been held in ENUM should be held outside of the =20 IETF. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 18:19:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3gN-0002lW-J2; Sun, 18 Mar 2007 18:16:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT3gM-0002lQ-7c for enum@ietf.org; Sun, 18 Mar 2007 18:16:54 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HT3gK-0004SI-2D for enum@ietf.org; Sun, 18 Mar 2007 18:16:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C769AB.0A3F7440" Subject: Re: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 23:16:13 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] My view of where we are in ENUM Thread-Index: AcdpaWQOjQ+WpCzcRQu6ZQgp/BP2ZQAP8dF4 References: From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C769AB.0A3F7440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Patrik, =20 I do not really see a problem here =20 I do not see A, B and C as different camps (I do not understand D), all of these 3 are valid ENUM applications =20 As Penn is saying, C is of no concern in IETF, A is already solved leaves B open: This is also solved in the WG, the drafts are there what is missing is a statement from IETF/IESG/IAB to the ITU-T =20 My proposal is that IESG/IAB is to offer the ITU-T to use also an apex in .arpa and also to use RIPE NCC to operate the Tier-0,=20 it is the ITU-T decision to take this offer or chose another apex (and somebody else to operate it). =20 In SG2 Q.1 already a correspondance group has been created at the last plenary in February (the rapporteur is Karen Mulberry from = Neustar) to deal with this issue (and awaiting a liaison from IESG). =20 In addition, to my understanding nobody in ITU-T considers that this will have any influence on e164.arpa and the Interim Procedures. =20 So what we need to do is advancing the 4 I-Ds to RFCs and send them with = a letter to ITU-T =20 Richard ________________________________ Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] Gesendet: So 18.03.2007 15:23 An: enum@ietf.org Cc: iab@ietf.org; The IESG Betreff: [Enum] My view of where we are in ENUM Note: My co-chair have seen this, think the wording is correct, but=20 these are my words I identify regarding ENUM 4 different camps: [A] User ENUM The Public ENUM where the end user, holder of the E.164, is=20 controlling the DNS and URIs. [B] Public Infrastructure ENUM ENUM that is in the public DNS, where lame delegation is not allowed,=20 but the "carrier" responsible for the number (one and only one=20 organisation, not the end user) is controlling the data in a way=20 similar to A. [C] Private Infrastructure ENUM ENUM that is NOT in the public DNS, where groups of organisations on=20 bilateral agreements can make information about the number public.=20 Only parties signing up to the agreements can access the data in the=20 DNS. [D] Non-telephony users of ENUM B (and possibly C - dependent on the agreements) treat "providers of=20 telephony" special, using the regulative/legal definition of carrier=20 as the special entity that part from the end user (as covered in=20 solution A) can add data to the DNS. Category D include other=20 providers of services, not the end user, that argue for them to get=20 the same treatment as the carrier in solutions like B and/or C. ---- o ----- Out of these four, B is very vocal in the IETF. A participates, but=20 is relatively silent (their problem is solved already). C is not=20 participating in IETF but have their own conferences. D does not=20 really exist, but I am nervous about the day when D get members, and=20 what impact D might have on the solutions. The solutions advocated for in the IETF related to B require a branch=20 in the DNS tree, so that solutions for A and B are stored under=20 different domain names, or apexes. How that branch is created, where it is created, and whether it is to=20 be created, is based on arguments that I personally feel we in the=20 IETF are not capable of discussing. Especially as alternative C=20 people are present in the discussions. Those discussions are such=20 that I think (for example) ITU-T in SG2 should discuss. What you should read of the note (that I stand behind that many of=20 you objected to) is that I as co-chair tell IAB and IESG that I do=20 not feel capable recommending the IETF to create a branch, or where=20 some apex should be, of a specific kind without support from a=20 combination of IAB and IESG. Plus a recommendation that many=20 discussions that have been held in ENUM should be held outside of the=20 IETF. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C769AB.0A3F7440 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig4WAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKwAAAFJlOiBbRW51bV0gTXkgdmll dyBvZiB3aGVyZSB3ZSBhcmUgaW4gRU5VTQDvDQEFgAMADgAAANcHAwASABcAEAANAAAAJwEBIIAD AA4AAADXBwMAEgAXABAADQAAACcBAQmAAQAfAAAAMDU2RDYwNjk3MjJBNDRBQ0M0RTI1MzAwQ0JD OURDALoGAQOQBgCQGwAAOQAAAAMANgAAAAAAQAA5AEB0PwqraccBHgA9AAEAAAAFAAAAUmU6IAAA AAACAUcAAQAAADAAAABjPXVzO2E9IDtwPU9FRkVHO2w9T0VGRUctUzA0LTA3MDMxODIyMTYxM1ot MTk2MAAeAEkAAQAAACcAAABbRW51bV0gTXkgdmlldyBvZiB3aGVyZSB3ZSBhcmUgaW4gRU5VTQAA QABOAABfKwxpaccBHgBaAAEAAAARAAAAUGF0cmlrIEbkbHRzdHL2bQAAAAACAVsAAQAAADwAAAAA AAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABQYXRyaWsgRuRsdHN0cvZtAFNNVFAAcGFmQGNpc2NvLmNv bQACAVwAAQAAABMAAABTTVRQOlBBRkBDSVNDTy5DT00AAB4AXQABAAAAEQAAAFBhdHJpayBG5Gx0 c3Ry9m0AAAAAAgFeAAEAAAA8AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAUGF0cmlrIEbkbHRz dHL2bQBTTVRQAHBhZkBjaXNjby5jb20AAgFfAAEAAAATAAAAU01UUDpQQUZAQ0lTQ08uQ09NAAAe AGYAAQAAAAUAAABTTVRQAAAAAB4AZwABAAAADgAAAHBhZkBjaXNjby5jb20AAAAeAGgAAQAAAAUA AABTTVRQAAAAAB4AaQABAAAADgAAAHBhZkBjaXNjby5jb20AAAAeAHAAAQAAACcAAABbRW51bV0g TXkgdmlldyBvZiB3aGVyZSB3ZSBhcmUgaW4gRU5VTQAAAgFxAAEAAAAbAAAAAcdpaWQOjQ+WpCzc RQu6ZQgp/BP2ZQAP8dF4AB4AcwABAAAAFwAAAGlhYkBpZXRmLm9yZzsgVGhlIElFU0cAAB4AdAAB AAAADgAAAGVudW1AaWV0Zi5vcmcAAAAeABoMAQAAABAAAABTdGFzdG55IFJpY2hhcmQAHgAdDgEA AAAnAAAAW0VudW1dIE15IHZpZXcgb2Ygd2hlcmUgd2UgYXJlIGluIEVOVU0AAAIBCRABAAAAwhQA AL4UAAAtTgAATFpGdQbojb4DAAoAcmNwZzEyNYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrA c2V0MCAHEwKA/xADAFAEVghVB7IR1Q5RAwHdENcyBgAGwxHVMwRGENlZEu9mNBBvEXs1GF8g+FRh aANxAoAR4wjvCff2Oxy/DjA1Hd8dsRHhDGDOYwBQCwkBZDM2EWALpWQ0IBACKlwOsgGQZy8U8Aqj EeMjCDQU8DwhAERPQ1RZUEUgAEhUTUwgUFVCAExJQyAiLS8viFczQyagRFREJbQIMy4yJqBFTiI+ 5yQNI68o4TE4JRAlwigvGyk/K7AzIqAqkEVBRF8q7Q7xLA8ujyoUNg7wPFBNRVRBB7BBMYA9TCJH CfAEkGF0BbAi0RcQT05UJ/BUMhAF4URFeBjhbmdlBlJ2DxMxNGEAkAIgIDYuNcouAcAzJ6A2OSge L+8JKiM3NyUQVElUTApFKu40DvBbRW51dG1dBdB5NJAIkAfgb7BmIHdoBJA0EHc0EI8KwDQQC4Az kE5VTSmO+jUlEC84fzavK2U5wT1wFy1vK79BRDURYDxCTxxEWUC9IhFB32c5NpElEERJVjvQZD1G MCBPV0FSZQtQeVQIZXh0JPA5OTMg0GRpcj1BYHJAsEEjfQAhIAAAR+EKsUjSGOBc/nEDIUhFEWBD n0SvRbZHr+dIv0nKQPk2NE2qSf8qFEo0KnFGMvEgZgDQZYo9BxMgHDM9IzBUs+ogAJB6U8AyTZsY MAMwnmMT8AOyAdBJ2UhpJgBTMoAFEGssKZw1RcEv/1NCTZlNp0/rAcBNpwqiWpj7CoApnDAtMScA RgBZ71Hf/0tPTF9Nb05/Ws9Qn1/vUr//U8ZVL1Y0Vu1Yf1mPX79BNYI4IqAmbmJzcAKA8WOXXCdh AUBlX1vPXN//Xe9e/27/YR9iL2M/ZE9xr79mb3bPaI9pn2qvVwtJeeDwbyBubwVAH0AHQEbgZ4EA CeA7kCBwA2ACYGX+bSK8VmF4UzsibI9tn1qf/3Kfc690v3XPfn9373j/eg//ex98L30/fk9/X4Bv gX9rn/+HD4gfmm9v33DviX+Kj4uf/4yvnK+Oz4/fkO+R/5MPlB9/lS+lj5dPmF+Zb4L/hHJByCwg QjuQbmQXEDuQPwQgqGABIDsxAjBUMGFtrnAEIIVfptIog3d1sxDnNLEBkLMRRClYb5v/iP//oP+i D6MfpC+s36ZPp1+ob/+pf6qPq5+sr62/rs+v31bee4QhOtJ0OyAZICeQO5N2nwdARjA8A7SPwFNh cAtQ9w3gMoA04XO3b7h/uY+6n/+7r7y/vc/Gf7/vwP/CD8Mf/8QvxT/GT8dfyG/Jf5oPz4//0J/i 755Pn1/R/9MP1B/VL//lL9dP2F/Zb9p/24/cn92vX+4P38/g3+Hv9WZBBCBQTwnwA6AEAPfwYXkL gGf/t1znH+guJmD64Trhg8BUMb5uU7AEoc1f71I74UkxkO5Gt10xMEMRUvFZ8hALgN+G0fnJ+tIH QIQBZIRRBvD9NGBk43/kj9GP6Y/qn+uv/+y/9W/u3+/v8P/yD/Mf9C+/9T/2T/df+G/ijYUQYTRg 07NwsuBvcB1AOgFvAn/PA4wajxufA4xUaPrhBIMfBTAFJf+PAJbL4SBXR8uywCNCZDJwZnQEkTtB /8vhhs8GjwefCK8JvwrPC9//HO8N/w8PEB8RLxI/E08UX38VbxZ/F48YnzsQWBD60m2/+uA2sPtQ BHM2oC2QdIUgvbPyZoTghT8t5AESLwEQ1FNHPOBBsuB0g6AjQuBJVFUtVCUPJh8nL/8oPylPKl8r bzQfLY8uny+v/zC/Mc8y3zPvNP82Dzcf4o//Pm8/f1HP/A/9H0DfQe9C//9ED1QPRi9HP0hPSV9K b0t/v0yPXO9Or0+/UM9kRk2EUPmE0XBv+xBh4Prhy+A5Mf8892oCg6D+sLPBO09eIz2/71WvVr9k gj2BdcwRIQOzAHuEoBpAeB2PHp8DjADhLh9eMFlwsvMhA3CVUklQ8EUgTkOzQD2Ba99eMk8aMSQQ OpAjM1RptrAt/jCywHHPct9z7TlDbSdfsJxlY/rgzyE9c2FrJJL7/oNrkm9eQGGgabAjYHcff85j g8EkwXF/em97f10AKKezAgUwOrBibwUBZSEQzySRa1F4dXygKS5SX1Nv/0BvWG9Zf1qPW59kT12/ Xs//X99g72H/Yw9kH2UvZj9nT/9Rb4dPiF+ar24/b0+Jv4rP/4vfjO+c748PkB+RL5I/k09/lF+V b6XPl4+Yn5mvrSZJg/rAPRAyIFEuMQSnuzpA/xByJOCfMP8gZLbwya8wIGc7EHVwf++nA/M5ICCw YmUaUP8ABNE6kN8FjYLvg/85MSNCbLYgOuBfzsAaUKcQBRAA4UaFgHL6dbsSKCNCJBDOsH9gOpB2 dacg+uFLJHH/f6b0Tbx1bLZQs5AFEDsDTrzQ+TphcimbP5xPiU+hT6Jf/6NvpH+tL6afp6+ov6nP qt//q++s/64Prx+wL5pNPYF9oLXR0Xd8oGh+pDmhdSNg8YUDYXdhfKA50jpAva//yVIcgNZQBTD6 wDsDPPKHD//BT8Jfw2/Ef8WPxp/PT8i//8nPyt/L78z/zg/PH9Av0T//0k/TX9lv2n/gr55vn3/m f//c793/3w/vD+Ev4j/jT+Rf/+Vv8s/nj/fv6a/qv+vPsYu/sxD64NZws+AjoWtQbWlQ/nV1YL8w OmF1YDnSgVCFk98jEdbvPGN9U7NwbgIABbK/aiO3H7gvHKx+s9TgbP0AzzkgIYB1QbsyZmzVsLQi 9X4BZQqANHT38E/xX/JqXyMzBx88YzrQvzBpOzBQ+zsQtDBkvOAZ4Nlf7n/bf//zf/SP9Z/2r/9f +M/53/rv//v//Q/+H/8vAD8BTwJf7H//FT8WTyifD+8Q/xevGL8Zz/8a3yrfHP8eDx8fIC8hPyJP vyNfM78lfyaPJ587F1NrUPp3akJ3cOCEIBSw1FNrUN9qACwPLR8RmrMQdrQRBjJHEm/XtkKASS1E ayNS/EZD1WCFE71wQQG6UNjgvdTjYQmvCr+ELLrgdBQR/3XSbW8p/xb/Lv8wDzEfMi//Mz80TzVf Nm83fziPOZ86r/87vzzPPd8+71w/Tb9T70Hf/0LvWb9QL1E/Uk9TX2NfVX//Vo9Xn1ivZg9az2sv XO9d//NfD2AbUmlwMGzAtw1hz/9Oz2bPZ99o72n/aw99337v/3//bI9tn26vb7+Cj0mDsnA/Sf18 gblagv+ED4USSFIZDJBhYrIgCRB4PS0qMXXcMXBQY3BQalyJvwBkYnbAfiBfkIL/kEFK03xziq+L vnE/ck9zX/F0aVRhaNjQs1B1f3aBfjV2z2O+SfCGC5AxmddW7bPgOoy8iWEvm3p6aRRgm7oQdSBr u3BlsGU0B6DjuqCHICdmNtjgRW+Mci5bl9ANANRgOnyAZkCVRNBzs3Aus3BtXUjv30n/uTyab5t/ podHFPBH8R9L8J1Pnl8R10AhMTguSDAzLpmQMDetEDX4OjIzpB+lL6Y/p0+oX/2wxEGdP6tPEcih b4xyvXCQdW1AaaogZi68oH5nri+vP7BPsV+yb7tkQ15js/+1DxHXdTBiuDc7/CBURTHZArjPud+6 77v/m70PxURCqiAU4GZmvp8Tv68R11tFuAFdIE3XBXC2r4xydrhAdw5gdmB/QFAJIA1wQKGKgA1w BuFF+E5VTcKvw7/Ez3h/eY//0a/Pv9DPes9733zvgL/Tz/+ST4xfhPeGC9yP3Z+T2dtQ/lCJv+Bo 38/Uz3Q3mA92gWk/TE5vTBA6y9IIwC3/d/GFoA00R+AOIAyTBREMsPZuoEBFIne4kAYjDMEIwHJy FOBjdAUQzB/iEmL+dQmcZI9lntT/1g8LzqnR/85jBWHsskGc8y/0P/JP93+dSv1JDcAJEBQAaWYF cN0U4Gd4EQYyzuIg8FCFkB/IoM4BFADt7+IDY2Ft/HBzyMz6T/tf+W8Bj0r99FtBy8BVR+DeMM7v BF8fBW8DfwhfSv3CIlB1Yr1K4GP9tM3kRSJH8nUG0f/r8JewkBBMIc2x/t/iEkUi9EUuCzA06/BB j/Bv8X/fCo8Ln0s57WD8wHIPoErhEUUERE5TR5NVUkn8cy4VPxZPCX8aPxtPBdo+QsvADZUQP+IS jiBmcuphoNF17bB1zhEHHx3f/x7vHP8kP0r9/cPrsEBx7TF7zrFFInANpBkx6/DN5Gz/ADDOUKoQ S+D9QPzQnSAgr7viA+0xbuoARHAYkG/OQPxkLBJfE28UfyaPJ58xJzvvQUUTIgAg7YC4QHIiv/0R MACdIOfQDbDOUGbswOtFE7gBYkwhKJ0gzlFHsfcsn+ISnSBs9gA3kS7fL+//MP8yDzMfPDe4kUeg 69AsM7fr8C4SDrop7SQYXGQsMB+X4M6xl+A4H+ISd2F5fznvOv88Dz0fPi9HZ+fQbf+i4OIRowCz wBn/SP8lT0vv20z/BctDICF1IHYsMMJB/yIfIy9Pz03fU99U7yh/Q59zEUQppE5PdKAqDysWZ/0Y cHUAUM2iP8pB0FoPOST/RR9GL0c/Vw9YHzQoSyHqEO9SsHBwohDIgGUrsPzAQdHzP/D14GFrzpI2 kZfQLEP/wVBdwDTUNxVfL+ISXIRLvN9hb2J/Y49knz77Tzly2WH3/ND1cOfBZ0AAGMFd0Eti7zTy Zx2XUJdgc0HQQrdqL/8to1wja+9s/24Pbx9wL3mnfxkxS797P1XPfZ9+rwXLRLPLwOnwbi3qECwA cJew/m72AA8yXfNTf4FPgl+Ab7uGbz7dQjdwN99q92904KM2QfYAQyAtK9FwqfI//qEsYXN8QaDI cSmhInDfGHDNYA/BXw85BWZ3X3hv/3l/iL+Jz/TIhAY1sJNw7aC9wUBs6/APMBi2/SF1ZpG5UiBl LywCZvCqEGY+0P5pLEMQD/+3NWOST5NflG//lX+Wj6AHUsA045jVQRH80L509gApg3ISNoAYcG0O q/+LcUHS6zDIgIu/dpadv57Pf5/foO+h/0poD6DvUCxSQftBoHRjZEFAQvNzRX0yvmCtUkFn7MD2 AETOoWOu4P8r4KdvORT1UZ2vqe+q/6wP/60ftiiQOM2xpnHNYHTBQI//D2Epg+RAmiA2d6XBS4Cy T/3iEmfBkLPvtP+2D7cfuC//9MrnwCuij8NnYqOGNUXOor+uxkHQIHBoIYtgi5EvNqH7vc/iEkN9 b8Mvh3/Kj8uf/8yvv5/Ar8//0Q/SH9Mv1D/f1UyNwNkRjoDZAy3Nb85//8+P2g/bH3EaNMGbwfVU NpD/UzDr8Itg7TGnEfYAyP/KAhx2bwAgZvBcFUlFVPpGsPBBcgSZAMnw6hDr4f/vT9cP1T/c/94P 3BrtMf0gX5pEjYE2MCwA/qEo9VFp/8jfaxUYcDZRpcAp0a7BmoDHQUAuUI/RZHkpsPEpwv8uEeVf 5m/nf+iP6Z+5OORX/xiyQ0HjwjSjvGCagOzvETb/7MEugENQGDH+Y3TBsPCxoPxkb3Jh8F/xb/J/ 84/0n0/cGo/RGJDr8GV4EjB0/+UD92AuQKXAPuC6sF3AQdD/aRT4XxFGQvDr8CsxQ1CxoP+/EWfw Z1Bp4bsBi5H7v/zPv/3f/u///wl3KzApom3J8PdTELGRSxBnCKD39I6VA+//ygLHd8pfCw/b7xEf Ei8TOv5Uo9LHh6/A4vKxMEFANpI/41nrVKdBS3GLYFNAcXVv7MA3sQ7/yfNiZtCx0Gj/By8IPwlP FE8VX+qoXCRc8f2PsmWZQK7AKXTHeDaS5CB/i5LIYVNBUtA/wKdPydV1f44xs98dnx6vH78gzyn4 ZHxpZvpzBkD7MGgAQ0Fu18VxuwE2oWGkEHj60Sqf3yuvEx8v7zD/PxlI+gCk5P8cNFuSJh+dA4/S JeBdJptg/0GzOEaLkl1Bs6I5FUtwJ7//KM8p3zMPNB9l6MahOEZbof5ipsAl72AHvJNnZLxTArD/ pBCQoGBwAbP6cIQAXTBoMv93HzwvPT8+Tz9f9Zv3cyVif7sydGDJ8O5xm78bti2Qc+5ju/CZcrDw RZjVjYGmwf8BsGaxLqCaYo2gRq9Hv0jPx0nfSu/12GVvcE2hJWL/kDDgYexRXBVOD08aELIW4e+N MAVRWqglVHUcf1K/U8+/VN9V78R7RMO8UPVwa+xwf70CAgDFcFfRj6BZT8oCSRBUVS1UxzJTRzL/ rrCEQJowr+FPZC+vYO8xz9dnz2jfaepXvGJ54LBmpv/vguAF+3LGoOyBRMNknxAT/2tAu8EGkGNh GdG8Yi5QhGH/ki9d/18Pat9r7/W5bfLuYH5qmPAZtI+gOwJEtKbDLX9c4C5gvSGEAJrwcD9lo0H/ yGP3YWZwRJb7MHMfdC91P/92T3dfgLe7MkXDTVYakKbw/m1EQS2QmZX3cxnxODR7r//J8xrAHDQu 8zjDfm9/f4CP/4Gfgq+uOcWBL0JmpgaQLvGPjnAawJjTmzBjIGtyEh53m2BmwQPPD/V1cHD7sWCl dWGJz4rfi++M/44P+5cnhXFi9XBRUa8hTdF9Cv2w8FCu4ANhhUibFLxTkq//ygJyopTfle+W/5gP mR8tCf9b6LxT+AMGkAXR4FBm8S5x8EVOVU2QOKdEkmHsEP+yEU3fBMifz6Dfoe+i/6QPf0v7Z5+v L2m/sZ+yr7O6X/+3f7iPuVq0f7WP9YydUEQw/6m/nzXsIPcCyBACMLpvu39ZvI9tQMcArRAuiUBn b7/PwN+zn6t7POQgyeNoERqQZj0irMB0cHOQOi8vd8jwMS7DFnYvvwJyoS+/gvVwJKAvfb1iIsTZ w7CRkKdhw7JmB2bw9XACMHtIWVBFwFJMSU5LIMhvyX95yol9fcvhZvAGsDdwXPBjZjFckHDFcMYH zc9/zt/Kl6y3rKe0UNUPtE458WaQPC9BxNDDn8Svxb8v2Q/aH9sv3DY13MEvRvhPTlTdGdWfrRB8 ouD4r94YfJPeHzc2N9hiUNi+wjDHcS9ESVbgT+RvnmfWIXyz6M/p3zU42HHwQk9EWdi9ZpDrD+2R QjfYcUhUTUzdEH0B78AAAB4ANRABAAAAPQAAADwzMjc1NUQzNTRFNkI2NTQ5OEMzQkQ5RkQ0OTZD N0Q0NjJDNENBMUBvZWZlZy1zMDQub2VmZWcubG9jPgAAAAAeADkQAQAAADEAAAA8RTAwRUU1NjUt QTJEMy00OTBFLTlEOTAtNzE3NzRBMThCRDVFQGNpc2NvLmNvbT4AAAAAHgBHEAEAAAAPAAAAbWVz c2FnZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAABiAAAAUgBlACUAMwBBACAAWwBFAG4AdQBtAF0A IABNAHkAIAB2AGkAZQB3ACAAbwBmACAAdwBoAGUAcgBlACAAdwBlACAAYQByAGUAIABpAG4AIABF AE4AVQBNAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMNp3VSupaccBQAAIMAJgSwqraccBAwDeP69v AAADAPE/BwwAAB4A+D8BAAAAEAAAAFN0YXN0bnkgUmljaGFyZAACAfk/AQAAAFkAAAAAAAAA3KdA yMBCEBq0uQgAKy/hggEAAAAAAAAAL089T0VGRUcvT1U9RVJTVEUgQURNSU5JU1RSQVRJVkUgR1JV UFBFL0NOPVJFQ0lQSUVOVFMvQ049U1RBAAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJh dG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QE AAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABAAAAFNUQQAeADFAAQAA AAQAAABTVEEAHgAyQAEAAAAOAAAAcGFmQGNpc2NvLmNvbQAAAB4AM0ABAAAADgAAAHBhZkBjaXNj by5jb20AAAAeADhAAQAAAAQAAABTVEEAHgA5QAEAAAACAAAALgAAAAMAdkD/////CwApAAAAAAAL ACMAAAAAAAMABhD8lPOzAwAHEHELAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASElQQVRS SUssSURPTk9UUkVBTExZU0VFQVBST0JMRU1IRVJFSURPTk9UU0VFQSxCQU5EQ0FTRElGRkVSRU5U Q0FNUFMoSURPTk9UVU5ERVJTVEFOREQpLEFMTE9GVEhFU0UzQQAAAAACAX8AAQAAAD0AAAA8MzI3 NTVEMzU0RTZCNjU0OThDM0JEOUZENDk2QzdENDYyQzRDQTFAb2VmZWctczA0Lm9lZmVnLmxvYz4A AAAAnDc= ------_=_NextPart_001_01C769AB.0A3F7440 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ------_=_NextPart_001_01C769AB.0A3F7440-- From enum-bounces@ietf.org Sun Mar 18 19:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4L8-0006ZH-RO; Sun, 18 Mar 2007 18:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4L7-0006ZC-Nj for enum@ietf.org; Sun, 18 Mar 2007 18:59:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT4L3-0002hi-Ee for enum@ietf.org; Sun, 18 Mar 2007 18:59:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2007 18:58:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2IMwqrq015575 for ; Sun, 18 Mar 2007 18:58:52 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2IMwqlG022512 for ; Sun, 18 Mar 2007 22:58:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 18:58:52 -0400 Received: from [130.129.19.212] ([10.86.242.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 18:58:52 -0400 Message-ID: <45FDC42B.3020101@cisco.com> Date: Sun, 18 Mar 2007 18:58:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Mar 2007 22:58:52.0478 (UTC) FILETIME=[FF7B4DE0:01C769B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1305; t=1174258733; x=1175122733; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20to=20draft-lewis-enum-teluri-e212-00.txt |Sender:=20 |To:=20enum@ietf.org; bh=Vml6v4vUY5sTqVr+YHKRBx2SO0gPUP6VnL7FMiyaTrs=; b=iowUkzBqDiOwpRSCbkK4XIYoFw98+SfWHkkXO8X8r/AK/onq/Smidwi/ZTE2OlN4Z5xmfzw6 xAIgS61UheYb5AMKm1+bqNwJHavmuWcqNiNu3jofsEPPwgz4NG2nMlw5; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I read this and the companion enumservice. My comment is similar to Cullen - I cannot understand the use case of why we need this. Just because something is a parameter today in the PSTN doesn't mean we need it in VoIP. I'd like to see the call flows and reasons why someone would look at this, what they'd do with it, and how it gets set. Also, as a general comment, I'm not sure I agree that this is a tel URI parameter. There is this increasing trend that says, "if I need parameter foo which was previously carried in ISUP, all I need to do is make it new foo parameter of the tel URI". In many cases these things are wholly inappropriate as tel URI parameters since they aren't qualifiers of the resource identified by the URI at all. One litmus test on this is - does the parameter make sense if the URI were a SIP URI like sip:jdrosen@cisco.com? If it still makes sense in that context you know for sure it shouldn't be a tel URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 20:18:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5YH-0005EJ-MF; Sun, 18 Mar 2007 20:16:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5YG-0005Dp-BE; Sun, 18 Mar 2007 20:16:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5YE-00043T-Vh; Sun, 18 Mar 2007 20:16:40 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 01:16:39 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2J0GcXh021308; Mon, 19 Mar 2007 01:16:38 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J0GblZ011460; Mon, 19 Mar 2007 00:16:37 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:16:37 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:16:37 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <15951592-B415-40A9-B7CB-C4C46B8AAF9A@cisco.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 01:16:30 +0100 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 00:16:37.0347 (UTC) FILETIME=[DBF5D330:01C769BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2607; t=1174263398; x=1175127398; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Enum]=20My=20view=20of=20where=20we=20are=20in=20ENU M |Sender:=20; bh=z1fe/d0JKpWvziNU78XE36PVMGncpj2AenSNol09hzw=; b=uDubXhvOxODZyXoczUiwCGrk28I96RTK6HeZWe5z5a9uHKvNxTzIPdm1oKnr0N6nX07WNZG7 Q//YyvUUYmDLfjn5ga01cdf3dCbE4Sx0G0YZjaAguV8VgRTPmQX8CkWT; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 18 mar 2007, at 19.19, Andrew Newton wrote: > On Mar 18, 2007, at 10:23 AM, Patrik F=E4ltstr=F6m wrote: >> [C] Private Infrastructure ENUM >> >> ENUM that is NOT in the public DNS, where groups of organisations =20 >> on bilateral agreements can make information about the number =20 >> public. Only parties signing up to the agreements can access the =20 >> data in the DNS. > > Actually, they could very well be in the public DNS but reside in =20 > private trees. Correct. We are sort of splitting hairs here. It could be everything =20 form public DNS, but a "special apex", via split DNS situations using =20= the same root as public DNS, to something that is not even using =20 that. There are many shades of grey. >> C is not participating in IETF but have their own conferences. > > That's not true, they just don't participate in the ENUM working =20 > group because their problem is already solved. Ok, let me then rephrase myself, I do not see them participate in the =20= discussions. >> How that branch is created, where it is created, and whether it is =20= >> to be created, is based on arguments that I personally feel we in =20 >> the IETF are not capable of discussing. Especially as alternative =20 >> C people are present in the discussions. Those discussions are =20 >> such that I think (for example) ITU-T in SG2 should discuss. > > I don't understand how C fits into your conclusion, but I suspect =20 > that you are right. Because how the algorithm how you resolve the E.164 to a URI (or a =20 set of URIs) end up being a quite complicated process given A+B+C, =20 and how you do it MIGHT include both legal and business decisions. I am as co-chair of this wg not comfortable declaring consensus =20 without input from my AD's (although I immediately cc the IAB as they =20= handle the liaison with ITU). If the wg (or individuals of the wg) think I am wrong, that is fine. =20 I accept that. The AD have to tell me what to do anyways. I have also heard two other "complaints" on how I have handled this =20 process, and I do acknowledge that as well: (1) The discussions I have had with individuals have not been on the =20 ENUM wg mailinglist, as they should. People was surprised by the =20 message. I understand that. (2) The wording of the initial message could have been different. I =20 should have spent more time editing it. Based on (1) above, I should =20 have understood every letter was important. I understand this as well. I do hope you *NOW* understand what my view is. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 20:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5cM-0007U4-SL; Sun, 18 Mar 2007 20:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5cK-0007R1-Vq; Sun, 18 Mar 2007 20:20:52 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5cJ-0004Tn-AJ; Sun, 18 Mar 2007 20:20:52 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 01:20:51 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2J0KoOo009528; Mon, 19 Mar 2007 01:20:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J0KolZ012008; Mon, 19 Mar 2007 00:20:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:20:49 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:20:49 +0100 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> References: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <88BE3CBD-D27D-4B0D-AE7E-427AC4361E3D@cisco.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 01:20:43 +0100 To: "PFAUTZ, PENN L, ATTCORP" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 00:20:49.0611 (UTC) FILETIME=[725241B0:01C769BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6759; t=1174263650; x=1175127650; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Enum]=20My=20view=20of=20where=20we=20are=20in=20ENU M |Sender:=20; bh=wRW7mTPlxsdrS1YXbxhMxu7l1pIks4cWG0QMWxjVs9Y=; b=wx5KJBTbhV91+T9Z0SRnCdo2ATh0Io5df8INUf22p1cjl+SRL9jkiTO8S2/3L5ArZUECOUX9 21fXEdB10h++XrhG2npLFLQ8DoELbwhDjuSTkXMTmaKYMWq59JZu/YA9; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 18 mar 2007, at 21.52, PFAUTZ, PENN L, ATTCORP wrote: > Patrik: > I would tend to agree with your parsing of the different varieties =20 > of ENUM with the possible exception of D. Understood. Lets ignore D for now. > The real world and its regulatory framework for numbers (more or =20 > less explicitly recognized in the IAB's initial > agreements with the ITU that allowed work to move forward with =20 > e164.arpa) clearly recognizes number assignee and carrier > rights with respect to numbers and these are reflected in (A) and =20 > (B). Indeed, some of us recall initial ENUM discussions that =20 > explicitly considered a role for carriers. These were abandoned =20 > more for lack of interest and technical complexity than a consensus =20= > that carriers had no rights. Correct. > User and Carrier roles are often codified with some variations in =20 > law. While other categories, such as resellers, exist, these are =20 > usually handled through either the user or the carrier framework. =20 > And indeed, one could argue that putative parties in (D) could get =20 > ENUM RRs populated either through the user tree (A) or through the =20 > underlying network service provider (B). >> =46rom the beginning, the fact that ENUM would be used in private =20 >> arrangements (C) was always understood. > So, while I understand the logical concept of (D), I don't see it =20 > as a reason to deny carriers a tree moving forward any more than I =20 > would see it as a reason to deny users their tree. If countries =20 > should accord specific rights with respect to parties that are =20 > neither users nor carriers of record, I suspect countries would =20 > have it in their power, as part of delegation rights for any global =20= > user or carrier tree to require specific administrative =20 > arrangements to provide those rights in the carrier and/or user trees. See previous note. Exactly HOW the branch is created (including IF =20 the branch is created) have to do with so many things that is =20 discussed outside of the IETF that I am (too) nervous of making a =20 decision. > I believe that the concern with the memo that you and Rich =20 > distributed previously was that it suggested reservations about =20 > going forward with a request to the ITU to consider establishing a =20 > global apex for (B). Many of us had thought that the WG had come to =20= > a consensus to do this. Understood. > Realistically, establishing a global regime for (B) may be the best =20= > way of protecting the interests of those concerned with D following =20= > the logic stated above that national authorities would then have a =20 > way of enforcing whatever rights they chose to accord such parties. > The alternative to (B) is not further work towards some sort =20 > arrangement to provide for (D) but simply that carriers will =20 > organize private national or global trees under which the parties =20 > whose interests you are concerned about re (D) would have no =20 > standing. This is the course that the GSMA is taking, for example. GSMA is of course part of C, we all know that. My point is that I do not feel I have enough data to declare =20 consensus on how the solution for B should look like. If the IETF =20 leadership give me advice, I am happy to implement in the wg whatever =20= is suggested. Regarding the suggestion to interact with ITU, that is a reflection =20 on input I have got as a co-chair regarding the ITU-T SG2 discussing =20 many issues that involves policy that impacts the result of the ENUM =20 wg (and the SPEERMINT wg for that matter). Patrik > Penn > > > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Sunday, March 18, 2007 10:24 AM > To: enum@ietf.org > Cc: iab@ietf.org; The IESG > Subject: [Enum] My view of where we are in ENUM > > Note: My co-chair have seen this, think the wording is correct, but > these are my words > > I identify regarding ENUM 4 different camps: > > [A] User ENUM > > The Public ENUM where the end user, holder of the E.164, is > controlling the DNS and URIs. > > [B] Public Infrastructure ENUM > > ENUM that is in the public DNS, where lame delegation is not allowed, > but the "carrier" responsible for the number (one and only one > organisation, not the end user) is controlling the data in a way > similar to A. > > [C] Private Infrastructure ENUM > > ENUM that is NOT in the public DNS, where groups of organisations on > bilateral agreements can make information about the number public. > Only parties signing up to the agreements can access the data in the > DNS. > > [D] Non-telephony users of ENUM > > B (and possibly C - dependent on the agreements) treat "providers of > telephony" special, using the regulative/legal definition of carrier > as the special entity that part from the end user (as covered in > solution A) can add data to the DNS. Category D include other > providers of services, not the end user, that argue for them to get > the same treatment as the carrier in solutions like B and/or C. > > ---- o ----- > > Out of these four, B is very vocal in the IETF. A participates, but > is relatively silent (their problem is solved already). C is not > participating in IETF but have their own conferences. D does not > really exist, but I am nervous about the day when D get members, and > what impact D might have on the solutions. > > The solutions advocated for in the IETF related to B require a branch > in the DNS tree, so that solutions for A and B are stored under > different domain names, or apexes. > > How that branch is created, where it is created, and whether it is to > be created, is based on arguments that I personally feel we in the > IETF are not capable of discussing. Especially as alternative C > people are present in the discussions. Those discussions are such > that I think (for example) ITU-T in SG2 should discuss. > > What you should read of the note (that I stand behind that many of > you objected to) is that I as co-chair tell IAB and IESG that I do > not feel capable recommending the IETF to create a branch, or where > some apex should be, of a specific kind without support from a > combination of IAB and IESG. Plus a recommendation that many > discussions that have been held in ENUM should be held outside of the > IETF. > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Mar 18 20:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5gH-00026g-K7; Sun, 18 Mar 2007 20:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5gG-000264-Kb; Sun, 18 Mar 2007 20:24:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5gF-0004rG-8B; Sun, 18 Mar 2007 20:24:56 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 01:24:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2J0OqUg022379; Mon, 19 Mar 2007 01:24:52 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J0OqlZ012395; Mon, 19 Mar 2007 00:24:52 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:51 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:51 +0100 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 01:24:45 +0100 To: Stastny Richard X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 00:24:51.0656 (UTC) FILETIME=[02976480:01C769BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1896; t=1174263892; x=1175127892; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Enum]=20My=20view=20of=20where=20we=20are=20in=20ENU M |Sender:=20; bh=u2TLoXC+cI5X3DAAdT7onhYLGL6edNb9IcGhrYyPo20=; b=PHzau5kqiYqFADGat34t5soLfS3eBzzUH1WvVQZXo31lX5KP90PJwm1+9e6gC0cnLx1UW9ng lc64PSSDHPEt/tz+LYnBOhBkwNmVG7NHcxGahSqhc997M5j6Ix4g5szd; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 18 mar 2007, at 23.16, Stastny Richard wrote: > I do not really see a problem here Ok. > I do not see A, B and C as different camps (I do not understand D), > all of these 3 are valid ENUM applications > > As Penn is saying, C is of no concern in IETF, > A is already solved > leaves B open: Well, it is FOR ME not that simple. The part that holds an E.164 in his hand, and is going to do resolution on it using some ENUM technology is going to use some algorithm. What that algorithm look like is something I feel I want to know before feeling comfortable, and that includes A, B and C (lets ignore D for now). > This is also solved in the WG, the drafts are there > what is missing is a statement from IETF/IESG/IAB to the ITU-T I completely understand your view. > My proposal is that IESG/IAB is to offer the ITU-T to use also an apex > in .arpa and also to use RIPE NCC to operate the Tier-0, > it is the ITU-T decision to take this offer or chose another apex > (and somebody else to operate it). This might be one solution. I want input from our ADs on this. > In SG2 Q.1 already a correspondance group has been created > at the last plenary in February (the rapporteur is Karen Mulberry > from Neustar) > to deal with this issue (and awaiting a liaison from IESG). > > In addition, to my understanding nobody in ITU-T considers that > this will have any influence on e164.arpa and the Interim Procedures. That is good news, if it is correct. But also, this is why I do not feel comfortable making any decisions before we have this input/ interaction/whatever. We are not that far apart as you might think. Or what I might think :-) > So what we need to do is advancing the 4 I-Ds to RFCs and send them > with a > letter to ITU-T Note that I am *NOT* suggesting any I-D should be thrown away! Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 05:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDiw-0007yh-Ed; Mon, 19 Mar 2007 05:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDiu-0007xv-Fr; Mon, 19 Mar 2007 05:00:12 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDit-0004Hh-3l; Mon, 19 Mar 2007 05:00:12 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id l2J8xvoQ023238; Mon, 19 Mar 2007 09:00:09 GMT From: "Richard Shockey" To: "'PFAUTZ, PENN L, ATTCORP'" , References: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> Subject: RE: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 04:59:51 -0400 Organization: NeuStar, Inc, Message-ID: <01ea01c76a04$f5630830$5c118182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdpakamh1sF+/SrQhS0Nhp1y4JYAgALr+UQAAMXhiA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: iab@ietf.org, 'The IESG' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Sunday, March 18, 2007 4:53 PM > To: enum@ietf.org > Cc: iab@ietf.org; The IESG > Subject: RE: [Enum] My view of where we are in ENUM >=20 > Patrik: > I would tend to agree with your parsing of the different varieties of = ENUM > with the possible exception of D. > The real world and its regulatory framework for numbers (more or less > explicitly recognized in the IAB's initial > agreements with the ITU that allowed work to move forward with = e164.arpa) > clearly recognizes number assignee and carrier > rights with respect to numbers and these are reflected in (A) and (B). > Indeed, some of us recall initial ENUM discussions that explicitly > considered a role for carriers. These were abandoned more for lack of > interest and technical complexity than a consensus that carriers had = no > rights. User and Carrier roles are often codified with some variations = in > law. While other categories, such as resellers, exist, these are = usually > handled through either the user or the carrier framework. And indeed, = one > could argue that putative parties in (D) could get ENUM RRs populated > either through the user tree (A) or through the underlying network = service > provider (B). I think we have all agreed that mixing the two is a bad idea technically = and administratively. > >From the beginning, the fact that ENUM would be used in private > arrangements (C) was always understood. > So, while I understand the logical concept of (D), I don't see it as a > reason to deny carriers a tree moving forward any more than I would = see it > as a reason to deny users their tree. If countries should accord = specific > rights with respect to parties that are neither users nor carriers of > record, I suspect countries would have it in their power, as part of > delegation rights for any global user or carrier tree to require = specific > administrative arrangements to prFrom enum-bounces@ietf.org Mon Mar 19 05:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDiw-0007yh-Ed; Mon, 19 Mar 2007 05:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDiu-0007xv-Fr; Mon, 19 Mar 2007 05:00:12 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDit-0004Hh-3l; Mon, 19 Mar 2007 05:00:12 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id l2J8xvoQ023238; Mon, 19 Mar 2007 09:00:09 GMT From: "Richard Shockey" To: "'PFAUTZ, PENN L, ATTCORP'" , References: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> Subject: RE: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 04:59:51 -0400 Organization: NeuStar, Inc, Message-ID: <01ea01c76a04$f5630830$5c118182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdpakamh1sF+/SrQhS0Nhp1y4JYAgALr+UQAAMXhiA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: iab@ietf.org, 'The IESG' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Sunday, March 18, 2007 4:53 PM > To: enum@ietf.org > Cc: iab@ietf.org; The IESG > Subject: RE: [Enum] My view of where we are in ENUM >=20 > Patrik: > I would tend to agree with your parsing of the different varieties of = ENUM > with the possible exception of D. > The real world and its regulatory framework for numbers (more or less > explicitly recognized in the IAB's initial > agreements with the ITU that allowed work to move forward with = e164.arpa) > clearly recognizes number assignee and carrier > rights with respect to numbers and these are reflected in (A) and (B). > Indeed, some of us recall initial ENUM discussions that explicitly > considered a role for carriers. These were abandoned more for lack of > interest and technical complexity than a consensus that carriers had = no > rights. User and Carrier roles are often codified with some variations = in > law. While other categories, such as resellers, exist, these are = usually > handled through either the user or the carrier framework. And indeed, = one > could argue that putative parties in (D) could get ENUM RRs populated > either through the user tree (A) or through the underlying network = service > provider (B). I think we have all agreed that mixing the two is a bad idea technically = and administratively. > >From the beginning, the fact that ENUM would be used in private > arrangements (C) was always understood. > So, while I understand the logical concept of (D), I don't see it as a > reason to deny carriers a tree moving forward any more than I would = see it > as a reason to deny users their tree. If countries should accord = specific > rights with respect to parties that are neither users nor carriers of > record, I suspect countries would have it in their power, as part of > delegation rights for any global user or carrier tree to require = specific > administrative arrangements to provide those rights in the carrier = and/or > user trees. Penn the issue as Patrik and I see it is that no one is denying carriers their own public apex for Infrastructure ENUM ..its only that the ITU = not the IETF can ultimately make that decision and what the appropriate administrative procedures are surrounding that apex. > I believe that the concern with the memo that you and Rich distributed > previously was that it suggested reservations about going forward with = a > request to the ITU to consider establishing a global apex for (B). = Many of > us had thought that the WG had come to a consensus to do this. The WG may have come to consensus to define an apex but we the WG chairs = ( and many others) felt an obligation to point out the severe risks to the IETF community in doing so. Which is why we expressed our views in a = memo vs an ID. > Realistically, establishing a global regime for (B) may be the best = way of > protecting the interests of those concerned with D following the logic > stated above that national authorities would then have a way of = enforcing > whatever rights they chose to accord such parties. > The alternative to (B) is not further work towards some sort = arrangement > to provide for (D) but simply that carriers will organize private = national > or global trees under which the parties whose interests you are = concerned > about re (D) would have no standing. This is the course that the GSMA = is > taking, for example. But again where is the appropriate forum for such decisions to be = made...we believe it is not in the IETF. Again you are ignoring the issues in the DNS in general. The IETF = defines the protocols for DNS but its administrative policies and procedures are ICANN.=20 In my view again .. should the ITU believe it is the interest of the = global telecommunications community that such a new Infrastructure ENUM apex = exist it can petition the IETF to create such a domain in .apra or use any = domain it wants. >=20 > Penn >=20 >=20 > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Sunday, March 18, 2007 10:24 AM > To: enum@ietf.org > Cc: iab@ietf.org; The IESG > Subject: [Enum] My view of where we are in ENUM >=20 > Note: My co-chair have seen this, think the wording is correct, but > these are my words >=20 > I identify regarding ENUM 4 different camps: >=20 > [A] User ENUM >=20 > The Public ENUM where the end user, holder of the E.164, is > controlling the DNS and URIs. >=20 > [B] Public Infrastructure ENUM >=20 > ENUM that is in the public DNS, where lame delegation is not allowed, > but the "carrier" responsible for the number (one and only one > organisation, not the end user) is controlling the data in a way > similar to A. >=20 > [C] Private Infrastructure ENUM >=20 > ENUM that is NOT in the public DNS, where groups of organisations on > bilateral agreements can make information about the number public. > Only parties signing up to the agreements can access the data in the > DNS. >=20 > [D] Non-telephony users of ENUM >=20 > B (and possibly C - dependent on the agreements) treat "providers of > telephony" special, using the regulative/legal definition of carrier > as the special entity that part from the end user (as covered in > solution A) can add data to the DNS. Category D include other > providers of services, not the end user, that argue for them to get > the same treatment as the carrier in solutions like B and/or C. >=20 > ---- o ----- >=20 > Out of these four, B is very vocal in the IETF. A participates, but > is relatively silent (their problem is solved already). C is not > participating in IETF but have their own conferences. D does not > really exist, but I am nervous about the day when D get members, and > what impact D might have on the solutions. >=20 > The solutions advocated for in the IETF related to B require a branch > in the DNS tree, so that solutions for A and B are stored under > different domain names, or apexes. >=20 > How that branch is created, where it is created, and whether it is to > be covide those rights in the carrier = and/or > user trees. Penn the issue as Patrik and I see it is that no one is denying carriers their own public apex for Infrastructure ENUM ..its only that the ITU = not the IETF can ultimately make that decision and what the appropriate administrative procedures are surrounding that apex. > I believe that the concern with the memo that you and Rich distributed > previously was that it suggested reservations about going forward with = a > request to the ITU to consider establishing a global apex for (B). = Many of > us had thought that the WG had come to a consensus to do this. The WG may have come to consensus to define an apex but we the WG chairs = ( and many others) felt an obligation to point out the severe risks to the IETF community in doing so. Which is why we expressed our views in a = memo vs an ID. > Realistically, establishing a global regime for (B) may be the best = way of > protecting the interests of those concerned with D following the logic > stated above that national authorities would then have a way of = enforcing > whatever rights they chose to accord such parties. > The alternative to (B) is not further work towards some sort = arrangement > to provide for (D) but simply that carriers will organize private = national > or global trees under which the parties whose interests you are = concerned > about re (D) would have no standing. This is the course that the GSMA = is > taking, for example. But again where is the appropriate forum for such decisions to be = made...we believe it is not in the IETF. Again you are ignoring the issues in the DNS in general. The IETF = defines the protocols for DNS but its administrative policies and procedures are ICANN.=20 In my view again .. should the ITU believe it is the interest of the = global telecommunications community that such a new Infrastructure ENUM apex = exist it can petition the IETF to create such a domain in .apra or use any = domain it wants. >=20 > Penn >=20 >=20 > -----Original Message----- > From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > Sent: Sunday, March 18, 2007 10:24 AM > To: enum@ietf.org > Cc: iab@ietf.org; The IESG > Subject: [Enum] My view of where we are in ENUM >=20 > Note: My co-chair have seen this, think the wording is correct, but > these are my words >=20 > I identify regarding ENUM 4 different camps: >=20 > [A] User ENUM >=20 > The Public ENUM where the end user, holder of the E.164, is > controlling the DNS and URIs. >=20 > [B] Public Infrastructure ENUM >=20 > ENUM that is in the public DNS, where lame delegation is not allowed, > but the "carrier" responsible for the number (one and only one > organisation, not the end user) is controlling the data in a way > similar to A. >=20 > [C] Private Infrastructure ENUM >=20 > ENUM that is NOT in the public DNS, where groups of organisations on > bilateral agreements can make information about the number public. > Only parties signing up to the agreements can access the data in the > DNS. >=20 > [D] Non-telephony users of ENUM >=20 > B (and possibly C - dependent on the agreements) treat "providers of > telephony" special, using the regulative/legal definition of carrier > as the special entity that part from the end user (as covered in > solution A) can add data to the DNS. Category D include other > providers of services, not the end user, that argue for them to get > the same treatment as the carrier in solutions like B and/or C. >=20 > ---- o ----- >=20 > Out of these four, B is very vocal in the IETF. A participates, but > is relatively silent (their problem is solved already). C is not > participating in IETF but have their own conferences. D does not > really exist, but I am nervous about the day when D get members, and > what impact D might have on the solutions. >=20 > The solutions advocated for in the IETF related to B require a branch > in the DNS tree, so that solutions for A and B are stored under > different domain names, or apexes. >=20 > How that branch is created, where it is created, and whether it is to > be created, is based on arguments that I personally feel we in the > IETF are not capable of discussing. Especially as alternative C > people are present in the discussions. Those discussions are such > that I think (for example) ITU-T in SG2 should discuss. >=20 > What you should read of the note (that I stand behind that many of > you objected to) is that I as co-chair tell IAB and IESG that I do > not feel capable recommending the IETF to create a branch, or where > some apex should be, of a specific kind without support from a > combination of IAB and IESG. Plus a recommendation that many > discussions that have been held in ENUM should be held outside of the > IETF. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 05:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDhp-0007h2-SJ; Mon, 19 Mar 2007 04:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDhn-0007gv-G6 for enum@ietf.org; Mon, 19 Mar 2007 04:59:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDhl-00048v-6x for enum@ietf.org; Mon, 19 Mar 2007 04:59:03 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id l2J8wjoQ023227; Mon, 19 Mar 2007 08:58:57 GMT From: "Richard Shockey" To: "'Jonathan Rosenberg'" , References: <45FDC42B.3020101@cisco.com> Subject: RE: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt Date: Mon, 19 Mar 2007 04:58:37 -0400 Organization: NeuStar, Inc, Message-ID: <01e201c76a04$ca195620$5c118182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45FDC42B.3020101@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdpsQi7tQh7NHWxQSCb7TvPgEMxlQAUrM9A X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Sunday, March 18, 2007 6:59 PM > To: enum@ietf.org > Subject: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt > > I read this and the companion enumservice. My comment is similar to > Cullen - I cannot understand the use case of why we need this. Just > because something is a parameter today in the PSTN doesn't mean we need > it in VoIP. I'd like to see the call flows and reasons why someone would > look at this, what they'd do with it, and how it gets set. In fact the use case is exactly the opposite. You are right is not about VoIP but providing alternative query mechanisms for TCAP data ..we are already there with LNP and CNAM data ..so the use case here is exactly the same. This is a simple ENUMservice registration. We have not forced an applicability test on registrations nor do we see the need for one at this point. > > Also, as a general comment, I'm not sure I agree that this is a tel URI > parameter. There is this increasireated, is based on arguments that I personally feel we in the > IETF are not capable of discussing. Especially as alternative C > people are present in the discussions. Those discussions are such > that I think (for example) ITU-T in SG2 should discuss. >=20 > What you should read of the note (that I stand behind that many of > you objected to) is that I as co-chair tell IAB and IESG that I do > not feel capable recommending the IETF to create a branch, or where > some apex should be, of a specific kind without support from a > combination of IAB and IESG. Plus a recommendation that many > discussions that have been held in ENUM should be held outside of the > IETF. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 05:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDhp-0007h2-SJ; Mon, 19 Mar 2007 04:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDhn-0007gv-G6 for enum@ietf.org; Mon, 19 Mar 2007 04:59:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDhl-00048v-6x for enum@ietf.org; Mon, 19 Mar 2007 04:59:03 -0400 Received: from RSHOCKEYLTXP (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id l2J8wjoQ023227; Mon, 19 Mar 2007 08:58:57 GMT From: "Richard Shockey" To: "'Jonathan Rosenberg'" , References: <45FDC42B.3020101@cisco.com> Subject: RE: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt Date: Mon, 19 Mar 2007 04:58:37 -0400 Organization: NeuStar, Inc, Message-ID: <01e201c76a04$ca195620$5c118182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45FDC42B.3020101@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdpsQi7tQh7NHWxQSCb7TvPgEMxlQAUrM9A X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Sunday, March 18, 2007 6:59 PM > To: enum@ietf.org > Subject: [Enum] comments to draft-lewis-enum-teluri-e212-00.txt > > I read this and the companion enumservice. My comment is similar to > Cullen - I cannot understand the use case of why we need this. Just > because something is a parameter today in the PSTN doesn't mean we need > it in VoIP. I'd like to see the call flows and reasons why someone would > look at this, what they'd do with it, and how it gets set. In fact the use case is exactly the opposite. You are right is not about VoIP but providing alternative query mechanisms for TCAP data ..we are already there with LNP and CNAM data ..so the use case here is exactly the same. This is a simple ENUMservice registration. We have not forced an applicability test on registrations nor do we see the need for one at this point. > > Also, as a general comment, I'm not sure I agree that this is a tel URI > parameter. There is this increasing trend that says, "if I need > parameter foo which was previously carried in ISUP, all I need to do is > make it new foo parameter of the tel URI". In many cases these things > are wholly inappropriate as tel URI parameters since they aren't > qualifiers of the resource identified by the URI at all. > One litmus test on this is - does the parameter make sense if the URI > were a SIP URI like sip:jdrosen@cisco.com? If it still makes sense in > that context you know for sure it shouldn't be a tel URI. You can argue that this is not an appropriate use of TEL paramameters just tell us what parameter should we use .. data: ??? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ng trend that says, "if I need > parameter foo which was previously carried in ISUP, all I need to do is > make it new foo parameter of the tel URI". In many cases these things > are wholly inappropriate as tel URI parameters since they aren't > qualifiers of the resource identified by the URI at all. > One litmus test on this is - does the parameter make sense if the URI > were a SIP URI like sip:jdrosen@cisco.com? If it still makes sense in > that context you know for sure it shouldn't be a tel URI. You can argue that this is not an appropriate use of TEL paramameters just tell us what parameter should we use .. data: ??? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 05:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTECS-0006rp-UT; Mon, 19 Mar 2007 05:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTECQ-0006pF-1g; Mon, 19 Mar 2007 05:30:42 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTECO-00086f-MK; Mon, 19 Mar 2007 05:30:42 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 10:30:38 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2J9Ubx6013081; Mon, 19 Mar 2007 10:30:37 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J9U2m9005620; Mon, 19 Mar 2007 09:30:33 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:30:32 +0100 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:30:31 +0100 In-Reply-To: <01ea01c76a04$f5630830$5c118182@cis.neustar.com> References: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> <01ea01c76a04$f5630830$5c118182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3718275C-94B4-442C-B9CF-3BEA476E2137@cisco.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 10:30:26 +0100 To: richard@shockey.us X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 09:30:31.0990 (UTC) FILETIME=[3D59E560:01C76A09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=678; t=1174296637; x=1175160637; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20 |Subject:=20Re=3A=20[Enum]=20My=20view=20of=20where=20we=20are=20in=20ENU M |Sender:=20; bh=9/IvqiI88R1tkTaknlm2C05totnMC/i98XGvfiNTxtw=; b=oTMW7Y1VkJh3drMbsaPW8DfoRG1NQsDt+xSKkcn4jy0hYSbDlKHsZ1X9ou/l75fwDVjhgzBF hziag921CT7JkS2QC8UcVfpu1Wf/LA5aXqaOGpvXyHFKXqnLv90EEquv; Authentication-Results: ams-dkim-1; header.From=paf@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: enum@ietf.org, iab@ietf.org, "'PFAUTZ, PENN L, ATTCORP'" , 'The IESG' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 19 mar 2007, at 09.59, Richard Shockey wrote: > its only that the ITU not > the IETF can ultimately make that decision and what the appropriate > administrative procedures are surrounding that apex. Let me phrase this differently, because I think I understand where the sensitivity is. In what Richard is saying lies two things: 1. As co-chairs we can not, given the landscape, declare consensus that we need a branch and a specific apex for that branch. We need input from AD/IAB. 2. We suggest IAB/IETF cooperate with ITU-T on the question, but whether any question is to be sent etc is a decision that lies with IAB and IESG. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 06:03:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEhP-0004Q5-4I; Mon, 19 Mar 2007 06:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEhO-0004Ou-2X; Mon, 19 Mar 2007 06:02:42 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTEhL-0004NE-Oo; Mon, 19 Mar 2007 06:02:42 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 19 Mar 2007 05:58:15 -0400 id 0158C3D3.45FE5EB7.00004D33 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4CA1@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Andrew Newton Subject: Re: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 06:01:58 -0400 To: Stastny Richard X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092270076==" Errors-To: enum-bounces@ietf.org --===============0092270076== Content-Type: multipart/alternative; boundary=Apple-Mail-7-570306945 --Apple-Mail-7-570306945 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 18, 2007, at 6:16 PM, Stastny Richard wrote: > As Penn is saying, C is of no concern in IETF I strongly disagree with this statement. -andy --Apple-Mail-7-570306945 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Mar 18, 2007, at 6:16 PM, Stastny Richard wrote:

As Penn is saying, C is of no concern in IETF


I strongly disagree with this statement.

-andy
--Apple-Mail-7-570306945-- --===============0092270076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0092270076==-- From enum-bounces@ietf.org Mon Mar 19 07:36:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTG7q-0003xd-O7; Mon, 19 Mar 2007 07:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTG7o-0003pG-N7; Mon, 19 Mar 2007 07:34:04 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTG7k-0000Gz-II; Mon, 19 Mar 2007 07:34:04 -0400 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l2JBXvuR006749; Mon, 19 Mar 2007 07:33:59 -0400 Received: from dul1trutkow-l1.verisign.com ([10.26.0.226]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 07:33:53 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Mar 2007 07:33:47 -0400 To: richard@shockey.us, "'PFAUTZ, PENN L, ATTCORP'" , From: Tony Rutkowski Subject: RE: [Enum] My view of where we are in ENUM In-Reply-To: <01ea01c76a04$f5630830$5c118182@cis.neustar.com> References: <34DA635B184A644DA4588E260EC0A25A0EF88D7A@ACCLUST02EVS1.ugd.att.com> <01ea01c76a04$f5630830$5c118182@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 Mar 2007 11:33:53.0196 (UTC) FILETIME=[78D04EC0:01C76A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iab@ietf.org, 'The IESG' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard, >In my view again .. should the ITU believe it is the interest of the global >telecommunications community that such a new Infrastructure ENUM apex exist >it can petition the IETF to create such a domain in .apra or use any domain >it wants. Glad to see the realism here at last. These are, after all, the namespace and global public telecommunication identifiers of ITU-T and domestically of member administrations. In the U.S., the namespace is explicitly subject to the Communications Act of 1996 and managed by the FCC pursuant to Part 52 of its Rules. Shortly, in the U.S. the assignment of those numbers will be subject to a charge that among other things will pay the costs of administrative contractors like NeuStar. In Europe, their use is subject to the Data Retention Directive. What protocols, platforms, or leafs are used to implement the authoritative resolution of the identifiers for public telecommunication services are irrelevant to the matter of jurisdiction and regulatory requirements. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 07:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGTt-0005I2-J8; Mon, 19 Mar 2007 07:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGTr-0005GS-Qv; Mon, 19 Mar 2007 07:56:51 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTGTa-0004eV-Ts; Mon, 19 Mar 2007 07:56:51 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1174305393!22111995!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 22998 invoked from network); 19 Mar 2007 11:56:33 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 19 Mar 2007 11:56:33 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2JBuWvM012391; Mon, 19 Mar 2007 07:56:32 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2JBuP69012321; Mon, 19 Mar 2007 07:56:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] My view of where we are in ENUM Date: Mon, 19 Mar 2007 07:56:22 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0EF88DDA@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <3718275C-94B4-442C-B9CF-3BEA476E2137@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] My view of where we are in ENUM Thread-Index: AcdqCUSUD0Of9JmOT8i9RTc4esVNAQAE8ksg From: "PFAUTZ, PENN L, ATTCORP" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org OK. I think all we were looking for was a recognition of working group = consensus to ask for an apex and a corresponding recommendation to the = IAB/IESG (following AD concurrence) to forward the issue to the ITU.=20 Penn -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 Sent: Monday, March 19, 2007 5:30 AM To: richard@shockey.us Cc: PFAUTZ, PENN L, ATTCORP; enum@ietf.org; iab@ietf.org; 'The IESG' Subject: Re: [Enum] My view of where we are in ENUM On 19 mar 2007, at 09.59, Richard Shockey wrote: > its only that the ITU not > the IETF can ultimately make that decision and what the appropriate > administrative procedures are surrounding that apex. Let me phrase this differently, because I think I understand where =20 the sensitivity is. In what Richard is saying lies two things: 1. As co-chairs we can not, given the landscape, declare consensus =20 that we need a branch and a specific apex for that branch. We need =20 input from AD/IAB. 2. We suggest IAB/IETF cooperate with ITU-T on the question, but =20 whether any question is to be sent etc is a decision that lies with =20 IAB and IESG. Patrik _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Mar 19 07:57:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGUs-0005p9-TT; Mon, 19 Mar 2007 07:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTGUq-0005mp-2O; Mon, 19 Mar 2007 07:57:52 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTGUm-00050Q-3e; Mon, 19 Mar 2007 07:57:52 -0400 Received: from [130.129.18.112] (account jim [130.129.18.112] verified) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 160627; Mon, 19 Mar 2007 11:57:32 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Enum] My view of where we are in ENUM Date: Sun, 18 Mar 2007 22:19:22 +0000 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 18, 2007, at 18:19, Andrew Newton wrote: >> C is not participating in IETF but have their own conferences. > > That's not true, they just don't participate in the ENUM working > group because their problem is already solved. That's not true either Andy. There's a forest of disjoint trees out there. So many of those in group C have solved their immediate problem. But at the expense of even bigger problems of interconnecting name spaces with competitors who use different trees and/or name spaces. And just because those guys don't come to the ENUM WG doesn't mean there isn't a problem. This is why I believe there's a role for the WG and the IESG/IAB to work out an apex (at the very least) for private infrastructure ENUM. If it's not the IETF that does this, who will? Or could? _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Mar 20 06:38:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbhR-0008DN-TA; Tue, 20 Mar 2007 06:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbhP-0008Ce-Sc; Tue, 20 Mar 2007 06:36:15 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbhN-0004Kt-GA; Tue, 20 Mar 2007 06:36:14 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 20 Mar 2007 06:32:17 -0400 id 015880EB.45FFB831.000064AC In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0332FB2A-B437-4359-B67F-F68BA3B38B04@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Enum] My view of where we are in ENUM Date: Tue, 20 Mar 2007 06:36:05 -0400 To: Jim Reid X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: enum@ietf.org, iab@ietf.org, The IESG X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Mar 18, 2007, at 6:19 PM, Jim Reid wrote: > On Mar 18, 2007, at 18:19, Andrew Newton wrote: > >>> C is not participating in IETF but have their own conferences. >> >> That's not true, they just don't participate in the ENUM working >> group because their problem is already solved. > > That's not true either Andy. There's a forest of disjoint trees out > there. So many of those in group C have solved their immediate > problem. But at the expense of even bigger problems of > interconnecting name spaces with competitors who use different > trees and/or name spaces. Well, there was a proposal in ENUM that would have fixed the disjoint problem you are talking about for the people in the C area (private ENUM trees). The problem is, the proposal was identified with B needs (public infrastructure ENUM) and thus has progressed nowhere. I think that speaks well of Patrik's point about no consensus. > And just because those guys don't come to the ENUM WG doesn't mean > there isn't a problem. This is why I believe there's a role for the > WG and the IESG/IAB to work out an apex (at the very least) for > private infrastructure ENUM. If it's not the IETF that does this, > who will? Or could? I'm well aware of the problem, but there are other solutions to it that do not require protocol standardization. I have a programmer working on it right now. As for an apex for private infrastructure ENUM, I don't think that is necessary and would create far more problems than it would solve. In the end, wouldn't it look like a domain registry? Is there something special about an anointed apex that cannot be solved by the use of normal domain names? I don't think the DNS protocol cares, therefore this sounds like a question for the ITU or ICANN. -andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Mar 22 10:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcT-0003xY-97; Thu, 22 Mar 2007 10:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcA-0003oN-90; Thu, 22 Mar 2007 10:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOc7-0003XG-Q0; Thu, 22 Mar 2007 10:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4282A26F3E; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-0008Aa-Vw; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-06.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-06.txt Pages : 9 Date : 2007-3-22 This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-vcard-06.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-vcard-06.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. --NFrom enum-bounces@ietf.org Thu Mar 22 10:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcT-0003xY-97; Thu, 22 Mar 2007 10:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcA-0003oN-90; Thu, 22 Mar 2007 10:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOc7-0003XG-Q0; Thu, 22 Mar 2007 10:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4282A26F3E; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-0008Aa-Vw; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vcard-06.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for vCard Enumservice Author(s) : A. Mayrhofer Filename : draft-ietf-enum-vcard-06.txt Pages : 9 Date : 2007-3-22 This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vcard-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-vcard-06.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-vcard-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-22063015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22063015.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Mar 22 10:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcT-0003xT-0C; Thu, 22 Mar 2007 10:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcA-0003oK-7g; Thu, 22 Mar 2007 10:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOc7-0003XF-OA; Thu, 22 Mar 2007 10:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1EE8026F37; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-0008A6-Ol; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-07.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-07.txt Pages : 32 Date : 2007-3-22 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-07.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-drextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-22063015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vcard-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vcard-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22063015.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Thu Mar 22 10:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcT-0003xT-0C; Thu, 22 Mar 2007 10:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOcA-0003oK-7g; Thu, 22 Mar 2007 10:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOc7-0003XF-OA; Thu, 22 Mar 2007 10:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1EE8026F37; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc6-0008A6-Ol; Thu, 22 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-experiences-07.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-07.txt Pages : 32 Date : 2007-3-22 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-experiences-07.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-experiences-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-22055537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-experiences-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-experiences-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22055537.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- afts/draft-ietf-enum-experiences-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-22055537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-experiences-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-experiences-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22055537.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Mar 28 10:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZTy-0004nA-G0; Wed, 28 Mar 2007 10:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZTv-0004kK-83; Wed, 28 Mar 2007 10:50:35 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWZTs-00053P-No; Wed, 28 Mar 2007 10:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A588B2ACCD; Wed, 28 Mar 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HWZTO-00076P-EV; Wed, 28 Mar 2007 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Mar 2007 10:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-validation-epp-04.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-ietf-enum-validation-epp-04.txt Pages : 24 Date : 2007-3-28 This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-validation-epp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-validation-epp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-28095832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-validation-epp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-validation-epp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28095832.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Mar 28 15:51:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWe9v-00005S-Gh; Wed, 28 Mar 2007 15:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWe9j-0008Tq-9U; Wed, 28 Mar 2007 15:50:03 -0400 Received: from [2001:503:c779:1a::9c9a:108a] (helo=ns1.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWe9j-0001x8-09; Wed, 28 Mar 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A674D26EB7; Wed, 28 Mar 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HWe9i-0004aJ-HE; Wed, 28 Mar 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Mar 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-unused-02.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration for Enumservice UNUSED Author(s) : R. Stastny, et al. Filename : draft-ietf-enum-unused-02.txt Pages : 16 Date : 2007-3-28 This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-unused-02.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-unused-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-28123000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-unused-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-unused-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-28123000.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Wed Mar 28 19:24:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhT0-0003jn-Ob; Wed, 28 Mar 2007 19:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhSz-0003ji-Mb for enum@ietf.org; Wed, 28 Mar 2007 19:22:09 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhSy-0006vu-AV for enum@ietf.org; Wed, 28 Mar 2007 19:22:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id EAF1AA6C37 for ; Thu, 29 Mar 2007 00:21:54 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CB9CE3E-67B9-4275-B349-E3070E262E53@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-unused-02.txt Date: Thu, 29 Mar 2007 00:21:53 +0100 To: IETF ENUM WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Folks, this update reflects the discussions during the meeting. As always, how (and if) you use this Enumservice is up to you. => Section 7 is no more, making the draft MUCH shorter and simpler. Apart from that, no change apart from a very slightly longer description in the registration template text. Can folk please get any remaining comments in real soon, please? This one is needed and is ready for bed, IMHO. all the best, Lawrence On 28 Mar 2007, at 20:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Telephone Number Mapping Working > Group of the IETF. > > Title : IANA Registration for Enumservice UNUSED > Author(s) : R. Stastny, et al. > Filename : draft-ietf-enum-unused-02.txt > Pages : 16 > Date : 2007-3-28 > > This document registers the Enumservice "unused" using the URI scheme > "data:" as per the IANA registration process defined in the ENUM > specification, RFC 3761. This Enumservice may be used to indicate > that the E.164 number (or E.164 number range) tied to the domain in > which the enclosing NAPTR is published is not allocated or assigned > for communications service. When such an indication is > provided, an > ENUM client can detect calls that will fail "early". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-unused-02.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum