RE: [Enum] ENUM FAQ

["Michael Froomkin - U.Miami School of Law" <[e-mail]>]

Currently ICANN's rules prohibit registrars and registries from
offering privacy-enhanced registration services akin to "unlisted"
phone numbers.  To be fair, this policy was inherited from the prior
regime (NFS/NSI), although ICANN's UDRP rules for removing domains from
registrants give the current policy much greater teeth than the old one
had. 

I have often wondered if the no-privacy policy contravenes European
privacy law. I certainly don't think it is a good rule, and efforts to get
ICANN to reform it will be welcome -- although they will be met with
reflexive cries of horror by the copyright lobby, which thinks that DNS
records help it trace copyright violators.  [I've never understood that
argument, since I would have thought what you need is the physical address
of the host machine, which is quite a separate matter, but there you go.]

I agree this is a major issue.

On Sat, 29 Jul 2000 [e-mail] wrote:

> Richard,
> 
> Thanks for the FAQ.  I've only done a quick reading of it,
> but I think it should be very useful.  One thing that I
> would like added would be more about security / privacy.
> 
> Is there a way to grant/deny access to certain DNS
> records?  I haven't seen any.  My 'fear' would be that
> I would have many services in my personal ENUM DNS record
> and then be harrassed by all sorts of new spam, SIP SPAM,
> email SPAM, telemarketers, etc.
> 
> cheers,
> John
> 
> > -----Original Message-----
> > From: EXT Richard Shockey [mailto:[e-mail]]
> > Sent: July 26, 2000 23:47
> > To: [e-mail]
> > Subject: [Enum] ENUM FAQ
> > 
> > 
> > Since our work may be entering a new phase ..I've taken the 
> > liberty to 
> > trying to pull together some thinking about ENUM into a FAQ.
> > 
> > This will probably not be a WG document but if any of you 
> > would like to 
> > contribute questions answers or comment on it generally you 
> > are welcome to 
> > do so.
> > 
> > ################
> > 
> > 
> > 
> > 
> > ENUM Working Group                                            
> >   Richard Shockey
> > Internet-Draft: DRAFT-SHOCKEY-ENUM-FAQ-00.TXT           NeuStar, Inc
> > Expiration <1/2001>                                           
> >   July 26, 2000
> > 
> > 
> >                          FREQUENTLY ASKED QUESTIONS ABOUT ENUM
> > 
> > This is a very preliminary draft.  It has not been reviewed 
> > or accepted by 
> > the working group.  Comments are eagerly sought, as are 
> > suggestions for 
> > additional questions and alternative answers.
> > 
> > Status Of This Memo
> > 
> > This document is an Internet-Draft and is in full conformance with all
> > provisions of Section 10 of RFC2026.
> > 
> > Internet-Drafts are working documents of the Internet Engineering Task
> > Force (IETF), its areas, and its working groups.  Note that 
> > other groups 
> > may also distribute working documents as Internet-Drafts.  
> > Internet-Drafts 
> > are draft documents valid for a maximum of six months and may 
> > be updated, 
> > replaced, or obsoleted by other documents at any time.  It is 
> > inappropriate 
> > to use Internet-Drafts as reference material or to cite them 
> > other than as 
> > "work in progress."
> > 
> > The list of current Internet-Drafts can be accessed at
> > http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
> > Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
> > 
> > This document and related documents are discussed on the IETF 
> > Enum mailing 
> > list. To join the list, send mail to <mailto:enum-
> > [e-mail]?body=subscribe>.
> > 
> > To contribute to the discussion, send mail to  
> > <mailto:[e-mail]> The 
> > Enum working group charter, including the current list of 
> > group documents, 
> > can be found at http://www.ietf.org/html.charters/enum-charter.html.
> > 
> > 
> > Copyright Notice
> > Copyright (C) The Internet Society (2000).  All Rights Reserved.
> > 
> > ABSTRACT
> > 
> > The IETF ENUM work group has been chartered to develop 
> > protocols that map 
> > telephone numbers to resources typically found on the 
> > Internet , such as 
> > URI's, using the Domain Name Service. It has been proposed 
> > that a global 
> > ENUM service be created in the e164.arpa domain. How 
> > e164.arpa should be 
> > organized and administered is now a serious issue confronting 
> > the Internet 
> > Community.  This document is provided as a list of common 
> > questions, and 
> > their answers, concerning E.164 numbers and their use on the 
> > Internet.  Knowledge of Domain
> > Name Service technology is assumed.
> > 
> > INTRODUCTION
> > 
> > The IETF ENUM work group has been chartered to develop 
> > protocols that map 
> > telephone numbers to Internet resources.  The working group 
> > charter is 
> > specified at:
> > 
> > <http://www.ietf.org/html.charters/enum-charter.html>
> > 
> > A Goals and Requirements specification is under active discussion.
> > The current draft is:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-rqmts-01.txt>
> > 
> > The central ENUM protocol document is:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-02.txt>.
> > 
> > It describes the technique whereby a globally unique E.164 
> > telephone number 
> > is placed under a single DNS administrative domain. Using classic DNS 
> > resolution, a client application could then discover 
> > resources associated 
> > with that number from NAPTR or SRV Resource Records.
> > 
> > Several application developers and telecommunications service 
> > providers 
> > have expressed interest in quickly deploying ENUM based services.
> > 
> > It has been proposed that a global ENUM service be created in 
> > the e164.arpa 
> > domain.
> > 
> > How e164.arpa should be organized and administered is now a 
> > serious issue 
> > confronting the Internet Community.
> > 
> > FREQUENTLY ASKED QUESTIONS
> > 
> > WHAT IS ENUM?
> > 
> > ENUM stands for Telephone Number Resolution. It is a 
> > chartered WG of the 
> > IETF <http://www.ietf.org>.  The reason the work group exists 
> > is detailed 
> > in its charter. The URL is listed above.
> > 
> > There have been numerous experimental trials of DNS based 
> > resolution of
> > telephone number resources. The most significant of those was 
> > the TPC.INT 
> > fax experiment described in RFC 1709. Many of the concepts 
> > use by ENUM came 
> > out of that early work
> > 
> > 
> > WHAT BENEFITS DOES ENUM GIVE TO USERS?
> > 
> > The main benefits are:
> > 
> > ENUM enables calling users or entities to make a selection 
> > from the range 
> > of services that are available especially over the Internet for
> > communicating with a particular person or entity when the calling user
> > knows only their telephone number.
> > 
> > ENUM enables users to access Internet based services and 
> > resources from
> > ordinary telephones where they are only be able to input digits
> > 
> > ENUM enables users to specify their preferences for receiving incoming
> > communications (eg specifying a preference for voicemail 
> > messages over live 
> > calls or indicating a destination for call forwarding). ENUM 
> > will give much 
> > improved user control over communications.
> > 
> > There are many potential applications for ENUM and some are 
> > discussed in 
> > this document.
> > 
> > WHAT IS E.164?
> > 
> > E.164 is the international telephone numbering plan [Document 
> >  ITU-T E.164] 
> > written and administered by the International 
> > Telecommunication Union (ITU) 
> > in Geneva <http://www.itu.int>. The plan specifies the 
> > format, structure, 
> > and administrative hierarchy of telephone numbers. At the 
> > root of the E.164 
> > administrative hierarchy, the ITU issues country codes to sovereign 
> > national entities and thereby allocates new telephony 
> > numbering resources 
> > as needed. In addition there are other allocations for services and 
> > networks.  Administration of telephone numbers within each country is 
> > officially governed by the appropriate national telecommunications 
> > regulatory agency (e.g. FCC in the US,
> > CRTC in Canada, Oftel in UK).  The regulator or their 
> > designated contractor 
> > performs the actual national number resource administration itself.
> > 
> > HOW DOES ENUM WORK?
> > 
> > The enum solution  is driven , in part by the fact that most 
> > telephony 
> > users have telephone keypads [ 12 digit ] to work with.
> > 
> > 1. A phone number is translated intoE.164 form by in 
> > concluding country 
> > code or area/city code, e.g. 918-9020 dialed in St. Louis would be 
> > translated to [phone], where +1 is the North American 
> > country code.
> > 2. Remove all character parts from the digits. Example: 13149189020
> > 3. Reverse the order of the digits. Example: 02098194131
> > 4. Put dots (".") between each digit. Example: 0.2.0.9.8.1.9.4.1.3.1
> > 5. Append the domain "e164.arpa" to the end.  Example: 
> > 0.2.0.9.8.1.9.4.1.3.1.e164.arpa
> > 6. Perform a DNS query on this domain
> > 7. Retrieve relevant NAPTR Resource records from the Name 
> > Server for this 
> > number and perform whatever relevant application required.
> > 
> > WHY THE FUNNY REVERSAL OF THE NUMBER AND WHAT ARE ALL OF 
> > THOSE DOTS FOR?
> > 
> > Each dot separates the number into administrative "domains" 
> > or zones in DNS 
> > terms. This accommodates delegation of authority at varying points 
> > throughout the e164.name space thereby avoiding the 
> > imposition of either a 
> > fixed delegation scheme worldwide or requiring clients to 
> > know that scheme 
> > in order to know where to put the dots. Delegation in a DNS name is 
> > structured from right to left. This
> > is very important. See: 
> > <http://www.rfc-editor.org/rfc/rfc2672.txt> for 
> > more details
> > 
> > AM I GOING TO HAVE TO TYPE IN THOSE DOTS AND REVERSED NUMBERS 
> > TO USE ENUM?
> > 
> > Definitely not!  Your application will take care of all of 
> > this for you. 
> > You just enter in a phone number like you always do, into whatever 
> > application or device that supports ENUM, and it  will take 
> > care of the 
> > conversion.
> > 
> > WHY THE .ARPA TOP LEVEL DOMAIN?
> > 
> > The .arpa domain has been designated to be used for Internet 
> > Infrastructure 
> > purposes. It is managed by the IANA in cooperation with the Internet 
> > technical community under the guidance of the Internet 
> > Architecture Board. 
> > The e164.arpa domain is believed to be the most appropriate 
> > place to host 
> > the e164 namespace on the Internet.  ENUM constitutes an 
> > infrastructure 
> > support function by virtue of it providing a set of DNS-based 
> > resource 
> > directories, referenced by phone
> > number, for use by various ENUM-enabled application clients (e.g. 
> > telephones, SIP servers, voice messaging systems).  ENUM will 
> > not be used 
> > directly by people as a new way of navigating to web sites.  
> > Consequently, 
> > ENUM is an infrastructure application appropriate for use within the 
> > designated .arpa domain established for these purposes.
> > 
> > WHAT ARE SRV AND NAPTR RECORDS?
> > 
> > These are DNS Resource Records that will contain information 
> > about what 
> > Internet resources, services or applications that are 
> > associated with a 
> > particular phone number. Subscribers determine what those 
> > services are.
> > 
> > For more information, see:
> > 
> > SRV :  <http://www.rfc-editor.org/rfc/rfc2782.txt>
> > NAPTR  :  
> > http://search.ietf.org/internet-drafts/draft-ietf-urn-naptr-rr-03.txt
> > 
> > WHAT KINDS OF APPLICATIONS COULD USE ENUM?
> > 
> > Since ENUM provides a generic way to perform telephone number-based 
> > resource discovery, there are lots of examples of ENUM-enabled 
> > applications, but several have come to the forefront. The 
> > voice messaging 
> > industry has been hard at work developing a comprehensive 
> > mechanism by 
> > which voice mail systems could exchange messages over IP 
> > networks. This 
> > work is called VPIM, or Voice Profile for Internet Messaging. 
> > http://www.ietf.org/html.charters/vpim-charter.html. The
> > industry has been looking for a way to discover the host name 
> > and domain 
> > for Internet based voice mail servers. The problem has been 
> > that a typical 
> > voice mail user only has a telephone number and a telephone 
> > keypad to work 
> > with. ENUM permits these VPIM servers to locate each other 
> > and exchange 
> > messages.
> > 
> > Clearly the most active interest in ENUM service has been in Internet 
> > Telephony. It has been a long standing goal of the Voice over 
> > IP (VoIP) 
> > industry to make a phone call over the Internet as simple to 
> > make as a 
> > regular PSTN call.
> > 
> > ENUM links a telephone number to a host or resources on the 
> > Internet that 
> > can connect the call, either end to end over IP networks or through a 
> > designated gateway to the PSTN. This would be very useful for 
> > connecting 
> > SIP <http://www.ietf.org/html.charters/sip-charter.html> or 
> > H.323-capable 
> > endpoints that exist across domain boundaries.
> > 
> > ENUM is general enough that multiple discrete services 
> > (applications) may 
> > all be associated with the same telephone number at the same 
> > time, each 
> > application associated with their own unique endpoint resources as 
> > provisioned in ENUM, assuming the subscriber has the 
> > appropriate clients 
> > supporting those services.  ENUM does not require that all 
> > such telephone 
> > number-based services be provided by the same service 
> > provider (telco, ISP, 
> > whatever), even though the subscriber's right to use that particular 
> > telephone number may only flow from their having subscribed to one of 
> > them.Won't ENUM telephone routing confuse the
> > regular, PSTN routing system?
> > 
> > ENUM facilitates the discovery of resources associated with a 
> > telephone 
> > number, and hence facilitates how various applications will identify 
> > appropriate peer servers associated with an intended 
> > end-user.  It does 
> > not, however, impact how those applications will operate once 
> > the location 
> > of an end-user associated application server has been 
> > established.  Consequently, ENUM doesn't affect application-level 
> > functions, such as call routing, signaling, etc., regardless
> > of the underlying application technology employed (ISUP, SIP, 
> > H.323).  . 
> > [For example, see TRIP 
> > <http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-02.txt>]. 
> > However it is possible that a telephone company call-routing 
> > mechanism 
> > could use ENUM technology as well.
> > 
> > It is a core principle that in providing a unified resource discovery 
> > service, that ENUM will not change the existing right-to-use 
> > rules and 
> > principles for telephone numbers.  ENUM is not intended to change how 
> > telephone numbers are administered, but instead facilitate a 
> > wide range of 
> > applications using phone numbers as subscriber names.  
> > Lastly, ENUM will 
> > not interfere with existing PSTN functions and technology, 
> > such as circuit 
> > switching, SS7 (ISUP or TCAP), or IN (Intelligent Networking), where 
> > similar resource discovery activities are performed through 
> > the PSTN legacy 
> > technologies.
> > 
> > WHAT PROTOCOL DOES ENUM USE FOR INTERNET TELEPHONY?
> > 
> > ENUM itself is "protocol agnostic" because it's application 
> > agnostic.  It 
> > does not specify what applications a particular telephone number is 
> > associated with, but instead provides a unified way of discovering 
> > resources associated with it.  For example it can work with 
> > either H.323 or 
> > the Session Initiation Protocol [SIP].See 
> > <http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-dns-00.txt>
> > for further details.
> > 
> > I'VE HEARD THIS VOICE OVER IP STUFF DOESN'T WORK.? THERE ARE LOTS OF 
> > ARTICLES IN THE TECHNICAL PRESS THAT SAY IT JUST DOESN'T WORK.
> > 
> > VoIP is an evolving technology that is in an early stage of 
> > development but 
> > rapidly improving. It is only a question of when, not if, Internet 
> > Telephony will become a reality, fully integrated with the 
> > existing, global 
> > telephone service.  This is an orthogonal issue to ENUM, as 
> > ENUM is not 
> > intended solely to facilitate VoIP, but a range of 
> > applications where a 
> > telephone number is used as a subscriber name.
> > 
> > DO I "OWN" MY PHONE NUMBER?
> > 
> > The ITU provides guidelines for the structure of phone numbers.  They 
> > allocate part of the structure of the phone number, the 
> > country code, to 
> > countries.  Each country's national regulatory agency (NRA) 
> > determines the 
> > remaining structure of the phone numbers within their 
> > country.  The NRA 
> > also designates a national number administrator (NNA), in 
> > many countries 
> > the NRA is the NNA.  The NNA allocates blocks of numbers to 
> > communications 
> > service providers.  Communications service providers allocate 
> > numbers to 
> > their users.  When a user disconnects
> > their service, after an appropriate aging interval, the 
> > number becomes an 
> > available resource to the service provider for the purposes 
> > of reassignment 
> > to a new or different user.
> > 
> > It is generally accepted that there are  no property rights 
> > associated with 
> > numbers. That means you cannot sell your telephone number to 
> > someone else, 
> > unlike the fact that you could sell an Internet domain name 
> > under your 
> > control.  As a matter of fact user's phone numbers get 
> > changed without 
> > their consent quite frequently.  In the US, for example, it 
> > results from an 
> > area code split, where the 3-digit area code prefix is changed in the 
> > user's geographic area, but usually not the last 7 digits.  
> > However, when 
> > this happens, the user no longer
> > has the same 10-digit phone number they once had.
> > 
> > It is becoming more common for users to have more control 
> > over their phone 
> > numbers.  In many countries with rules and regulations about 
> > telephone 
> > number portability, you can take your telephone number from 
> > carrier to 
> > carrier or from service type to service type (e.g., land-line 
> > to mobile) as 
> > you wish. Regulations vary from country to country.
> > 
> > Within the ENUM community it is the general view that the telephone 
> > subscriber representatives [ISP's, carriers, etc],  would be 
> > allowed to
> > determine what resources are associated  with that telephone 
> > number within 
> > the ENUM service.
> > 
> > 
> > WHAT HAPPENS TO THE NUMBER WHEN A SUBSCRIBER PORTS FROM ONE SERVICE 
> > PROVIDER TO ANOTHER?
> > 
> > When a number ports, the service provider of record changes.  
> > That is the 
> > industry now recognizes a different service provider as the 
> > holder for that 
> > particular number.  This is important for routing and billing 
> > purposes.
> > 
> > The subscriber should still be able to continue using their 
> > ENUM-enabled 
> > services, assuming their new service provider(s) support 
> > them.  Naturally, 
> > the actual location of server resources identified by ENUM 
> > will likely 
> > change as the subscriber changes any of the underlying 
> > service providers.
> > 
> > When the user disconnects the number goes back to the original service
> > provider's inventory, not to the new service provider's inventory.
> > 
> > WHAT HAPPENS TO THE ENUM SERVICES WHEN A SUBSCRIBER CANCELS 
> > TELEPHONE SERVICE?
> > 
> > As we now know the number returns to the communications 
> > service provider's 
> > inventory for the purposes of reassignment.  The subscriber 
> > that cancels 
> > their telephone service will have to cancel the associations 
> > that number 
> > has with all ENUM services, even those provided by other service 
> > providers.  If this was not done the new user of that 
> > telephone number 
> > could have a conflict with the old user.  On the other hand, 
> > where number 
> > portability is available, a user has the option of porting 
> > their number 
> > over to a new service provider instead of canceling their 
> > existing service 
> > and losing their current number.
> > 
> > COULD ENUM BE USED TO PROVIDE TELEPHONE NUMBER PORTABILITY?
> > 
> > In those countries that do not yet have a centralized database 
> > administration service, having a shared directory service 
> > like ENUM might 
> > be of interest.  However, ENUM is not intended to serve this 
> > function, as 
> > there are very
> > significant technical, regulatory, security, and operational 
> > limitations in 
> > using ENUM for this purpose.  ENUM is a shared resource 
> > discovery service, 
> > not an industry provisioning service.  In most countries where number 
> > portability is deployed, telephone service providers are 
> > generally required 
> > to comply with regulatory/industry processes, procedures, and 
> > systems, 
> > regardless of the underlying technology they employ for 
> > telephony service 
> > delivery (SIP, H.323, circuit-switched, or string-and-cans).  
> > How ENUM is 
> > administered in those countries will also likely require mirroring of 
> > provisioning rules (e.g. anti-slamming) employed for number 
> > portability and 
> > number administration so as to ensure that service providers using 
> > ENUM-enabled services do not violate applicable regulatory rules or 
> > industry guidelines.  ENUM is another downstream use of numbering 
> > provisioning and administration activities, and will need to 
> > be deployed 
> > consistent with applicable national requirements, it does not 
> > create an 
> > alternate numbering universe with its own set of rules and policies.
> > 
> > HOW IS THE USER OF A NUMBER AUTHENTICATED?
> > 
> > Users could be corporations, individuals, government 
> > agencies, military, 
> > and hosts of other non-individual users.  Service providers typically 
> > assign large blocks of numbers to these entities.  The 
> > telecom manager 
> > within these entities then assigns numbers to users.  So even 
> > the service 
> > providers cannot identify the users for a very large portion of the 
> > allocated numbers.
> > 
> > This is an unresolved issue but one that must be resolved prior to 
> > deploying a robust and secure ENUM service.  It's likely that 
> > the service 
> > provider that allocated the number(s) to the user will be 
> > involved in the 
> > process of authentication.
> > 
> > WELL WHAT ABOUT PRIVATE NUMBERING PLANS WITHIN A COMPANY?
> > 
> > Excellent question. The ENUM protocol can be used in private 
> > numbering 
> > plans the same way it can be used in the public E.164 number 
> > plan.  The 
> > Internet Telephony gateway or proxy needs some intelligence 
> > to "decode" a 
> > particular dialing string and then decide how to look up 
> > resources for that 
> > particular number. Instead of looking for resources in e164.arpa the 
> > gateway or proxy would look for SRV or NAPTR records for 
> > private numbers 
> > under some other structure, such as
> > e164.bigcompany.com .
> > 
> > WHAT ABOUT EMERGENCY SERVICES LIKE 911 OR 112 [EUROPE]?
> > 
> > In general, emergency service numbers are "access codes" and 
> > not "E.164
> > numbers", and will not be part of ENUM services.
> > 
> > HOW WILL THE E164.ARPA DOMAIN BE ORGANIZED?
> > 
> > One convenient way of doing this would be to delegate 
> > according to the 243 
> > country codes designated by the ITU.  It's important to understand, 
> > however, that delegation in DNS can occur at any digit, or 
> > zone domain in 
> > DNS terms
> > 
> > So within the root e164.arpa there would be an NS listing for 
> > 1.e164.arpa 
> > representing the top level of the North American Numbering Plan. [US, 
> > Canada, and several Caribbean countries]
> > 
> > A NS listing for -.4.4.e164.arpa - representing the top level 
> > (44) of the UK
> > A NS listing for - 4.6.e164.arpa - representing the top level (46) 
> > of  Sweden.
> > A NS listing for - 8.1.e164.arpa - representing the top level 
> > (81) of Japan.
> > A NS listing for - 8.5.3.e164.arpa - representing the top 
> > level (358) of
> > Finland.
> > 
> > At the national TN/NS level further NS delegation [DNAME, 
> > CNAME, PTR] can 
> > occur to enterprises, TN/NS application service providers, 
> > carriers, and 
> > even individuals who have DNS servers in their house.
> > 
> > WHO WILL ADMINISTER THESE NATIONAL TELEPHONE NUMBER NAME SERVERS?
> > 
> > There are many competent companies or organizations that can 
> > operate these 
> > servers. A number of companies have already come forward to 
> > express their 
> > interest in running these servers, initially free of charge and on an 
> > experimental basis, until such time as consensus can be 
> > reached on how this 
> > system is to ultimately organize.
> > 
> > Some theories on how this system will be organized on a 
> > permanent basis 
> > will be discussed a little later in this FAQ.  There are a number of 
> > regulatory constraints in various countries that might apply 
> > on the ENUM 
> > administrator, name service operators, as well as delegation 
> > policies below 
> > the national level.  For example, where local telephony 
> > service competition 
> > and number portability are being deployed in a country, it is 
> > not unusual 
> > that a neutral third party is required to provide master database 
> > administration services, and a requirement for anti-slamming and 
> > non-reliance on competing carriers for routing or
> > resolution functions.
> > 
> > AM I ULTIMATELY GOING TO HAVE TO PAY TO HAVE MY TELEPHONE NUMBER ENUM
> > PROVISIONED?
> > 
> > Probably yes, but most likely the costs will be indirectly recovered 
> > through the underlying prices for ENUM-enabled services that 
> > subscribers 
> > pay. This is a DNS-based system. If you want a domain name 
> > registered in 
> > DNS someone must pay for that. Listing telephone numbers will be no 
> > different.  Whether the cost will be charged directly to the 
> > subscriber or 
> > will be an indirect charge as part of some larger services 
> > will depend on 
> > those offering the services.
> > 
> > Remember you do not have to ENUM list your phone number. ENUM 
> > would be a 
> > subscriber-controlled "opt-in" system to "announce", over the 
> > Internet, the 
> > availability of a particular telephone number to accept 
> > service sessions 
> > and how to manage those sessions as a result of having 
> > subscribed to an 
> > ENUM-enabled service. If you do not have an Internet 
> > telephony device or 
> > service you will likely not need to list your number.  On the 
> > other hand, 
> > subscribers may not necessarily be aware they've subscribed to such a 
> > service, and have had ENUM provisioned for that service by 
> > their service 
> > provider on their behalf.
> > 
> > AM I GOING TO HAVE CONTROL OVER HOW MY PHONE NUMBER IS USED 
> > IN THIS SYSTEM?
> > 
> > Ultimately yes. We want to repeat that the first principal in 
> > the creation 
> > and operation of a global ENUM service is that the phone 
> > number subscriber 
> > or their designated representatives is the ultimate decision 
> > maker on how a 
> > DNS record for a phone number is to be provisioned.
> > 
> > ARE THERE ANY EXAMPLES OF GLOBAL NAMESPACE DELEGATION THAT SHOULD BE 
> > CONSIDERED
> > AS MODELS?
> > 
> > The closest, technical equivalent is in-addr.arpa.  That 
> > domain provides a 
> > reverse mapping, from IP address to domain name.  It is used 
> > as part of the 
> > Internet infrastructure operation, to help authenticate an IP 
> > address and 
> > identify the operator associated with an IP address.  It is not seen 
> > directly by users.  The same is true for e164.arpa.  It will be for 
> > operational infrastructure, rather than for directl access by 
> > end users.
> > 
> > As with e164.arpa, in-addr.arpa, allocations are 
> > hierarchical, according to 
> > the infrastructure administrative structure.  For in-addr.arpa, the 
> > hierarchy uses the "CIDR" address allocation hierarchy.  For 
> > e164.arpa, the 
> > hierarchy will be based on the ITU E.164 Recommendation.
> > 
> > WHO CAN ADMINISTER THE ENUM REGISTRY IN THE NEAR-TERM?
> > 
> > ENUM is approaching the stage where the industry will want to start
> > interoperability testing.  And they will want to test using 
> > the e164.arpa 
> > domain.  The interoperability test would have the same 
> > principles that 
> > current ones do; no charge, sharing of information, etc..
> > 
> > A. One method of enabling the registry would be to develop an 
> > RFC that 
> > defines the interim delegation principles for IANA as well as 
> > principles 
> > for the transition to the permanent registry.
> > 
> > WHAT CAN BE DONE IN THE LONG TERM?
> > 
> > There will need to be a formal effort to define and establish 
> > the structure 
> > for this activity.  An example of the charter for that effort 
> > would be:
> > 
> > 1. Define the global ENUM Service.
> > 2. Perform the task of certifying organizations to IANA that wish to 
> > operate national TN/NS once they have been nominated by their 
> > respective 
> > nation states.
> > 3. Coordinate technical standards for the operation of ENUM service in
> > cooperation with the IETF.
> > 4. Establish guidelines and policies, which national TN/NS 
> > administrators 
> > operate.
> > 5. Promote public policy on how ENUM resources should be used.
> > 
> > Oversight for this activity should be constituted that 
> > comprise several
> > constituencies, such as
> > 
> > 1. The potential ENUM user community
> > 2. The potential ENUM provider community
> > 3. National governments, at least as an advisory
> > 4. IAB-IESG representatives
> > 5. others?
> > 
> > FORGET ALL THIS POLICY TALK...HOW IS ENUM GOING TO WORK FOR 
> > ME?  WHAT DOES 
> > THIS SYSTEM LOOK LIKE TO ME... JOHN DOE TELEPHONE SUBSCRIBER? 
> >  HOW WILL THE 
> > RIGHTS OF TELEPHONE NUMBER SUBSCRIBERS BE PROTECTED?
> > 
> > This is an essential question that must be resolved, but a 
> > clear statement 
> > of policy protecting subscribers should be part of any ENUM 
> > system charter.
> > 
> > A simple answer is by respecting existing regulatory and 
> > business rules
> > regarding number administration, slamming, non-reliance, etc.  Only by
> > replicating or re-implementing ENUM analogs to the existing 
> > rules of the 
> > road will we avoid a wide range of very serious 
> > administrative, operational 
> > and political conflicts.
> > 
> > HOW ARE YOU GOING TO PREVENT "SLAMMING" OR "HIJACKING"?
> > 
> > Slamming, or the involuntary transfer of service provider, 
> > must be avoided 
> > in any ENUM system.  However it is a serious problem in the 
> > PSTN and we 
> > must be careful not elsewhere. Note that anti-slamming fundamentally 
> > requires a neutral third party solution.  The US industry is 
> > grappling with 
> > this on long distance right now.  It was solved on number 
> > portability from 
> > the outset.  Authenticated subscriber access is not a total solution, 
> > because if a subscriber disconnects their telephony service, 
> > they lose 
> > rights to the phone number.  Consequently, some combination 
> > of originator 
> > authentication as well as telephone number rights validation, using 
> > existing new and existing validation sources, can be used to 
> > solve the 
> > problem, depending on the level of standard required.
> > 
> > WHAT IS THE EFFECT OF E164.ARPA DEPLOYMENT ON THE GLOBAL DNS SYSTEM?
> > 
> > We don't know. This is going to need research, such as the 
> > effect of "wrong 
> > dials" on the root of e164.  That is, caller specification of a wrong 
> > number can result in many additional queries to the e164.arpa root.
> > 
> > Additional work will be necessary in advising ENUM 
> > applications such things 
> > as the level of data caching necessary in order relieve 
> > stress  -- suppress 
> > escalating of poorly formed queries - mis-dials - or cache 
> > misses -- on the 
> > root structure.
> > 
> > For telephony applications, performance and load engineering 
> > is critical, 
> > as query volumes from small to medium size cities can easily 
> > reach many 
> > thousands per second alone.  Response times, as well as 
> > transaction loads, 
> > must be carefully considered.  Conventional DNS caching is of 
> > significantly 
> > reduced value in ENUM due to the huge size of the name space 
> > and relatively 
> > even distribution of queries into the space over arbitrary time 
> > intervals.  Unlike conventional DNS queries, calls volumes 
> > aren't highly 
> > concentrated into a popular small subset of the number space.
> > 
> > WHAT WILL BE THE EFFORT TO ADMINISTER THE ROOT OF THE 
> > E164.ARPA NAMESPACE?
> > 
> > Any solution ought to require little or no work on the part of the 
> > e164.arpa root administrator. Optimally the root of e164.arpa should 
> > contain a small listing of all of the national ENUM top level 
> > country code 
> > name servers as described above.
> > 
> > SECURITY CONSIDERATIONS:
> > 
> > Authentication of ENUM provisioning requests, validation of telephone 
> > number use rights where appropriate, and security of 
> > e164.arpa zone roots, 
> > poses the primary security concerns for ENUM.
> > 
> > ACKNOWLEDGEMENTS:
> > 
> > The author wants to acknowledge the following individuals in 
> > preparing this 
> > document, though any errors or omissions are the 
> > responsibility of the 
> > author. Thanks to :Dave Crocker, Mark Foster, Tom McGarry,  
> > John Horrocks
> > 
> > REFERENCES:
> > 
> > AUTHOR:
> > 
> > Richard Shockey
> > Senior Technical Industry Liaison
> > NeuStar
> > 1120 Vermont Ave  N.W.
> > Washington DC 20005
> > Tel: [phone]
> > Fax: [phone]
> > Email: [e-mail]
> > [e-mail]
> > 
> > 
> > 
> > 
> > 
> >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Please Note New Contact Information:
> > 
> > Richard Shockey
> > Shockey Consulting LLC
> > 5237 Sutherland
> > St. Louis, MO 63109
> > Voice 314.503.0640
> > eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
> > INTERNET Mail & IFAX : [e-mail]
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/enum
> 

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [e-mail]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
[phone]  |  [phone] (fax)  |  http://www.law.tm
                        -->It's hot here.<--


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