Subject: RE: [Enum] Number Portability Draft

From: "Yu, James" <[email-masked]>
Date: Tue, 30 Oct 2001 13:16:40 -0600

This is to respond to the comments (marked by [YU] below) from Patrik, Tony
and Paul.  Thanks for the comments.

James

------------Patrik's comments-----------------------

(b) There is no security considerations section. I.e. no talk about
security issues with the different models, and the different proposed
solutions, and implications listed at the end.

[YU] Will add a security section (no security implications) and follow RFC
publication guidelines.

------------Tony's comments-----------------------

1. Although this is informational, it does state "conclusions."
Wouldn't it be more appropriate to describe these observations
as "potential implications."

[YU] Will change to "potential implications" and also add discussion about
NP impacts on ENUM if the carriers use ENUM for network services under
e164.arpa.

2. The conclusions section states:

    is a regulatory requirement on NP in some countries.  The delegated
    authority for a given E.164 number is likely to be an entity
    designated by the end user that owns/controls a specific telephone
    number or a third-party designated by the end-user or by the
    industry.

What is the basis for the sentence, and what does it mean for
delegated authority to be "the industry?"

[YU] Will change the sentence to "The delegated authority for a given E.164
number is likely to be an entity designated by the end user that
owns/controls a specific telephone number or one that is designated by the
service registrar."   

[YU] Initially, we thought that there was a Tier 2 Entity that would support
both ENUM Registrar and Tier 2 Nameserver functions.  This delegated
authority that hosts the ENUM Registrant's NAPTR RRs is the Tier 2
Nameserver.   No matter what, "the industry" should not be appear.  Thanks
for catching the error.

------------Paul's comments-----------------------

Section 5.4 on Onward routing contains the text "This scheme is also called
Remote Call Forwarding".  I would delete this text.  RCF was very much a
short term expedient whereby customer facilities on GSTN switches were used
to forward calls from the donor network to the customer's new network, hence
giving the illusion of NP.  Onward routing, on the other hand, uses
particular tables which are quite often within the network side of the GSTN
switch databuild.  There are profound differences, because while RCF can
impede the operation of some GSTN features/services, OR does not have such
an impact.

[YU] Will remove the sentence "This scheme is also called Remote Call
Forwarding."

Section 5.5 contains the text "The OR scheme is the least efficient in terms
of using the network resources".  While this is the case when considering
transmission capacity alone (clearly given there are two legs to any call),
the situation is more complex when the network as a whole is considered.
For ACQ, for example, GSTN switch resources are used to perform the NP
query, whether or not the call is to a ported number.  The precise impact of
this varies according to the switch design, and means that for countries
which do not have GSTN switches optimised around IN, querying all calls can
cause a significant overhead, indeed a higher cost than the extra call leg
for that minority of numbers which are ported.  This means that there is a
cross-over point where ACQ is more efficient than OR, driven by the %age of
numbers that are ported, and this cross-over point will vary from country to
country.  The text about efficiency is therefore somewhat trite, and should
be removed.

[YU] Will change to "The OR scheme is the least efficient in terms of using
the network transmission facilities."  

[YU] Will also discuss ACQ scheme where only calls in the portable NPA+NXX
ranges (in the U.S.) require NPDB dips.

In Section 7.2, there is a paragraph which commences "Please note that all
those enhancements are for national use".  I would make two points to this
paragraph.  Firstly, it is not a specific European issue, and deserves a
section in its own right.  Secondly, I think the point that needs
re-inforcing in this section is that any NP parameters obtained for a ported
number are only any use in the country where they reside.  To clarify; if a
call to a ported UK number egressed from an IP network into the GSTN in the
USA containing the UK routeing prefix, the call would fail as the prefix is
not internationally significant.  Similarly, if a call to a ported USA
number egressed from an IP network into the GSTN in the UK utilising the
US-LRN for addressing, the call could similarly fail as the parameters are
not designed to be sent internationally.

[YU] Will add clarifications to the section.

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

---

From: "Jim Fleming" <[email-masked]>
Date: Tue, 30 Oct 2001 13:45:53 -0600

----- Original Message -----
From: "Yu, James" <[email-masked]>
> NP impacts on ENUM if the carriers use ENUM for network services under

The IN-ADDR.[TLD] zones are taking shape.
http://www.in-addr.info
3:219 INFO

What is the status of the E164.[TLD] zones ?

Where [TLD] is taken from here...
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

Jim Fleming
http://www.IPv8.info