From enum-admin@ietf.org Sun Oct 1 18:15:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12801 for ; Sun, 1 Oct 2000 18:15:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04707; Sun, 1 Oct 2000 18:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04679 for ; Sun, 1 Oct 2000 18:14:09 -0400 (EDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12786 for ; Sun, 1 Oct 2000 18:14:05 -0400 (EDT) Received: from computer.ix.netcom.com (user-2iveoir.dialup.mindspring.com [165.247.98.91]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA20651; Sun, 1 Oct 2000 18:14:04 -0400 (EDT) Message-Id: <5.0.0.25.2.20001001172719.027b2400@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 01 Oct 2000 17:57:20 -0400 To: enum@ietf.org From: Richard Shockey Cc: sob@harvard.edu, mankin@east.isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] WG objectives in advance of IETF 49 in San Diego Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org As you all know our core protocol document was approved as RFC 2916 last week but we still have a considerable amount of work to do. The list has been very quiet the last several weeks but I would like to get things going again in preparation for San Diego. We need to start now... 1. I would like to bring our Requirements Document to last call if possible. We had several objections to language in the document before the Pittsburgh meetings and at that point I held up going to last call. http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt I would like the WG to review this document again so we can start the last call process ASAP. Does this document need revisions? If so in what way.... 2. I believe that since Pittsburgh it was fairly obvious that that Greg's Operations document needed some revisions based on decisions made by the WG... once again the sooner we begin discussions again the sooner we can conclude this work item. http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt 3. We need to look into whether we need a Management Information Base ( MIB ) for ENUM. I have privately asked some members of the WG whether they would be interested in taking on the work but we should ask ourselves what the scope of this work might look like. 4. I am aware that Penn Pfautz's document on Adminstrative issues is undergoing substantial revisions and will probably be brought forward as an Informational document. The current version is... http://www.ietf.org/internet-drafts/draft-pfautz-na-enum-01.txt For any number of reasons this is going to be a very important document for us to review. As new versions of this document are made available I would appreciate it if we could discuss it at some length. 5. In addition if any of you are interested in presenting documents in San Diego this is your First Call... now is the time to put your drafts is so they can be properly discussed on the list in advance of the meeting. I will request another single 2 1/2 hour slot when reservations open up shortly. 6. In addition it was brought up in the meeting in Pittsburgh that it may be necessary to put together a BOF in San Diego on Administrative and Operational issues in ENUM. As some of you know there has been substantial activity along those lines in may forums. There are active discussions with our ITU SG2/Q1 colleagues on the resolution of several issues and I imagine there will a great deal to report on. Scott - Allison ..is a BOF the way to do this or schedule 2 ENUM meetings? Should the BOF have a charter? I can certainly write one. I would assume that we should discuss what kinds of data we need during trial phases etc as this moves forward. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Sun Oct 1 20:58:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14070 for ; Sun, 1 Oct 2000 20:58:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06461; Sun, 1 Oct 2000 20:55:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06432 for ; Sun, 1 Oct 2000 20:55:06 -0400 (EDT) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14030 for ; Sun, 1 Oct 2000 20:55:03 -0400 (EDT) Received: from computer.ix.netcom.com (user-2iveois.dialup.mindspring.com [165.247.98.92]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA16266 for ; Sun, 1 Oct 2000 20:55:00 -0400 (EDT) Message-Id: <5.0.0.25.2.20001001165856.027ab0f0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 01 Oct 2000 20:54:32 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA06433 Subject: [Enum] Yes ...the Meeting Minutes from ENUM WG at IETF 48 Pittsburgh Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id UAA06461 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA14070 Yes ..I know this is unusually late and there is no excuse for it and my sincerest apologies to Jay Hilton and other who have correctly complained about this...however if we can review this and people will send me corrections or clarifications I will process them and get this off ASAP. This will not happen again ... if Jay will volunteer to do this again in San Diego ..he will have document control only subject to the final approval of the chair(s). :-) Telephone Number Mapping WG (ENUM) IETF 48 Pittsburgh Tuesday, August 1 from 0900-1130 ============================= CHAIR: Richard Shockey (rshockey@ix.netcom.com) Scott Petrak (scott.petrack@metatel.com) Scribe: Jay Hilton ( jhilton@telcordia.com) AGENDA: Meeting Agenda 1. Agenda Bashing - 5 min 2. Document Status: Chair 2 min Core Protocol e164-DNS submitted to IESG Last Call draft-ietf-enum-e164-dns-01.txt Requirements on hold before submitted to IESG Last Call draft-ietf-enum-rqmts-01.txt 3. ENUM Open Requirements issues ­ Greg Vaudreuil x min 3a. ENUM Operations issues... Greg Vaudreuil 20 min draft-ietf-enum-operation-00.txt 4. ITU e164 workplan Andy Galant 10min draft-gallant-enum-e164-snap-00.txt 5. Service Principles when Public Circuit Switched International Telecommunication Networks Interworking with IP-based Networks - Steve Lind 15 min draft-lind-itut-e370-00.txt 6. ENUM Call Flows for VoIP Interworking . Steve Lind 15 min draft-lind-enum-callflows-00.txt 7. ENUM in Signaling Transport: 20 min John Loughney draft-loughney-enum-sigtran-00.txt 8. ENUM Usage in Cellular Roaming John Loughney 10 min draft-loughney-enum-roaming-00.txt Future Directions and revised milestones 10m DELETE: FAQ ­ Operations vs Out of Scope issues GENERAL DISCUSSION ########################## Related Documents: ITU Number Portability draft-ietf-enum-e164s2-np-00.txt Number Portability in the GSTN: An Overview draft-ietf-enum-e164-gstn-np-00.txt Dynamic Delegation Discovery System (DDDS) draft-ietf-urn-ddds-00.txt URI Resolution using the Dynamic Delegation Discovery System draft-ietf-urn-uri-res-ddds-00.txt ] ########################### 1. Agenda Bashing Richard Shockey opened meeting with request for comments for additions or deletions from the agenda. The agenda was approved. General Opening Comments: (1.) Richard Shockey noted there were two number portability ID for discussion and possible review however these were not part of the agenda : ITU Number portability draft from ITU-T Study Group 2 and number portability in the Global Switched Telephone Network (GSTN) explaining applications in use in North America. These may be proposed as Informational RFCs at some time in the near future. (2.) Scott Bradner noted that he had received some flack regarding the specification of a particular vendors application in a document. When identifying existing applications/implementations in draft documents we need to identify all or no vendors in the document. (3) Richard Shockey noted that there are several other drafts that impact on ENUM work, in particular the new Dynamic Delegation Discovery System documents, draft-ietf-urn-dns-ddds-database-00.txt and draft-ietf-urn-uri-res-ddds-00.txt. Principals included within are a core part of NAPTR RR itself. It was noted in the Application Area General Session that these documents are fundamental to ongoing work in solving the problems of Service Resolution and eventually Capabilities Resolution RESCAP. Greg Vaudreuil asked about the limitation of only using NAPTR for ENUM. Scott Petrack noted that we will also use CNAME and DNAME for delegation purposes etc. The charter identifies that ENUM will provide a resource in the Internet, e.g., a URL. Therefore, the result of an ENUM query is a URL. Christian Huitema noted that ENUM results in two queries, one to find the URL, the second is to resolve the URL. Add note was agreed from the ENUM Charter, as quoted from Scott. "The system must enable resolving input telephone numbers into a set of URLs which represent different ways to start communication with a device associated to the input phone number." Scott noted simply "Telephone Number IN ..URL OUT" The chair requested that discussion of the limitation on use of the NAPTR record only be deferred until the General Discussion since it had been clear from the discussion on the list that this was the most contentious issue in the Falstrom e164-dns-01 drafts. 2. Document Status: Chair began a discussion of current Document Status. 2.1 Core ENUM Protocol Document - e164-DNS submitted to IESG Last Call A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt This is the ENUM protocol document. It has been submitted for IESG LAST CALL. Some minor comments received (editorial and suggestions for adding another example which clarify differences between delegation of name servers in DNS and then further explanations of telephony applications). These will be incorporated in the document. 2.2 Requirements submitted to IESG Last Call A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt Richard did not submit the document for last call due to the number of comments received over the email list. The plan is to resolve the outstanding issues in the very near future and then go to last call. The meeting discussed several open issues with the document. Greg Vaudreuil presented these issues for the author, Anne Brown, since she was not able to attend this meeting: Issues with the Requirements Document Resolved at the meeting: As part of the discussion of Requirements issues Greg Vaudreuil presented a series of slides. Response Timeout: Draft indicated there must be a mechanism. Need more detail as to what should be provided, how long should a client wait before timeout? Is it a requirement? Christian Huitema proposed that no value be provided, therefore the application can set its own value. CONCLUSION: It was agreed by the meeting that Response Timeout is NOT a requirement for ENUM. DNS Security: Should authorization be a part of ENUM? Integrity? Privacy? CONCLUSION: This was agreed to be dropped as a requirement for ENUM. Availability and reliability: GSTN Reliability is desired. CONCLUSION: This is an operational requirement, not a protocol requirement and therefore the meeting agreed that this is NOT an ENUM requirement. Response Time: 95% within 2 secs. Is that achievable? Question regarding what is the DNS packet loss and will this work with the proposal? There is a 20% or greater chance of exceeding this requirement. Christian noting that we would exceed this requirement very often. Should this be an operations requirement? Scott Bradner suggesting that we include the PSTN requirement as a piece of information. Much of that information is contained in a variety of SIGTRAN documents. No specific ID were mentioned. Proposal to add notes regarding what the PSTN requirements are for both reliability and response time. CONCLUSION: It was agreed that this is NOT a hard and fast ENUM requirement. Corporate Dialing Plans: Use of ENUM for private dialing plans may be outside of the scope of this work. These are not e.164 numbers, which is the scope of ENUM. CONCLUSION: It was agreed that this is NOT an ENUM requirement. However Richard Shockey noted that there was nothing precluding the use ENUM by private dialing plans. Capabilities Discovery: ENUM identifies services and a service is something that can be identified by a URL. ENUM will not negotiate services. RESCAP will identify the capability. CONCLUSION: The meeting agreed that this is NOT an ENUM requirement. More discussion in the general discussions below. 3. ENUM Operations issues... Greg Vaudreuil A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-00.txt Issues: Recommended TTL: Need clarification between services needing slow updates (15 minutes) and those needing fast updates (out of scope for ENUM) CONCLUSION: Do NOT add text on how to change TTLs. Number portability: How repointed DNAME, CNAME, etc, or changing the provider of a particular service via NAPTR, should be reflected. Proposal to identify in some internationally generic manner. Need to continue this discussion on the mailing list. Good idea to distinguish these 2 cases in the document. There is an issue of control as well as portability in this discussion. Change Propagation Rate: Is 15 minutes a worldwide time frame? No complaints.CONCLUSION: Leave as is. 4. Service Principles when Public Circuit Switched International Telecommunication Networks Interwork with IP-based Networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-itut-e370-00.txt Steve Lind is the rapporteur for Question 10 in ITU-T Study Group2. This was developed by Q10/2 and is planned for approval at the January 2001 meeting of SG2. Proposal is to further the collaborative effort between SG2 and IETF. From the draft document: This document describes the current thinking of the collaborators of ITU-T Question 10/2, "Management and development of PSTN-based telecommunication services," about service principles when public circuit switched international telecommunication networks interwork with IP-based networks. This document contains most of the text (there has been some rearrangement of the text) from draft new Recommendation E.370 [1], starting from section 3 of this Internet Draft, which was determined to be stable at the March 2000 meeting of Study Group 2. It may be approved by the members of the ITU, subject to written comments received from those members, at a meeting of the Study Group (or its successor) in early 2001 (provisionally 23-26 January 2001). It is hoped that this document will further the collaborative efforts between Study Group 2 and the various working groups of the IETF. Discussed possible service scenarios that utilize IP networks. Looking for input from IETF WGs. Post comments to the itu+ietf@ietf.org mailing list. 5. ENUM Call Flows for VoIP Interworking . Steve Lind Reference: http://www.ietf.org/internet-drafts/draft-lind-enum-callflows-00.txt Genesis of this document was the IP Telecoms workshop held in January 2000, in Geneva, Switzerland. The issues identified within this document include: - identification of freephone service providers within DNS, - identification of Gateways using location routing numbers (or potentially by other means), - source of local number portability information for queries from IP-based infrastructure, - mechanisms for transport of LNP information to the final switching destination, - provision and maintenance of information in DNS. The document proposed that while some of these issues may be outside the scope of ENUM, they nevertheless have to be addressed if IP-based communication will be viable. Between the IETF and the ITU, core competencies exist to address these issues; continued cooperation will be beneficial. It has been proposed to submit the results of the collaborative effort as an ENUM WG RFC. 6. ENUM in Signaling Transport: John Loughney A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-loughney-enum-sigtran-01.txt This document describes the use of ENUM Services by SIGTRAN Protocols. A question was raised regarding how do we handle address resolution issues? Christian Huitema arguing against the proposal in the document. Suggesting that Gateway discovery protocol developed by IPTel would be more appropriate than the ENUM proposal. 7. ENUM Usage in Cellular Roaming John Loughney A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-loughney-enum-roaming-00.txt This document is a first draft that proposes a new service, called 'roam' to enable roaming in cellular systems (2G, 3G), supported by using the ENUM solution for DNS resolution of E.164 numbers. By querying DNS for the roaming service entity for the particular E.164 number, DNS can return the location of the network element that supports the cellular roaming services (i.e. - HLR, VLR, AAA server). Scott Petrack noted that the application of ENUM as a solution should result in a URL. No decision by the group. 8. ITU Number Portability Andy Gallant A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164s2-np-00.txt This document contains a text version of the Number Portability Supplement (11/98) to ITU-T Recommendation E.164 (The international public telecommunication numbering plan, 05/97) [2]. That Supplement [3] defined terminology for number portability within an E.164 numbering scheme; identified formats, call flows, architectures, and routing approaches for some methods; and gave examples of some processes needed to implement number portability. This document was presented for information to the ENUM WG. 9. ITU e164 work plan Andy Gallant A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gallant-enum-e164-snap-00.txt The presentation of this material was made by Andy Gallant. This is an unofficial snapshot of some of the E.164 work. It includes some information on E.164-series ITU-T Recommendations, "country code" assignments, and future pending decisions, meetings, and work. There was a question regarding the use of subaddressing numbers in ISDN numbering that may come into play with VoiceMail services. The answer was not clear and interested parties need to follow-up on this question after the meeting. The presentation provided a valuable insight into the definition and operation of the Numbering work within the ITU-T. Andy also provided an identification of the ITU documents of interest to the ENUM group. Scott Bradner noted that the ITU and the Internet Society are members of each other's organization and can send reps to each other's meetings. Question from the floor: Is there a relationship between the hierarchical nature of E.164 and DNS? Yes, at the highest level they are administered by a central body with the lower level being administered locally. 10. Future Directions and revised milestones -Sept 2000 ENUM Requirements to proposed standard? Consensus ..yes. -Nov 2000 ENUM Operations to proposed standard? Scott noted that operations documents are not normally an IETF STD. Therefore, will propose as a BCP. Development Questions - Chicken / Egg discussion related to requirements, protocol and operations documents. -Re charter or go dormant?? CONSENSUS : This is a question the WG will have to address once it has delivered its initial products. Also, a need was expressed for some type of transition scheme from Non ENUM to ENUM usage. 11. Richard Shockey noted that he had posted a ENUM FAQ - At the request of the AD's this document will eventually be segmented into Protocol questions ..which could move forward to Informational RRC as a WG product vs Operations and Administrative issues which would be a personal ID. 12. General discussion... Chairs reopen the question of NAPTR use. Are we making a requirement that ENUM use NAPTR record types only? The chairs state categorically that ...Yes, that is what is in the e.164 dns draft that is in IESG last call status. There are other ways to use different schemes than NAPTR and they could be identified in an Informational RFC but ENUM is about the use of NAPTR records. Question ..does NAPTR Queries return all records? Answer : Yes there is no selective query. Discussion follows that it MAY require the opening of a TCP connection if there are too many RR's. It is noted that NAPTR is new and untested but offers considerable power. Greg Vaudreuil notes that there is still objection to this requirement. Chairs call for a show of hands... Question... Shall ENUM use NAPTR record types only? CONSENSUS BY SHOW OF HANDS: Yes. - Chicken / Egg Problem : How to get end users to use ENUM. Need service providers and some work to get this setup in numbering schemes. May want to have a BoF at the next IETF to discuss the deployment issues. - Movement of the .int to the .arpa domain discussion. Scott Bradner explained why this move was made. .arpa was selected by the IAB for Internet Infrastructure issues. It is controlled by IANA which is a part of ICANN but under the direction of the IAB. The IAB has made a formal statement about .arpa and its uses. - When a client gets a list of URLs for a service (ordered list). Records will be fetched in the same order, which may not be proper for competitive situations. Suggestion to add a RESCAP URL to allow for additional information to be retrieved related to that original record. Will a NAPTR resource field contain a RESCAP to define what is in the location that was identified? Will take this to the ENUM mail list for further discussion. - for section 4 of the protocol document discusses IANA Considerations. Was an Expert chosen? The expert has NOT been chosen yet to deal with the delegation of names in the e164.arpa zone. - Use of ENUM in the Cellular community. E164 #s are dynamically changing. Do not know immediately that a number is a cellular #, by the number itself. Scott Petrak ENUM is not an answer to cellular roaming issues. - QoS issues in ENUM need to be addressed. May be a topic for a potential BoF at the next meeting. - Applications issues and basic guidelines for enum will be of substantial value. Scott Petrak noted once again that the ENUM process is Telephone Number IN ...URL / URI out. - Richard Shockey requested a show of hands of how many individuals in the meeting were planing products and/or services based on ENUM. Substantial 50+ hands raised. Meeting Concluded. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Oct 2 09:00:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07259 for ; Mon, 2 Oct 2000 09:00:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21005; Mon, 2 Oct 2000 09:00:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20958 for ; Mon, 2 Oct 2000 09:00:05 -0400 (EDT) Received: from cqmx.corp.comsat.com (cqmx.corp.comsat.com [134.133.184.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07245 for ; Mon, 2 Oct 2000 09:00:02 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 2 Oct 2000 08:58:44 -0400 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0017E213; Mon, 2 Oct 2000 09:03:36 -0400 Mime-Version: 1.0 Date: Mon, 2 Oct 2000 08:58:47 -0400 Message-ID: <0017E213.C22277@comsat.com> To: enum@ietf.org, Richard Shockey Subject: Re: [Enum] Yes ...the Meeting Minutes from ENUM WG at IETF 4 Content-Type: multipart/mixed; boundary="IMA.Boundary.6181940790" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --IMA.Boundary.6181940790 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Suggestion/Request: Could this report have another section called "Updates since IETF48" or equivalent? If yes, then please add these two items: 1. Core Protocol Document Status The status of "E.164 number and DNS" changed to: - Proposed Standard (IETF announce, Tue, 15 Aug 2000). - RFC 2916 (IETF announce, Tue, 26 Sep 2000). 2. ISDN Subaddressing (ENUM report, section 9) ISDN subaddresses are not part of E.164 numbers (ENUM archive, Wed, 23 Aug 2000). Related report excerpts are below. Thanks. -Andy ______________________________ Reply Separator _________________________________ Subject: [Enum] Yes ...the Meeting Minutes from ENUM WG at IETF 48 Pi Author: Richard Shockey at INTERNET-IMA Date: 10/1/00 8:54 PM Yes ..I know this is unusually late and there is no excuse for it and my sincerest apologies to Jay Hilton and other who have correctly complained about this...however if we can review this and people will send me corrections or clarifications I will process them and get this off ASAP. This will not happen again ... if Jay will volunteer to do this again in San Diego ..he will have document control only subject to the final approval of the chair(s). :-) Telephone Number Mapping WG (ENUM) IETF 48 Pittsburgh Tuesday, August 1 from 0900-1130 ============================= CHAIR: Richard Shockey (rshockey@ix.netcom.com) Scott Petrak (scott.petrack@metatel.com) Scribe: Jay Hilton ( jhilton@telcordia.com) AGENDA: Meeting Agenda 1. Agenda Bashing - 5 min 2. Document Status: Chair 2 min Core Protocol e164-DNS submitted to IESG Last Call draft-ietf-enum-e164-dns-01.txt Requirements on hold before submitted to IESG Last Call draft-ietf-enum-rqmts-01.txt 3. ENUM Open Requirements issues - Greg Vaudreuil x min 3a. ENUM Operations issues... Greg Vaudreuil 20 min draft-ietf-enum-operation-00.txt 4. ITU e164 workplan Andy Galant 10min draft-gallant-enum-e164-snap-00.txt 5. Service Principles when Public Circuit Switched International Telecommunication Networks Interworking with IP-based Networks - Steve Lind 15 min draft-lind-itut-e370-00.txt 6. ENUM Call Flows for VoIP Interworking . Steve Lind 15 min draft-lind-enum-callflows-00.txt 7. ENUM in Signaling Transport: 20 min John Loughney draft-loughney-enum-sigtran-00.txt 8. ENUM Usage in Cellular Roaming John Loughney 10 min draft-loughney-enum-roaming-00.txt Future Directions and revised milestones 10m DELETE: FAQ - Operations vs Out of Scope issues GENERAL DISCUSSION ########################## [snip] 2. Document Status: Chair began a discussion of current Document Status. 2.1 Core ENUM Protocol Document - e164-DNS submitted to IESG Last Call A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-01.txt This is the ENUM protocol document. It has been submitted for IESG LAST CALL. Some minor comments received (editorial and suggestions for adding another example which clarify differences between delegation of name servers in DNS and then further explanations of telephony applications). These will be incorporated in the document. [snip] 9. ITU e164 work plan Andy Gallant A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gallant-enum-e164-snap-00.txt The presentation of this material was made by Andy Gallant. This is an unofficial snapshot of some of the E.164 work. It includes some information on E.164-series ITU-T Recommendations, "country code" assignments, and future pending decisions, meetings, and work. There was a question regarding the use of subaddressing numbers in ISDN numbering that may come into play with VoiceMail services. The answer was not clear and interested parties need to follow-up on this question after the meeting. [snip] [eom] --IMA.Boundary.6181940790 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from neal.ctd.comsat.com ([134.133.40.21]) by cqgate5.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 0017D26B; Sun, 1 Oct 2000 21:01:22 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by neal.ctd.comsat.com with smtp (Exim 2.12 #8) id 13fttA-0003o4-00 for andrew.gallant@comsat.com; Sun, 1 Oct 2000 20:55:28 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06461; Sun, 1 Oct 2000 20:55:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06432 for ; Sun, 1 Oct 2000 20:55:06 -0400 (EDT) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14030 for ; Sun, 1 Oct 2000 20:55:03 -0400 (EDT) Received: from computer.ix.netcom.com (user-2iveois.dialup.mindspring.com [165.247.98.92]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA16266 for ; Sun, 1 Oct 2000 20:55:00 -0400 (EDT) Message-Id: <5.0.0.25.2.20001001165856.027ab0f0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 01 Oct 2000 20:54:32 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA06433 Subject: [Enum] Yes ...the Meeting Minutes from ENUM WG at IETF 48 Pittsburgh Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id UAA06461 --IMA.Boundary.6181940790-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Oct 2 09:23:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07612 for ; Mon, 2 Oct 2000 09:23:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21459; Mon, 2 Oct 2000 09:21:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21426 for ; Mon, 2 Oct 2000 09:21:32 -0400 (EDT) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07588 for ; Mon, 2 Oct 2000 09:21:25 -0400 (EDT) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 97B2E149; Mon, 2 Oct 2000 15:20:55 +0200 (MET DST) Received: from [10.0.0.2] ([171.70.221.21]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06587; Mon, 2 Oct 2000 15:20:47 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <0017E213.C22277@comsat.com> References: <0017E213.C22277@comsat.com> Date: Mon, 2 Oct 2000 06:10:57 -0700 To: Andrew.Gallant@comsat.com, enum@ietf.org, Richard Shockey From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] Yes ...the Meeting Minutes from ENUM WG at IETF 4 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08.58 -0400 00-10-02, Andrew.Gallant@comsat.com wrote: > 1. Core Protocol Document Status > > The status of "E.164 number and DNS" changed to: > > - Proposed Standard (IETF announce, Tue, 15 Aug 2000). > > - RFC 2916 (IETF announce, Tue, 26 Sep 2000). This is only one thing, not two (but two events). The first is the announcement of the decision by the IESG, and the second is a notice from the RFC-Editor that the document now exists. Both events always have to happen before the document is considered done. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 3 08:50:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08818 for ; Tue, 3 Oct 2000 08:50:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18823; Tue, 3 Oct 2000 08:48:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18792 for ; Tue, 3 Oct 2000 08:48:41 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08761 for ; Tue, 3 Oct 2000 08:48:40 -0400 (EDT) Received: from computer.ix.netcom.com (user-2iveobs.dialup.mindspring.com [165.247.97.124]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id IAA00434 for ; Tue, 3 Oct 2000 08:48:37 -0400 (EDT) Message-Id: <5.0.0.25.2.20001003084922.02aaa130@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Oct 2000 08:50:05 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FYI - Article on ENUM in Network World Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org IETF spec could propel Internet telephony By CAROLYN DUFFY MARSAN Network World, 10/02/00 Think of it as directory assistance for the 'Net. The Internet engineering community has developed a technology that lets you type a telephone number into your Web browser and find a corresponding URL, e-mail address or IP address. Called Enum, the new technology integrates the world's telephone numbering plan with the Internet's Domain Name System (DNS) to power a new class of online telephony services. The Internet Engineering Task Force (IETF) published its Enum specification as a proposed standard in September. Last week, Telcordia Technologies and VeriSign announced the first large-scale test of Enum services. And network vendors such as Cisco, Lucent and Nortel Networks are expected to ship Enum-compliant products next year. Why all the buzz about Enum? Because it's considered a key enabling technology for the anticipated convergence of the public switched telephone network and the Internet. For corporate network managers, Enum offers the potential for each employee to have a single contact for communications devices, including PCs, fax machines, handheld computers, cell phones and pagers. "Enum may enable the corporate phone group to manage the mapping between phone numbers and per-user lists of URLs, where the URLs tell the caller how to contact the callee via phone, e-mail, fax, etc.," says Scott Bradner, director of the IETF's transport area. "Enum puts this under the control of the corporate phone person, not the phone company." Enum is a simple service that functions like a large database. When an end user types a telephone number into an Enum-enabled application, he pulls up what's called a Naming Authority Pointer record that lists all the resources associated with that number, including the domain name. Enum doesn't change the international telephone numbering plan - which uses globally unique E.164 numbers - or how individual countries with the oversight of the International Telecommunication Union administer these numbers. Instead, Enum lets an end user or application see what Internet resources are available for a particular telephone number. Enum is designed for use in the Internet and in private telephone numbering systems and IP networks. On the Internet, businesses and consumers will have to pay to register their phone numbers for Enum services. The businesses and consumers can then specify their preferences for receiving incoming messages to that number, whether as live calls, voice mails, e-mails or faxes. VeriSign sees a potential opportunity to serve as the central registry for Enum, says Pat Conley, a business development executive. That's why VeriSign and Telcordia are hosting a free test bed for Enum developers that will run for six months starting in December. "There are 250 million telephones in the U.S. If 1% of those numbers were registered as Enum records, that would be 2.5 million registrations," Conley says. "We think [Enum] could be a big opportunity around the globe." Enum developers say the technology will be useful in an array of corporate applications, including e-mail, instant messaging and voice-over-IP services. "Enum would be supported in Web browsers, e-mail clients and voice mail systems for unified messaging scenarios," says Patrik Faltstrom, author of the Enum specification and a Cisco engineer. "You could have a system that, at the voice prompt, records a message and sends it on as e-mail." In conjunction with another IETF protocol - Voice Profile for Internet Messaging - Enum would let carrier and enterprise voice mail servers locate each other over the 'Net and exchange messages. Enum also would let Internet-aware fax machines send documents to each other and to unified messaging systems. But Enum shows the most promise in making it simple to place telephone calls over the Internet. "What Enum does is allow [voice-over-IP] proxies and gatekeepers to find each other with no other information than the phone number," says Richard Shockey, co-chair of the IETF's Telephone Number Mapping group and a senior technical industry liaison with NeuStar, the North American telephone numbering authority. "That's always been the biggest problem in [voice-over-IP] services." This innovation promises big savings for corporations, which typically spend 40% of their long-distance bills on internal communications, Shockey says. "Voice over IP. Universal messaging. Fax. These are major enterprise applications that can be enabled more efficiently over IP networks vs. switched networks," Shockey adds. "Enum leverages the enormous investment that corporations have made in their IP backbones and VPNs." One application that already supports Enum is Bind 9, the latest version of the open source software that powers most DNS servers. Bind 9 supports all the resource record types required by Enum, says David Conrad, chief technology officer at Nominum, which wrote Bind 9. Although the Enum protocol is considered solid, it faces a slew of administrative and regulatory hurdles before it can be deployed in the U.S. One challenge was resolved one week ago, when the Internet Assigned Numbers Authority set aside a new domain - E164.arpa - for the storage of E.164 numbers. The next question is: Which federal agency will oversee Enum registrations? Telephone numbering administration is handled by the Federal Communications Commission, while the Department of Commerce oversees DNS. Some regulatory agency will need to oversee Enum subdelegations. Another sticky issue is the ownership and portability of Enum registrations. Businesses and consumers don't own their telephone numbers, but they do own their domain names and can move them from one ISP to another. "The technology is pretty much there. It's just a matter of setting up the administrative infrastructure and procedures you need to make it work," says Penn Pfautz, an AT&T manager and a participant of the IETF Enum effort. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 3 10:33:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12610 for ; Tue, 3 Oct 2000 10:33:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20788; Tue, 3 Oct 2000 10:27:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20760 for ; Tue, 3 Oct 2000 10:27:15 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12512 for ; Tue, 3 Oct 2000 10:27:14 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA16268 for ; Tue, 3 Oct 2000 09:27:14 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id JAA01053 for ; Tue, 3 Oct 2000 09:27:14 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 3 Oct 2000 09:26:59 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 10:26:58 -0400 Message-Id: <4102273CEB77D211869200805FE6F5939EBEBE@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] FYI - Article on ENUM in Network World Date: Tue, 3 Oct 2000 10:26:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Neat article. One question about portability of phone numbers: Is there a long term plan in the US for how these numbers would be formatted? My understanding is that as of now, portable numbers in the US plan look just like fixed numbers. This has the drawback of making them less than totally portable. Is there some plan to change the scheme to a more geographically agnostic-looking number? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Tuesday, October 03, 2000 8:50 AM > To: enum@ietf.org > Subject: [Enum] FYI - Article on ENUM in Network World > > > > IETF spec could propel Internet telephony > > By CAROLYN DUFFY MARSAN > Network World, 10/02/00 > > Think of it as directory assistance for > the 'Net. > > The Internet engineering community > has developed a technology that lets > you type a telephone number into your > Web browser and find a corresponding > URL, e-mail address or IP address. > Called Enum, the new technology > integrates the world's telephone > numbering plan with the Internet's > Domain Name System (DNS) to power > a new class of online telephony > services. > > The Internet Engineering Task Force > (IETF) published its Enum specification > as a proposed standard in September. > Last week, Telcordia Technologies and > VeriSign announced the first > large-scale test of Enum services. And > network vendors such as Cisco, > Lucent and Nortel Networks are > expected to ship Enum-compliant > products next year. > > Why all the buzz about Enum? Because > it's considered a key enabling > technology for the anticipated > convergence of the public switched > telephone network and the Internet. > > For corporate network managers, > Enum offers the potential for each > employee to have a single contact for > communications devices, including > PCs, fax machines, handheld > computers, cell phones and pagers. > > "Enum may enable the corporate > phone group to manage the mapping > between phone numbers and per-user > lists of URLs, where the URLs tell the > caller how to contact the callee via > phone, e-mail, fax, etc.," says Scott > Bradner, director of the IETF's > transport area. "Enum puts this under > the control of the corporate phone > person, not the phone company." > > Enum is a simple service that > functions like a large database. When > an end user types a telephone number > into an Enum-enabled application, he > pulls up what's called a Naming > Authority Pointer record that lists all > the resources associated with that > number, including the domain name. > > Enum doesn't change the international > telephone numbering plan - which uses > globally unique E.164 numbers - or how > individual countries with the oversight > of the International > Telecommunication Union administer > these numbers. Instead, Enum lets an > end user or application see what > Internet resources are available for a > particular telephone number. Enum is > designed for use in the Internet and in > private telephone numbering systems > and IP networks. > > On the Internet, businesses and > consumers will have to pay to register > their phone numbers for Enum > services. The businesses and > consumers can then specify their > preferences for receiving incoming > messages to that number, whether as > live calls, voice mails, e-mails or faxes. > > VeriSign sees a potential opportunity > to serve as the central registry for > Enum, says Pat Conley, a business > development executive. > > That's why VeriSign and Telcordia are > hosting a free test bed for Enum > developers that will run for six months > starting in December. > > "There are 250 million telephones in > the U.S. If 1% of those numbers were > registered as Enum records, that > would be 2.5 million registrations," > Conley says. "We think [Enum] could > be a big opportunity around the globe." > > Enum developers say the technology > will be useful in an array of corporate > applications, including e-mail, instant > messaging and voice-over-IP services. > > "Enum would be supported in Web > browsers, e-mail clients and voice mail > systems for unified messaging > scenarios," says Patrik Faltstrom, > author of the Enum specification and a > Cisco engineer. "You could have a > system that, at the voice prompt, > records a message and sends it on as > e-mail." > > In conjunction with another IETF > protocol - Voice Profile for Internet > Messaging - Enum would let carrier > and enterprise voice mail servers > locate each other over the 'Net and > exchange messages. Enum also would > let Internet-aware fax machines send > documents to each other and to > unified messaging systems. > > But Enum shows the most promise in > making it simple to place telephone > calls over the Internet. > > "What Enum does is allow > [voice-over-IP] proxies and > gatekeepers to find each other with no > other information than the phone > number," says Richard Shockey, > co-chair of the IETF's Telephone > Number Mapping group and a senior > technical industry liaison with > NeuStar, the North American > telephone numbering authority. "That's > always been the biggest problem in > [voice-over-IP] services." > > This innovation promises big savings > for corporations, which typically spend > 40% of their long-distance bills on > internal communications, Shockey > says. > > "Voice over IP. Universal messaging. > Fax. These are major enterprise > applications that can be enabled more > efficiently over IP networks vs. > switched networks," Shockey adds. > "Enum leverages the enormous > investment that corporations have > made in their IP backbones and VPNs." > > One application that already supports > Enum is Bind 9, the latest version of > the open source software that powers > most DNS servers. Bind 9 supports all > the resource record types required by > Enum, says David Conrad, chief > technology officer at Nominum, which > wrote Bind 9. > > Although the Enum protocol is > considered solid, it faces a slew of > administrative and regulatory hurdles > before it can be deployed in the U.S. > One challenge was resolved one week > ago, when the Internet Assigned > Numbers Authority set aside a new > domain - E164.arpa - for the storage of > E.164 numbers. > > The next question is: Which federal > agency will oversee Enum > registrations? Telephone numbering > administration is handled by the > Federal Communications Commission, > while the Department of Commerce > oversees DNS. Some regulatory > agency will need to oversee Enum > subdelegations. > > Another sticky issue is the ownership > and portability of Enum registrations. > Businesses and consumers don't own > their telephone numbers, but they do > own their domain names and can move > them from one ISP to another. > > "The technology is pretty much there. > It's just a matter of setting up the > administrative infrastructure and > procedures you need to make it work," > says Penn Pfautz, an AT&T manager > and a participant of the IETF Enum > effort. > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 3 10:35:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12673 for ; Tue, 3 Oct 2000 10:35:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21090; Tue, 3 Oct 2000 10:33:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21061 for ; Tue, 3 Oct 2000 10:33:20 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12609 for ; Tue, 3 Oct 2000 10:33:18 -0400 (EDT) Received: by dnspri.npac.com; id JAA07922; Tue, 3 Oct 2000 09:33:18 -0500 (CDT) Received: from unknown(192.168.20.146) by dnspri.npac.com via smap (V5.0) id xma007877; Tue, 3 Oct 00 09:33:04 -0500 Message-Id: <5.0.0.25.2.20001003103102.0278a790@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Oct 2000 10:35:18 -0400 To: "Manfredi, Albert E" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] FYI - Article on ENUM in Network World In-Reply-To: <4102273CEB77D211869200805FE6F5939EBEBE@xch-phl-01.he.boein g.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:26 AM 10/3/2000 -0400, Manfredi, Albert E wrote: >Neat article. > >One question about portability of phone numbers: > >Is there a long term plan in the US for how these numbers would be >formatted? My understanding is that as of now, portable numbers in the US >plan look just like fixed numbers. This has the drawback of making them less >than totally portable. Is there some plan to change the scheme to a more >geographically agnostic-looking number? > >Bert >albert.e.manfredi@boeing.com Neither the Industry Numbering Council [INC] or the FCC has any plans to permit "geographic portability" in the US ..though it is technically feasible. However service number portability ..from landline to cellular or from cellular to cellular provider has been mandated beginning in 2002. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 3 10:50:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13065 for ; Tue, 3 Oct 2000 10:50:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21560; Tue, 3 Oct 2000 10:48:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21488 for ; Tue, 3 Oct 2000 10:48:30 -0400 (EDT) Received: from netsol-nic-ex04.prod.netsol.com (h17.s238.netsol.com [216.168.238.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12964 for ; Tue, 3 Oct 2000 10:48:29 -0400 (EDT) Received: by netsol-nic-ex04.prod.netsol.com with Internet Mail Service (5.5.2448.0) id ; Tue, 3 Oct 2000 10:48:00 -0400 Message-ID: From: "Conley, Pat" To: enum@ietf.org Subject: RE: [Enum] FYI - Article on ENUM in Network World Date: Tue, 3 Oct 2000 10:47:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org I do not believe there are any real plans in place, but telephone numbers in the US are gradually loosing their geographic meaning... 800 numbers, 500 numbers and over- lapping area codes are adding to this trend. IMHO we will see this trend continue... albeit slowly. pat -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Tuesday, October 03, 2000 10:27 AM To: 'Richard Shockey'; enum@ietf.org Subject: RE: [Enum] FYI - Article on ENUM in Network World Neat article. One question about portability of phone numbers: Is there a long term plan in the US for how these numbers would be formatted? My understanding is that as of now, portable numbers in the US plan look just like fixed numbers. This has the drawback of making them less than totally portable. Is there some plan to change the scheme to a more geographically agnostic-looking number? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Tuesday, October 03, 2000 8:50 AM > To: enum@ietf.org > Subject: [Enum] FYI - Article on ENUM in Network World > > > > IETF spec could propel Internet telephony > > By CAROLYN DUFFY MARSAN > Network World, 10/02/00 > > Think of it as directory assistance for > the 'Net. > > The Internet engineering community > has developed a technology that lets > you type a telephone number into your > Web browser and find a corresponding > URL, e-mail address or IP address. > Called Enum, the new technology > integrates the world's telephone > numbering plan with the Internet's > Domain Name System (DNS) to power > a new class of online telephony > services. > > The Internet Engineering Task Force > (IETF) published its Enum specification > as a proposed standard in September. > Last week, Telcordia Technologies and > VeriSign announced the first > large-scale test of Enum services. And > network vendors such as Cisco, > Lucent and Nortel Networks are > expected to ship Enum-compliant > products next year. > > Why all the buzz about Enum? Because > it's considered a key enabling > technology for the anticipated > convergence of the public switched > telephone network and the Internet. > > For corporate network managers, > Enum offers the potential for each > employee to have a single contact for > communications devices, including > PCs, fax machines, handheld > computers, cell phones and pagers. > > "Enum may enable the corporate > phone group to manage the mapping > between phone numbers and per-user > lists of URLs, where the URLs tell the > caller how to contact the callee via > phone, e-mail, fax, etc.," says Scott > Bradner, director of the IETF's > transport area. "Enum puts this under > the control of the corporate phone > person, not the phone company." > > Enum is a simple service that > functions like a large database. When > an end user types a telephone number > into an Enum-enabled application, he > pulls up what's called a Naming > Authority Pointer record that lists all > the resources associated with that > number, including the domain name. > > Enum doesn't change the international > telephone numbering plan - which uses > globally unique E.164 numbers - or how > individual countries with the oversight > of the International > Telecommunication Union administer > these numbers. Instead, Enum lets an > end user or application see what > Internet resources are available for a > particular telephone number. Enum is > designed for use in the Internet and in > private telephone numbering systems > and IP networks. > > On the Internet, businesses and > consumers will have to pay to register > their phone numbers for Enum > services. The businesses and > consumers can then specify their > preferences for receiving incoming > messages to that number, whether as > live calls, voice mails, e-mails or faxes. > > VeriSign sees a potential opportunity > to serve as the central registry for > Enum, says Pat Conley, a business > development executive. > > That's why VeriSign and Telcordia are > hosting a free test bed for Enum > developers that will run for six months > starting in December. > > "There are 250 million telephones in > the U.S. If 1% of those numbers were > registered as Enum records, that > would be 2.5 million registrations," > Conley says. "We think [Enum] could > be a big opportunity around the globe." > > Enum developers say the technology > will be useful in an array of corporate > applications, including e-mail, instant > messaging and voice-over-IP services. > > "Enum would be supported in Web > browsers, e-mail clients and voice mail > systems for unified messaging > scenarios," says Patrik Faltstrom, > author of the Enum specification and a > Cisco engineer. "You could have a > system that, at the voice prompt, > records a message and sends it on as > e-mail." > > In conjunction with another IETF > protocol - Voice Profile for Internet > Messaging - Enum would let carrier > and enterprise voice mail servers > locate each other over the 'Net and > exchange messages. Enum also would > let Internet-aware fax machines send > documents to each other and to > unified messaging systems. > > But Enum shows the most promise in > making it simple to place telephone > calls over the Internet. > > "What Enum does is allow > [voice-over-IP] proxies and > gatekeepers to find each other with no > other information than the phone > number," says Richard Shockey, > co-chair of the IETF's Telephone > Number Mapping group and a senior > technical industry liaison with > NeuStar, the North American > telephone numbering authority. "That's > always been the biggest problem in > [voice-over-IP] services." > > This innovation promises big savings > for corporations, which typically spend > 40% of their long-distance bills on > internal communications, Shockey > says. > > "Voice over IP. Universal messaging. > Fax. These are major enterprise > applications that can be enabled more > efficiently over IP networks vs. > switched networks," Shockey adds. > "Enum leverages the enormous > investment that corporations have > made in their IP backbones and VPNs." > > One application that already supports > Enum is Bind 9, the latest version of > the open source software that powers > most DNS servers. Bind 9 supports all > the resource record types required by > Enum, says David Conrad, chief > technology officer at Nominum, which > wrote Bind 9. > > Although the Enum protocol is > considered solid, it faces a slew of > administrative and regulatory hurdles > before it can be deployed in the U.S. > One challenge was resolved one week > ago, when the Internet Assigned > Numbers Authority set aside a new > domain - E164.arpa - for the storage of > E.164 numbers. > > The next question is: Which federal > agency will oversee Enum > registrations? Telephone numbering > administration is handled by the > Federal Communications Commission, > while the Department of Commerce > oversees DNS. Some regulatory > agency will need to oversee Enum > subdelegations. > > Another sticky issue is the ownership > and portability of Enum registrations. > Businesses and consumers don't own > their telephone numbers, but they do > own their domain names and can move > them from one ISP to another. > > "The technology is pretty much there. > It's just a matter of setting up the > administrative infrastructure and > procedures you need to make it work," > says Penn Pfautz, an AT&T manager > and a participant of the IETF Enum > effort. > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 3 14:52:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20985 for ; Tue, 3 Oct 2000 14:52:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26523; Tue, 3 Oct 2000 14:50:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26491 for ; Tue, 3 Oct 2000 14:50:25 -0400 (EDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20959 for ; Tue, 3 Oct 2000 14:50:23 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id OAA17653 for ; Tue, 3 Oct 2000 14:41:39 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525696D.0066AD45 ; Tue, 3 Oct 2000 14:41:30 -0400 X-Lotus-FromDomain: TELCORDIA From: "Jay R. Hilton" To: enum@ietf.org Message-ID: <8525696D.0066ACC2.00@notes949.cc.telcordia.com> Date: Tue, 3 Oct 2000 14:40:47 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Enum] ITU-T SG2/Q1 Issues Discussion Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard, Your email regarding "[ENUM] WG Objectives in advance on IETF 49 in San Diego" noted that: >6. In addition it was brought up in the meeting in Pittsburgh that it may >be necessary to put together a BOF in San Diego on Administrative and >Operational issues in ENUM. > >As some of you know there has been substantial activity along those lines >in may forums. There are active discussions with our ITU SG2/Q1 colleagues >on the resolution of several issues and I imagine there will a great deal >to report on. In reference to the discussions in ITU-T SG2/Q1, what is the procedure for establishing an IETF position on these issues? Would it be possible to have discussions on the ENUM list for these issues? This would include listing the known/expected issues and then having a dialog on the ENUM list in preparation for the ITU-T SG2/Q1 meeting. If we can not establish an "IETF" position at least we would have had some preparatory discussions. Thanks in advance, Jay Hilton _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Oct 4 12:37:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25606 for ; Wed, 4 Oct 2000 12:37:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24726; Wed, 4 Oct 2000 12:31:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24698 for ; Wed, 4 Oct 2000 12:31:28 -0400 (EDT) Received: from vesuve.globetrotter.net (vesuve.globetrotter.net [142.169.1.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25276 for ; Wed, 4 Oct 2000 12:31:28 -0400 (EDT) Received: from home.com ([206.162.183.130]) by vesuve.globetrotter.net (8.9.3/8.9.3) with ESMTP id MAA28222 for ; Wed, 4 Oct 2000 12:30:56 -0400 (EDT) Message-ID: <39DB5B75.5E391B6A@home.com> Date: Wed, 04 Oct 2000 12:31:49 -0400 From: Herman Silbiger Reply-To: hsilbiger@ieee.org X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: enum@ietf.org References: <200010041600.MAA23919@optimus.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: ITU-T SG2/Q1 Issues Discussion Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Jay, Richard, That is the procedure that was followed in the Fax WG when issues were to be presented to SG8. The IETF position, which actually went in as an ISOC position, was first agreed on the list. It would then be put in the appropriate format and submitted to the ITU in advance of the deadline. It would be presented at the meeting by the designated IETF/ISOC delegate, whose name would have been submitted ahead of time. In our case Scott Bradner was the official contact person to the ITU. Herman > > Message: 1 > From: "Jay R. Hilton" > To: enum@ietf.org > Date: Tue, 3 Oct 2000 14:40:47 -0400 > Subject: [Enum] ITU-T SG2/Q1 Issues Discussion > > Richard, > > Your email regarding "[ENUM] WG Objectives in advance on IETF 49 in San Diego" > noted that: > > >6. In addition it was brought up in the meeting in Pittsburgh that it may > >be necessary to put together a BOF in San Diego on Administrative and > >Operational issues in ENUM. > > > >As some of you know there has been substantial activity along those lines > >in may forums. There are active discussions with our ITU SG2/Q1 colleagues > >on the resolution of several issues and I imagine there will a great deal > >to report on. > > In reference to the discussions in ITU-T SG2/Q1, what is the procedure for > establishing an IETF position on these issues? Would it be possible to have > discussions on the ENUM list for these issues? This would include listing the > known/expected issues and then having a dialog on the ENUM list in preparation > for the ITU-T SG2/Q1 meeting. > > If we can not establish an "IETF" position at least we would have had some > preparatory discussions. > > Thanks in advance, > > Jay Hilton > > --__--__-- > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum > > End of enum Digest _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Oct 4 15:05:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29213 for ; Wed, 4 Oct 2000 15:05:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27420; Wed, 4 Oct 2000 15:03:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27388 for ; Wed, 4 Oct 2000 15:03:07 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29179 for ; Wed, 4 Oct 2000 15:02:15 -0400 (EDT) Received: by dnspri.npac.com; id OAA26760; Wed, 4 Oct 2000 14:02:14 -0500 (CDT) Received: from unknown(192.168.20.146) by dnspri.npac.com via smap (V5.0) id xmac25900; Wed, 4 Oct 00 14:01:26 -0500 Message-Id: <5.0.0.25.2.20001004142200.02bd5b90@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 04 Oct 2000 14:26:35 -0400 To: "Jay R. Hilton" , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion In-Reply-To: <8525696D.0066ACC2.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 02:40 PM 10/3/2000 -0400, Jay R. Hilton wrote: >Richard, > >Your email regarding "[ENUM] WG Objectives in advance on IETF 49 in San Diego" >noted that: > > >6. In addition it was brought up in the meeting in Pittsburgh that it may > >be necessary to put together a BOF in San Diego on Administrative and > >Operational issues in ENUM. > > > >As some of you know there has been substantial activity along those lines > >in may forums. There are active discussions with our ITU SG2/Q1 colleagues > >on the resolution of several issues and I imagine there will a great deal > >to report on. > >In reference to the discussions in ITU-T SG2/Q1, what is the procedure for >establishing an IETF position on these issues? Develop an ID... for discussion on this list.... > Would it be possible to have >discussions on the ENUM list for these issues? Of course... > This would include listing the >known/expected issues and then having a dialog on the ENUM list in preparation >for the ITU-T SG2/Q1 meeting. Excellent... >If we can not establish an "IETF" position at least we would have had some >preparatory discussions. I totally agree... >Thanks in advance, > >Jay Hilton Herman Silbiger is correct here .. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 09:46:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28963 for ; Thu, 5 Oct 2000 09:46:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20979; Thu, 5 Oct 2000 09:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20948 for ; Thu, 5 Oct 2000 09:44:29 -0400 (EDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28913 for ; Thu, 5 Oct 2000 09:44:27 -0400 (EDT) Received: from computer.ix.netcom.com (tfx-us15-130.ix.netcom.com [207.94.236.130]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id JAA30819 for ; Thu, 5 Oct 2000 09:44:24 -0400 (EDT) Message-Id: <5.0.0.25.2.20001005094423.034100c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Oct 2000 09:46:13 -0400 To: enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > >In reference to the discussions in ITU-T SG2/Q1, what is the procedure for >establishing an IETF position on these issues? Would it be possible to have >discussions on the ENUM list for these issues? This would include listing the >known/expected issues and then having a dialog on the ENUM list in preparation >for the ITU-T SG2/Q1 meeting. Jay and the list as a whole ...as a follow up to your suggestions you might not be aware that the ITU has put up a web site for ENUM info. http://www.itu.int/infocom/enum/ I'm thinking ..if there is no objection from everyone I have all of the materials from the Pittsburgh meeting etc PPT files ... If Bob would be interested we could have them all posted there for the benefit of our ITU colleagues etc. Now that would be a new spin on things .. the unofficial home page of a IETF WG would be hosted by the ITU...humm.. :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 10:40:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29966 for ; Thu, 5 Oct 2000 10:40:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21861; Thu, 5 Oct 2000 10:39:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21832 for ; Thu, 5 Oct 2000 10:39:24 -0400 (EDT) Received: from neo.it.comsat.com (neo.it.comsat.com [134.133.253.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29944 for ; Thu, 5 Oct 2000 10:39:03 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com (cqnt5.cmc.comsat.com [134.133.162.20]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e95EWuU03569; Thu, 5 Oct 2000 10:32:56 -0400 (EDT) Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 00189F44; Thu, 5 Oct 2000 10:42:44 -0400 Mime-Version: 1.0 Date: Thu, 5 Oct 2000 10:32:53 -0400 Message-ID: <00189F44.C22277@comsat.com> To: enum@ietf.org, Richard Shockey Subject: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Content-Type: multipart/mixed; boundary="IMA.Boundary.4696570790" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --IMA.Boundary.4696570790 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Some related(?) thoughts: 1. Don't know about "positions" but there is a delayed (305) to start discussions on issues, processes, and assessments. 2. Would be good to agree on a nearly normative site where a list of pointers to relevant docs can be maintained and kept current. 3. Would be nice to try to coordinate presentations, e.g., for mutual education, on basic frameworks/architectures. (Note to self: get back to work on same!) -Andy PS: The deadline for delayeds to be received by TSB is Oct 9. However, I'm sure that WP1/2 management can authorize TDs and/or working documents after that date (as appropriate, of course). ______________________________ Reply Separator _________________________________ Subject: Re: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Author: Richard Shockey at INTERNET-IMA Date: 10/5/00 9:46 AM > > >In reference to the discussions in ITU-T SG2/Q1, what is the procedure for >establishing an IETF position on these issues? Would it be possible to have >discussions on the ENUM list for these issues? This would include listing the >known/expected issues and then having a dialog on the ENUM list in preparation >for the ITU-T SG2/Q1 meeting. Jay and the list as a whole ...as a follow up to your suggestions you might not be aware that the ITU has put up a web site for ENUM info. http://www.itu.int/infocom/enum/ I'm thinking ..if there is no objection from everyone I have all of the materials from the Pittsburgh meeting etc PPT files ... If Bob would be interested we could have them all posted there for the benefit of our ITU colleagues etc. Now that would be a new spin on things .. the unofficial home page of a IETF WG would be hosted by the ITU...humm.. :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 314.503.0640 Fax to EMail 815.333.1237 (Preferred for Fax) DC Number 202.533.2811 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum --IMA.Boundary.4696570790 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from neal.ctd.comsat.com ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 00146CFC; Thu, 5 Oct 2000 09:53:20 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by neal.ctd.comsat.com with smtp (Exim 2.12 #8) id 13hBKi-0003DT-00 for andrew.gallant@comsat.com; Thu, 5 Oct 2000 09:45:12 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20979; Thu, 5 Oct 2000 09:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20948 for ; Thu, 5 Oct 2000 09:44:29 -0400 (EDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28913 for ; Thu, 5 Oct 2000 09:44:27 -0400 (EDT) Received: from computer.ix.netcom.com (tfx-us15-130.ix.netcom.com [207.94.236.130]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id JAA30819 for ; Thu, 5 Oct 2000 09:44:24 -0400 (EDT) Message-Id: <5.0.0.25.2.20001005094423.034100c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 05 Oct 2000 09:46:13 -0400 To: enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --IMA.Boundary.4696570790-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 10:41:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00013 for ; Thu, 5 Oct 2000 10:41:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21916; Thu, 5 Oct 2000 10:40:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21887 for ; Thu, 5 Oct 2000 10:40:11 -0400 (EDT) Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29960 for ; Thu, 5 Oct 2000 10:40:08 -0400 (EDT) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:35:08 +0200 Message-ID: From: "Shaw, Robert" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Date: Thu, 5 Oct 2000 16:39:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > I'm thinking ..if there is no objection from everyone I have > all of the materials from the Pittsburgh meeting etc PPT files ... > If Bob would be interested we could have them all posted there for the > benefit of our ITU colleagues etc. Yes. That'd be helpful in the run-up to the SG2 Berlin meeting as long as they're info-orientated and not vendor pitches. thanks, Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 10:52:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00278 for ; Thu, 5 Oct 2000 10:52:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22238; Thu, 5 Oct 2000 10:50:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22208 for ; Thu, 5 Oct 2000 10:50:49 -0400 (EDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00254 for ; Thu, 5 Oct 2000 10:50:41 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA22546; Thu, 5 Oct 2000 10:50:03 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA02014; Thu, 5 Oct 2000 10:48:36 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 10:49:58 -0400 Message-ID: From: "Lind, Steven D, ALCOO" To: "'Andrew.Gallant@comsat.com'" , enum@ietf.org, Richard Shockey Subject: RE: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Date: Thu, 5 Oct 2000 10:49:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org My comments below. Steve --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 web: sdlind.ims.att.com --------------------------------------------------------------- > -----Original Message----- > From: Andrew.Gallant@comsat.com [SMTP:Andrew.Gallant@comsat.com] > Sent: Thursday, October 05, 2000 10:33 AM > To: enum@ietf.org; Richard Shockey > Subject: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion > > Some related(?) thoughts: > > 1. Don't know about "positions" but there is a delayed (305) to > start > discussions on issues, processes, and assessments. > > 2. Would be good to agree on a nearly normative site where a list of > > pointers to relevant docs can be maintained and kept current. [Lind, Steven, ALINT] Recognizing that some documents may pertain to ITU-only issues, some to IETF-only issues, and some to issues being worked jointly. > 3. Would be nice to try to coordinate presentations, e.g., for > mutual > education, on basic frameworks/architectures. (Note to self: get > back to work on same!) [Lind, Steven, ALINT] Recognizing the working procedures that exist in the ITU, sources of any documents must be identified and any necessary "internal consensus" reached before they can be considered at the Working Party meetings. > -Andy > > PS: The deadline for delayeds to be received by TSB is Oct 9. > However, I'm sure that WP1/2 management can authorize TDs and/or > working documents after that date (as appropriate, of course). [Lind, > Steven, ALINT] I don't think we want to repeat the problems that UPT had > from the appearance of "stealth contributions" showing up during the > meetings. > > ______________________________ Reply Separator > _________________________________ > Subject: Re: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion > Author: Richard Shockey at INTERNET-IMA > Date: 10/5/00 9:46 AM > > > > > > > > >In reference to the discussions in ITU-T SG2/Q1, what is the procedure > for > >establishing an IETF position on these issues? Would it be possible to > have > >discussions on the ENUM list for these issues? This would include > listing the > >known/expected issues and then having a dialog on the ENUM list in > preparation > >for the ITU-T SG2/Q1 meeting. > > Jay and the list as a whole ...as a follow up to your suggestions you > might > not be aware that the ITU has put up a web site for ENUM info. > > http://www.itu.int/infocom/enum/ > > I'm thinking ..if there is no objection from everyone I have all of the > materials from the Pittsburgh meeting etc PPT files ... If Bob would be > interested we could have them all posted there for the benefit of our ITU > colleagues etc. > > Now that would be a new spin on things .. the unofficial home page of a > IETF WG would be hosted by the ITU...humm.. :-) > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey > Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W. > Suite 550 > Washington DC. 20005 > Voice 314.503.0640 > Fax to EMail 815.333.1237 (Preferred for Fax) > DC Number 202.533.2811 > INTERNET Mail & IFAX : rich.shockey@neustar.com > or rshockey@ix.netcom.com > http://www.neustar.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum << File: cc:Mail note part >> _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 11:15:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00752 for ; Thu, 5 Oct 2000 11:15:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22760; Thu, 5 Oct 2000 11:14:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22733 for ; Thu, 5 Oct 2000 11:14:06 -0400 (EDT) Received: from neo.it.comsat.com (neo.it.comsat.com [134.133.253.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00724 for ; Thu, 5 Oct 2000 11:14:05 -0400 (EDT) From: Andrew.Gallant@comsat.com Received: from cqgate5.cmc.comsat.com (cqnt5.cmc.comsat.com [134.133.162.20]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e95F7wU03992; Thu, 5 Oct 2000 11:07:58 -0400 (EDT) Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0018A145; Thu, 5 Oct 2000 11:17:46 -0400 Mime-Version: 1.0 Date: Thu, 5 Oct 2000 11:12:25 -0400 Message-ID: <0018A145.C22277@comsat.com> To: enum@ietf.org, Richard Shockey , "Lind; Steven D; ALCOO" Subject: Re[4]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Content-Type: multipart/mixed; boundary="IMA.Boundary.6609570790" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --IMA.Boundary.6609570790 Content-Type: text/plain; charset="US-ASCII" Content-Description: cc:Mail note part Content-Transfer-Encoding: 7bit Steve et al, Yes. Totally agree (implied by use of "appropriate"). We need to keep in mind where formalities apply and where they don't. Re formality, I agree with you about "stealth contributions" (since I and others have been on the receiving end at times ). Re informality, evening info sessions have been, well, informative. Conclusion: both are useful. Note that Jay's original question about "an IETF position" is a reminder of the challenge we all face - to progress work and respect the processes of both IETF and ITU. -Andy ______________________________ Reply Separator _________________________________ Subject: RE: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Author: "Lind; Steven D; ALCOO" at INTERNET-IMA Date: 10/5/00 10:49 AM My comments below. Steve --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 web: sdlind.ims.att.com --------------------------------------------------------------- > -----Original Message----- > From: Andrew.Gallant@comsat.com [SMTP:Andrew.Gallant@comsat.com] > Sent: Thursday, October 05, 2000 10:33 AM > To: enum@ietf.org; Richard Shockey > Subject: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion > > Some related(?) thoughts: > > 1. Don't know about "positions" but there is a delayed (305) to > start > discussions on issues, processes, and assessments. > > 2. Would be good to agree on a nearly normative site where a list of > > pointers to relevant docs can be maintained and kept current. [Lind, Steven, ALINT] Recognizing that some documents may pertain to ITU-only issues, some to IETF-only issues, and some to issues being worked jointly. > 3. Would be nice to try to coordinate presentations, e.g., for > mutual > education, on basic frameworks/architectures. (Note to self: get > back to work on same!) [Lind, Steven, ALINT] Recognizing the working procedures that exist in the ITU, sources of any documents must be identified and any necessary "internal consensus" reached before they can be considered at the Working Party meetings. > -Andy > > PS: The deadline for delayeds to be received by TSB is Oct 9. > However, I'm sure that WP1/2 management can authorize TDs and/or > working documents after that date (as appropriate, of course). [Lind, > Steven, ALINT] I don't think we want to repeat the problems that UPT had > from the appearance of "stealth contributions" showing up during the > meetings. > > ______________________________ Reply Separator > _________________________________ > Subject: Re: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion > Author: Richard Shockey at INTERNET-IMA > Date: 10/5/00 9:46 AM > > > > > > > > >In reference to the discussions in ITU-T SG2/Q1, what is the procedure > for > >establishing an IETF position on these issues? Would it be possible to > have > >discussions on the ENUM list for these issues? This would include > listing the > >known/expected issues and then having a dialog on the ENUM list in > preparation > >for the ITU-T SG2/Q1 meeting. > > Jay and the list as a whole ...as a follow up to your suggestions you > might > not be aware that the ITU has put up a web site for ENUM info. > > http://www.itu.int/infocom/enum/ > > I'm thinking ..if there is no objection from everyone I have all of the > materials from the Pittsburgh meeting etc PPT files ... If Bob would be > interested we could have them all posted there for the benefit of our ITU > colleagues etc. > > Now that would be a new spin on things .. the unofficial home page of a > IETF WG would be hosted by the ITU...humm.. :-) > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey > Senior Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue N.W. > Suite 550 > Washington DC. 20005 > Voice 314.503.0640 > Fax to EMail 815.333.1237 (Preferred for Fax) > DC Number 202.533.2811 > INTERNET Mail & IFAX : rich.shockey@neustar.com > or rshockey@ix.netcom.com > http://www.neustar.com > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum << File: cc:Mail note part >> _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum --IMA.Boundary.6609570790 Content-Type: text/plain; charset="US-ASCII"; name="RFC822 message headers" Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Content-Transfer-Encoding: 7bit Received: from neal.ctd.comsat.com ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 00147028; Thu, 5 Oct 2000 10:59:20 -0400 Received: from [132.151.1.19] (helo=optimus.ietf.org) by neal.ctd.comsat.com with smtp (Exim 2.12 #8) id 13hCMi-0006cA-00 for andrew.gallant@comsat.com; Thu, 5 Oct 2000 10:51:20 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22238; Thu, 5 Oct 2000 10:50:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22208 for ; Thu, 5 Oct 2000 10:50:49 -0400 (EDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00254 for ; Thu, 5 Oct 2000 10:50:41 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA22546; Thu, 5 Oct 2000 10:50:03 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA02014; Thu, 5 Oct 2000 10:48:36 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 10:49:58 -0400 Message-ID: From: "Lind, Steven D, ALCOO" To: "'Andrew.Gallant@comsat.com'" , enum@ietf.org, Richard Shockey Subject: RE: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Date: Thu, 5 Oct 2000 10:49:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --IMA.Boundary.6609570790-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 14:02:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04070 for ; Thu, 5 Oct 2000 14:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26619; Thu, 5 Oct 2000 14:00:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26588 for ; Thu, 5 Oct 2000 14:00:24 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04036 for ; Thu, 5 Oct 2000 14:00:23 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA16610 for ; Thu, 5 Oct 2000 13:00:19 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id NAA27847 for ; Thu, 5 Oct 2000 13:00:17 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 5 Oct 2000 13:00:14 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 14:00:13 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5A87@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Date: Thu, 5 Oct 2000 13:59:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard Shockey wrote: > Now that would be a new spin on things .. the unofficial home > page of a > IETF WG would be hosted by the ITU...humm.. :-) Is _this_ what they mean when they say "convergence"? Bert albert.e.manfredi@boeing.com _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 14:22:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04364 for ; Thu, 5 Oct 2000 14:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26933; Thu, 5 Oct 2000 14:18:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26904 for ; Thu, 5 Oct 2000 14:18:55 -0400 (EDT) Received: from vesuve.globetrotter.net (vesuve.globetrotter.net [142.169.1.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04328 for ; Thu, 5 Oct 2000 14:18:53 -0400 (EDT) Received: from home.com ([206.162.183.130]) by vesuve.globetrotter.net (8.9.3/8.9.3) with ESMTP id OAA10487 for ; Thu, 5 Oct 2000 14:18:23 -0400 (EDT) Message-ID: <39DCA2F6.9E8EC0A@home.com> Date: Thu, 05 Oct 2000 11:49:10 -0400 From: Herman Silbiger Reply-To: hsilbiger@ieee.org X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: enum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] New ITU Recommendation E.195 on numbering resources administration Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The following information is submitted to enum since it should be of interest to the working group. The ITU-T, at the World Telecommunications Standardization Assembly, agreed to form the ITU Numbering Administration Group (NAG) within the Telecommunication Standardization Bureau (TSB.) The NAG is defined in new Recommendation E.195, ITU-T International Numbering Resource Administration. E.195 defines processes to ensure that all requests for numbering resources are handled in an impartial, uniform, consistent, and effective manner. The two primary responsibilities of ITU-NAG will be: - resource administration - support ITU's efforts to accommodate current and future numbering needs, and to provide advice interested parties on numbering issues for the resources for which it has responsibility; - resource registration - assign and administer resources in an impartial, uniform, consistent, and effective manner consistent with ITUT developed Recommendations. ITU-NAG will consult with appropriate ITU-T Study Groups as necessary to solicit advice with regard to the administration and registration of resources. For example, for technical issues relating to the international telephone, telegraph, and telex services, SG 2 will need to be consulted. For issues related to international signaling system No. 7, SG 11 should be consulted; for carrier codes, SG 4; for T.35 fax non-standard facilities country codes, SG 16; and for international data services it should be SG 7. SG 2, as the lead SG on numbering resources operational matters, is the source for consultation on all matters of relevance to these resources. The ITU-NAG may call upon the technical expertise of the appropriate SG to review assignee conformance. with appropriate and relevant Recommendations . The purpose of such reviews is to ensure assignee conformance with appropriate and relevant Recommendations and to determine if the resource(s) requested are actually required based primarily on the utilization of already assigned resources. The review may occur: - at the request for an additional resource when it appears that the assigned resources may not be properly utilized; or - when there is suspicion (by ITU-NAG or a complainant) that an assigned resource is not being used in conformance with the appropriate Recommendation(s). Following is a list of the ITU-T Recommendation that define numbering resources of potential interest to enum: - E.164 Country Codes (including shared Country Codes and associated Identification Codes). - Registration and Administration of E.169.1 Universal International Freephone Numbers (UIFNs). - E.164 Dialling Procedures (International prefix, national (trunk) prefix and national significant number). - E.212 Mobile Country Codes. - Supplement 2 to Recommendation E.180 Various Tones used in National Networks. - X.121 Data Country Codes (DCCs) and Data Network Identification Codes (DNICs). - X.125 Identification Codes for public frame relay data networks and ATM networks numbered under the E.164 numbering plan. - T.35 Allocation of ITU-T Defined Codes for Non-Standard Facilities. - Universal Personal Telecommunication Numbers (Recommendation E.168 refers). - Universal International Premium Rate Numbers (Recommendation E.169.2 refers). - Universal International Shared Cost Numbers (Recommendation E.169.3 refers). _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 5 17:25:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07200 for ; Thu, 5 Oct 2000 17:25:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29925; Thu, 5 Oct 2000 17:21:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29897 for ; Thu, 5 Oct 2000 17:21:56 -0400 (EDT) Received: from vesuve.globetrotter.net (vesuve.globetrotter.net [142.169.1.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07129 for ; Thu, 5 Oct 2000 17:21:53 -0400 (EDT) Received: from home.com ([206.162.183.130]) by vesuve.globetrotter.net (8.9.3/8.9.3) with ESMTP id RAA08436 for ; Thu, 5 Oct 2000 17:21:24 -0400 (EDT) Message-ID: <39DCE932.3E2BAD28@home.com> Date: Thu, 05 Oct 2000 16:48:51 -0400 From: Herman Silbiger Reply-To: hsilbiger@ieee.org X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: enum@ietf.org References: <200010051600.MAA24376@optimus.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Enum] Re: Deadline for submission of documents to SG 11 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit The next Study Group 1 meetng starts 1/23/01. Documents have to be submitted to the TSB (electronically) seven working days before the meeting, in this case1/11/01. Herman > > -Andy > > PS: The deadline for delayeds to be received by TSB is Oct 9. > However, I'm sure that WP1/2 management can authorize TDs and/or > working documents after that date (as appropriate, of course). > > _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 12 15:57:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04977 for ; Thu, 12 Oct 2000 15:57:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29880; Thu, 12 Oct 2000 15:54:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29852 for ; Thu, 12 Oct 2000 15:54:47 -0400 (EDT) Received: from gatekeeper2.fcc.gov (firewall-user@gatekeeper2.fcc.gov [192.104.54.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04954 for ; Thu, 12 Oct 2000 15:54:44 -0400 (EDT) Received: by gatekeeper2.fcc.gov; id PAA26556; Thu, 12 Oct 2000 15:54:45 -0400 (EDT) Received: from unknown(165.135.237.22) by gatekeeper2.fcc.gov via smap (V5.5) id xma026439; Thu, 12 Oct 00 15:53:50 -0400 Received: from ROUTE_A-Message_Server by fcc.gov with Novell_GroupWise; Thu, 12 Oct 2000 15:53:48 -0400 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 12 Oct 2000 15:53:14 -0400 From: "Robert Cannon" To: Subject: Re: Re[2]: [Enum] Follow UPITU-T SG2/Q1 Issues Discussion Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29853 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit To the extent that it is helpful, there is a collection of ENUM links and documents at http://www.cybertelecom.org/teleph.htm#enum >>> 10/05/00 10:32AM >>> Some related(?) thoughts: 2. Would be good to agree on a nearly normative site where a list of pointers to relevant docs can be maintained and kept current. _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 12 18:02:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06878 for ; Thu, 12 Oct 2000 18:02:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01561; Thu, 12 Oct 2000 18:01:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01533 for ; Thu, 12 Oct 2000 18:01:14 -0400 (EDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06856 for ; Thu, 12 Oct 2000 18:01:10 -0400 (EDT) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id RAA29880 for ; Thu, 12 Oct 2000 17:30:50 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256976.00761E46 ; Thu, 12 Oct 2000 17:30:09 -0400 X-Lotus-FromDomain: TELCORDIA From: "Jay R. Hilton" To: enum@ietf.org Message-ID: <85256976.0076187C.00@notes949.cc.telcordia.com> Date: Thu, 12 Oct 2000 17:28:53 -0400 Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard and the ENUM list, Sorry that I have been absent from the follow-up discussions from my original query, but I am back now. Thanks for the pointer to the ITU website for ENUM activities ( http://www.itu.infocom/enum). I find the information contained on that site to provide a good overview of the activities underway. I recommend a visit by all interested parties. As I looked at the documents to be discussed at the upcoming ITU-T SG2 Working Party 1 meeting (October 19-26, In Berlin, Germany), I found several documents that, through discussion at the meeting should provide fruitful information for our on-going work in ENUM. Since access to the site is restricted to ITU members, I will only reference titles and abstracts of contributions. Specifically the following seem of interest: Delayed Document #301, source: AT&T and LMGT TITLE: Overview of the IETF48 ENUM WG session from a WP1/2 perspective Abstract This document collects some aspects of the ENUM WG session from IETF48 of interest to WSP1/2. It also discusses documents and presentations by the authors, and it includes additional information and pointers about ENUM. Individuals participate in the IETF at a working level, and representing a Member State or Sector Member is not applicable. The views in this document are offered in that spirit. Delayed Document #304, source LMGT TITLE: Unofficial updated version of "E.164 number and DNS" Abstract This contribution is an unofficial update of "E.164 number and DNS" , an internet draft approved by the IESG as a proposed standard. It is provided for working purposes only. Delayed Document #305; source LMGT and AT&T TITLE: Preliminary Assessment of ENUM Issues Relevant to WP1/2 Abstract This contribution contains a preliminary assessment of ENUM issues relevant to WP1/2. It includes a list of issues, classification by scope, and next steps. Other issues possibly arising from other sources are also considered. This work is intended to provide initial input and stimulate discussion. Delayed Document #306; source: Telenor TITLE: Update of draft Rec.E.TIPI Naming, numbering and addressing for interworking between E.164 and IP address-based networks Scope: The Recommendation provides guidance for interworking between the E.164 and IP address-based networks, and identifies the users, service providers and Administrations requirements to the naming options of this interworking. It recommends the type of E.164 naming resources that should be made available to IP address-based networks, and how these resources should be administered. It identifies the addressing requirements to the involved E.164 and IP address-based networks and the addressing space in the referred networks, and recommends addressing schemes to be utilized in the E.164 address-based networks. Delayed Document #307, Source: NTT TITLE: Consideration of new draft recommendation E.TIPI No abstract available Delayed Document #309, source: AT&T TITLE: Administrative Requirements for Deployment of ENUM in North America No abstract available I would like to specifically thank the authors for compiling such a base of knowledge for discussion at the meeting. For example, #305 provides an excellent listing and discussion of the kinds of issues that I was originally referencing in my earlier message. Also, #309 begins the discussion of the administrative issues for a USA deployment of ENUM services, which will lay groundwork for International deployment of ENUM services. Andy Gallant, Steve Lind and Penn Pfautz should be congratulated. I will be most interested to hear their comments regarding the results of the ITU discussions at the next IETF meeting. Regards, Jay Hilton _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 09:45:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05488 for ; Fri, 13 Oct 2000 09:45:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17312; Fri, 13 Oct 2000 09:43:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17281 for ; Fri, 13 Oct 2000 09:43:47 -0400 (EDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05443 for ; Fri, 13 Oct 2000 09:43:47 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA26257; Fri, 13 Oct 2000 09:43:17 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA06826; Fri, 13 Oct 2000 09:41:55 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Fri, 13 Oct 2000 09:43:16 -0400 Message-ID: From: "Lind, Steven D, ALCOO" To: "'Jay R. Hilton'" Cc: enum@ietf.org Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Date: Fri, 13 Oct 2000 09:43:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org See below. Also available Temp. Doc. 25 - ENUM Call Flows for VoIP Interworking This document provides illustrations of the use of ENUM functionality and identifies issues associated with such use. To accomplish this objective, the document presents service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a "direct dial" basis. For more complicated calls, requiring number portability or freephone call processing, the issues are described with the intent of working through those issues in subsequent drafts. The document does not propose that the examples represent the only or best approach for interworking between the PSTN and IP-based networks. Steve Lind --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 web: sdlind.ims.att.com --------------------------------------------------------------- > -----Original Message----- > From: Jay R. Hilton [SMTP:jhilton@telcordia.com] > Sent: Thursday, October 12, 2000 5:29 PM > To: enum@ietf.org > Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion > > > > Richard and the ENUM list, > > Sorry that I have been absent from the follow-up discussions from my > original > query, but I am back now. > > Thanks for the pointer to the ITU website for ENUM activities ( > http://www.itu.infocom/enum). I find the information contained on that > site to > provide a good overview of the activities underway. I recommend a visit > by all > interested parties. > > As I looked at the documents to be discussed at the upcoming ITU-T SG2 > Working > Party 1 meeting (October 19-26, In Berlin, Germany), I found several > documents > that, through discussion at the meeting should provide fruitful > information for > our on-going work in ENUM. Since access to the site is restricted to ITU > members, I will only reference titles and abstracts of contributions. > Specifically the following seem of interest: > [Lind, Steven, ALINT] ...snip... > > Delayed Document #309, source: AT&T > TITLE: Administrative Requirements for Deployment of ENUM in North > America > No abstract available [Lind, Steven, ALINT] This document discusses a number of the administrative issues that must be resolved before effective deployment of ENUM[1,2] services in complex environments with number portability and multiple providers for using DNS for translation of E.164 (telephone) numbers. The United States is examined critically because its environment may be more complex than most and because current deregulation trends may drive other countries/regions in similar directions. In particular the current mechanisms for number administration and number portability in the U.S. will require establishment of a new administrative function for managing the domain name entries for ported numbers. > I would like to specifically thank the authors for compiling such a base > of > knowledge for discussion at the meeting. For example, #305 provides an > excellent listing and discussion of the kinds of issues that I was > originally > referencing in my earlier message. Also, #309 begins the discussion of > the > administrative issues for a USA deployment of ENUM services, which will > lay > groundwork for International deployment of ENUM services. Andy Gallant, > Steve > Lind and Penn Pfautz should be congratulated. I will be most interested > to hear > their comments regarding the results of the ITU discussions at the next > IETF > meeting. > > Regards, > > Jay Hilton > > > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 10:52:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07002 for ; Fri, 13 Oct 2000 10:52:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18039; Fri, 13 Oct 2000 10:51:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18011 for ; Fri, 13 Oct 2000 10:50:59 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06973 for ; Fri, 13 Oct 2000 10:50:58 -0400 (EDT) Received: from [192.168.1.19] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27833; Fri, 13 Oct 2000 07:50:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <85256976.0076187C.00@notes949.cc.telcordia.com> References: <85256976.0076187C.00@notes949.cc.telcordia.com> Date: Fri, 13 Oct 2000 16:47:33 +0200 To: "Jay R. Hilton" , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 17.28 -0400 00-10-12, Jay R. Hilton wrote: >Delayed Document #304, source LMGT >TITLE: Unofficial updated version of "E.164 number and DNS" > >Abstract >This contribution is an unofficial update of "E.164 number and DNS" >, an internet draft approved by the IESG as a >proposed standard. It is provided for working purposes only. This is now published as RFC 2916, which can be found as http://www.ietf.org/rfc/rfc2916.txt. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 10:56:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07113 for ; Fri, 13 Oct 2000 10:56:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18155; Fri, 13 Oct 2000 10:55:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18126 for ; Fri, 13 Oct 2000 10:55:30 -0400 (EDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07088 for ; Fri, 13 Oct 2000 10:55:29 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA22055; Fri, 13 Oct 2000 10:54:54 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA24857; Fri, 13 Oct 2000 10:53:32 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Fri, 13 Oct 2000 10:54:54 -0400 Message-ID: From: "Lind, Steven D, ALCOO" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "Jay R. Hilton" , enum@ietf.org Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Date: Fri, 13 Oct 2000 10:54:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA18127 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id KAA18155 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07113 It has been distributed to the Berlin meeting as Temp. Doc. 28. --------------------------------------------------------------- Steven D. Lind Tel: (973) 236-6787 AT&T Fax: (973) 236-6452 180 Park Ave., Bldg. 2 e-mail: sdlind@att.com Florham Park, NJ 07932 web: sdlind.ims.att.com --------------------------------------------------------------- > -----Original Message----- > From: Patrik Fältström [SMTP:paf@cisco.com] > Sent: Friday, October 13, 2000 10:48 AM > To: Jay R. Hilton; enum@ietf.org > Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion > > At 17.28 -0400 00-10-12, Jay R. Hilton wrote: > >Delayed Document #304, source LMGT > >TITLE: Unofficial updated version of "E.164 number and DNS" > > > >Abstract > >This contribution is an unofficial update of "E.164 number and DNS" > >, an internet draft approved by the IESG as > a > >proposed standard. It is provided for working purposes only. > > This is now published as RFC 2916, which can be found as > http://www.ietf.org/rfc/rfc2916.txt. > > Patrik > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 11:11:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07388 for ; Fri, 13 Oct 2000 11:11:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18463; Fri, 13 Oct 2000 11:09:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18431 for ; Fri, 13 Oct 2000 11:09:50 -0400 (EDT) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07316 for ; Fri, 13 Oct 2000 11:09:49 -0400 (EDT) Received: from j ([12.88.173.189]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001013150916.BXHC23816.mtiwmhc22.worldnet.att.net@j>; Fri, 13 Oct 2000 15:09:16 +0000 From: "Judith Oppenheimer" To: =?iso-8859-1?B?J1BhdHJpayBG5Gx0c3Ry9m0n?= , "'Jay R. Hilton'" , Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Date: Fri, 13 Oct 2000 11:03:25 -0400 Message-ID: <00c601c03526$bd695480$bdad580c@oppenheimerworldnet.att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA18463 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07388 5. There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. Correct me if I'm wrong: does this not apply to the U.S. SMS/800 systsem? ie, that it "should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes."? Judith -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Patrik Fältström Sent: Friday, October 13, 2000 10:48 AM To: Jay R. Hilton; enum@ietf.org Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion At 17.28 -0400 00-10-12, Jay R. Hilton wrote: >Delayed Document #304, source LMGT >TITLE: Unofficial updated version of "E.164 number and DNS" > >Abstract >This contribution is an unofficial update of "E.164 number and DNS" >, an internet draft approved by the IESG as a >proposed standard. It is provided for working purposes only. This is now published as RFC 2916, which can be found as http://www.ietf.org/rfc/rfc2916.txt. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 11:20:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07516 for ; Fri, 13 Oct 2000 11:20:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18629; Fri, 13 Oct 2000 11:19:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18596 for ; Fri, 13 Oct 2000 11:19:29 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07505 for ; Fri, 13 Oct 2000 11:19:28 -0400 (EDT) Received: from [192.168.1.19] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08058; Fri, 13 Oct 2000 08:18:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <00c601c03526$bd695480$bdad580c@oppenheimerworldnet.att.net> References: <00c601c03526$bd695480$bdad580c@oppenheimerworldnet.att.net> Date: Fri, 13 Oct 2000 17:17:35 +0200 To: "Judith Oppenheimer" , "'Jay R. Hilton'" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-MIME-Autoconverted: from 8bit to quoted-printable by mailman.cisco.com id IAA08058 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18597 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA18629 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07516 At 11.03 -0400 00-10-13, Judith Oppenheimer wrote: >Correct me if I'm wrong: does this not apply to the U.S. SMS/800 systsem? > >ie, that it "should be designed with adequate mechanisms for identification >and authentication of those requesting changes and for authorization of >those changes."? Probably. Someone which knows what you mean by "SMS/800" system have to answer that. And also remember that we must in these discussions differ between local problems in one of the regions and the global issues. The point with this text is that this is inside the security considerations section in the RFC, and as such it shows what security issues which the base technology does _not_ solve, but what can be enabled via the administrative systems around the technology describes. I.e. updates are not discussed in this paper at all. That is handled either through DNS mechanisms (Dynamic DNS) or via out of band mechanisms (authenticated LDAP updates, or via secure http and some proper authentication or whatever the administrator finds ok). Patrik Fältström _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 11:42:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07990 for ; Fri, 13 Oct 2000 11:42:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18935; Fri, 13 Oct 2000 11:39:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18905 for ; Fri, 13 Oct 2000 11:39:32 -0400 (EDT) Received: from irvmail2.bdi.gte.com (irvmail2.bdi.gte.com [192.76.80.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07915 for ; Fri, 13 Oct 2000 11:39:26 -0400 (EDT) From: james.f.baskin@verizon.com Received: from irvmail2.bdi.gte.com (localhost [127.0.0.1]) by irvmail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id KAA26501; Fri, 13 Oct 2000 10:38:19 -0500 (EST) Received: from smtpftw.interwan.gte.com ([138.83.130.53]) by irvmail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id KAA26483; Fri, 13 Oct 2000 10:38:18 -0500 (EST) Received: from smtpftw.interwan.gte.com (localhost [127.0.0.1]) by smtpftw.interwan.gte.com (8.9.3/8.9.3) with ESMTP id KAA25852; Fri, 13 Oct 2000 10:39:10 -0500 (EST) Received: from imr01.bellatlantic.com ([141.152.156.12]) by smtpftw.interwan.gte.com (8.9.3/8.9.3) with ESMTP id KAA25636; Fri, 13 Oct 2000 10:39:01 -0500 (EST) Received: from fhsmtp01.bell-atl.com (is051991.bellatlantic.com [141.152.101.47]) by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id LAA16497; Fri, 13 Oct 2000 11:38:03 -0400 (EDT) Received: by fhsmtp01.bell-atl.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256977.0055DDEE ; Fri, 13 Oct 2000 11:37:53 -0400 X-Lotus-FromDomain: NYNEX To: "Judith Oppenheimer" cc: =?iso-8859-1?Q?=22=27Patrik_F=E4ltstr=F6m=27=22?= , "'Jay R. Hilton'" , enum@ietf.org Message-ID: <85256977.005562ED.00@fhsmtp01.bell-atl.com> Date: Fri, 13 Oct 2000 11:32:40 -0400 Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18906 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA18935 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07990 Customer/routing information in the SMS800 database can be updated only by the "Resporg" (responsible organization) - the carrier selected by the customer to manage a given toll-free number. Only the current Resporg can transfer Resporg responsibility to another carrier. It is the responsibility of the current Resporg to maintain mechanisms to authenticate customer requests to modify SMS800 database data or to change Resporg. Having worked in a Resporg data management group, I know that mechanisms are in place, but even so, there can be occassional problems. Jim Baskin "Judith Oppenheimer" on 10/13/2000 11:03:25 AM To: "'Patrik Fältström'" , "'Jay R. Hilton'" , enum@ietf.org cc: (bcc: James Baskin) Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion 5. There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. Correct me if I'm wrong: does this not apply to the U.S. SMS/800 systsem? ie, that it "should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes."? Judith -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Patrik Fältström Sent: Friday, October 13, 2000 10:48 AM To: Jay R. Hilton; enum@ietf.org Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion At 17.28 -0400 00-10-12, Jay R. Hilton wrote: >Delayed Document #304, source LMGT >TITLE: Unofficial updated version of "E.164 number and DNS" > >Abstract >This contribution is an unofficial update of "E.164 number and DNS" >, an internet draft approved by the IESG as a >proposed standard. It is provided for working purposes only. This is now published as RFC 2916, which can be found as http://www.ietf.org/rfc/rfc2916.txt. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 13 11:54:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08216 for ; Fri, 13 Oct 2000 11:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19110; Fri, 13 Oct 2000 11:54:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19079 for ; Fri, 13 Oct 2000 11:53:58 -0400 (EDT) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08205 for ; Fri, 13 Oct 2000 11:53:50 -0400 (EDT) Received: from j ([12.88.173.189]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001013155319.CMIE23816.mtiwmhc22.worldnet.att.net@j>; Fri, 13 Oct 2000 15:53:19 +0000 From: "Judith Oppenheimer" To: Cc: =?iso-8859-1?B?J1BhdHJpayBG5Gx0c3Ry9m0n?= , "'Jay R. Hilton'" , Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Date: Fri, 13 Oct 2000 11:47:27 -0400 Message-ID: <00f901c0352c$e436be80$bdad580c@oppenheimerworldnet.att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <85256977.005562ED.00@fhsmtp01.bell-atl.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA19110 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08216 >It is the responsibility of the current >Resporg to maintain mechanisms to authenticate customer requests to modify >SMS800 database data or to change Resporg. The problems are more than occasional, the methods are many (at the customer level, at the RespOrg level, and at the SMS/800 level), sometimes fraudulent, often simply negligent. My question is, how is the execution of ENUM affected by portability environments that are *not* designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes? Judith -----Original Message----- From: james.f.baskin@verizon.com [mailto:james.f.baskin@verizon.com] Sent: Friday, October 13, 2000 11:33 AM To: Judith Oppenheimer Cc: 'Patrik Fältström'; 'Jay R. Hilton'; enum@ietf.org Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion Customer/routing information in the SMS800 database can be updated only by the "Resporg" (responsible organization) - the carrier selected by the customer to manage a given toll-free number. Only the current Resporg can transfer Resporg responsibility to another carrier. It is the responsibility of the current Resporg to maintain mechanisms to authenticate customer requests to modify SMS800 database data or to change Resporg. Having worked in a Resporg data management group, I know that mechanisms are in place, but even so, there can be occassional problems. Jim Baskin "Judith Oppenheimer" on 10/13/2000 11:03:25 AM To: "'Patrik Fältström'" , "'Jay R. Hilton'" , enum@ietf.org cc: (bcc: James Baskin) Subject: RE: [Enum] ITU-T SG2/Q1 Issues Discussion 5. There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name- translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes. Correct me if I'm wrong: does this not apply to the U.S. SMS/800 systsem? ie, that it "should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes."? Judith -----Original Message----- From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of Patrik Fältström Sent: Friday, October 13, 2000 10:48 AM To: Jay R. Hilton; enum@ietf.org Subject: Re: [Enum] ITU-T SG2/Q1 Issues Discussion At 17.28 -0400 00-10-12, Jay R. Hilton wrote: >Delayed Document #304, source LMGT >TITLE: Unofficial updated version of "E.164 number and DNS" > >Abstract >This contribution is an unofficial update of "E.164 number and DNS" >, an internet draft approved by the IESG as a >proposed standard. It is provided for working purposes only. This is now published as RFC 2916, which can be found as http://www.ietf.org/rfc/rfc2916.txt. Patrik _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Thu Oct 19 06:37:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26768 for ; Thu, 19 Oct 2000 06:37:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09186; Thu, 19 Oct 2000 06:35:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09157 for ; Thu, 19 Oct 2000 06:35:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26390; Thu, 19 Oct 2000 06:35:38 -0400 (EDT) Message-Id: <200010191035.GAA26390@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Oct 2000 06:35:38 -0400 Subject: [Enum] I-D ACTION:draft-pfautz-yu-enum-adm-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ENUM Administrative Process in the U.S.A. Author(s) : P. Pfautz, J. Yu Filename : draft-pfautz-yu-enum-adm-00.txt Pages : Date : 18-Oct-00 This document considers administrative processes for ENUM in the U.S.A. and offers two 'strawman' proposals in the spirit of moving forward the work that must be done to implement a useful ENUM capability. The U.S.A. has implemented number portability; therefore, it is the telephony user that controls the assigned telephone number so long as it maintains the telephony service. While the proposed processes are tailored for the U.S.A. they may be appropriate for use by other countries that implement number portability so that the donor telephony service provider (e.g., the telephony service provider that is assigned a block of telephony numbers before any number porting event happens from that number block) is not relied on for maintaining the delegation information for a telephone number (e.g., the Tier 1 function in the ENUM process). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-yu-enum-adm-00.txt 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-pfautz-yu-enum-adm-00.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-pfautz-yu-enum-adm-00.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: <20001018143712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfautz-yu-enum-adm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfautz-yu-enum-adm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001018143712.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Oct 23 21:50:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29133 for ; Mon, 23 Oct 2000 21:50:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27884; Mon, 23 Oct 2000 21:46:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27853 for ; Mon, 23 Oct 2000 21:46:15 -0400 (EDT) Received: by ietf.org (8.9.1a/8.9.1a) id VAA28304; Mon, 23 Oct 2000 21:46:12 -0400 (EDT) Date: Mon, 23 Oct 2000 21:46:12 -0400 (EDT) Message-Id: <200010240146.VAA28304@ietf.org> X-Authentication-Warning: ietf.org: majordom set sender to Majordomo-Owner@ietf.org using -f To: enum@ietf.org From: Majordomo@ietf.org Reply-To: Majordomo@ietf.org Subject: [Enum] Confirmation for subscribe ietf-announce Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ietf-announce@ietf.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@ietf.org": auth d348ed05 subscribe ietf-announce enum If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d348ed05 subscribe ietf-announce \ enum If you have any questions about the policy of the list owner, please contact "ietf-announce-approval@ietf.org". Thanks! Majordomo@ietf.org _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Wed Oct 25 15:01:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26900 for ; Wed, 25 Oct 2000 15:01:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08901; Wed, 25 Oct 2000 14:58:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08870 for ; Wed, 25 Oct 2000 14:58:17 -0400 (EDT) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26189 for ; Wed, 25 Oct 2000 14:57:57 -0400 (EDT) Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with SMTP id OAA16729 for ; Wed, 25 Oct 2000 14:47:31 -0400 (EDT) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256983.00673B3B ; Wed, 25 Oct 2000 14:47:33 -0400 X-Lotus-FromDomain: TELCORDIA From: "Thomas C. Ely" To: enum@ietf.org Message-ID: <85256983.0067219A.00@notes950.cc.telcordia.com> Date: Wed, 25 Oct 2000 14:45:56 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Enum] auth d348ed05 subscribe ietf-announce enum Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org enum-admin@ietf.org on 10/24/2000 12:00:04 PM Please respond to enum@ietf.org To: enum@ietf.org cc: (bcc: Thomas C. Ely/Telcordia) Subject: enum digest, Vol 1 #141 - 1 msg Send enum mailing list submissions to enum@ietf.org To subscribe or unsubscribe via the web, visit http://www1.ietf.org/mailman/listinfo/enum or, via email, send a message with subject or body 'help' to enum-request@ietf.org You can reach the person managing the list at enum-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of enum digest..." Today's Topics: 1. Confirmation for subscribe ietf-announce (majordomo@ietf.org) --__--__-- Message: 1 Date: Mon, 23 Oct 2000 21:46:12 -0400 (EDT) To: enum@ietf.org From: Majordomo@ietf.org Reply-To: Majordomo@ietf.org Subject: [Enum] Confirmation for subscribe ietf-announce -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ietf-announce@ietf.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@ietf.org": auth d348ed05 subscribe ietf-announce enum If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth d348ed05 subscribe ietf-announce \ enum If you have any questions about the policy of the list owner, please contact "ietf-announce-approval@ietf.org". Thanks! Majordomo@ietf.org --__--__-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum End of enum Digest _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 06:40:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06207 for ; Fri, 27 Oct 2000 06:40:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12191; Fri, 27 Oct 2000 06:38:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12162 for ; Fri, 27 Oct 2000 06:38:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05640; Fri, 27 Oct 2000 06:38:46 -0400 (EDT) Message-Id: <200010271038.GAA05640@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 27 Oct 2000 06:38:46 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : ENUM Service Specific Provisioning: Principles of Operation Author(s) : A. Brown, G. Vaudreuil Filename : draft-ietf-enum-operation-01.txt Pages : 14 Date : 26-Oct-00 This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-operation-01.txt 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-operation-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-operation-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 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: <20001026125049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-operation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-operation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001026125049.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 10:01:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02574 for ; Fri, 27 Oct 2000 10:01:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14535; Fri, 27 Oct 2000 10:00:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14504 for ; Fri, 27 Oct 2000 10:00:17 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02049 for ; Fri, 27 Oct 2000 10:00:16 -0400 (EDT) Received: by dnspri.npac.com; id JAA01337; Fri, 27 Oct 2000 09:00:16 -0500 (CDT) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xmae00604; Fri, 27 Oct 00 08:59:43 -0500 Message-Id: <5.0.0.25.2.20001027095449.02f87030@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 10:00:03 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Reminder... IETF 49 is Coming up...Agenda Suggestions etc Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org The preliminary agenda indicates we are first up on monday.. MONDAY, December 11, 2000 0800-1930 IETF Registration - Harbor Island Foyer and Grande Ballroom Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer and Grande Ballroom Foyer 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting INT dhc v4 Dynamic Host Configuration WG RTG mpls Multiprotocol Label Switching WG TSV enum Telephone Number Mapping WG TSV ips IP Storage WG If anyone is interested in contributions ..lets get those ID's in ASAP so we can have some discussion before hand. I'd like to get comments for items for the Agenda. I'm assuming we have at least 3 documents to deal with. Goals and Requirements. Anne Brown? Principals of Operations Greg V? Informational document on North Americian administration James Yu- Penn Pfautz I'd like to discuss a MIB as well we need to have someone look into this issue ASAP. Timetables for future work - recharter - go dormant - close up shop.???? Anything else. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Senior Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue N.W. Suite 550 Washington DC. 20005 Voice 202.533.2811 Fax to EMail 815.333.1237 (Preferred for Fax) Cell : 314.503.0640 INTERNET Mail & IFAX : rich.shockey@neustar.com or rshockey@ix.netcom.com http://www.neustar.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 12:27:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18093 for ; Fri, 27 Oct 2000 12:27:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16180; Fri, 27 Oct 2000 12:26:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16152 for ; Fri, 27 Oct 2000 12:26:15 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17663 for ; Fri, 27 Oct 2000 12:26:14 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pCKb-000OXP-00 for enum@ietf.org; Fri, 27 Oct 2000 09:26:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt References: <200010271038.GAA05640@ietf.org> Message-Id: Date: Fri, 27 Oct 2000 09:26:13 -0700 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit why does this draft use a dangerous and unnecessary DNAME? randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 13:26:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05363 for ; Fri, 27 Oct 2000 13:26:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16847; Fri, 27 Oct 2000 13:25:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16816 for ; Fri, 27 Oct 2000 13:24:58 -0400 (EDT) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05031 for ; Fri, 27 Oct 2000 13:24:57 -0400 (EDT) Received: by dnspri.npac.com; id MAA18637; Fri, 27 Oct 2000 12:24:16 -0500 (CDT) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xmac18127; Fri, 27 Oct 00 12:23:37 -0500 Message-Id: <5.0.0.25.2.20001027131839.02e8b4c0@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 13:19:48 -0400 To: Randy Bush , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt In-Reply-To: References: <200010271038.GAA05640@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 09:26 AM 10/27/2000 -0700, Randy Bush wrote: >why does this draft use a dangerous and unnecessary DNAME? Why do you consider it dangerous? What is your preference? DNAME was a suggestion Christian Huetima had quite some time ago. >randy > >_______________________________________________ >enum mailing list >enum@ietf.org >http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 13:35:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08500 for ; Fri, 27 Oct 2000 13:35:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17151; Fri, 27 Oct 2000 13:34:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17120 for ; Fri, 27 Oct 2000 13:34:51 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08200 for ; Fri, 27 Oct 2000 13:34:50 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA29095 for ; Fri, 27 Oct 2000 13:34:50 -0400 (EDT) Received: from mx0003exch001p.wins.lucent.com (h135-107-128-31.lucent.com [135.107.128.31]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA29078 for ; Fri, 27 Oct 2000 13:34:49 -0400 (EDT) Received: by MX0003EXCH001P with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 12:34:49 -0500 Message-ID: <808BCB95E77CD21188DB00805F6F99C7057E189B@txdj00exch005u.micro.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Randy Bush , enum@ietf.org Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt Date: Fri, 27 Oct 2000 12:34:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org DNAME is necessary to make real-world number plans work. DNAME is the only DNS facility available to redirect an entire branch of a domain name tree to another.... something needed to match the commonly performed redirection of a telephone number sub-tree. Maybe this should be more clear in the draft. DNAME makes possible a number of renumbering situations, where a block of telephone numbers may temporarily be accessed using one of two or more prefixes. For example, during a Dallas area-code split recently I could be reached at either: 2.2.7.2.3.3.7.2.7.9.1.e164.arpa and 2.2.7.2.3.3.7.4.1.2.1.e164.arpa one of which was simply a temporary pointer to the other. This also occurs where a national authority decides to add a prefix digit to their number plans. Duplicating the entire national ENUM hierarchy for transition is a bit much of a hurdle. It is also helpful when you want a single second-level authority to hold NAPTR records for internal and external numbering plans such as: 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (open-world PSTN) and 2.2.7.2.dallas.lucent.com (extension 2272 on local PBX) and 2.7.2.2.5.4.2.lucent.com (location 542, extension 2722) I want to direct one or more branches to be served by the same zone file for ease of administration, assurance of consistency, and just plain simplicity. I need to avoid teaching each client the complete local numbering plan to initiate a successful query. Yes, the proper use of DNAME and NAPTR is a real administrative mess with real danger since the initial string for NAPTR processing is not what the NAPTR record writer might have thought it was. We knew that risk before the ENUM document was published. Patrick and I went through a long set of potential applications and topologies, some on and some off the ENUM list. It turned out that in every case enough attention to detail would make any combination of application and topology I could think of work provided a complex enough Regexp is written. The resolution was simply that one must be knowledgeable and careful when constructing NAPTR records to make sure the regexp substitutions work for all initial strings and corresponding DNS paths used in your branch of numberland. In particular, be very very careful if doing anything more interesting than simply pointing to a static URL. At the last IETF, there was much hallway conversation about writing an ENUM profile of NAPTR to reduce the large risk of broken combinations and to dramatically simplify the task of an application client programmer. In particular, it is possible today for a server to serve NAPTRs a likely simple-minded client is unable to understand (recursion, pattern matching), or something where an end-customer writes a NAPTRs that breaks when an up-stream numbering authorities implements something unforeseen (renumbering). Initial implementation and experimentation will tell if we need to profile NAPTR or profile DNS to prohibit Cnames or Dnames in the ENUM branch. Greg V. -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Friday, October 27, 2000 11:26 AM To: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt why does this draft use a dangerous and unnecessary DNAME? randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 13:56:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13636 for ; Fri, 27 Oct 2000 13:56:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17355; Fri, 27 Oct 2000 13:55:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17325 for ; Fri, 27 Oct 2000 13:55:32 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13478 for ; Fri, 27 Oct 2000 13:55:30 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pDiz-000PJJ-00; Fri, 27 Oct 2000 10:55:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Richard Shockey Cc: enum@ietf.org Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt References: <200010271038.GAA05640@ietf.org> <5.0.0.25.2.20001027131839.02e8b4c0@127.0.0.1> Message-Id: Date: Fri, 27 Oct 2000 10:55:29 -0700 Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit > Why do you consider it dangerous? it is a form of delegation, and should be used *very* sparingly. dname far to clever (which is a pejorative). > DNAME was a suggestion Christian Huetima had quite some time ago. no comment randy _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 14:45:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27248 for ; Fri, 27 Oct 2000 14:45:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17942; Fri, 27 Oct 2000 14:44:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17913 for ; Fri, 27 Oct 2000 14:44:07 -0400 (EDT) Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26601 for ; Fri, 27 Oct 2000 14:44:05 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18641; Fri, 27 Oct 2000 11:43:34 -0700 (PDT) Received: from [192.168.1.10] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA19743; Fri, 27 Oct 2000 11:43:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <808BCB95E77CD21188DB00805F6F99C7057E189B@txdj00exch005u.micro.lucent.com> References: <808BCB95E77CD21188DB00805F6F99C7057E189B@txdj00exch005u.micro.lucent.com> Date: Fri, 27 Oct 2000 20:38:11 +0200 To: "Vaudreuil, Greg M (Greg)" , Randy Bush , enum@ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12.34 -0500 00-10-27, Vaudreuil, Greg M (Greg) wrote: >It is also helpful when you want a single second-level authority to hold >NAPTR records for internal and external numbering plans such as: > > 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (open-world PSTN) >and > 2.2.7.2.dallas.lucent.com (extension 2272 on local PBX) >and > 2.7.2.2.5.4.2.lucent.com (location 542, extension 2722) Are you talking about numbering plan or dialing plan here? People that work with telephony tell me it is important to distinguish between the two. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Fri Oct 27 15:54:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14331 for ; Fri, 27 Oct 2000 15:54:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18596; Fri, 27 Oct 2000 15:53:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18567 for ; Fri, 27 Oct 2000 15:53:07 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14106 for ; Fri, 27 Oct 2000 15:53:05 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA13898 for ; Fri, 27 Oct 2000 15:53:06 -0400 (EDT) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA13881 for ; Fri, 27 Oct 2000 15:53:05 -0400 (EDT) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id <46J9QN4J>; Fri, 27 Oct 2000 15:53:05 -0400 Message-ID: <808BCB95E77CD21188DB00805F6F99C7057E19D2@txdj00exch005u.micro.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Randy Bush , enum@ietf.org Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt Date: Fri, 27 Oct 2000 15:52:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18568 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id PAA18596 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA14331 What I am talking about is numbering plan. I recognise discussing private numbering plans is out-of-scope for the main work item of this group, it is worth understanding. Many of us intend to extend the ENUM work to encompas private plans and I have an explicit goal to make that technologically possible. In my example in the forwarded message below, there are two numbering plans that can be accessed using a single dialing plan. These are: 19727332722, a fully qualified number in the public numbering plan and 2452722, a fully qualified number in a fictional Lucent corporate-wide private dial plan. The plan is made of location code plus extension. (Being an AT&T child, the public plan is our private number plan :-) The extension 2272 can be considered a dial-plan short-cut within both numbering plans or a number plan itself. However, a different view is possible. It is common to have PBX extension numbers that have no corresponding wide-area numbering plan, that is, they are undialable from outside the "building". In that case, an administrator may consider the internal PBX extensions to be a separate numbering plan that is not a proper subset dialing plan of any other numbering plan. To illustrate, the following dialing plan provides access to three separate numbering plans: 4 digit number => Local PBX number plan 9 + N digits => Public plan 8 + 7 digits => Lucent private plan Clear? Greg V. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Friday, October 27, 2000 1:38 PM To: Vaudreuil, Greg M (Greg); Randy Bush; enum@ietf.org Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-operation-01.txt At 12.34 -0500 00-10-27, Vaudreuil, Greg M (Greg) wrote: >It is also helpful when you want a single second-level authority to hold >NAPTR records for internal and external numbering plans such as: > > 2.2.7.2.3.3.7.2.7.9.1.e164.arpa (open-world PSTN) >and > 2.2.7.2.dallas.lucent.com (extension 2272 on local PBX) >and > 2.7.2.2.5.4.2.lucent.com (location 542, extension 2722) Are you talking about numbering plan or dialing plan here? People that work with telephony tell me it is important to distinguish between the two. paf _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Mon Oct 30 14:57:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25668 for ; Mon, 30 Oct 2000 14:57:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15604; Mon, 30 Oct 2000 14:52:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15574 for ; Mon, 30 Oct 2000 14:51:59 -0500 (EST) Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24982 for ; Mon, 30 Oct 2000 14:52:01 -0500 (EST) Received: by dnspri.npac.com; id NAA07865; Mon, 30 Oct 2000 13:51:52 -0600 (CST) Received: from unknown(192.168.20.149) by dnspri.npac.com via smap (V5.0) id xmac07839; Mon, 30 Oct 00 13:51:49 -0600 Message-Id: <5.0.0.25.2.20001030135252.0205ac70@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 13:54:25 -0500 To: enum@ietf.org From: Richard Shockey Subject: Re: [Enum] Reminder... IETF 49 is Coming up...Agenda Suggestions etc Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Graham Klyne In-Reply-To: <4.3.2.7.2.20001029103325.00aa34e0@pop.dial.pipex.com> References: <5.0.0.25.2.20001027095449.02f87030@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org It looks like we're Thursday afternoon now.... that works ... THURSDAY, December 14, 2000 0800-1700 IETF Registration - Harbor Island Foyer and Grande Ballroom Foyer 0800-0900 Continental Breakfast - Harbor Island Foyer and Grande Ballroom Foyer 0900-1130 Morning Sessions APPfaxInternet Fax WG OPSmbonedMBONE Deployment WG RTGmobileipIP Routing for Wireless/Mobile Hosts WG SECidwgIntrusion Detection Exchange Format WG TSVsigtranSignaling Transport WG TSVnfsv4Network File System Version 4 WG 1130-1300 Break 1300-1500 Afternoon Sessions I APPdeltavWeb Versioning and Configuration Management WG OPSsnmpconfConfiguration Management with SNMP WG OPSngtransNext Generation Transition WG SECsacredSecurely Available Credentials WG TSVavtAudio/Video Transport WG TSVenumTelephone Number Mapping WG _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 31 10:08:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28134 for ; Tue, 31 Oct 2000 10:08:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01804; Tue, 31 Oct 2000 10:06:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01777 for ; Tue, 31 Oct 2000 10:05:58 -0500 (EST) Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25430 for ; Tue, 31 Oct 2000 10:05:56 -0500 (EST) Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 16:00:34 +0100 Message-ID: From: "Shaw, Robert" To: "'enum@ietf.org'" Date: Tue, 31 Oct 2000 16:05:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Liaison to IETF/ISOC on ENUM from ITU-T Working Party 1/2 meeting , Berlin, 19-26 October 2000 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At http://www.itu.int/infocom/enum/wp1-39_rev1.htm is the liaison statement just released to the IETF on ENUM administration issues. Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum From enum-admin@ietf.org Tue Oct 31 12:59:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10535 for ; Tue, 31 Oct 2000 12:59:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04183; Tue, 31 Oct 2000 12:57:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04154 for ; Tue, 31 Oct 2000 12:56:58 -0500 (EST) Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09675 for ; Tue, 31 Oct 2000 12:57:00 -0500 (EST) Received: from rwalter ([38.136.73.76]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001031175627.LCPM24415.hvmta03-stg@rwalter>; Tue, 31 Oct 2000 12:56:27 -0500 From: "Robert H. Walter" To: Cc: "Vaudreuil, Greg M \(Greg\)" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Randy Bush" Date: Tue, 31 Oct 2000 12:56:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Enum] Standard DNS Delegation or CNAME/DNAME Redirection Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit Greg, Ann, Please clarify why you believe CNAME and DNAME resource records are required to redirect the DNS query from the designated authority to the service registrar? Why re-issue, reform the query when standard DNS delegation will suffice? Consider the following scenarios that assume the designated authority for 1.e164.arpa has provisioned the fully specified E.164 domain name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service registrar ACME: Scenario 1: Use NS and A glue records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the advantage of not requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. Using glue records has the additional restriction that the delegated name servers MUST be children of the 1.e164.arpa sub-domain, but results in reduced resolution time because there are fewer queries and network traversals required. Notice the extended domain names for acmes name servers. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa. IN NS ns2.acme.1.e164.arpa. ns1.acme.1.e164.arpa. IN A 192.249.249.1 ns2.acme.1.e164.arpa. IN A 192.249.249.2 Scenario 2: Use only NS records to delegate authority for the fully specified E.164 domain name to the registered name server. This approach has the disadvantage of requiring client resolvers and/or foreign name servers to additionally query for the A records associated with the defined name servers. By not using glue records, the delegated name servers are not required to be children of the 1.e164.arpa sub-domain. The result is increased resolution time due to additional queries and network traversals. 2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com. IN NS ns2.acme.com. In either scenario, the delegated name server must be minimally provisioned with an e164.arpa zone that contains the associated NAPTR records. It may be more conventional that the delegated name server be provisioned with the zone at the cut boundary (1.e164.arpa), but this is not a requirement. Are you attempting to avoid having the service registrar provision the e164.arpa zone on their name server? Bob _______________________________________________ enum mailing list enum@ietf.org http://www1.ietf.org/mailman/listinfo/enum