Last Modified: 2004-09-07
Done | Initial draft of Service ENUM Requirements | |
Done | Initial draft of ENUM Protocol | |
Done | Revised draft of ENUM Protocol | |
Done | Submit ENUM Protocol document to IESG for publication as Proposed | |
Done | Revise and update RFC 2916 appropriate to DDDS (revision of 2915) | |
Done | ENUM service registrations for SIP and H.323 | |
Aug 03 | Document appropriate ENUM Security and Privacy Issues (Informational) | |
Nov 03 | Document appropriate ENUM Registration and Provisioning Procedures (Informational) |
RFC | Status | Title |
---|---|---|
RFC2916 | PS | E.164 number and DNS |
RFC3482 | I | Number Portability in the Global Switched Telephone Network (GSTN): An Overview |
RFC3761 | Standard | The E.164 to URI DDDS Application (ENUM) |
RFC3762 | Standard | ENUM Service Registration for H.323 URL |
RFC3764 | Standard | enumservice registration for SIP Addresses-of-Record |
Telephone Number Mapping WG (enum)
Monday, November 9 at 1930-2200 =============================== CHAIRS: Patrik Faltstrom <paf@cisco.com> Richard Shockey <rich.shockey@neustar.biz> 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/ Scribe: Spencer Dawkins - spencer@mcsr-labs.org AGENDA: AGENDA BASHING (5 min) Short Presentation on current status of ENUM in CC 1: Special Guest - Karen Mulberry MCI <>Karen is senior project manager for Numbering at MCI. She presented a Country Code 1 press release for a not-for-profit LLC (MCI, Sprint, Verizon are members now). $25K/year membership this year, all members equal, no limit on membership from interested parties, except cannot also be a vendor to the LLC. Most of the budget is liability insurance for the membership. </> 1. Problem is that 19 countries share "country code 1". This is the rat in the snake of ENUM deployment. All countries have to support delegation in order to make it happen. 2. Will write an RFC, will select one or more Tier One operators to operate a +1 ENUM registry. 3. Vision is that RFC goes to Tier Ones in June 2005, awarded/signed by October 2005, registry operational by January 2006. 4. http://www.enumllc.com is under construction now. 5. Are discussing a trial as soon as possible (before award, but after delegation). 6. Group is not chartered by anyone - US government has encouraged formation of this LLC, but can't be sure there are no alternatives in the woodpile. 7. IAB/ITU agreement is that ENUM delegation matches normal delegation perfectly. US and Canada can request the delegation, but no opposition is allowed (opposition will roadblock the delegation). 8. There is only one Tier One "A" vendors, but under that, there could be many Tier Two vendors. 1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it. New parameter for the "tel" URI to support ENUM, defined in http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt. * Support handling ENUM queries in SIP proxies, H.323 gatekeepers, other VoIP network elements. * Idea is that ENUM operations may result in repeated queries - want to give subsequent ENUM entities a list of queries that have already been performed, so they won't be repeated. This improves performance and reduces load on VoIP network elements. * Enumdi parameter isn't mandatory, so a VoIP network element that doesn't understand it will ignore it and still do the lookup. * Patrik - this needs to be a SHOULD NOT, not a MUST NOT. * Working group hum agrees... NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item. 2. [20 M ] Title : An ENUM Registry Type for the Internet Registry Information Service Author(s) : A. Newton Filename : draft-newton-iris-ereg-02.txt Pages : 45 Date : 2004-9-28 This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt * IRIS uses multiple layers, XML, NAPTR records. * Want to provide ENUM Registry (EREG) . Similar to DREG registry, with its own identifier namespace. * Implementation available at irisverisignlabs.com. * Supports both UDP and TCP (using BEEP). * Does not require universal adoption Working group interest? Seems like enough interest to adopt, no opposition but a lot of "don't cares", too. Chairs Conclusion : Adopt as a WG item NEW ITEMS : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process. 3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author(s) : B. Hoeneisen Filename : draft-hoeneisen-enum-validation-epp-00.txt Pages : 17 Date : 2004-9-30 This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.txt * The goal here is to know a lot more about who registered an E.164 domain than we know about who registered a plain, vanilla DNS domain. * Austria, Switzerland, - who doesn't need something like this? We vote Country Code 1, of course, but no conclusions here (except that we know we have a problem). CC1 has external databases that you may not have in Europe, so not sure if CC1 would use the same approach or not. * This has a lot of interactions with number portability (which is done differently in CC1 and in Europe - they call-forward instead of doing a database lookup. * If your country code considers ENUM deployment, all these issues pop up instantly. 4. [ 20 M ] ENUM Validation Architecture and Token Format Definition - Alexander Mayrhofer A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt * What's the incentive for legacy carriers to contribute to validation for ENUM? We think it's close to zero. Most others (users, porting process/NPAC, etc.) are more likely to participate. * We need to accommodate consumer choice, not set up the next monopoly. * Centralized validation agents? Multiple validation agents? Number range holder = registrar? No single solution works best, so define Validation Entity as a role, not as an agency. * Question - where is the end user in all this? This validation flows one way (registrars validated registrants, not the other way around). What about the danger of slamming as we had in US long distance competition? * Question - we are getting from the problem statement to the solution - what are the requirements? Should a validation token be traceable to a verifier? * Question - are validation tokens signed, or encrypted and signed? Sweden has a distinction between validation entities and registration entities, and they don't share data, especially about customers. * Question - can the ENUM WG clear up the trust model here? * Question - what about cancelling tokens? New tokens override old ones, but there's an explicit cancel as well. What's still needed here? Definition of terms. Will this be one document or two (a framework and a specific implementation)? Will work on one document (framework, roles, requirements, definitions) during next IETF cycle (confirm this on the mailing list). ONGOING WORK: Title : IANA Registration for Enumservice VOID Author(s) : R. Stastny, L. Conroy Filename : draft-ietf-enum-void-00.txt Pages : 0 Date : 2004-10-12 This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt *** Older business: Title : ENUM Implementation Issues and Experiences Author(s) : L. Conroy, K. Fujiwara Filename : draft-ietf-enum-experiences-01.txt Pages : 26 Date : 2004-10-25 This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-01.txt * Want to get implementers' experience in next 30 days for WGLC by yearend. Title : IANA Registration for ENUMservices email, fax, mms, ems and sms Author(s) : R. Brandner, et al. Filename : draft-ietf-enum-msg-03.txt Pages : 20 Date : 2004-10-21 This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-03.txt |