RE: [Enum] IETF 53 ENUM WG Minutes Preliminary

["Zmolek, Andrew (Andrew)" <[e-mail]>]

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:[e-mail]]
> Sent: Monday, April 01, 2002 2:01 PM
> To: [e-mail]
> 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 <[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
>          - 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: [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

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