Notes from the ENUM WG Meeting WEDNESDAY, March 20, 2002; 0900-1130 IETF 53 Telephone Number Mapping (ENUM) WG Agenda Chair(s): Patrik Faltstrom and Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ Introductions and meeting expectations were completed. The Main Topics for discussion were identified as: - ENUM protocol registrations - NAPTTR service registration - Core document review - Documents of note not on agenda 1. AGENDA BASHING Moved the core document, rfc2916bis, to first in the agenda to set the tone for the discussions that followed. 2. NEW CHARTER REVIEW - Chairs The new, revised ENUM charter was briefly discussed. The charter had been discussed at length on the mailing list before the last IETF meeting. No additional items were thought necessary to be added or deleted. A copy of the current enum wg charter is available at http://www.ietf.org/html.charters/enum-charter.html 3. REVISED MILESTONES: The following milestones face the ENUM WG: June 2002: Revise and update RFC2916 appropriate to DDDS (revision of 2915) and advance to Draft Standard. July 2002: Document appropriate ENUM Registration and Provisioning Procedures (Informational). August 2002: Document appropriate ENUM Operational Security, Privacy Issues and Procedures (Informational) These milestones may be adjusted based on the progress made at this meeting. 4. CORE DOCUMENT REVIEW 4.1 RFC2916bis Update - The E.164 to URI DDDS Application; draft-ietf-enum-rfc2916bis-00.txt ABSTRACT: This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. Major Changes were summarized as: Section 1.2, Use of these mechanisms for private dialing plans (other than e.164 numbers Section 1.3, Application of local policy Section 2, ENUM applications specification; changed the specification of the service parameters. Allows for distinction of DDDS data bases. Section 3, registration mechanism for enum services. Copied from mime type registration documents, includes, function, naming, security and publication. Section 3.2.2, Registration template, must be used for enum services. There will be an update after this IETF. The author requested that specific text editing suggestions would be appreciated, rather than general statements that must be interpreted into specific text. 5. SERVICE FIELD DOCUMENTS 5.1 ENUM Service Descriptions, draft-walter-ranalli-enum-service-01.txt, Doug Ranalli. ABSTRACT: This document describes a set of ENUM resolution protocols and services that enable communication applications to interoperate with and unambiguously differentiate between multiple communications services associated with an E.164 telephone number. This document served as an introduction to a lengthy discussion of the enum services issue. The underlying assumptions for the discussion in this document were: - Enum is a service discovery application, not just protocol discovery. - Differentiating 1 service from another "might" require more information than protocol or URI type. - No one knows the "right answer" today. Further market experience is required. Doug commented that he had experience with service providers wanting to provide multiple services using the same E.164 number. To accomplish this, there is a need for more granularity in the service description. This would address the potential for 2 different service providers using same SIP format. Comments and questions regarding this draft included the following: Q: J.Rosenberg: does the 2nd line have the same tel #? In the Internet, the same # can be assoc w/multiple services. D.Ranalli: How do you separate one NPTR record from another for the different service? Q: R.Mahy: Already have a unique name on the Internet. What happens when someone on the Internet dials that? DR: You get back both NAPTR records and networks have to make a decision which NAPTR to use. P.Falstrom: When you get naptr records, the service field and priority tell which to use. DR: If the user wants enum to point to primary voice service, had to point to voice and then invent a new service type for the 2nd service. A.Zmolek: SIP takes care of this problem on its own. D.Ranalli: The 2 different service providers are running on two different SIP URIs. P.Falstrom: The ENUM is an opt-in service. The USER defines the priority. M.Mealing: The problem exists in enum. Remove sip because it exists outside of sip. If you get two tel urls, can not tell which to use. P.Falstrom: If you are not using 2916bis, this discussion does not matter. R.Shockey: Problem statement: 2 naptr, both sip. One is voice, one is instant messaging. J.Rosenberg: problem is do what I mean. Not what I say. H.Sinnreich: An example of multiple services would be a person that has sbc for local service, sprint for mobile (wireless)service and WorldCom for long distance service. Can do this today using SIP. Do you mean we have to change and use enum in the future? R.Shockey: Where is the correct place to put called party preferences? D.Oran: Is URI scheme not granular enough to resolve problem? M.Mealing: We do have a problem with granularity of URI scheme. P.Falstrom: 2916bis does not address this granularity. It solves the problem in a different way. D.Oran: Instance, versus type, discriminator is the problem. P.Falstrom 2916bis solves the URI resolution problem!!! Lets move forward in the presentation. D.Ranalli: This draft proposed that the URI scheme alone is not sufficient to discriminate. 2916bis, took core tenants of this draft and incorporated it into 2916bis, including IANA registration. We should move forward with enum services as defined in 2916bis. Make the registrations one rfc per enum service and one rfc at a time. D.Ranalli is happy with the way 2916bis does this. The Bis document captures all that was proposed in this ID. 5.2 THE USE OF ENUM BY SIP: draft-ietf-sipping-e164-01.txt, Jon Peterson ABSTRACT: Although SIP was clearly one of the primary applications for which ENUM was created, there is nevertheless widespread uncertainty about the demarcation of SIP location services from ENUM. This document attempts to sharpen the distinction between location services provided by the two protocols, illustrating how the two protocols might work in concert and clarifying the authoring and processing of ENUM records for SIP applications. SIP and enum issues: - How should naptr service fields for sip be structured? - What kinds of sip URIs should be stored in enum? Addresses of record or contact records? -What is sip for? Protocol for end points to discover one another and exchange context information about a session they would like to share. - How does enum benefit sip? MAIN ISSUES: - Propose should provision an address of record instead of the contact record. - Makeup of a session may change during the call/session, go from IM to voice. - Contact record is a device record. Would not give out the contact record for long term communication contact. - SIP has its own capabilities for negotiation. - Building enum records for SIP: - Single record for sip If there are multiple records, how does service provider choose? Record should contain address of record Devices will register their contact records under the Address of Record, devices should not be registered in enum. - SIP records should be preferred over alternatives. - Use Sip+E2U or E2U P.Pfautz: What if some one wanted to register other than the proposal. P.Falstrom: If agreed as an RFC the that should deal with issue. J.Peterson: No problem with 2916bis as it is written. M.Mealing: If you want a sip URI you must use E2U PF: want 1 enum service field for sip. What if have 2 sip URIs? Voice and IM. Should they be 1 or 2 naptr records? Look up in enum is not competing w/sip. JP: Proposing to use sip as opposed to enum to handle the situation of using an Address of Record then having Contact records under it. Greg: Are you proposing that sip should be used for near real time interactions? JP: sip can use this under contact recs. Sip is primarily used for interactive communication services. JR: that is the scope of the sip universe. R.Mahy: 3 different providers with different Address of Records. Kevin M.: Is the reason enum exists is for sip?? JP: see sections 3.4 and 3.5 for non-real-time URIs. This was directed to sipping. Happy to remove any traces of bigotry so that can go to last call in both groups. 5.3 ENUM SERVICE RESOLUTION, draft-zmolek-enum-pointer-00.txt ABSTRACT: Current notions of service field tags in ENUM NAPTR records would frame the service exposure problem as a tradeoff between the privacy and heft involved in revealing detailed service information on the one hand or the arbitrary constraint of such information on the other. This draft suggests an alternative approach that keeps NAPTR record size small, places service exposure policy and presence capabilities in the hands of the ENUM registrant where it belongs, and minimizes impact to the ENUM registrar and their respective DNS architecture. - Not planning to define presence. - Is enum a presence service? Update latency does not help. DNS caching does not help. - Is presence separate from SIP? - Why force enum to pick a winner now (sip)? URI indicates protocol - room for many. Same enum service field tag for all presence. - Consensus needed: - Is presence an enum service? Yes, it can be. - Update draft, move forward as a WG item Define enum presence service Suggest sip-based presence tag usage (coordinated w/JPs sip draft) Provide guidance for future presence service usage - Name for service tag? Suggest "pres" (or E2U+pres" per bis?) R.Shockey: Agreement that mapping presence to an E.164 number is a good thing. IMPP is defined in rfc2778/2779 L.Conroy: Already have presence service? How will this change it? AZ: If there is no interaction possibility, then you do not need a discriminator (options). Providing options is protocol specific and details not addressed in this draft. Need to discuss further on the list. J.Rosenberg:Consider embracing the definition of service resolution as put forward in Leslie Daigle's "napster" draft. Dave: Progress = now we hear that sip does everything. Lurking issue is service versus protocol. This s an important fundamental issue. We are starting to do things with protocols that give us many choices. One of the dangers that are emerging is that the DNS is becoming more of a search service. Discussion is probably an IAB discussion, however, this group will have to address. 5.4 THE ENUM TEL ENUM SERVICE, draft-brandner-enum-tel-00.txt ABSTRACT: This document describes the enum service 'tel' and how it is used with an ENUM application when indicated within a returned a NAPTR record. It gives guidelines for the treatment of records having this sub-field value, and for the onward processing of information gleaned from the enclosing NAPTR record. DISCUSSIONS: - This document is raising issues w/tel URI. - It could be useful for LNP. Need a parameter to indicate the routing number. Need to update rfc Option 1: LNPO in the golden tree. Ownership modification rights for that entry are clouded. Enum may be an opt-in service (it is an opt-in service). Who is going to pay (who is registrant?) Option 2: LNP in operator enum (opENUM). Do we need rfc 2916bis operator? Question on domain contents: What rr except naptr can exist w/in the golden tree? PF: Do not want a discussion on how to run DSN, here. Penn/Kevin: problem w/trying to store LNP information in an enum record. LNP records are stored and processed by carriers. Why try to store them in enum? RS: If you do not want to use SS7, you may want to use DNS as the source. J.YU: enum forum agreed to not combine LNP data in enum. Suggest using tel URI extensions to meet need. L.Conroy: No conflict with new YU draft. Content of main # is an Routing Number and not a DN. Trying to store static data in an LNP cloud for connectivity. Not appropriate to use an aux field to find this out. Telephony Service Provider (TSP) data in the tel URI has been discussed in sip/enum service. When look at the naptr you do not know who the TSP is. RS: What information is appropriate in the E164.arpa tree and what is appropriate in other trees? KM: If you want an LNP IP database, you may need this info. Does not support storing tsp info in the e164.arpa domain. RS: What is the application statement for the tel URI in the public e164.arpa, what do you want to do and why? L.Conroy: A call forwarding service(not itu std) Tel enum service implies that the URI you get will result in a telephone call to a PSTN terminal or a network that uses e164 numbers. ?? Obvious concerns with update time, etc. Obviously better ways to do this. 6.0 OTHER DOCUMENTS 6.1 Extensible Provisioning Protocol and E.164, draft-hollenbeck-epp-e164-02.txt EPP is a provreg WG item in IETF last Call. ??: Very useful to help with provisioning. It was agreed that this could be a WG item (Hum=yes). Will need to be aligned with 2916bis. IESG will review this and insure it is within the revised charter for ENUM. PF and RS: This class of activity is in the revised enum charter. 6.2 ENUM CALL FLOWS, draft-lind-enum-callflows-03.txt, Steve Lind S.Lind: Original intention was as an education document, targeted to the ITU. Put enum in context of traditional service offerings. Separated enum issues from other issues from an ITU perspective (e.g. internet telephony) Will not have new #s assigned to IP telephony. Will reuse existing tel #s. This is an informational document. RS: It was agreed to make this a WG item (Hum = yes) When do we move forward? Be cautious until we can finish debate on service fields. L.Conroy: Is call flows the right term? Maybe usage scenarios would be better. This can be an extremely useful document. 7. GENERAL DISCUSSION OF SERVICE FIELDS AND SERVICES: JR: People are trying to support a user preference model? PF: enum service is supposed to help to minimize the risk for false positives. Lots of input about taking a URI and then needing to restart. Heard today that if people are using sip URI, the risk is low for getting a false positive. If this is so, then only need a single enum service field. JR: Need to look at cases more discreetly. Such a email. Need to look at different usages to see if enum is appropriate for these. Requires a lot more discussion than is in 2916bis. PF: 2916bis is to help in this discussion. RS: Can use enum to find out capability of end points. MM: Need to be very clear on taxonomy when setting up URIs. What task needs to be solved? R Stasney: Several problems in how to map services to URIs. RS: WG needs to agree that registration procedure in 2916bis is correct and we are moving in the right direction. Agreed by WG (Hum = yes) JR: Using DNS for user choice/policy via different addresses is difficult, may not be appropriate for DNS. Important for anything that has an IANA registry that we provide guidance on what is the right thing to have a registry for. JR will send a message to the enum list. 8. NO DISCUSSION ON THE FOLLOWING: DOCUMENTS OF NOTE [ NOT ON AGENDA ] 8.1 US ENUM Forum Overview http://www.ietf.org/internet-drafts/draft-freilich-overview-enum-forum-00.txt 8.2 History and Context of ENUM Operational Decisions http://www.ietf.org/internet-drafts/draft-iab-itu-enum-notes-00.txt 8.3 Number Portability in the PSTN draft-ietf-enum-e164-gstn-np-03.txt Notes Respectfully submitted by Jay Hilton - end of notes -