Subject: RE: [Enum] ENUM Requirements

From: "Anne Brown" <[email-masked]>
Date: Mon, 7 Feb 2000 09:11:16 -0600

James,

My comments below.

Regards,
Anne

		-----Original Message-----
		From:	James Yu [mailto:[email-masked]]
		Sent:	February 07, 2000 9:22 AM
		To:	Brown, Anne [NORSE:5N00:EXCH]
		Cc:	[email-masked]'
		Subject:	[Enum] ENUM Requirements

		Ann,
		NeuStar submitted some proposed revisions to the
draft-ietf-enum-rqmts-00.on
		12/8.  Since it did not generate any discussion, we are
resubmitting the
		proposed changes but with some modifications.  We suggest
that the
		discussion be based on the changes proposed in this message
and have the
		changes incorporated into the enum requirements document.
People familiar
		with the post dialing delays please help in identifying the
post dialing
		delay requirement for the international calls in the GSTN
today.  The reason
		is that the same post dialing delay requirement will apply
to the scenario
		where a call is originated from the GSTN to the GSTN via the
Internet.
		We suggest to revise sections 3.7 and 3.9 (see proposed
texts below) and
		clarify 3.11 in draft-ietf-enum-rqmts-00.
		3.7 Number Portability
		The system MUST take into consideration of all the existing
local number
		portability mechanisms that allow the subscribers to keep
their phone
		numbers when switching from one local access service
provider to another,
		where applicable. It is RECOMMENDED that the system not be
designed in such
		a way as to impede future number portability that allows the
subscribers to
		keep their phone numbers when moving from one physical
location to another
		or changing their subscribed services within or across those
systems that
		use E.164 numbers to identify the end users or
terminals/devices. 

I don't believe that the ENUM service (or protocol or solution) should have
to be aware of all existing LNP mechanisms, which is implied by your text.
The solution should, however, support the lookup of ported E.164 numbers.
Would you agree on the following text:

3.7 Number Portability
The system MUST support the retrieval of information, based on an E.164
number, regardless of whether or not the E.164 number is a locally or
globally ported number. It is RECOMMENDED that the system..... 

		3.9 Query Performance
		The system is not expected to respond to queries with the
same performance
		levels as current GSTN queries; however, the DNS process
SHOULD not
		significantly increase the post dialing delay as perceived
by the caller or
		specified by the regulatory bodies (e.g., 10 seconds for
domestic calls). 

Define "significantly"?  I recommend removing the word significantly and
changing the text "SHOULD not" to "SHOULD NOT" as per RFC 2119.  

		Please clarify "the owner of the telephone number" in
Section 3.11. Is it
		the subscriber that is assigned the telephone number or the
service provider
		that currently serves that number?

Section 3.11 on Privacy states that "The system MUST allow the owner of the
telephone number to control the information which prospective callers may
receive."  I recommend replacing the text with "The system MUST allow the
user to whom the telephone number was assigned, the ability to control the
information...".

		James

		James Yu
		Principal Technical Industry Liaison
		NeuStar Inc.
		1120 Vermont Avenue, NW,
		Suite 550
		Washington, D.C. 20005
		USA
		+1-202-533-2814 (B)
		+1-202-533-2975 (Fax)
		+1-202-256-1200 (Mobile)
		[email-masked]
		http://www.neustar.com

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

---

From: James Yu <[email-masked]>
Date: Mon, 7 Feb 2000 10:01:38 -0600

Randy,

Agree.  It will be from me then.  Thanks.

James

> From: Randy Bush [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 10:59 AM
> To: James Yu
> Cc: enum wg
> Subject: Re: [Enum] ENUM Requirements
> 
> 
> > 12/8.
> as ietf is made up of individual experts, not companies, 
> governments, ...
> i doubt it.
> 
> randy
>

---

From: James Yu <[email-masked]>
Date: Mon, 7 Feb 2000 10:15:13 -0600

Ann,
 
The need to be aware of the existing LNP implementations will ensure that
the ENUM scheme will provide a common mechanism for retrieving the
information that currently reside on various LNP databases.  I have no
problem with the last two comments.
 
James

-----Original Message-----
From: Anne Brown [mailto:[email-masked]]
Sent: Monday, February 07, 2000 10:11 AM
To: 'James Yu'
Cc: [email-masked]'
Subject: RE: [Enum] ENUM Requirements

James, 

My comments below. 

Regards, 
Anne 

	BM__MailData-----Original Message----- 
From:   James Yu [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent:   February 07, 2000 9:22 AM 
To:     Brown, Anne [NORSE:5N00:EXCH] 
Cc:     [email-masked]' 
Subject:        [Enum] ENUM Requirements 

	Ann, 
NeuStar submitted some proposed revisions to the draft-ietf-enum-rqmts-00.on

12/8.  Since it did not generate any discussion, we are resubmitting the 
proposed changes but with some modifications.  We suggest that the 
discussion be based on the changes proposed in this message and have the 
changes incorporated into the enum requirements document.  People familiar 
with the post dialing delays please help in identifying the post dialing 
delay requirement for the international calls in the GSTN today.  The reason

is that the same post dialing delay requirement will apply to the scenario 
where a call is originated from the GSTN to the GSTN via the Internet. 
We suggest to revise sections 3.7 and 3.9 (see proposed texts below) and 
clarify 3.11 in draft-ietf-enum-rqmts-00. 
3.7 Number Portability 
The system MUST take into consideration of all the existing local number 
portability mechanisms that allow the subscribers to keep their phone 
numbers when switching from one local access service provider to another, 
where applicable. It is RECOMMENDED that the system not be designed in such 
a way as to impede future number portability that allows the subscribers to 
keep their phone numbers when moving from one physical location to another 
or changing their subscribed services within or across those systems that 
use E.164 numbers to identify the end users or terminals/devices. 

3.7 Number Portability 

	3.9 Query Performance 
The system is not expected to respond to queries with the same performance 
levels as current GSTN queries; however, the DNS process SHOULD not 
significantly increase the post dialing delay as perceived by the caller or 
specified by the regulatory bodies (e.g., 10 seconds for domestic calls). 

	Please clarify "the owner of the telephone number" in Section 3.11.
Is it 
the subscriber that is assigned the telephone number or the service provider

	James 

	James Yu 
Principal Technical Industry Liaison 
NeuStar Inc. 
1120 Vermont Avenue, NW, 
Suite 550 
Washington, D.C. 20005 
USA 
+1-202-533-2814 (B) 
+1-202-533-2975 (Fax) 
+1-202-256-1200 (Mobile) 
[email-masked] 
http://www.neustar.com <http://www.neustar.com>  

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

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Tue, 8 Feb 2000 08:33:53 -0000

Regarding portability:
Agreed that there needs to be some kind of mechanism for dealing with
LNP/GNP/Service Provider portability (different names for the same thing).
In principle, there is no reason why Enum shouldn't need to cope with E.164
numbers being ported 

*	between a circuit switched and an IP network
*	within an IP network
*	between an IP network and a circuit switched network

Given that ENUM converts from a E.164 number to a set of mechanisms of
locating that number (SIP, potscall etc), in principle it should accommodate
the above.  However, for the first porting case, the call is incoming from
the GSTN and the trigger is not in fact an E.164 number, but an "E.164-like"
number.  In the USA solution, a LRN is applied, in Europe a
(non-internationally significant) routeing prefix is used etc.  I don't
think this discredits ENUM, insofar as the scope of the work is specifically
about conversion from E.164; what it means is that ENUM will not accommodate
portability as it is currently scoped.  

The two solutions around this that I see are that either ENUM is expanded in
scope, or "ENUM-like" techniques are used on a separate tld to accommodate
in-ported numbers.  For example, if a UK routeing number of
51234501344713246 were to be received, this could be accommodated by
triggering an ENUM-like mechanism with
6.4.2.3.1.7.4.4.3.1.0.5.4.3.2.1.5.uk.ported.e164.int.  There is an issue
that the client would need to know that the input number was a routeing
number versus an E.164, but in general such things are conveyed in the
(GSTN) signalling.

As such, if the first approach is taken (expand ENUM), then James' text is
best.  If the latter approach, then Anne's proposed change is acceptable but
once we get ENUM to generally acceptable state, then we could do with an
EPORT...

Regards

Paul

	-----Original Message-----
	From:	James Yu [SMTP:[email-masked]]
	Sent:	Monday, February 07, 2000 4:15 PM
	To:	'Anne Brown'
	Cc:	[email-masked]'
	Subject:	RE: [Enum] ENUM Requirements

	Ann,
	 
	The need to be aware of the existing LNP implementations will ensure
that
	the ENUM scheme will provide a common mechanism for retrieving the
	information that currently reside on various LNP databases.  I have
no
	problem with the last two comments.
	 
	James

	-----Original Message-----
	From: Anne Brown [mailto:[email-masked]]
	Sent: Monday, February 07, 2000 10:11 AM
	To: 'James Yu'
	Cc: [email-masked]'
	Subject: RE: [Enum] ENUM Requirements

	James, 

	My comments below. 

	Regards, 
	Anne 

		BM__MailData-----Original Message----- 
	From:   James Yu [ mailto:[email-masked]
<mailto:[email-masked]>
	] 
	Sent:   February 07, 2000 9:22 AM 
	To:     Brown, Anne [NORSE:5N00:EXCH] 
	Cc:     [email-masked]' 
	Subject:        [Enum] ENUM Requirements 

		Ann, 

	12/8.  Since it did not generate any discussion, we are resubmitting
the 
	proposed changes but with some modifications.  We suggest that the 
	discussion be based on the changes proposed in this message and have
the 
	changes incorporated into the enum requirements document.  People
familiar 
	with the post dialing delays please help in identifying the post
dialing 
	delay requirement for the international calls in the GSTN today.
The reason

	is that the same post dialing delay requirement will apply to the
scenario 
	where a call is originated from the GSTN to the GSTN via the
Internet. 
	We suggest to revise sections 3.7 and 3.9 (see proposed texts below)
and 
	clarify 3.11 in draft-ietf-enum-rqmts-00. 
	3.7 Number Portability 
	The system MUST take into consideration of all the existing local
number 
	portability mechanisms that allow the subscribers to keep their
phone 
	numbers when switching from one local access service provider to
another, 
	where applicable. It is RECOMMENDED that the system not be designed
in such 
	a way as to impede future number portability that allows the
subscribers to 
	keep their phone numbers when moving from one physical location to
another 
	or changing their subscribed services within or across those systems
that 
	use E.164 numbers to identify the end users or terminals/devices. 

	I don't believe that the ENUM service (or protocol or solution)
should have
	to be aware of all existing LNP mechanisms, which is implied by your
text.
	The solution should, however, support the lookup of ported E.164
numbers.
	Would you agree on the following text:

	3.7 Number Portability 
	The system MUST support the retrieval of information, based on an
E.164
	number, regardless of whether or not the E.164 number is a locally
or
	globally ported number. It is RECOMMENDED that the system..... 

		3.9 Query Performance 
	The system is not expected to respond to queries with the same
performance 
	levels as current GSTN queries; however, the DNS process SHOULD not 
	significantly increase the post dialing delay as perceived by the
caller or 
	specified by the regulatory bodies (e.g., 10 seconds for domestic
calls). 

	Define "significantly"?  I recommend removing the word significantly
and
	changing the text "SHOULD not" to "SHOULD NOT" as per RFC 2119.  

		Please clarify "the owner of the telephone number" in
Section 3.11.
	Is it 
	the subscriber that is assigned the telephone number or the service
provider

	Section 3.11 on Privacy states that "The system MUST allow the owner
of the
	telephone number to control the information which prospective
callers may
	receive."  I recommend replacing the text with "The system MUST
allow the
	user to whom the telephone number was assigned, the ability to
control the
	information...".

		James 

		James Yu

---

From: James Yu <[email-masked]>
Date: Tue, 8 Feb 2000 07:44:51 -0600

Paul,

For the first porting case, there are two scenarios: (1) NPDB query has been
performed at the GSTN before the call is routed to the Internet, and (2)
NPDB query has not been performed.  You discussed the scenario (1).  

If both the "network routing number" and "directory number" are passed to
the Internet, the network element that handles the call (e.g., GW, GK, or
SIP server) should know the existence of both numbers.  If DNS scheme is
still used for call routing/handling, then the "directory number" would be
used to formulate the DNS query.  Whether and how the "network routing
number" is used by the DNS scheme is to be seen.  With the "network routing
number," that network element also knows that "NPDB has been performed" so
it will not perform a NPDB query even if the DNS scheme returns information
about where to get the network routing number information (if the DNS scheme
is used to provide that information).]

For scenario (2), only the directory number is passed, the DNS scheme will
use it to get information about call routing/handling.

James

> From: Rosbotham, Paul [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2000 3:34 AM
> To: 'James Yu'; 'Anne Brown'
> Cc: [email-masked]'
> resubmitting
> texts below)
> location to