CHAIR: Richard Shockey (rshockey@ix.netcom.com) Scott Petrak (scott.petrack@metatel.com) Scribe: Jay Hilton (jhilton@telcordia.com) 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.