Subject: RE: [Enum] RFC 3482 on Number Portability in the Global Switched Telephone Network (GSTN): An Overview

From: "Yu, James" <[email-masked]>
Date: Thu, 20 Feb 2003 11:35:57 -0500

Jeff,

I am in CA and just saw the discussions.

First, this is an informational RFC, so it is not a "standard" such as the
SIP RFC.

NeuStar examined the impacts of NP on many of IETF's current activities and
the potential areas that might be caused by NP.  One area was ENUM (that was
why this document was submitted to the enum WG).  As indicated by Penn,
NeuStar and AT&T jointly investigated the impact of NP on the ENUM
provisioning process and showed how the provisioning process would be done
if the telephony carriers and the subscribers share the common domain tree
(e.g., e164.arpa).  The process became complicate when NP is involved
because the new telephony carrier's NAPTR RRs must be used when the
subscriber (ENUM user or ENUM registrant) changes the telephony carrier.  We
recommended that "carrier" ENUM (or "infrastructure" ENUM," - the use of
ENUM by the telephony carriers) use a different domain tree to avoid
involving NP in the ENUM provisioning process. 

We have identified several other issues such as those related to iptel WG
and convergence.  Please see the last section that discusses those issues.

Hope that the above providess the clarifications.

James

> -----Original Message-----
> From: Jeff Williams [mailto:[email-masked]]
> Sent: Thursday, February 20, 2003 12:43 PM
> To: Kevin McCandless
> Cc: [email-masked]
> Subject: Re: [Enum] RFC 3482 on Number Portability in the Global
> Switched Telephone Network (GSTN): An Overview
> 
> 
> Kevin and all,
> 
>   Number portability is not a new technology by any means.  
> It has been
> used in the Military for at least two decades that I am aware of and
> have some experience with.  Nuestar is not the only 
> company/organization
> that has broad experience in this arena either.
> 
>   But your right that what this has to do with ENUM is anyone's
> guess, just now...  However I can see some interesting correlation's
> here...  Hence my concern...  So I prefer to stay ahead of the
> curve, so to speak...  >;)
> 
> Kevin McCandless wrote:
> 
> > Jeff:
> >
> > This is a contribution to educate us on Number Portability. 
>  We should be
> > glad that a company like Neustar understands this complex 
> service.  What it
> > has to do with ENUM is still anyone's guess.
> >
> > K...
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Thursday, February 20, 2003 3:16 AM
> > > To: Jeff Williams; [email-masked]
> > > Cc: [email-masked]; [email-masked]; 
> [email-masked];
> > > [email-masked]; Jeff Neuman
> > > Subject: RE: [Enum] RFC 3482 on Number Portability in the Global
> > > Switched Telephone Network (GSTN): An Overview
> > >
> > >
> > > Jeff,
> > > I do not read this.
> > > So what is your problem with this informational document?
> > > I there anything wrong in it?
> > > Richard
> > >
> > > > -----Original Message-----
> > > > From: Jeff Williams [mailto:[email-masked]]
> > > > Sent: Thursday, February 20, 2003 7:13 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; Jeff Neuman
> > > > Subject: Re: [Enum] RFC 3482 on Number Portability in the
> > > > Global Switched Telephone Network (GSTN): An Overview
> > > >
> > > >
> > > > RFC Editor and all,
> > > >
> > > >   Looks an awful lot like a Nuestar/IEGF document/RFC to me.
> > > > Has Nuestar taken over a percentage of the IETF recently?
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > A new Request for Comments is now available in online RFC
> > > libraries.
> > > > >
> > > > >         RFC 3482
> > > > >
> > > > >         Title:      Number Portability in the Global Switched
> > > > >                     Telephone Network (GSTN): An Overview
> > > > >         Author(s):  M. Foster, T. McGarry, J. Yu
> > > > >         Status:     Informational
> > > > >         Date:       February 2003
> > > > >         Mailbox:    [email-masked],
> > > > [email-masked],
> > > > >                     [email-masked]
> > > > >         Pages:      30
> > > > >         Characters: 78552
> > > > >         Updates/Obsoletes/SeeAlso:    None
> > > > >
> > > > >         I-D Tag:    draft-ietf-enum-e164-gstn-np-05.txt
> > > > >
> > > > >         URL:       
> ftp://ftp.rfc-editor.org/in-notes/rfc3482.txt
> > > > >
> > > > > This document provides an overview of E.164 telephone number
> > > > > portability (NP) in the Global Switched Telephone 
> Network (GSTN).
> > > > >
> > > > > NP is a regulatory imperative seeking to liberalize local
> > > telephony
> > > > > service competition, by enabling end-users to retain
> > > > telephone numbers
> > > > > while changing service providers.  NP changes the
> > > > fundamental nature
> > > > > of a dialed E.164 number from a hierarchical physical
> > > > routing address
> > > > > to a virtual address, thereby requiring the transparent
> > > > translation of
> > > > > the later to the former.  In addition, there are various
> > > regulatory
> > > > > constraints that establish relevant parameters for NP
> > > > implementation,
> > > > > most of which are not network technology specific.
> > > > Consequently, the
> > > > > implementation of NP behavior consistent with applicable
> > > regulatory
> > > > > constraints, as well as the need for interoperation with
> > > > the existing
> > > > > GSTN NP implementations, are relevant topics for numerous
> > > > areas of IP
> > > > > telephony works-in-progress with the IETF.
> > > > >
> > > > > This document is a product of the Telephone Number
> > > Mapping Working
> > > > > Group of the IETF.
> > > > >
> > > > > This memo provides information for the Internet
> > > community.  It does
> > > > > not specify an Internet standard of any kind.
> > > Distribution of this
> > > > > memo is unlimited
> > > > >
> > > > > This announcement is sent to the IETF list and the 
> RFC-DIST list.
> > > > > Requests to be added to or deleted from the IETF
> > > distribution list
> > > > > should be sent to [email-masked].  Requests to be
> > > > added to or
> > > > > deleted from the RFC-DIST distribution list should be sent to
> > > > > [email-masked].
> > > > >
> > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained
> > > > by sending
> > > > > an EMAIL message to [email-masked] with the 
> message body
> > > > > help: ways_to_get_rfcs.  For example:
> > > > >
> > > > >         To: [email-masked]
> > > > >         Subject: getting rfcs
> > > > >
> > > > >         help: ways_to_get_rfcs
> > > > >
> > > > > Requests for special distribution should be addressed to
> > > either the
> > > > > author of the RFC in question, or to 
> [email-masked].
> > > > > Unless specifically noted otherwise on the RFC itself,
> > > all RFCs are
> > > > > for unlimited distribution.echo Submissions for Requests
> > > > for Comments
> > > > > should be sent to [email-masked].  Please
> > > > consult RFC 2223,
> > > > > Instructions to RFC Authors, for further information.
> > > > >
> > > > > Joyce K. Reynolds and Sandy Ginoza
> > > > > USC/Information Sciences Institute
> > > > >
> > > > > ...
> > > > >
> > > > > Below is the data which will enable a MIME compliant 
> Mail Reader
> > > > > implementation to automatically retrieve the ASCII 
> version of the
> > > > > RFCs.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Jeffrey A. Williams
> > > > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders
> > > > strong!)
> > > > ================================================================
> > > > CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> > > > Information Network Eng. Group. INEG. INC. E-Mail
> > > > [email-masked] Contact Number: 214-244-4827 or 
> 214-244-3801
> > > >
> > > >
> > > > _______________________________________________
> > > > enum mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/enum
> > > >
> > > _______________________________________________
> > > enum mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/enum
> > >
> 
> Regards,
> --
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> ================================================================
> CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> Information Network Eng. Group. INEG. INC.
> E-Mail [email-masked]
> Contact Number: 214-244-4827 or 214-244-3801
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Thu, 20 Feb 2003 12:06:25 -0800

Yu and all,

> First, this is an informational RFC, so it is not a "standard" such as the

  Yes I understood that clearly.  But thank you again for this restatement.

> involving NP in the ENUM provisioning process.

  Yes I understood this to be the case when reading this informational RFC.

> and convergence.  Please see the last section that discusses those issues.

  I did so.  I will likely have further comments to that specific section
at a later date, pending some technical investigation.

> Hope that the above providess the clarifications.

  Some, yes.

Regards,

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 20 Feb 2003 10:40:28 -0600

----- Original Message -----
From: "Yu, James" <[email-masked]>
> (e.g., e164.arpa).
====

...do you really think enlightened people are fooled any more ?

http://IPv8.isfun.net
http://www.go-mono.com/
http://www.knoppix.com
http://www.netfilter.org
http://www.digium.com
http://www.asterisk.org
http://www.openss7.org
http://www.zapatatelephony.org
http://www.new.net
http://IPv8.iscool.net

Jim Fleming
[email-masked] Consultant
http://www.Unir.NET
http://www.Unir.com
http://www.Uni%ae.com
http://www.Uni®.com