Subject: RE: [Enum] [Fwd: I-Dsubmission:draft-lind-infrastructure-enum-reqs-01]

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 19 Oct 2005 11:59:26 -0400

Penn,

Good draft.  I think you can drop the parenthetical (Note:..) in section
1.2.  I couldn't figure out what it means, but don't think it is
important.

Mike 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pfautz, Penn L, NEO
> Sent: Wednesday, October 19, 2005 8:41 AM
> To: [email-masked]; Richard Shockey; [email-masked]
> Subject: RE: [Enum] [Fwd: 
> I-Dsubmission:draft-lind-infrastructure-enum-reqs-01]
> 
> Doug:
> Thanks. Your point is a good one; we did not intend to imply 
> a single URI for all services or protocols but I see upon 
> reflection our language might be taken in that way.
> 
> 
> Penn 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Douglas Ranalli
> Sent: Wednesday, October 19, 2005 8:31 AM
> To: 'Richard Shockey'; [email-masked]
> Subject: RE: [Enum] [Fwd: I-D
> submission:draft-lind-infrastructure-enum-reqs-01]
> 
> Penn and Steve,
> 
> Nice work on this first draft of Carrier-ENUM requirements.  
> One comment regarding scope of the solution.  Section 1.1 
> "Definition" defines Infrastructure-ENUM as a service that 
> returns a single URI identifying a point of interconnection.  
> Consider broadening the scope of the first sentence of 
> section 1.1 as follows: 
> 
> "...to map a telephone number into one or more URIs that 
> identify protocol or service specific points of interconnection..." 
> 
> Doug
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Shockey
> Sent: Tuesday, October 18, 2005 12:46 PM
> To: [email-masked]'
> Subject: [Enum] [Fwd: I-D submission:
> draft-lind-infrastructure-enum-reqs-01]
> 
> 
> ENUM                                                          
>    S. Lind
> Internet-Draft                                                
>  AT&T Labs
> Expires: April 22, 2006                                       
>  P. Pfautz
>  
> AT&T
>                                                          October 18,
> 2005
> 
> 
>                  Carrier/Infrastructure ENUM Requirements
>                   draft-lind-infrastructure-enum-reqs-01
> 
> Status of this Memo
> 
>     This document is an Internet-Draft and is subject to all 
> provisions
>     of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
>     author represents that any applicable patent or other IPR 
> claims of
>     which he or she is aware have been or will be disclosed, 
> and any of
>     which he or she becomes aware will be disclosed, in 
> accordance with
>     Section 6 of BCP 79.
> 
>     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 Internet-Draft will expire on April 22, 2006.
> 
> Copyright Notice
> 
>     Copyright (C) The Internet Society (2005).
> 
> Abstract
> 
>     This document provides requirements for "infrastructure" 
> or "carrier"
>     ENUM, defined as the use of RFC 3761 technology to facilitate
>     interconnection of networks for E.164 number addressed 
> services, in
>     particular but not restricted to VoIP.
> 
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 1]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
> Conventions used in this document
> 
>     RFC2119 [1] provides the interpretations for the key words "MUST",
>     "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
> "SHOULD NOT",
>     "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
> 
> 
> 1.  Infrastructure ENUM
> 
> 1.1.  Definition
> 
>     Infrastructure ENUM is defined as the use of the technology in
>     RFC3761 [2] by the carrier-of-record for a specific E.164 
> number [3]
>     to map a telephone number into a URI that identifies a 
> specific point
>     of interconnection to that service provider's network that could
>     enable the originating party to establish communication with the
>     associated terminating party.  It is separate from any 
> URIs that the
>     end-user, who registers their E.164 number, may wish to associate
>     with that E.164 number.
> 
>     For purposes of this document, "Carrier of Record" refers to the
>     entity that provides PSTN service for an E.164 number with the
>     understanding that this definition is ultimately a matter for
>     national authorities to determine.
> 
> 1.2.  Background
> 
>     Carriers use E.164 numbers currently as their main naming 
> and routing
>     vehicle.  Carrier ENUM in e164.arpa or another publicly available
>     tree allows Carriers to link Internet based resources 
> such as URIs to
>     E.164 numbers (Note: this is the other way round then User ENUM).
>     This allows Carrier in addition to interconnecting via 
> the PSTN (or
>     exclusively) to peer via IP-based protocols.  Carriers 
> may announce
>     all E.164 numbers or number ranges they host, regardless 
> if the final
>     end-user device is on the Internet, on IP-based closed 
> NGNs or on the
>     PSTN, provided an access (e.g.  SBC or gateway) to the destination
>     carriers network is available on the Internet.  There is also no
>     guarantee that the originating carrier querying Carrier 
> ENUM is able
>     to access the ingress network element of the destination carriers
>     network.  Additional peering and accounting agreements requiring
>     authentication may be necessary.  The access provided may 
> also be to
>     a shared network of a group of carriers, resolving the final
>     destination network within the shared network.
> 
> 
> 2.  Requirements for Infrastructure ENUM
> 
> 
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 2]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
> 2.1.
> 
>     Infrastructure ENUM SHALL provide a means for a carrier 
> to populate
>     DNS RRs in a common publicly accessible namespace for the E.164
>     numbering resources for which it is the carrier-of-record.
> 
> 2.2.
> 
>     Queries of infrastructure ENUM FQDNs MUST return a result, even if
>     the result is NXDOMAIN.  Queries must not be rejected, 
> e.g. based on
>     ACLs.
> 
> 2.3.
> 
>     Infrastructure ENUM SHALL support RRs providing a URI that can
>     identify a point of interconnection for delivery of communications
>     addressed to the E.164 number.
> 
> 2.4.
> 
>     Infrastructure ENUM SHALL support an IRIS capability that allows
>     qualified parties to obtain information regarding the 
> E.164 numbering
>     resources and the corresponding carrier-of-record.
> 
> 2.5.
> 
>     Implementation of Infrastructure ENUM MUST NOT restrict 
> the ability
>     of an end-user, in a competitive environment, to choose a 
> Registrar
>     and/or Tier 2 name server provider for end-user ENUM 
> registrations.
> 
> 2.6.
> 
>     Infrastructure ENUM SHALL be implemented under a TLD that 
> can support
>     reliability and performance suitable for PSTN applications.
> 
> 2.7.
> 
>     Infrastructure ENUM MUST meet all reasonable privacy 
> concerns about
>     visibility of information an end user has no control over, for
>     example discovery of unlisted numbers, or inadvertent 
> disclosure of
>     user identity.
> 
> 2.8.
> 
>     Proposed implementations of Infrastructure ENUM SHOULD
> 
>     a.  Minimize changes required to existing requirements 
> that are part
>     of RFC 3761
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 3]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
>     b.  Work with open numbering plans
> 
>     c.  Restrict additional functionality to carrier resolvers.
> 
>     d.  Minimize the number of lookups required to obtain as 
> many NAPTR
>     records (end-user and carrier) as possible.
> 
>     e.  Minimize the client knowledge of the numbering plan required.
> 
>     f.  Maximize synergies with end-user ENUM
> 
>     g.  Support interworking with private ENUM trees.
> 
> 
> 3.  Security Considerations
> 
>     Existing security considerations for ENUM detailed in [2] still
>     apply.  Note that some registration validation issues 
> concerning end
>     user ENUM may not apply to carrier ENUM.  Where the Tier 
> 1 registry
>     is able to identify the carrier serving a number e.g., based on
>     industry data for number block assignments and number portability,
>     registration might be more easily automated and a 
> separate registrar
>     not required.
> 
>     Some parties have expressed concern that a carrier ENUM could
>     compromise end user privacy by making it possible for others to
>     identify unlisted or unpublished numbers based on their 
> registration
>     in ENUM.  This can be avoided if carriers register all of 
> the their
>     allocated (as opposed to assigned) numbers.  Unassigned numbers
>     should be provisioned to route to the carrier's network 
> in the same
>     fashion as assigned numbers and only then provide an 
> indication that
>     they are unassigned.  In that way, carrier registration 
> of a number
>     in ENUM provides no more information about status of a number than
>     could be obtained by dialing it.
> 
> 
> 4.  IANA Considerations
> 
>     IANA considerations will depend on the architecture 
> ultimately chosen
>     to meet the requirements.
> 
> 5.  Normative References
> 
>     [1]  Bradner, S., "Key words for use in RFCs to Indicate 
> Requirement
>          Levels", BCP 14, RFC 2119, March 1997.
> 
>     [2]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
>          Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 4]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
>          Application (ENUM)", RFC 3761, April 2004.
> 
>     [3]  International Telecommunications Union-T, "The International
>          Public Telecommunication Number Plan", Recommendation E.164",
>          May 1997.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 5]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
> Authors' Addresses
> 
>     Steven Lind
>     AT&T Labs
>     180 Park Ave
>     Florham Park, NJ  07932-0971
>     USA
> 
>     Email: [email-masked]
> 
> 
>     Penn Pfautz
>     AT&T
>     200 S. Laurel Ave
>     Middletown, NJ  07748
>     USA
> 
>     Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 6]
> 
> Internet-Draft          Carrier ENUM Requirements           
> October 2005
> 
> 
> Intellectual Property Statement
> 
>     The IETF takes no position regarding the validity or scope of any
>     Intellectual Property Rights or other rights that might 
> be claimed to
>     pertain to the implementation or use of the technology 
> described in
>     this document or the extent to which any license under such rights
>     might or might not be available; nor does it represent that it has
>     made any independent effort to identify any such rights.
> Information
>     on the procedures with respect to rights in RFC documents can be
>     found in BCP 78 and BCP 79.
> 
>     Copies of IPR disclosures made to the IETF Secretariat and any
>     assurances of licenses to be made available, or the result of an
>     attempt made to obtain a general license or permission 
> for the use of
>     such proprietary rights by implementers or users of this
>     specification can be obtained from the IETF on-line IPR 
> repository at
>     http://www.ietf.org/ipr.
> 
>     The IETF invites any interested party to bring to its 
> attention any
>     copyrights, patents or patent applications, or other proprietary
>     rights that may cover technology that may be required to implement
>     this standard.  Please address the information to the IETF at
>     [email-masked].
> 
> 
> Disclaimer of Validity
> 
>     This document and the information contained herein are 
> provided on an
>     "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 
> HE/SHE REPRESENTS
>     OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>     ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
> OR IMPLIED,
>     INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>     INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Copyright Statement
> 
>     Copyright (C) The Internet Society (2005).  This document 
> is subject
>     to the rights, licenses and restrictions contained in BCP 78, and
>     except as set forth therein, the authors retain all their rights.
> 
> 
> Acknowledgment
> 
>     Funding for the RFC Editor function is currently provided by the
>     Internet Society.
> 
> 
> 
> 
> Lind & Pfautz            Expires April 22, 2006               
>   [Page 7]
> 
> 
> -- 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Director - Member of Technical Staff NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
> ENUM +87810-13313-31331
> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
> Fax: +1 815.333.1237
> <mailto:richard(at)shockey.us> or
> <mailto:richard.shockey(at)neustar.biz>
> <http://www.neustar.biz> ; <http://www.enum.org> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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