Subject: RE: [Enum] ENUM FAQ

From: [email-masked]
Date: Sat, 29 Jul 2000 21:46:09 +0300

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:[email-masked]]
> Sent: July 26, 2000 23:47
> To: [email-masked]
> 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-
> [email-masked]?body=subscribe>.
> 
> To contribute to the discussion, send mail to  
> <mailto:[email-masked]> 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 +1-314-918-9020, 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: +1 314.503.0640
> Fax: +1 815.333.1237
> Email: [email-masked]
> [email-masked]
> 
> 
> 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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 : [email-masked]
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Sat, 29 Jul 2000 15:03:13 -0400 (EDT)

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.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 29 Jul 2000 15:15:02 -0400

>email SPAM, telemarketers, etc.

Nope, and I should add that to the security considerations section. 
I.e. we have been discussing several months ago this issue, and the 
conclusion was that IF you have sensitive information that should for 
example be stored in an LDAP database or something else which handle 
authentication, and an LDAP URI in DNS.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 29 Jul 2000 15:33:37 -0400

At 15.15 -0400 00-07-29, Patrik Fältström wrote:
>conclusion was that IF you have sensitive information that should 
>for example be stored in an LDAP database or something else which 
>handle authentication, and an LDAP URI in DNS.

I forgot one thing, a directory service like this can _never_ replace 
the authentication mechanism you use in whatever protocol you use for 
the actual transport. With the directory, you only get to know what 
endpoint to use.

Say that you don't want denial of service attacks on your (secret) 
webserver. Do you think you will be safe if you don't have a hostname 
in DNS, but only use an IP-address?

Not really...

The only thin we can talk about here is when the endpoint identifier 
itself have to be protected for various reasons, and that is when 
directory services protocols which do have strong authentication (and 
encryption) comes into mind.

   paf

---

From: Richard Shockey <[email-masked]>
Date: Sun, 30 Jul 2000 00:49:52 -0500

>I agree this is a major issue.

It is my understanding that the policy does contravene European privacy 
laws and this topic came out at the Registrars meeting at ICANN at Yokohama 
in relation to domain names. It is the subject of much debate and possible 
review in the EC as it might relate to the requirements of law enforcement 
agencies among others.

One thing I have tried to say in the FAQ is that ENUM  is designed as a 
OPT-IN system.

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640