[Enum] FINAL Minutes IETF 43 - ENUM WG

[Richard Shockey <[e-mail]>]

Notes from the ENUM WG Meeting

WEDNESDAY, March 20, 2002; 0900-1130

IETF 53 Telephone Number Mapping (ENUM) WG

Agenda

Chair(s): Patrik Faltstrom <[e-mail]> and Richard Shockey 
<[e-mail]>

Transport Area Advisor: Scott Bradner <[e-mail]>

Mailing Lists:
General Discussion:[e-mail]
To Subscribe: [e-mail]
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 -



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto: [e-mail]> or
<mailto: [e-mail]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum