Subject: RE: [Enum] IETF 53 ENUM WG Minutes Preliminary

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Mon, 1 Apr 2002 16:11:23 -0700

Two items-

1. small nit: Zmolek has no "c"

2. (5.3) During my discussion on draft-zmolek-enum-pointer-00 Jonathan Rosenberg asked that I consider embracing the definition of service resolution as put forward in Leslie Daigle's "napster" draft (draft-daigle-napstr-00.txt). 

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 2:01 PM
> To: [email-masked]
> Subject: [Enum] IETF 53 ENUM WG Minutes Preliminary
> 
> 
> Preliminary notes from the ENUM WG Meeting
> 
> Once again I'd like to thank Jay Hilton for a outstanding job here of 
> capturing the fast and furious discussions.
> 
> If there are any comments, additions deletions or rewrites 
> please post them 
> ASAP
> 
> ################
> 
> WEDNESDAY, March 20, 2002; 0900-1130
> 
> IETF 53 Telephone Number Mapping (ENUM) WG
> 
> Agenda
> 
> Chair(s): Patrik Faltstrom <[email-masked]> and Richard Shockey 
> <[email-masked]>
> 
> Transport Area Advisor: Scott Bradner <[email-masked]>
> 
> Mailing Lists:
> General Discussion:[email-masked]
> To Subscribe: [email-masked]
> 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
>          - NAPTR 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 inter 
> operate 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.Zmoleck:  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.
> 
> 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?
> 
> P. Faltstrom:  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 Stastny:  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-en
um-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: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

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

---

From: "bill" <[email-masked]>
Date: Tue, 9 Apr 2002 08:44:49 +0800

Jay Hilton:

Thank for you reply. For I am not a native English speaker, so I am not very clearly getting up with the process especially in the fast ending of the last ENUM WG session. There do have the consensus about the direction of the 2916bis. And may there  be any agreement about other documents in process? I raised the question in the list in order to make me more clear about the direction of the ENUM WG.

Thank again.

Bill

CNNIC

2002/04/09[GMT+8]

---

From: "Jay R. Hilton" <[email-masked]>
Date: Tue, 9 Apr 2002 09:08:15 -0500

Bill:

I have summarized the decisions (or lack of) made for each document
discussed in the ENUM WG at IETF #53 below.  I hope this will help you.

If you have any further questions, please do not hesitate to contact me.

Best regards,

Jay Hilton
===============================

Document:  Status/Decision

1) Revised Charter:  Adequate discussion on the email list.  No further
changes proposed.  Accepted.

2) Milestones:  May be adjusted as a result of the discussions in the enum
meeting at IETF#53.  No agreements at the meeting to specific date changes.

3) RFC2916bis:  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.

4) draft-walter-ranalli-enum-service-01.txt:  The Bis document (rfc2916bis)
captures all that was proposed in this ID.

5) draft-ietf-sipping-e164-01.txt:  The author will be, "Happy to remove
any traces of bigotry so that can go to last call
in both groups."  JRH:  My expectation is that the author will complete
required edits and then request a WG Last Call (SIPPING and ENUM).

6) draft-zmolek-enum-pointer-00.txt:  The author will revise the document
including "Consider embracing the definition of service resolution as put
forward in Leslie Daigle's "napster" draft", coordinate with the
sipping-e164 draft above and resubmit for discussion.

7) draft-brandner-enum-tel-00.txt:  No agreement on this document.  Some
concerns were expressed, including the "enum forum agreed to not combine
LNP data in enum.  Suggest using tel URI extensions to meet need."

8) draft-hollenbeck-epp-e164-02.txt:  "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.  P.Falstrom and
R.Shockey: This class of activity is in the revised enum charter."

9) draft-lind-enum-callflows-03.txt:  It was agreed to make this a WG item
(Hum = yes)

10) draft-freilich-overview-enum-forum-00.txt:  For information only, no
discussion in meeting.

11) draft-iab-itu-enum-notes-00.txt:  For information only, no discussion
in meeting.

12) draft-ietf-enum-e164-gstn-np-03.txt:  For information only, no
discussion in meeting.

- end -