Current Meeting Report
Slides


2.7.21 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 08-Feb-02
Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
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/
Description of Working Group:
This working group has defined a DNS-based architecture and protocol [RFC 2916] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). The result of the ENUM query is a series of DNS NAPTR resource records [RFC2915] which can be used to contact a resource (e.g.URI) associated with that number.

The Working Group proposes to advance RFC 2916 from Proposed Standard to Draft Standard.

Background:

E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. E.164 numbers are used to identify ordinary phones, fax machines, pagers, data modems, email clients, text terminals for the hearing impaired, etc.

A prospective caller may wish to discover which services and protocols are supported by the terminal named by a given telephone number. The caller may also require more information than just the telephone number to communicate with the terminal.

The holder of an E.164 number or device may wish to control what URI's, are associated with that number.

Working Group Revised Goals and Scope:

1. The working group will update RFC 2916 to reference the DDDS system (revision of RFC 2915) and advance RFC 2916 to Draft Standard.

2. The working group will examine and document various aspects of ENUM administrative and/or operational procedures as Informational. Issues to be considered include privacy and security considerations in storing ENUM related data as well as validation and authentication of data, including DDDS NAPTR records in the DNS. The working group will coordinate activities in these areas with the DNSEXT WG and PROVREG WG when appropriate.

3. The Working Group will continue to maintain appropriate contact and liaison with standards bodies and groups, specifically ITU-T SG2, in order to provide technical or educational information as needed, such as the appropriate use of DNS. The Working Group will encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations or administration of RFC 2916.

Goals and Milestones:
Done   Initial draft of Service ENUM Requirements
Done   Initial draft of ENUM Protocol
Done   Revised draft of ENUM Protocol
Done   Submit ENUM Protocol document to IESG for publication as Proposed
Jun 02   Revise and update RFC 2916 appropriate to DDDS (revision of 2915) and advance to Draft Standard
Jul 02   Document appropriate ENUM Registration and Provisioning Procedures (Informational)
Aug 02   Document appropriate ENUM Operational Security, Privacy Issues and Procedures (Informational)
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2916PSE.164 number and DNS

Current Meeting Report

 Notes from the ENUM WG Meeting

WEDNESDAY, March 20, 2002; 0900-1130

IETF 53 Telephone Number Mapping (ENUM) WG

Agenda

Chair(s): Patrik Faltstrom <paf@cisco.com> and Richard Shockey <rich.shockey@neustar.biz>

Transport Area Advisor: Scott Bradner <sob@harvard.edu>

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 -

Slides

Extensible Provisioning Protocol Mapping for ENUM
Service Resolution ('Presence') ENUM Service
Ranalli-Walter ENUM-Service Draft
'draft-lind-enum-callflows-03'
ENUM Telephone Number Mapping
tel enumservice
2916bis