1. ENUM Services and their Provisioning Submitted by VeriSign, Inc and Telcordia Technologies, Inc Available at http://www.enumworld.com/policy/ http://www.enumworld.com/policy/ Contacts: mailto:pconley@verisign.com, mailto:grichena@telcordia.com, mailto:trutkowski@netsol.commailto:pconley@verisign.com mailto:grichena@telcordia.commailto:trutkowski@netsol.com ENUM Round Table National Telecommunications and Information Administration Washington DC USA 18 December 2000

2. Potential ENUM Services Flexibility of the ENUM NAPTR approach a repository for all identifiers with rules for use and interworking includes diverse network identities and object attributes, including presence Initial services likely to focus on Internet Telephony and simple interworking, e.g., voicemail to email Long range services - a rich, constantly evolving array of capabilities across all networks, devices, applications Potential ubiquitous operational infrastructure platform complexity needs to be hidden from end user compelling, innovative applications needed developers Market novelty, uncertainty, and value proposition make an open, unfettered provisioning environment essential Substantial uncertainty re:DNS/ENUM performance metrics and relationship to provisioning architectures

3. ENUM Provisioning Issues "ENUM light" has existed in an open, unfettered competitive environment for 8 years under domain - tpc.int – only for messaging Consensus exists on synchronizing end user ENUM Names & E164 numbers with PSTN during provider transitions and deletions authentication interfaces, access to carrier information critical for authentication How should E.164 numbers be used ENUM names are based on E.164 numbers some assert numbers are intellectual or sovereign property with extended rights number portability considerations consensus exists on avoiding multiple ENUM instantiations for same end user consumer protection considerations (slamming, privacy, etc) concern in North America exists about availability independent from PSTN use ENUM provisioning denomination as private, enhanced service is important Provisioning architecture – multiple IETF “informational” views A multi-tier model promotes competitive opportunities Competitive tier 1 provisioning - regulated monopoly or competition? (next slide) Competitive tier 2 provisioning - registry-registrar architectures and self-certification Any rules of the road for provisioning architectures? By whom? By what authority?

4. Key ENUM Tier 1 Provisioning Issue Is ENUM Tier 1 “authoritative” provisioning infrastructure designed as a new regulated national monopoly (E164.ARPA) or an open level playing field in competitive marketplace of multiple providers (e.g., E164.COM, E164.[whatever]) Arguments for a regulated national monopoly administrative structure perceived engineering and administrative efficiencies matches legacy telephony provisioning models competition at ENUM Tier 2 viewed as sufficient competition attractiveness of a unified global administrative model facilitated by ITU Arguments for an open level competitive administrative structure a level marketplace provides a good sorting of complexities, uncertainties, and efficiencies a new regulated monopoly in every country facilitated by an intergovernmental organization is not a desirable model engineering concerns can be met through industry cooperation

5. Role of bodies Industry collaborative ENUM Forum (possible new organization like SIP Forum), ITAB,... Industry ENUM collaborative organizations offer potentially effective model Domestic government agencies, corporations & advisory committees FCC, NTIA, DOS-EB CIP, FTC, DOJ,…ITAC SG-A AdHoc, ICANN, GAC SG-A AdHoc can help with governmental and intergovernmental issues Local governmental bodies Probably jurisdictionally precluded, but remain interested parties Intergovernmental orgs ITU,WTO,CEC,… No automatic ENUM jurisdiction; provisioning agreements/MoUs are inappropriate Standards bodies IETF/IAB, ETSI, ITU-T,TSAG... Can deal with protocols, bakeoffs, and interworking interfaces Developer bodies [They don't exist yet] What will be the mechanism for the US industry to resolve U.S. implementation and deployment issues?