From daemon@optimus.ietf.org Mon Apr 1 16:38:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16070 for ; Mon, 1 Apr 2002 16:38:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13741 for enum-archive@odin.ietf.org; Mon, 1 Apr 2002 16:38:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12767; Mon, 1 Apr 2002 16:29:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11425 for ; Mon, 1 Apr 2002 16:02:04 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14781 for ; Mon, 1 Apr 2002 16:02:01 -0500 (EST) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g31L1Y808370 for ; Mon, 1 Apr 2002 16:01:34 -0500 Message-Id: <5.1.0.14.2.20020401141728.0269bdd8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 16:05:08 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Reminder that Patrik and Michael are drafting 2916bis Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At the meeting in Minneapolis Patrik asked that if anyone had specific text they wanted incorporated in the next revision of 2616 t to please forward those ASAP. Hopefully we can get back to work on this shortly since I believe some other WG's [ VPIM ] may be looking to incorporate the output in their drafts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Apr 1 16:41:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16135 for ; Mon, 1 Apr 2002 16:41:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13944 for enum-archive@odin.ietf.org; Mon, 1 Apr 2002 16:42:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12800; Mon, 1 Apr 2002 16:29:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11443 for ; Mon, 1 Apr 2002 16:02:05 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14783 for ; Mon, 1 Apr 2002 16:02:02 -0500 (EST) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g31L1Y808373 for ; Mon, 1 Apr 2002 16:01:34 -0500 Message-Id: <5.1.0.14.2.20020401142346.0262a950@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 01 Apr 2002 16:01:27 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] IETF 53 ENUM WG Minutes Preliminary Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 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 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 - 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-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: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Apr 1 18:20:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18721 for ; Mon, 1 Apr 2002 18:20:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19429 for enum-archive@odin.ietf.org; Mon, 1 Apr 2002 18:20:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19214; Mon, 1 Apr 2002 18:10:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19116 for ; Mon, 1 Apr 2002 18:10:45 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18599 for ; Mon, 1 Apr 2002 18:10:41 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19666 for ; Mon, 1 Apr 2002 18:09:08 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19659 for ; Mon, 1 Apr 2002 18:09:08 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] IETF 53 ENUM WG Minutes Preliminary Date: Mon, 1 Apr 2002 16:11:23 -0700 Message-ID: Thread-Topic: [Enum] IETF 53 ENUM WG Minutes Preliminary Thread-Index: AcHZxpHpQ5+IYOc4S6OwtIKy91iIPgACkXeQ From: "Zmolek, Andrew (Andrew)" To: "Richard Shockey" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA19119 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit 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:rich.shockey@NeuStar.com] > Sent: Monday, April 01, 2002 2:01 PM > To: enum@ietf.org > 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 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 > - 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Apr 1 22:39:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25045 for ; Mon, 1 Apr 2002 22:39:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01575 for enum-archive@odin.ietf.org; Mon, 1 Apr 2002 22:38:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00465; Mon, 1 Apr 2002 22:11:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00435 for ; Mon, 1 Apr 2002 22:11:10 -0500 (EST) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23799 for ; Mon, 1 Apr 2002 22:11:07 -0500 (EST) Received: from ENUM1 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GTX7K500.34Y; Tue, 2 Apr 2002 11:12:05 +0800 From: "bill" To: "Richard Shockey" Cc: Subject: re: [Enum] IETF 53 ENUM WG Minutes Preliminary Date: Tue, 2 Apr 2002 11:11:05 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.1.0.14.2.20020401142346.0262a950@popd.ix.netcom.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA00436 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Mr. Shockey: I remember that at the end of WG session, there is some consensus about the direction of the working group. I don't see it in the minutes. Bill CNNIC 2002/04/02 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 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 - 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-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: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Apr 5 07:28:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02778 for ; Fri, 5 Apr 2002 07:28:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26776 for enum-archive@odin.ietf.org; Fri, 5 Apr 2002 07:28:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26341; Fri, 5 Apr 2002 07:19:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25651 for ; Fri, 5 Apr 2002 07:00:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02247; Fri, 5 Apr 2002 07:00:55 -0500 (EST) Message-Id: <200204051200.HAA02247@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 05 Apr 2002 07:00:55 -0500 Subject: [Enum] I-D ACTION:draft-ietf-enum-epp-e164-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : Extensible Provisioning Protocol E.164 Number Mapping Author(s) : S. Hollenbeck Filename : draft-ietf-enum-epp-e164-00.txt Pages : 19 Date : 04-Apr-02 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-epp-e164-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-epp-e164-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020404153406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-epp-e164-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-epp-e164-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020404153406.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Sat Apr 6 16:25:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15756 for ; Sat, 6 Apr 2002 16:25:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04758 for enum-archive@odin.ietf.org; Sat, 6 Apr 2002 16:25:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04561; Sat, 6 Apr 2002 16:15:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04531 for ; Sat, 6 Apr 2002 16:15:43 -0500 (EST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15622 for ; Sat, 6 Apr 2002 16:15:39 -0500 (EST) Received: from user-2ivercu.dialup.mindspring.com ([165.247.109.158] helo=dick.ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16txXB-0003hW-00 for enum@ietf.org; Sat, 06 Apr 2002 16:15:41 -0500 Message-Id: <5.1.0.14.2.20020406161920.040167e0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 06 Apr 2002 16:19:29 -0500 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: RFC 3245 on History and Context of ENUM Operational Decisions Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >To: IETF-Announce: ; >Subject: RFC 3245 on History and Context of ENUM Operational Decisions >Cc: rfc-editor@rfc-editor.org >Date: Sat, 06 Apr 2002 11:55:26 -0800 >From: RFC Editor > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 3245 > > Title: The History and Context of Telephone Number > Mapping (ENUM) Operational Decisions: > Informational Documents Contributed to ITU-T Study > Group 2 (SG2) > Author(s): J. Klensin, Ed. > Status: Informational > Date: March 2002 > Mailbox: iab@iab.org > Pages: 10 > Characters: 23758 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-iab-itu-enum-notes-00.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3245.txt > > >RFC 2916 assigned responsibility for a number of administrative and >operational details of Telephone Number Mapping (ENUM) to the IAB. It >also anticipated that ITU would take responsibility for determining >the legitimacy and appropriateness of applicants for delegation of >"country code"-level subdomains of the top-level ENUM domain. >Recently, three memos have been prepared for the ITU-T Study Group 2 >(SG2) to explain the background of, and reasoning for, the relevant >decisions. The IAB has also supplied a set of procedural instructions >to the RIPE NCC for implementation of their part of the model. The >content of the three memos is provided in this document for the >information of the IETF community. > >This memo provides information for the Internet community. It does >not specify an Internet standard of any kind. Distribution of this >memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution.echo >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. >Content-Type: text/plain >Content-ID: <020406115353.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc3245 > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Apr 8 21:03:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11829 for ; Mon, 8 Apr 2002 21:03:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27249 for enum-archive@odin.ietf.org; Mon, 8 Apr 2002 21:03:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25630; Mon, 8 Apr 2002 20:45:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25602 for ; Mon, 8 Apr 2002 20:45:06 -0400 (EDT) Received: from whale.cnnic.net.cn ([159.226.6.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11501 for ; Mon, 8 Apr 2002 20:44:50 -0400 (EDT) Received: from ENUM1 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GU9ZG800.L8E; Tue, 9 Apr 2002 08:45:44 +0800 From: "bill" To: "Jay R. Hilton" Cc: Subject: Re: [Enum] IETF 53 ENUM WG Minutes Preliminary Date: Tue, 9 Apr 2002 08:44:49 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA25603 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit 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] _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Apr 9 10:28:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06557 for ; Tue, 9 Apr 2002 10:28:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23144 for enum-archive@odin.ietf.org; Tue, 9 Apr 2002 10:28:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22367; Tue, 9 Apr 2002 10:14:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22336 for ; Tue, 9 Apr 2002 10:14:53 -0400 (EDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06166 for ; Tue, 9 Apr 2002 10:14:50 -0400 (EDT) Received: from notes200.cc.telcordia.com (notes200.cc.telcordia.com [128.96.244.9]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA16873; Tue, 9 Apr 2002 10:08:15 -0400 (EDT) Subject: Re: [Enum] IETF 53 ENUM WG Minutes Preliminary To: "bill" Cc: enum@ietf.org, "Jay R. Hilton" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jay R. Hilton" Date: Tue, 9 Apr 2002 09:08:15 -0500 X-MIMETrack: Serialize by Router on notes200/Telcordia(Release 5.0.6a |January 17, 2001) at 04/09/2002 10:08:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 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 - _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu Apr 11 07:56:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24763 for ; Thu, 11 Apr 2002 07:56:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA11811 for enum-archive@odin.ietf.org; Thu, 11 Apr 2002 07:56:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11315; Thu, 11 Apr 2002 07:40:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10642 for ; Thu, 11 Apr 2002 07:30:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24284; Thu, 11 Apr 2002 07:30:17 -0400 (EDT) Message-Id: <200204111130.HAA24284@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 11 Apr 2002 07:30:17 -0400 Subject: [Enum] I-D ACTION:draft-rutkowski-enum-network-element-access-00.txt Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : FACILITATING PRIVATE COMPETITIVE PROVISIONING OF ENUM AS A PREFERRED TECHNICAL, OPERATIONAL,AND REGULATORY CHOICE Author(s) : A. Rutkowski Filename : draft-rutkowski-enum-network-element-access-00.txt Pages : Date : 10-Apr-02 ENUM is an Internet information service for the benefit of private users of the Internet. It makes use of authoritative E.164 telephone number data maintained among public telecommunication service providers to enable some useful value added messaging services on the Internet. Anyone can (and several companies do) provide these ENUM services competitively today without government involvement or regulation. Other providers can enter the marketplace. Although one ENUM provisioning option is to denominate a particular Internet offering worldwide as 'public' and 'authoritative,' there are significant technical, operational, and regulatory burdens and costs created that make the prospect rather daunting at best. It is also unnecessary. A more effective alternative is to facilitate ENUM service providers' access to authoritative E.164 number and customer information through fair and non-discriminatory contractual arrangements with public telecommunication service providers, and leave the rest to a competitive ENUM provider marketplace and the commercial relationships between Internet Service Providers and public telecommunication carriers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rutkowski-enum-network-element-access-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rutkowski-enum-network-element-access-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rutkowski-enum-network-element-access-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020410130932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rutkowski-enum-network-element-access-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rutkowski-enum-network-element-access-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020410130932.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri Apr 12 11:44:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07618 for ; Fri, 12 Apr 2002 11:43:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23430 for enum-archive@odin.ietf.org; Fri, 12 Apr 2002 11:43:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22320; Fri, 12 Apr 2002 11:30:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22213 for ; Fri, 12 Apr 2002 11:28:58 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05844 for ; Fri, 12 Apr 2002 11:28:53 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3CFSD826634 for ; Fri, 12 Apr 2002 11:28:14 -0400 Message-Id: <5.1.0.14.2.20020412111216.02d04eb0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Apr 2002 11:13:04 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] FINAL Minutes IETF 43 - ENUM WG Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org 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 - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum