From mailman-owner@ietf.org  Fri Dec  1 05:16:34 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13424
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 05:16:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24735
	for <enum-web-archive@www.ietf.org>; Fri, 1 Dec 2000 05:16:35 -0500 (EST)
Date: Fri, 1 Dec 2000 05:16:35 -0500 (EST)
Message-Id: <200012011016.FAA24735@optimus.ietf.org>
From: mailman-owner@ietf.org
Subject: ietf.org mailing list memberships reminder
To: enum-web-archive@ns.ietf.org
X-No-Archive: yes
Precedence: bulk
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List <diffserv.ietf.org>

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, enum-request@ietf.org) containing just the word
'help' in the message body, and an email message will be sent to you
with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org.  Thanks!

Passwords for enum-web-archive@www.ietf.org:

List                                     Password // URL
----                                     --------  
enum@ietf.org                            i7hy      
http://www1.ietf.org/mailman/options/enum/enum-web-archive@www.ietf.org


From enum-admin@ietf.org  Fri Dec  1 07:13:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18382
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 07:13:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05402;
	Fri, 1 Dec 2000 07:12:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05334
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 07:12:17 -0500 (EST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17946
	for <enum@ietf.org>; Fri, 1 Dec 2000 07:12:16 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21)
	id <X57PDDM7>; Fri, 1 Dec 2000 13:11:13 +0100
Message-ID: <98388C05D464D111B61800805F1504160233A118@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'Judith Oppenheimer'" <joppenheimer@icbtollfree.com>
Cc: enum@ietf.org
Subject: RE: CORRECTION   RE: [Enum] I-DACTION:draft-ranalli-peek-walter-e
	num-t1ro les-00.txt
Date: Fri, 1 Dec 2000 13:11:12 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA05335
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id HAA05402
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA18382

Judith,
as an operator, I make money from my customers, so I tend to get a
subscriber-centric approach.
But in that case, the Subscriber Agent role is redundant with the TSP role
in my opinion.
Maybe it is my european view or my ITU UIFN view, but I do not figure out
situations where the TSP (the one who will suballocate or will indirectly
allocate the number to the subscriber) and the SA will be different
entities. You may say that the SA will contact the TSP on behalf of the
subscriber, but it makes a lot of people around in my opinion.

Valerie.


end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole

FTR&D/DAC/ACE

tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

mail to : valerie.barnole@francetelecom.fr



-----Message d'origine-----
De : Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com]
Envoyé : jeudi 30 novembre 2000 19:05
À : 'BARNOLE Valerie FTRD/DAC/ISS'; 'Douglas Ranalli'
Cc : enum@ietf.org
Objet : CORRECTION RE: [Enum]
I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt


My last post went out incomplete (my keyboard sometimes has a mind of its
own <grin>) ...

> A third point I just saw : in the 2nd role of TSP, the words
> "to terminate"
> and "termination" might be misunderstood as "to accomplish a call" and
> "completion". I suggest to use "to disconnect" and
> "disconnection", if I am
> not the only one to think this misunderstanding is possible.

I agree.

> Important note : this is not what "bellheads" call assignment
> of numbers,
> because the ITU_does_the assignment. It is an indirect
> allocation from the
> ITU to the subscriber via the SAP (not even a suballocation
> from the SAP to
> the subscriber).

This description parallels that of the RespOrg and its relationship to the
800 SMS and the subscriber, except that the RespOrg maintains the
subscriber ID records, not the 800 SMS.  (Because FCC regs and the tariff
stipulate that a RespOrg must have a customer for every number it reserves,
I don't think it would be considered a suballocation either.)

> So I
> would reword it
> E.164 indirect allocation (fit for services numbers like
> freephone) or E.164
> suballocation (fit for geogaphical numbers) and describe it
> as "suballocates
> E.164 numbers received from the administration system to subscribers".

This makes sense.  Re acronyms, it depends if you consider the verification
process telephone number-centric or subscriber-centric.

In the first case TNA for Telephone Number Allocator or TNV for Telephone
Number Verifier would make sense.  If the latter, SA, for Subscriber Agent,
since that is the function of an SAP or RespOrg:  an agency function on
behalf of the subscriber solely for management of the number.

On another general point, the North American Numbering Council's Chair John
R. Hoffman points out this week to the FCC, "It should be noted that the
toll free system is far larger and more complex than the LNP system.  This
is due to the fact that the LNP system provides the ability only to
identify the service provider to complete a call to a telephone number;
while the toll free system provides capabilities (e.g., time-of-day
routing, routing based on the point of origination, routing based on
pre-established call loads, etc.) far greater than anything contemplated
for LNP."

I point out this distinction to help clarify the difference between local
number portability, and toll free portability, which has much more complex
provisioning and contact variables attached to it.

Judith

Judith Oppenheimer, 212 684-7210, 1 800 The Expert
Publisher, http://www.ICBTollFreeNews.com
President, http://www.1800TheExpert.com
FREE 800/Domain Classifieds, http://ICBclassifieds.com
Domain Name & 800 News, Intelligence, Analysis


> -----Original Message-----
> From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
> BARNOLE Valerie FTRD/DAC/ISS
> Sent: Thursday, November 30, 2000 11:53 AM
> To: 'Douglas Ranalli'
> Cc: 'enum@ietf.org'
> Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro
> les-00.txt
>
>
> Douglas and all,
> from my european point of view, "Telephone number provider"
> has a strong
> flavor of administration system, which is not the purpose of the draft
> because both types of entities are clearly separated within
> it. This term
> sounds connected to Number Pooling, that you already have in
> the States due
> to your implementation of Number portability but that studies showed
> inadequate to most of Europe countries for the time being.
> So, on this basis, I would prefer the former term TSP. I can
> offer another
> proposal, which is SAP (Service access Provider) and comes from an ITU
> Recommendation, in order to provide a kind of universal
> understanding if it
> is possible :-).
> In the ITU E.152 (International Freephone Service)
> definition, the SAP is
> responsible to ensure the establishment of access to the international
> freephone number in the country of origin of the call. It is
> also what was
> called ROA A (or service provider A, which is close to the
> TSP term) and
> renamed SAP. ROA A has the responsability of processing all
> applications
> received on behalf of their IFS customer. So it will obtain
> from the ITU the
> numbers requested by the customer and notifies him the "rules
> of the game"
> (no trading nor licensing of the numbers).
> Important note : this is not what "bellheads" call assignment
> of numbers,
> because the ITU_does_the assignment. It is an indirect
> allocation from the
> ITU to the subscriber via the SAP (not even a suballocation
> from the SAP to
> the subscriber).
> ROA A (SAP) is the interface with the customer and has overall control
> responsabilities to ensure the completion of the service order for
> initiation, change, suspension and disconnection of service.
> Of course, the E.152 exemple looks simplistic compared to the
> definitions of
> the draft : in E.152, the SAP act simultaneously as a TSP, an
> Agent and a
> registrant.
> A second point in §4.2, as a "bellhead", I think that the
> first quoted role
> of the TSP is misworded (see my important note above). So I
> would reword it
> E.164 indirect allocation (fit for services numbers like
> freephone) or E.164
> suballocation (fit for geogaphical numbers) and describe it
> as "suballocates
> E.164 numbers received from the administration system to subscribers".
> A third point I just saw : in the 2nd role of TSP, the words
> "to terminate"
> and "termination" might be misunderstood as "to accomplish a call" and
> "completion". I suggest to use "to disconnect" and
> "disconnection", if I am
> not the only one to think this misunderstanding is possible.
> To sum up :
> - I agree on TSP or SAP, mentionning in the first role
> "E.164 Suballocation
> : suballocates E.164 numbers received from the administration
> system to
> subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to
> Subscribers".
> - According to the forementionned reasons, I tend to disagree with
> "Telephone Number Provider".
> - I suggest to use "to disconnect" and "disconnection"instead of  "to
> terminate" and "termination"
>
> Valerie.
>
>
>
>
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Valérie Barnole
>
> FTR&D/DAC/ACE
>
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
>
> mail to : valerie.barnole@francetelecom.fr
>
>
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
>

Judith Oppenheimer, 212 684-7210, 1 800 The Expert
Publisher, http://www.ICBTollFreeNews.com
President, http://www.1800TheExpert.com
FREE 800/Domain Classifieds, http://ICBclassifieds.com
Domain Name & 800 News, Intelligence, Analysis


>


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:32:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29528
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:32:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06750;
	Fri, 1 Dec 2000 08:31:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06723
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:31:51 -0500 (EST)
Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29278
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:31:50 -0500 (EST)
Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20001201133116.RSXI1216.hvmta01-stg@dranalli>;
          Fri, 1 Dec 2000 08:31:16 -0500
Message-ID: <005201c05b9a$832e8890$5a498826@netnumber.com>
Reply-To: "Douglas Ranalli" <dranalli@netnumber.com>
From: "Douglas Ranalli" <dranalli@netnumber.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <rich.shockey@neustar.com>,
        <enum@ietf.org>
References: <DF737E620579D411A8E400D0B77E671D310FF5@regdom-ex01.prod.netsol.com>
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numbering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 08:27:54 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

Scott,

Thank you for the clarification and the recommendation.  Based on the way
you've described the BCP designation this sounds like a more appropriate fit
for the "roles & responsibilities" draft.  Richard (ENUM Chair), what's the
mechanism for following up on Scott's recommendation?

Doug

----- Original Message -----
From: Hollenbeck, Scott <shollenbeck@verisign.com>
To: 'Douglas Ranalli' <dranalli@netnumber.com>; <rich.shockey@neustar.com>;
<enum@ietf.org>
Sent: Thursday, November 30, 2000 7:20 PM
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers,
and Numbering Authorities - January 17, 2001


> Doug,
>
> I don't believe that the "Roles & Responsibilities" draft lends itself to
> the evolutionary standards track maturity levels (Proposed Standard, Draft
> Standard, Standard) as described in RFC 2026.  However, the definition of
> the Best Current Practice (BCP) series describes the benefit of
identifying
> "common guidelines for policies and operations", so perhaps targeting BCP
> would be appropriate.
>
> Scott Hollenbeck
> VeriSign Global Registry Services
>
> -----Original Message-----
> From: Douglas Ranalli [mailto:dranalli@netnumber.com]
> Sent: Thursday, November 30, 2000 5:10 PM
> To: rich.shockey@neustar.com; enum@ietf.org
> Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
> Makers, and Numbering Authorities - January 17, 2001
>
>
> Richard and ENUM list-group,
>
> I'm writing to follow-up on the note from Robert Shaw regarding the
upcoming
> ITU workshop on ENUM implementation.  My thought is that the "Roles &
> Responsibilities" draft that we've been discussing on the list group is a
> core document for ENUM and the ITU discussion.  The process of gaining
> agreement on the set of "actors" in the ENUM System and the "roles and
> responsibilities" of those actors is a foundation for all follow-on ENUM
> work.  Based on this, I'd like to propose that we consider making the
"Roles
> & Responsibilities" draft a standards track document so that we can all
work
> to gain consensus on a common framework for advancing ENUM.  Please let me
> know your thoughts.
>
> Regards,
>
> Doug
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:41:39 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03765
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:41:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06965;
	Fri, 1 Dec 2000 08:41:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06936
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:41:04 -0500 (EST)
Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03510
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:41:04 -0500 (EST)
Received: from worldnet ([12.88.173.43]) by mtiwmhc27.worldnet.att.net
          (InterMail vM.4.01.03.10 201-229-121-110) with SMTP
          id <20001201134027.LFYN2234.mtiwmhc27.worldnet.att.net@worldnet>;
          Fri, 1 Dec 2000 13:40:27 +0000
From: "Judith Oppenheimer" <joppenheimer@icbtollfree.com>
To: "'BARNOLE Valerie FTRD/DAC/ISS'" <valerie.barnole@rd.francetelecom.fr>
Cc: <enum@ietf.org>
Subject: RE: CORRECTION   RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt
Date: Fri, 1 Dec 2000 08:37:50 -0500
Message-ID: <026701c05b9b$e6a4ea80$2bad580c@att.net.icbtollfree.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <98388C05D464D111B61800805F1504160233A118@p-ibis.issy.cnet.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: High
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA06965
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03765

> as an operator, I make money from my customers, so I tend to get a
> subscriber-centric approach.

Our operators take a subscribe-centric approach too - for themselves as the
subscriber!

In the U.S. toll free arena, TSP's directly compete with subscribers for
valuable 800 numbers both for their own (MCI Worldcom's 1 800 COLLECT) and
related uses.  Warehousing of numbers by TSP's is rampant; "loss" and theft
is not an uncommon occurrence.  TSP's will concoct billing disputes in
attempts to withhold portability from or directly steal numbers from
subscribers.

I know this first hand because much of my consulting practice is comprised
of retrieving lost and stolen numbers for aggrieved subscribers.  Its a
very black and white issue, with nothing subject to interpretation.  Either
the paper trail reflects the subscriber's contention, or not.  We turn away
few projects because most are legitimate.  Our track record at retrieval
and/or actionable accountability, is virtually 100%.

Of course, there is much more of this activity than comes across my desk,
either dealt with by others, or dropped because subscribers don't yet know
they can "fight city hall," so to speak.

Its a very competitive environment.  The RespOrg is supposed to represent
only the subscriber's interest in the toll free number and service.  Rather
shortsightedly and naively, the FCC allowed TSP's to become RespOrgs,
allowing the foxes in the henhouse.

There are however independent RespOrgs as well, and as more people learn of
their options, they make the smarter choice of separating their RespOrg and
TSP vendors.

It is important not to lose distinctions whether U.S. or elsewhere that
protect and benefit the end user public, just to rush to completion, a
one-size-fits-all ENUM.

Judith

Judith Oppenheimer, 212 684-7210, 1 800 The Expert
Publisher, http://www.ICBTollFreeNews.com
President, http://www.1800TheExpert.com
FREE 800/Domain Classifieds, http://ICBclassifieds.com
Domain Name & 800 News, Intelligence, Analysis


> -----Original Message-----
> From: BARNOLE Valerie FTRD/DAC/ISS
> [mailto:valerie.barnole@rd.francetelecom.fr]
> Sent: Friday, December 01, 2000 7:11 AM
> To: 'Judith Oppenheimer'
> Cc: enum@ietf.org
> Subject: RE: CORRECTION RE: [Enum]
> I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt
>
>
> Judith,
> as an operator, I make money from my customers, so I tend to get a
> subscriber-centric approach.
> But in that case, the Subscriber Agent role is redundant with
> the TSP role
> in my opinion.
> Maybe it is my european view or my ITU UIFN view, but I do
> not figure out
> situations where the TSP (the one who will suballocate or
> will indirectly
> allocate the number to the subscriber) and the SA will be different
> entities. You may say that the SA will contact the TSP on
> behalf of the
> subscriber, but it makes a lot of people around in my opinion.
>
> Valerie.
>
>
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Valérie Barnole
>
> FTR&D/DAC/ACE
>
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
>
> mail to : valerie.barnole@francetelecom.fr
>
>
>
> -----Message d'origine-----
> De : Judith Oppenheimer [mailto:joppenheimer@icbtollfree.com]
> Envoyé : jeudi 30 novembre 2000 19:05
> À : 'BARNOLE Valerie FTRD/DAC/ISS'; 'Douglas Ranalli'
> Cc : enum@ietf.org
> Objet : CORRECTION RE: [Enum]
> I-DACTION:draft-ranalli-peek-walter-enum-t1ro les-00.txt
>
>
> My last post went out incomplete (my keyboard sometimes has a
> mind of its
> own <grin>) ...
>
> > A third point I just saw : in the 2nd role of TSP, the words
> > "to terminate"
> > and "termination" might be misunderstood as "to accomplish
> a call" and
> > "completion". I suggest to use "to disconnect" and
> > "disconnection", if I am
> > not the only one to think this misunderstanding is possible.
>
> I agree.
>
> > Important note : this is not what "bellheads" call assignment
> > of numbers,
> > because the ITU_does_the assignment. It is an indirect
> > allocation from the
> > ITU to the subscriber via the SAP (not even a suballocation
> > from the SAP to
> > the subscriber).
>
> This description parallels that of the RespOrg and its
> relationship to the
> 800 SMS and the subscriber, except that the RespOrg maintains the
> subscriber ID records, not the 800 SMS.  (Because FCC regs
> and the tariff
> stipulate that a RespOrg must have a customer for every
> number it reserves,
> I don't think it would be considered a suballocation either.)
>
> > So I
> > would reword it
> > E.164 indirect allocation (fit for services numbers like
> > freephone) or E.164
> > suballocation (fit for geogaphical numbers) and describe it
> > as "suballocates
> > E.164 numbers received from the administration system to
> subscribers".
>
> This makes sense.  Re acronyms, it depends if you consider
> the verification
> process telephone number-centric or subscriber-centric.
>
> In the first case TNA for Telephone Number Allocator or TNV
> for Telephone
> Number Verifier would make sense.  If the latter, SA, for
> Subscriber Agent,
> since that is the function of an SAP or RespOrg:  an agency
> function on
> behalf of the subscriber solely for management of the number.
>
> On another general point, the North American Numbering
> Council's Chair John
> R. Hoffman points out this week to the FCC, "It should be
> noted that the
> toll free system is far larger and more complex than the LNP
> system.  This
> is due to the fact that the LNP system provides the ability only to
> identify the service provider to complete a call to a
> telephone number;
> while the toll free system provides capabilities (e.g., time-of-day
> routing, routing based on the point of origination, routing based on
> pre-established call loads, etc.) far greater than anything
> contemplated
> for LNP."
>
> I point out this distinction to help clarify the difference
> between local
> number portability, and toll free portability, which has much
> more complex
> provisioning and contact variables attached to it.
>
> Judith
>
> Judith Oppenheimer, 212 684-7210, 1 800 The Expert
> Publisher, http://www.ICBTollFreeNews.com
> President, http://www.1800TheExpert.com
> FREE 800/Domain Classifieds, http://ICBclassifieds.com
> Domain Name & 800 News, Intelligence, Analysis
>
>
> > -----Original Message-----
> > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
> > BARNOLE Valerie FTRD/DAC/ISS
> > Sent: Thursday, November 30, 2000 11:53 AM
> > To: 'Douglas Ranalli'
> > Cc: 'enum@ietf.org'
> > Subject: RE: [Enum] I-DACTION:draft-ranalli-peek-walter-enum-t1ro
> > les-00.txt
> >
> >
> > Douglas and all,
> > from my european point of view, "Telephone number provider"
> > has a strong
> > flavor of administration system, which is not the purpose
> of the draft
> > because both types of entities are clearly separated within
> > it. This term
> > sounds connected to Number Pooling, that you already have in
> > the States due
> > to your implementation of Number portability but that studies showed
> > inadequate to most of Europe countries for the time being.
> > So, on this basis, I would prefer the former term TSP. I can
> > offer another
> > proposal, which is SAP (Service access Provider) and comes
> from an ITU
> > Recommendation, in order to provide a kind of universal
> > understanding if it
> > is possible :-).
> > In the ITU E.152 (International Freephone Service)
> > definition, the SAP is
> > responsible to ensure the establishment of access to the
> international
> > freephone number in the country of origin of the call. It is
> > also what was
> > called ROA A (or service provider A, which is close to the
> > TSP term) and
> > renamed SAP. ROA A has the responsability of processing all
> > applications
> > received on behalf of their IFS customer. So it will obtain
> > from the ITU the
> > numbers requested by the customer and notifies him the "rules
> > of the game"
> > (no trading nor licensing of the numbers).
> > Important note : this is not what "bellheads" call assignment
> > of numbers,
> > because the ITU_does_the assignment. It is an indirect
> > allocation from the
> > ITU to the subscriber via the SAP (not even a suballocation
> > from the SAP to
> > the subscriber).
> > ROA A (SAP) is the interface with the customer and has
> overall control
> > responsabilities to ensure the completion of the service order for
> > initiation, change, suspension and disconnection of service.
> > Of course, the E.152 exemple looks simplistic compared to the
> > definitions of
> > the draft : in E.152, the SAP act simultaneously as a TSP, an
> > Agent and a
> > registrant.
> > A second point in §4.2, as a "bellhead", I think that the
> > first quoted role
> > of the TSP is misworded (see my important note above). So I
> > would reword it
> > E.164 indirect allocation (fit for services numbers like
> > freephone) or E.164
> > suballocation (fit for geogaphical numbers) and describe it
> > as "suballocates
> > E.164 numbers received from the administration system to
> subscribers".
> > A third point I just saw : in the 2nd role of TSP, the words
> > "to terminate"
> > and "termination" might be misunderstood as "to accomplish
> a call" and
> > "completion". I suggest to use "to disconnect" and
> > "disconnection", if I am
> > not the only one to think this misunderstanding is possible.
> > To sum up :
> > - I agree on TSP or SAP, mentionning in the first role
> > "E.164 Suballocation
> > : suballocates E.164 numbers received from the administration
> > system to
> > subscribers" instead of "E.164 Assignment : Assigns E.164 numbers to
> > Subscribers".
> > - According to the forementionned reasons, I tend to disagree with
> > "Telephone Number Provider".
> > - I suggest to use "to disconnect" and
> "disconnection"instead of  "to
> > terminate" and "termination"
> >
> > Valerie.
> >
> >
> >
> >
> > end of message
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> >
> > Valérie Barnole
> >
> > FTR&D/DAC/ACE
> >
> > tel. : + 33 1 45 29 58 39
> > fax : + 33 1 46 29 31 42
> >
> > mail to : valerie.barnole@francetelecom.fr
> >
> >
> >
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> >
>
> Judith Oppenheimer, 212 684-7210, 1 800 The Expert
> Publisher, http://www.ICBTollFreeNews.com
> President, http://www.1800TheExpert.com
> FREE 800/Domain Classifieds, http://ICBclassifieds.com
> Domain Name & 800 News, Intelligence, Analysis
>
>
> >
>
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:41:56 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03891
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:41:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07038;
	Fri, 1 Dec 2000 08:41:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07006
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:41:24 -0500 (EST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03653
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:41:24 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21)
	id <X57PD1VS>; Fri, 1 Dec 2000 14:40:50 +0100
Message-ID: <98388C05D464D111B61800805F1504160233A11A@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>
Cc: "'enum@ietf.org'" <enum@ietf.org>, "'James Yu'" <james.yu@neustar.com>
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Fri, 1 Dec 2000 14:40:48 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA07007
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA07038
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03891

John,

the draft is not clear to me on some points.
1) You do a search on the mobile subscriber within e164.arpa number and you
get a DNS record with a service flag saying "roam+E2I". I suppose that you
can also receive other DNS records, like "E2U" or "SIP+E2U". Am I correct ?
2) If so, how can the "roam+E2I" is chosen ? It should be on a priority
basis that is enterd according to the subscriber. Am I right ?
3)If so, does it mean that the subscriber has to put the roaming always in
first priority ? 
4) where do the e214.arpa and e212.arpa searches take place ?
5) in the§4 example, Nokia offers the service "roam+E2I". Does it mean that
Nokia (which is a manufacturer and not a mobile operator, but I may be too
square) knows the IP address of the VLR or HLR ?
6) I am not an SCCP or a mobile specialist, but in the case of 3G to 2G
roaming, I think that 2G nodes might not have an IP address. In case they
have, it wouldn't be necessary to use E.212 or E.214. I don't know if this
assumption is correct.

Could you follow on your §4 nokia example to picture a situation where
e214.arpa or e212.searches would be necessary and used ?

Thank you.

Valerie.

 
end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole

FTR&D/DAC/ACE

tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

mail to : valerie.barnole@francetelecom.fr



-----Message d'origine-----
De : James Yu [mailto:james.yu@neustar.com]
Envoyé : mercredi 29 novembre 2000 19:27
À : 'BARNOLE Valerie FTRD/DAC/ISS'
Cc : enum@ietf.org; 'john.loughney@nokia.com'
Objet : RE: [Enum] RE: draft-loughney-enum-roaming-00.txt


Valerie,

enum is for E.164 number so E.212 (IMSI) or E.214 (mobile global title)
needs to use something else such as e212.arpa or e214.arpa.  The reason
E.214 is used today in the GSM has reasons due to SS7 message routing across
national boundaries.  IMHO, we probably only need e212.arpa.

One thing good about IMSI is that it is not portable (e.g., there is a
mobile network code that belongs to the cellular carrier) and the cellular
carriers are the ones that control those numbers (e.g., they can be the T2E
for their own IMSIs).  So there is no need to populate individual IMSIs at
the T1E.  A block of IMSIs will do the job.  For example, the T1E can point
to a T2E based on the first six digits of the IMSI.  The T2E returns the
NAPTR RRs for the associated IMSI.

The draft is for cases when E.164 numbers are used to identify cellular node
(e.g., HLR, VLR and message center, etc.).

James 

> -----Original Message-----
> From: BARNOLE Valerie FTRD/DAC/ISS
> [mailto:valerie.barnole@rd.francetelecom.fr]
> Sent: Wednesday, November 29, 2000 12:09 PM
> To: 'john.loughney@nokia.com'; james.yu@neustar.com; enum@ietf.org
> Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> John,
> I am sorry, I can't retrieve your 
> draft-loughney-enum-roaming-00.txt. Can
> you send it, please ?
> 
> I suppose that in this draft, you populate the DNS with E.212 or E.214
> numbers. I do not have your draft to see how you deal with the
> confidentiality of the IMSI, but my first idea is that mobile 
> operators
> should be very reluctant to populate the DNS with such 
> confidential data.
> Thank you for sending me your draft.
> 
> Regards,
> 
> Valerie.
> 
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> Valérie Barnole
> 
> FTR&D/DAC/ACE
> 
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
> 
> mail to : valerie.barnole@francetelecom.fr
> 
> 
> 
> -----Message d'origine-----
> De : john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Envoyé : mardi 7 novembre 2000 08:34
> À : james.yu@neustar.com; enum@ietf.org
> Cc : john.loughney@nokia.com
> Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> Hi James & everyone,
> 
> > One reason that GTT is used in SS7 message transport is 
> > because the message routing in many cases involve two 
> > cellular networks in different countries. A SS7 point code 
> > in U.K. cannot be used directly by a SS7 node in France to
> > send a SS7 message to.   IP will change that because IP is 
> > global.  This is just one example of use of ENUM.  Another 
> > example is to identify the message center that serves a 
> > particular cellular subscriber when there is a short
> > message destined towards that subscriber.  In this example, 
> > the E.164 number is assigned to an cellular subscriber; 
> > however, the service that uses ENUM is again a "network-related 
> > service."
> 
> Thanks for summarizing the intention of this draft.  You did 
> a much better job that what I did at Pittsburgh :)
> 
> I also want to mention that this issues will get much more
> complicated in the proposed 3G networks.  There will be 
> operators implementing all of their networks over IP.  In 
> your scenario, there will need to be some negotiation/
> mapping between the SS7 addresses and IP address that will
> be assigned for the VLR/HLR.
> 
> One further complication is that there may be AAA servers 
> providing the same functionality for 3G cellular subscribers.
> 
> I would like to think that ENUM could be a techology that is
> used to promote interoperability/interworking for this 
> purpose.
> 
> > John and I would like to hear from you to see whether they is 
> > any problem to move this I-D forward.  
> 
> thanks,
> John
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:43:31 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04646
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:43:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07187;
	Fri, 1 Dec 2000 08:43:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07156
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:43:02 -0500 (EST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04430
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:43:02 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir04nok.nokia.com (esvir04nok.nokia.com [131.228.20.76])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB1Dhcw04102
	for <enum@ietf.org>; Fri, 1 Dec 2000 15:43:38 +0200 (EET)
Received: from esebh03nok.ntc.nokia.com (unverified) by esvir04nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e4144cf85037ca25b3@esvir04nok.nokia.com>;
 Fri, 1 Dec 2000 15:42:58 +0200
Received: by esebh03nok with Internet Mail Service (5.5.2652.78)
	id <XZKRLRLX>; Fri, 1 Dec 2000 15:42:58 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF496@eseis04nok>
To: valerie.barnole@rd.francetelecom.fr, john.loughney@nokia.com
Cc: enum@ietf.org, james.yu@neustar.com
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Fri, 1 Dec 2000 15:42:57 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA07157
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA07187
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04646

Hi Valerie,

Thanks for your comments.  I will review them shortly - I have 
a few things to clear up first.

I have updated the draft, but I did not make the cut-off time
(network problems made me 5 minutes too late!)

I will try to re-issue it after the IETF meeting, and will
incorporate comments from you.

thanks,
John
 
> the draft is not clear to me on some points.
> 1) You do a search on the mobile subscriber within e164.arpa 
> number and you
> get a DNS record with a service flag saying "roam+E2I". I 
> suppose that you
> can also receive other DNS records, like "E2U" or "SIP+E2U". 
> Am I correct ?
> 2) If so, how can the "roam+E2I" is chosen ? It should be on 
> a priority
> basis that is enterd according to the subscriber. Am I right ?
> 3)If so, does it mean that the subscriber has to put the 
> roaming always in
> first priority ? 
> 4) where do the e214.arpa and e212.arpa searches take place ?
> 5) in the§4 example, Nokia offers the service "roam+E2I". 
> Does it mean that
> Nokia (which is a manufacturer and not a mobile operator, but 
> I may be too
> square) knows the IP address of the VLR or HLR ?
> 6) I am not an SCCP or a mobile specialist, but in the case 
> of 3G to 2G
> roaming, I think that 2G nodes might not have an IP address. 
> In case they
> have, it wouldn't be necessary to use E.212 or E.214. I don't 
> know if this
> assumption is correct.
> 
> Could you follow on your §4 nokia example to picture a situation where
> e214.arpa or e212.searches would be necessary and used ?
> 
> Thank you.
> 
> Valerie.
> 
>  
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> Valérie Barnole
> 
> FTR&D/DAC/ACE
> 
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
> 
> mail to : valerie.barnole@francetelecom.fr
> 
> 
> 
> -----Message d'origine-----
> De : James Yu [mailto:james.yu@neustar.com]
> Envoyé : mercredi 29 novembre 2000 19:27
> À : 'BARNOLE Valerie FTRD/DAC/ISS'
> Cc : enum@ietf.org; 'john.loughney@nokia.com'
> Objet : RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> Valerie,
> 
> enum is for E.164 number so E.212 (IMSI) or E.214 (mobile 
> global title)
> needs to use something else such as e212.arpa or e214.arpa.  
> The reason
> E.214 is used today in the GSM has reasons due to SS7 message 
> routing across
> national boundaries.  IMHO, we probably only need e212.arpa.
> 
> One thing good about IMSI is that it is not portable (e.g., there is a
> mobile network code that belongs to the cellular carrier) and 
> the cellular
> carriers are the ones that control those numbers (e.g., they 
> can be the T2E
> for their own IMSIs).  So there is no need to populate 
> individual IMSIs at
> the T1E.  A block of IMSIs will do the job.  For example, the 
> T1E can point
> to a T2E based on the first six digits of the IMSI.  The T2E 
> returns the
> NAPTR RRs for the associated IMSI.
> 
> The draft is for cases when E.164 numbers are used to 
> identify cellular node
> (e.g., HLR, VLR and message center, etc.).
> 
> James 
> 
> > -----Original Message-----
> > From: BARNOLE Valerie FTRD/DAC/ISS
> > [mailto:valerie.barnole@rd.francetelecom.fr]
> > Sent: Wednesday, November 29, 2000 12:09 PM
> > To: 'john.loughney@nokia.com'; james.yu@neustar.com; enum@ietf.org
> > Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > John,
> > I am sorry, I can't retrieve your 
> > draft-loughney-enum-roaming-00.txt. Can
> > you send it, please ?
> > 
> > I suppose that in this draft, you populate the DNS with 
> E.212 or E.214
> > numbers. I do not have your draft to see how you deal with the
> > confidentiality of the IMSI, but my first idea is that mobile 
> > operators
> > should be very reluctant to populate the DNS with such 
> > confidential data.
> > Thank you for sending me your draft.
> > 
> > Regards,
> > 
> > Valerie.
> > 
> > end of message
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > 
> > Valérie Barnole
> > 
> > FTR&D/DAC/ACE
> > 
> > tel. : + 33 1 45 29 58 39
> > fax : + 33 1 46 29 31 42
> > 
> > mail to : valerie.barnole@francetelecom.fr
> > 
> > 
> > 
> > -----Message d'origine-----
> > De : john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Envoyé : mardi 7 novembre 2000 08:34
> > À : james.yu@neustar.com; enum@ietf.org
> > Cc : john.loughney@nokia.com
> > Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > Hi James & everyone,
> > 
> > > One reason that GTT is used in SS7 message transport is 
> > > because the message routing in many cases involve two 
> > > cellular networks in different countries. A SS7 point code 
> > > in U.K. cannot be used directly by a SS7 node in France to
> > > send a SS7 message to.   IP will change that because IP is 
> > > global.  This is just one example of use of ENUM.  Another 
> > > example is to identify the message center that serves a 
> > > particular cellular subscriber when there is a short
> > > message destined towards that subscriber.  In this example, 
> > > the E.164 number is assigned to an cellular subscriber; 
> > > however, the service that uses ENUM is again a "network-related 
> > > service."
> > 
> > Thanks for summarizing the intention of this draft.  You did 
> > a much better job that what I did at Pittsburgh :)
> > 
> > I also want to mention that this issues will get much more
> > complicated in the proposed 3G networks.  There will be 
> > operators implementing all of their networks over IP.  In 
> > your scenario, there will need to be some negotiation/
> > mapping between the SS7 addresses and IP address that will
> > be assigned for the VLR/HLR.
> > 
> > One further complication is that there may be AAA servers 
> > providing the same functionality for 3G cellular subscribers.
> > 
> > I would like to think that ENUM could be a techology that is
> > used to promote interoperability/interworking for this 
> > purpose.
> > 
> > > John and I would like to hear from you to see whether they is 
> > > any problem to move this I-D forward.  
> > 
> > thanks,
> > John
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:47:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06257
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:47:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07467;
	Fri, 1 Dec 2000 08:46:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07375
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:46:15 -0500 (EST)
Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05898
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:46:14 -0500 (EST)
Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21)
	id <XXLZ2YWJ>; Fri, 1 Dec 2000 14:45:32 +0100
Message-ID: <98388C05D464D111B61800805F1504160233A11B@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>
Cc: enum@ietf.org, james.yu@neustar.com
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Fri, 1 Dec 2000 14:45:32 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA07376
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA07467
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06257

Thanks a lot. If I understand, I think everybody will !!!!:-)

Valerie.

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole

FTR&D/DAC/ACE

tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

mail to : valerie.barnole@francetelecom.fr



-----Message d'origine-----
De : john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Envoyé : vendredi 1 décembre 2000 14:43
À : valerie.barnole@rd.francetelecom.fr; john.loughney@nokia.com
Cc : enum@ietf.org; james.yu@neustar.com
Objet : RE: [Enum] RE: draft-loughney-enum-roaming-00.txt


Hi Valerie,

Thanks for your comments.  I will review them shortly - I have 
a few things to clear up first.

I have updated the draft, but I did not make the cut-off time
(network problems made me 5 minutes too late!)

I will try to re-issue it after the IETF meeting, and will
incorporate comments from you.

thanks,
John
 
> the draft is not clear to me on some points.
> 1) You do a search on the mobile subscriber within e164.arpa 
> number and you
> get a DNS record with a service flag saying "roam+E2I". I 
> suppose that you
> can also receive other DNS records, like "E2U" or "SIP+E2U". 
> Am I correct ?
> 2) If so, how can the "roam+E2I" is chosen ? It should be on 
> a priority
> basis that is enterd according to the subscriber. Am I right ?
> 3)If so, does it mean that the subscriber has to put the 
> roaming always in
> first priority ? 
> 4) where do the e214.arpa and e212.arpa searches take place ?
> 5) in the§4 example, Nokia offers the service "roam+E2I". 
> Does it mean that
> Nokia (which is a manufacturer and not a mobile operator, but 
> I may be too
> square) knows the IP address of the VLR or HLR ?
> 6) I am not an SCCP or a mobile specialist, but in the case 
> of 3G to 2G
> roaming, I think that 2G nodes might not have an IP address. 
> In case they
> have, it wouldn't be necessary to use E.212 or E.214. I don't 
> know if this
> assumption is correct.
> 
> Could you follow on your §4 nokia example to picture a situation where
> e214.arpa or e212.searches would be necessary and used ?
> 
> Thank you.
> 
> Valerie.
> 
>  
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> Valérie Barnole
> 
> FTR&D/DAC/ACE
> 
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
> 
> mail to : valerie.barnole@francetelecom.fr
> 
> 
> 
> -----Message d'origine-----
> De : James Yu [mailto:james.yu@neustar.com]
> Envoyé : mercredi 29 novembre 2000 19:27
> À : 'BARNOLE Valerie FTRD/DAC/ISS'
> Cc : enum@ietf.org; 'john.loughney@nokia.com'
> Objet : RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> Valerie,
> 
> enum is for E.164 number so E.212 (IMSI) or E.214 (mobile 
> global title)
> needs to use something else such as e212.arpa or e214.arpa.  
> The reason
> E.214 is used today in the GSM has reasons due to SS7 message 
> routing across
> national boundaries.  IMHO, we probably only need e212.arpa.
> 
> One thing good about IMSI is that it is not portable (e.g., there is a
> mobile network code that belongs to the cellular carrier) and 
> the cellular
> carriers are the ones that control those numbers (e.g., they 
> can be the T2E
> for their own IMSIs).  So there is no need to populate 
> individual IMSIs at
> the T1E.  A block of IMSIs will do the job.  For example, the 
> T1E can point
> to a T2E based on the first six digits of the IMSI.  The T2E 
> returns the
> NAPTR RRs for the associated IMSI.
> 
> The draft is for cases when E.164 numbers are used to 
> identify cellular node
> (e.g., HLR, VLR and message center, etc.).
> 
> James 
> 
> > -----Original Message-----
> > From: BARNOLE Valerie FTRD/DAC/ISS
> > [mailto:valerie.barnole@rd.francetelecom.fr]
> > Sent: Wednesday, November 29, 2000 12:09 PM
> > To: 'john.loughney@nokia.com'; james.yu@neustar.com; enum@ietf.org
> > Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > John,
> > I am sorry, I can't retrieve your 
> > draft-loughney-enum-roaming-00.txt. Can
> > you send it, please ?
> > 
> > I suppose that in this draft, you populate the DNS with 
> E.212 or E.214
> > numbers. I do not have your draft to see how you deal with the
> > confidentiality of the IMSI, but my first idea is that mobile 
> > operators
> > should be very reluctant to populate the DNS with such 
> > confidential data.
> > Thank you for sending me your draft.
> > 
> > Regards,
> > 
> > Valerie.
> > 
> > end of message
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > 
> > Valérie Barnole
> > 
> > FTR&D/DAC/ACE
> > 
> > tel. : + 33 1 45 29 58 39
> > fax : + 33 1 46 29 31 42
> > 
> > mail to : valerie.barnole@francetelecom.fr
> > 
> > 
> > 
> > -----Message d'origine-----
> > De : john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Envoyé : mardi 7 novembre 2000 08:34
> > À : james.yu@neustar.com; enum@ietf.org
> > Cc : john.loughney@nokia.com
> > Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > Hi James & everyone,
> > 
> > > One reason that GTT is used in SS7 message transport is 
> > > because the message routing in many cases involve two 
> > > cellular networks in different countries. A SS7 point code 
> > > in U.K. cannot be used directly by a SS7 node in France to
> > > send a SS7 message to.   IP will change that because IP is 
> > > global.  This is just one example of use of ENUM.  Another 
> > > example is to identify the message center that serves a 
> > > particular cellular subscriber when there is a short
> > > message destined towards that subscriber.  In this example, 
> > > the E.164 number is assigned to an cellular subscriber; 
> > > however, the service that uses ENUM is again a "network-related 
> > > service."
> > 
> > Thanks for summarizing the intention of this draft.  You did 
> > a much better job that what I did at Pittsburgh :)
> > 
> > I also want to mention that this issues will get much more
> > complicated in the proposed 3G networks.  There will be 
> > operators implementing all of their networks over IP.  In 
> > your scenario, there will need to be some negotiation/
> > mapping between the SS7 addresses and IP address that will
> > be assigned for the VLR/HLR.
> > 
> > One further complication is that there may be AAA servers 
> > providing the same functionality for 3G cellular subscribers.
> > 
> > I would like to think that ENUM could be a techology that is
> > used to promote interoperability/interworking for this 
> > purpose.
> > 
> > > John and I would like to hear from you to see whether they is 
> > > any problem to move this I-D forward.  
> > 
> > thanks,
> > John
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 08:53:41 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09178
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 08:53:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07660;
	Fri, 1 Dec 2000 08:53:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07632
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 08:53:08 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08910
	for <enum@ietf.org>; Fri, 1 Dec 2000 08:53:07 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir01nok.nokia.com (esvir01nok.nokia.com [131.228.20.73])
	by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eB1DqtK26184
	for <enum@ietf.org>; Fri, 1 Dec 2000 15:52:56 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <B83e414495037d34251@esvir01nok.nokia.com> for <enum@ietf.org>;
 Fri, 1 Dec 2000 15:52:55 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <YBKBJ1T8>; Fri, 1 Dec 2000 15:52:55 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF497@eseis04nok>
To: enum@ietf.org
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Maker
	s, and Numbering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 15:52:45 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi all,

> Thank you for the clarification and the recommendation.  
> Based on the way you've described the BCP designation this 
> sounds like a more appropriate fit for the "roles & 
> responsibilities" draft.  

I may be wrong, but I think that BCP documents should be
based on implementational / usage experiences.  I don't
think we are at that stage yet. 

I think INFORMATION should be the best designation.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 09:14:40 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18249
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 09:14:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08124;
	Fri, 1 Dec 2000 09:14:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08095
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 09:14:06 -0500 (EST)
Received: from heron.verisign.com ([216.168.233.95])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18235
	for <enum@ietf.org>; Fri, 1 Dec 2000 09:14:06 -0500 (EST)
Received: from REGDOM-EX01.prod.netsol.com (rdex01-node1.prod.netsol.com [10.131.4.28])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA04038;
	Fri, 1 Dec 2000 09:03:17 -0500 (EST)
Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2650.21)
	id <WRNGZP63>; Fri, 1 Dec 2000 09:10:24 -0500
Message-ID: <DF737E620579D411A8E400D0B77E671D310FFB@regdom-ex01.prod.netsol.com>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, enum@ietf.org
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Maker
	 s, and Numbering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 09:10:20 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

John,

Per RFC 2026 "An "Informational" specification is published for the general
information of the Internet community, and does not represent an Internet
community consensus or recommendation."

If the idea is to document consensus, Informational thus doesn't seem
appropriate.  On the other hand, RFC 2026 has this to say about BCP:

"The BCP subseries of the RFC series is designed to be a way to standardize
practices and the results of community deliberations. A BCP document is
subject to the same basic set of procedures as standards track documents and
thus is a vehicle by which the IETF community can define and ratify the
community's best current thinking on a statement of principle or on what is
believed to be the best way to perform some operations or IETF process
function."

The "community deliberations" and "best current thinking" descriptions in
the latter quote are what triggered my suggestion for BCP.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Friday, December 01, 2000 8:53 AM
To: enum@ietf.org
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
Maker s, and Numbering Authorities - January 17, 2001


Hi all,

> Thank you for the clarification and the recommendation.  
> Based on the way you've described the BCP designation this 
> sounds like a more appropriate fit for the "roles & 
> responsibilities" draft.  

I may be wrong, but I think that BCP documents should be
based on implementational / usage experiences.  I don't
think we are at that stage yet. 

I think INFORMATION should be the best designation.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 09:17:49 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18363
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 09:17:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08291;
	Fri, 1 Dec 2000 09:17:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08256
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 09:17:07 -0500 (EST)
Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18324
	for <enum@ietf.org>; Fri, 1 Dec 2000 09:17:07 -0500 (EST)
Received: from seagal ([208.146.135.202]) by hvmta03-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20001201141638.YABA24415.hvmta03-stg@seagal>;
          Fri, 1 Dec 2000 09:16:38 -0500
From: "David P. Peek" <dpeek@netnumber.com>
To: <john.loughney@nokia.com>, <enum@ietf.org>
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and Numbering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 09:16:44 -0500
Message-ID: <NEBBIIBBHJMPEMJAACBPGEMOCGAA.dpeek@netnumber.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE1031DF497@eseis04nok>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

To All,

According to RFC 2026 Section 5 I believe Scott is correct is making the
Tier 1 Roles and Responsibilities document a BCP.

RFC2026 part of Section 5:

	The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

Dave




> -----Original Message-----
> From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of
> john.loughney@nokia.com
> Sent: Friday, December 01, 2000 8:53 AM
> To: enum@ietf.org
> Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
> Makers, and Numbering Authorities - January 17, 2001
>
>
> Hi all,
>
> > Thank you for the clarification and the recommendation.
> > Based on the way you've described the BCP designation this
> > sounds like a more appropriate fit for the "roles &
> > responsibilities" draft.
>
> I may be wrong, but I think that BCP documents should be
> based on implementational / usage experiences.  I don't
> think we are at that stage yet.
>
> I think INFORMATION should be the best designation.
>
> best regards,
> John
>
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 09:25:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18583
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 09:25:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08444;
	Fri, 1 Dec 2000 09:24:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08415
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 09:24:53 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18559
	for <enum@ietf.org>; Fri, 1 Dec 2000 09:24:47 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir05nok.nokia.com (esvir05nok.nokia.com [131.228.20.77])
	by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eB1EOKK26539
	for <enum@ietf.org>; Fri, 1 Dec 2000 16:24:36 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir05nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e4144d775037ee084b@esvir05nok.nokia.com>;
 Fri, 1 Dec 2000 16:22:10 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <YBKBJHC2>; Fri, 1 Dec 2000 16:22:10 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF49A@eseis04nok>
To: shollenbeck@verisign.com, enum@ietf.org
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Maker
	 s, and Numbering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 16:22:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Scott,

> The "community deliberations" and "best current thinking" 
> descriptions in the latter quote are what triggered my suggestion 
> for BCP.

I stand corrected.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 09:34:24 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18896
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 09:34:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08833;
	Fri, 1 Dec 2000 09:33:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08804
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 09:33:52 -0500 (EST)
Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18881
	for <enum@ietf.org>; Fri, 1 Dec 2000 09:33:52 -0500 (EST)
Received: from dcrocker.dcrocker.net (node-64-145-172-82.dslspeed.zyan.com [64.145.172.82])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA20586;
	Fri, 1 Dec 2000 06:33:50 -0800
Message-Id: <5.0.1.4.2.20001201063442.033cf1c0@joy.songbird.com>
X-Sender: dhc@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 01 Dec 2000 06:36:06 -0800
To: "Douglas Ranalli" <dranalli@netnumber.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
  Makers, and Numbering Authorities - January 17, 2001
Cc: <enum@ietf.org>
In-Reply-To: <005201c05b9a$832e8890$5a498826@netnumber.com>
References: <DF737E620579D411A8E400D0B77E671D310FF5@regdom-ex01.prod.netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 08:27 AM 12/1/00 -0500, Douglas Ranalli wrote:
>Based on the way
>you've described the BCP designation this sounds like a more appropriate fit
>for the "roles & responsibilities" draft.  Richard (ENUM Chair), what's the
>mechanism for following up on Scott's recommendation?

The process of getting BCP is the same as getting Proposed Standard, except 
for the label.  (Purists might disagree with me, but I believe there are no 
meaningful differences.)

In other words, get a stable specification for which there is consensus, 
and then submit it to the IESG for approval.

d/


=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 11:22:23 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06834
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 11:22:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10700;
	Fri, 1 Dec 2000 11:21:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10669
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 11:21:29 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06627
	for <enum@ietf.org>; Fri, 1 Dec 2000 11:21:27 -0500 (EST)
Received: by dnspri.npac.com; id KAA21871; Fri, 1 Dec 2000 10:21:27 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma021438; Fri, 1 Dec 00 10:20:47 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGS3W3>; Fri, 1 Dec 2000 10:19:06 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CEA238A@dc02.npac.com>
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: "'A.M. Rutkowski'" <amr@netmagic.com>,
        "Shaw, Robert"
	 <Robert.Shaw@itu.int>,
        "'enum@ietf.org'" <enum@ietf.org>
Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Maker
	s, and Numb ering Authorities - January 17, 2001
Date: Fri, 1 Dec 2000 10:25:03 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C05BB2.6D14A630"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C05BB2.6D14A630
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, Tony.
 
So far, the only context I'm aware of came out of the October 2000 WP1/2
Berlin meeting, that a number of the list members (including you and me)
attended.  An extract from the I-D (for which one URL is
http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.txt
<http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.txt> )
states that:
 
<!--StartFragment-->
    o  The study being undertaken within WP1/2 (referred to above) will
       also attempt to identify options and provide guidance to assist
       those entities charged with the task of providing the
       administrative information to DNS administrators.
 
(The other study "referred to above" mentioned number portability and the
following extract applied to it: "However, it is currently understood that
this study and its result will not impact the IETF and its work.")
 
The new work was echoed in the Meeting Report as:   
 
8.5        The meeting noted that a new work project would be introduced in
Q.1/2 to study implementation issues specifically related to the provision
of E.164 resource information into the DNS with a view to identifying
options and guidance to ITU Member States.
 
I haven't seen anything more specific yet about this for the January SG2
meeting.
 
-Andy
 
 
Andrew Gallant, +1 202 533-2812,  <mailto:andrew.gallant@neustar.com>
andrew.gallant@neustar.com
 
 
-----Original Message-----
From: A.M. Rutkowski [mailto:amr@netmagic.com]
Sent: Thursday, November 30, 2000 6:03 PM
To: Shaw, Robert; 'enum@ietf.org'
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers,
and Numb ering Authorities - January 17, 2001


At 04:09 PM 11/30/2000, Shaw, Robert wrote:


available, I'll announce it on the list for those who may wish to 
participate and also post it to www.itu.int/infocom/enum/
<http://www.itu.int/infocom/enum/> .


The site says:

  The Internet Architecture Board (IAB) and ITU-T 
  Study Group 2 are working together on the operational, 
  administration and delegation issues related to 
  deployment of ENUM protocol-based services. 

Could someone indicate:

1) the respective authority to do this, and
2) the basis, process and availability of materials 
   or dialogue associated with this activity?

--tony



------_=_NextPart_001_01C05BB2.6D14A630
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi,=20
Tony.</FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D705030215-01122000>So far, the only context I'm aware of came =
out=20
of&nbsp;the October 2000&nbsp;WP1/2 Berlin meeting, that a number of =
the list=20
members (including you and me) attended.&nbsp;&nbsp;An extract from the =
I-D (for=20
which o</SPAN><SPAN class=3D705030215-01122000>ne URL&nbsp;is <A=20
href=3D"http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01=
.txt">http://www.ietf.org/internet-drafts/draft-itu-sg2-liason-enum-01.=
txt</A>)=20
states that:</SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&lt;!--StartFragment--&gt;<BR>&nbsp;&nbsp;&nbsp; o&nbsp; The =
study being=20
undertaken within WP1/2 (referred to above)=20
will<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; also attempt to identify =
options=20
and provide guidance to assist<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
those=20
entities charged with the task of providing=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; administrative information =
to DNS=20
administrators.</FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial><FONT =
size=3D2><FONT=20
color=3D#0000ff>(The other study "referred to above" mentioned number =
portability=20
and the following extract applied to it: "<SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; =
mso-ansi-language: EN-GB; mso-fareast-language: EN-US; =
mso-bidi-language: AR-SA">However,=20
it is currently understood that this study and its result will not =
impact the=20
IETF and its work.")</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
new work&nbsp;was echoed in the Meeting Report as:&nbsp;&nbsp;<FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3> =
</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff size=3D2><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3></FONT>&nbsp;</DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: justify"><SPAN =
lang=3DEN-GB>8.5<SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>The=20
meeting noted that a new work project would be introduced in Q.1/2 to =
study=20
implementation issues specifically related to the provision of E.164 =
resource=20
information into the DNS with a view to identifying options and =
guidance to ITU=20
Member States.</SPAN></FONT></SPAN><SPAN =
class=3D705030215-01122000><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
haven't seen anything more specific yet about this for the January SG2=20
meeting.</FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>-Andy</FONT></SPAN></DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff>Andrew =
Gallant<SPAN=20
class=3D705030215-01122000>, </SPAN>+1 202 533-2812<SPAN=20
class=3D705030215-01122000>, </SPAN></FONT></FONT><A=20
href=3D"mailto:andrew.gallant@neustar.com"><FONT=20
size=3D2>andrew.gallant@neustar.com</FONT></A></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705030215-01122000><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> A.M. Rutkowski=20
[mailto:amr@netmagic.com]<BR><B>Sent:</B> Thursday, November 30, 2000 =
6:03=20
PM<BR><B>To:</B> Shaw, Robert; 'enum@ietf.org'<BR><B>Subject:</B> Re: =
[Enum] ITU=20
ENUM Workshop: Issues for Regulators, Policy Makers, and Numb ering =
Authorities=20
- January 17, 2001<BR><BR></FONT></DIV><FONT size=3D3>At 04:09 PM =
11/30/2000,=20
Shaw, Robert wrote:<BR>
<BLOCKQUOTE class=3Dcite cite type=3D"cite">available, I'll announce it =
on the=20
  list for those who may wish to <BR>participate and also post it to <A =

  href=3D"http://www.itu.int/infocom/enum/"=20
  eudora=3D"autourl">www.itu.int/infocom/enum/</A>.</BLOCKQUOTE><BR>The =
site=20
says:<BR><BR>&nbsp; The Internet Architecture Board (IAB) and ITU-T =
<BR>&nbsp;=20
Study Group 2 are working together on the operational, <BR>&nbsp; =
administration=20
and delegation issues related to <BR>&nbsp; deployment of ENUM =
protocol-based=20
services. <BR><BR>Could someone indicate:<BR><BR>1) the respective =
authority to=20
do this, and<BR>2) the basis, process and availability of materials=20
<BR>&nbsp;&nbsp; or dialogue associated with this=20
activity?<BR><BR>--tony<BR><BR></FONT></BODY></HTML>

------_=_NextPart_001_01C05BB2.6D14A630--

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 11:29:05 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08458
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 11:29:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10939;
	Fri, 1 Dec 2000 11:28:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10909
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 11:28:37 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08324
	for <enum@ietf.org>; Fri, 1 Dec 2000 11:28:35 -0500 (EST)
Received: by dnspri.npac.com; id KAA24086; Fri, 1 Dec 2000 10:27:35 -0600 (CST)
Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0)
	id xmaf23506; Fri, 1 Dec 00 10:27:06 -0600
Message-Id: <5.0.0.25.2.20001201101506.02f12970@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Dec 2000 11:23:10 -0500
To: "Douglas Ranalli" <dranalli@netnumber.com>,
        "Hollenbeck, Scott" <shollenbeck@verisign.com>, <enum@ietf.org>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
  Makers, and Numbering Authorities - January 17, 2001
In-Reply-To: <005201c05b9a$832e8890$5a498826@netnumber.com>
References: <DF737E620579D411A8E400D0B77E671D310FF5@regdom-ex01.prod.netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 08:27 AM 12/1/2000 -0500, Douglas Ranalli wrote:
>Scott,
>
>Thank you for the clarification and the recommendation.  Based on the way
>you've described the BCP designation this sounds like a more appropriate fit
>for the "roles & responsibilities" draft.  Richard (ENUM Chair), what's the
>mechanism for following up on Scott's recommendation?


First I completely agree with Scott's assessment..thought I think 
Informational is more relevant here.  I'm of the feeling that ENUM BCP 
documents should be specifically targeted to the technical requirements of 
e164.arpa zone administrators in terms of the optimization of their 
servers, query response times objectives, cache, TTL  etc.

The kinds of data that we should be collecting as part of any trial 
operational plan. Some plans ..I might add I like to see some preliminary 
discussion on. I know I'm trying to herd cats here on where I thing we need 
to go but that my job.

How the geographic zones are to be administered will be the responsibility 
of nation states and it is useful and very appropriate to provide them 
information on current technical thinking.


Second I think we are completely ignoring the complementary draft Penn 
Pfautz and James Yu have produced that discusses similar issues.  I agree 
there are some problems with terms that need to be clarified and definition 
of those terms should cross all documents moving forward.

Third ..we are crossing into WG unchartered territory... and I mean that 
literally.  If the WG wishes to go down this path in the future we 
seriously need to A. Revisit our current milestones elements many of which 
have not been completed. I would still like to see some thinking on whether 
a MIB is still a requirement here. B. Narrowly define what is the scope of 
work we want to develop. C. Request recharter from the IESG.

I'd suggest this as a reasonable plan.


>Doug
>
>----- Original Message -----
>From: Hollenbeck, Scott <shollenbeck@verisign.com>
>To: 'Douglas Ranalli' <dranalli@netnumber.com>; <rich.shockey@neustar.com>;
><enum@ietf.org>
>Sent: Thursday, November 30, 2000 7:20 PM
>Subject: RE: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers,
>and Numbering Authorities - January 17, 2001
>
>
> > Doug,
> >
> > I don't believe that the "Roles & Responsibilities" draft lends itself to
> > the evolutionary standards track maturity levels (Proposed Standard, Draft
> > Standard, Standard) as described in RFC 2026.  However, the definition of
> > the Best Current Practice (BCP) series describes the benefit of
>identifying
> > "common guidelines for policies and operations", so perhaps targeting BCP
> > would be appropriate.
> >
> > Scott Hollenbeck
> > VeriSign Global Registry Services
> >

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Richard Shockey
Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W.
Suite 550
Washington DC. 20005
Voice 202.533.2811
Fax to EMail 815.333.1237 (Preferred for Fax)
Cell : 314.503.0640
INTERNET Mail & IFAX : rich.shockey@neustar.com
or   rshockey@ix.netcom.com
http://www.neustar.com

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  1 11:42:52 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12480
	for <enum-archive@odin.ietf.org>; Fri, 1 Dec 2000 11:42:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11496;
	Fri, 1 Dec 2000 11:41:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11466
	for <enum@ns.ietf.org>; Fri, 1 Dec 2000 11:41:49 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12044
	for <enum@ietf.org>; Fri, 1 Dec 2000 11:41:43 -0500 (EST)
Received: by dnspri.npac.com; id KAA28808; Fri, 1 Dec 2000 10:41:44 -0600 (CST)
Received: from unknown(192.168.20.106) by dnspri.npac.com via smap (V5.0)
	id xmaa28773; Fri, 1 Dec 00 10:41:16 -0600
Message-Id: <5.0.0.25.2.20001201113242.027842e0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 01 Dec 2000 11:34:51 -0500
To: Dave Crocker <dhc@dcrocker.net>,
        "Douglas Ranalli" <dranalli@netnumber.com>
From: Richard Shockey <rshockey@ix.netcom.com>
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
  Makers, and Numbering Authorities - January 17, 2001
Cc: <enum@ietf.org>
In-Reply-To: <5.0.1.4.2.20001201063442.033cf1c0@joy.songbird.com>
References: <005201c05b9a$832e8890$5a498826@netnumber.com>
 <DF737E620579D411A8E400D0B77E671D310FF5@regdom-ex01.prod.netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 06:36 AM 12/1/2000 -0800, Dave Crocker wrote:
>At 08:27 AM 12/1/00 -0500, Douglas Ranalli wrote:
>>Based on the way
>>you've described the BCP designation this sounds like a more appropriate fit
>>for the "roles & responsibilities" draft.  Richard (ENUM Chair), what's the
>>mechanism for following up on Scott's recommendation?
>
>The process of getting BCP is the same as getting Proposed Standard, 
>except for the label.  (Purists might disagree with me, but I believe 
>there are no meaningful differences.)
>
>In other words, get a stable specification for which there is consensus, 
>and then submit it to the IESG for approval.

Yes ..but Its just my preference that BCP represent protocol technicial 
thinking ..but I'm not tied to that thinking.

Recharting however seems to me "a good thing"..


>d/
>
>
>=-=-=-=-=
>Dave Crocker  <dcrocker@brandenburg.com>
>Brandenburg Consulting  <www.brandenburg.com>
>Tel: +1.408.246.8253,  Fax: +1.408.273.6464
>
>
>_______________________________________________
>enum mailing list
>enum@ietf.org
>http://www1.ietf.org/mailman/listinfo/enum




 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Richard Shockey
Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W.
Suite 550
Washington DC. 20005
Voice 202.533.2811
Fax to EMail 815.333.1237 (Preferred for Fax)
Cell : 314.503.0640
INTERNET Mail & IFAX : rich.shockey@neustar.com
or   rshockey@ix.netcom.com
http://www.neustar.com

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Dec  2 01:07:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26501
	for <enum-archive@odin.ietf.org>; Sat, 2 Dec 2000 01:07:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25265;
	Sat, 2 Dec 2000 01:06:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25209
	for <enum@ns.ietf.org>; Sat, 2 Dec 2000 01:06:00 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26098
	for <enum@ietf.org>; Sat, 2 Dec 2000 01:06:01 -0500 (EST)
Received: by dnspri.npac.com; id AAA25600; Sat, 2 Dec 2000 00:06:00 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma025588; Sat, 2 Dec 00 00:05:41 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGSSAZ>; Sat, 2 Dec 2000 00:04:00 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C8A8@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'BARNOLE Valerie FTRD/DAC/ISS'" <valerie.barnole@rd.francetelecom.fr>
Cc: "'enum@ietf.org'" <enum@ietf.org>,
        "'john.loughney@nokia.com'"
	 <john.loughney@nokia.com>
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Sat, 2 Dec 2000 00:09:57 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA25214
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id BAA25265
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA26501

Valerie,

I'll try to answer some of the questions.  

> 1) You do a search on the mobile subscriber within e164.arpa 
> number and you
> get a DNS record with a service flag saying "roam+E2I". I 
> suppose that you
> can also receive other DNS records, like "E2U" or "SIP+E2U". 
> Am I correct ?

Yes, other DNS records can be retrieved (all NAPTR RRs associated with the
same number are retrieved).

> 2) If so, how can the "roam+E2I" is chosen ? It should be on 
> a priority
> basis that is enterd according to the subscriber. Am I right ?


The mobile application that invokes the ENUM process knows that it only
needs the NAPTR RRs that have a service flag saying "roam+E2I."

> 3)If so, does it mean that the subscriber has to put the 
> roaming always in
> first priority ?

"roam" is a service that I consider a "network-related" service.  That is,
"roam" is not an end user application service such as e-mail address and SIP
phone address.  It is one of the "network-related" services that a telephony
service provider (the entity that currently serves the telephone number).
So end user does not provision those NAPTR RRs.  The telephony service
provider (in this case the cellular operator) does that.  Please see
draft-pfautz-yu-enum-adm.00.txt that has a brief discussion on
"network-related services" and "end user application services."

My personal view about end user application services:  any service that an
end user can subscribe from more than one service providers.  If a service
can only be supported/offered by a telephony service provider, it is a
network-related service.
 
> 4) where do the e214.arpa and e212.arpa searches take place ?

Using GSM model, the search for e214.arpa or e212.arpa begins for the first
message to be sent from the visited mobile network (e.g., VLR) to the home
mobile network (e.g., HLR).  This is because the visited mobile network
knows the IMSI of the roamer via the registration/authentication process
before it communicates with the home mobile network.  Certainly, if the
visited network maintains a table that maps the first 5/6 digits of the IMSI
(mobile country code+ mobile network code) to a URL, a domain name or even
an IP address, then there is no need to use ENUM to locate the HLR
associated with an IMSI. 

> 5) in the§4 example, Nokia offers the service "roam+E2I". 
> Does it mean that
> Nokia (which is a manufacturer and not a mobile operator, but 
> I may be too
> square) knows the IP address of the VLR or HLR ?
> 6) I am not an SCCP or a mobile specialist, but in the case 
> of 3G to 2G
> roaming, I think that 2G nodes might not have an IP address. 
> In case they
> have, it wouldn't be necessary to use E.212 or E.214. I don't 
> know if this
> assumption is correct.

This is correct.  But ENUM can be used to determine whether the home mobile
network supports IP and even the protocol (e.g., ANSI-41 or GSM) used by the
HLR.

ENUM can also be used to identify the short message center associated with
the cellular subscriber's phone number.  This happens when the cellular MSC
needs to transport a short message destined for a cellular subscriber who
may be in the home or roaming.
> 
> Could you follow on your §4 nokia example to picture a situation where
> e214.arpa or e212.searches would be necessary and used ?
> 
> Thank you.
> 
> Valerie.
> 
>  
> end of message
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> Valérie Barnole
> 
> FTR&D/DAC/ACE
> 
> tel. : + 33 1 45 29 58 39
> fax : + 33 1 46 29 31 42
> 
> mail to : valerie.barnole@francetelecom.fr
> 
> 
> 
> -----Message d'origine-----
> De : James Yu [mailto:james.yu@neustar.com]
> Envoyé : mercredi 29 novembre 2000 19:27
> À : 'BARNOLE Valerie FTRD/DAC/ISS'
> Cc : enum@ietf.org; 'john.loughney@nokia.com'
> Objet : RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> Valerie,
> 
> enum is for E.164 number so E.212 (IMSI) or E.214 (mobile 
> global title)
> needs to use something else such as e212.arpa or e214.arpa.  
> The reason
> E.214 is used today in the GSM has reasons due to SS7 message 
> routing across
> national boundaries.  IMHO, we probably only need e212.arpa.
> 
> One thing good about IMSI is that it is not portable (e.g., there is a
> mobile network code that belongs to the cellular carrier) and 
> the cellular
> carriers are the ones that control those numbers (e.g., they 
> can be the T2E
> for their own IMSIs).  So there is no need to populate 
> individual IMSIs at
> the T1E.  A block of IMSIs will do the job.  For example, the 
> T1E can point
> to a T2E based on the first six digits of the IMSI.  The T2E 
> returns the
> NAPTR RRs for the associated IMSI.
> 
> The draft is for cases when E.164 numbers are used to 
> identify cellular node
> (e.g., HLR, VLR and message center, etc.).
> 
> James 
> 
> > -----Original Message-----
> > From: BARNOLE Valerie FTRD/DAC/ISS
> > [mailto:valerie.barnole@rd.francetelecom.fr]
> > Sent: Wednesday, November 29, 2000 12:09 PM
> > To: 'john.loughney@nokia.com'; james.yu@neustar.com; enum@ietf.org
> > Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > John,
> > I am sorry, I can't retrieve your 
> > draft-loughney-enum-roaming-00.txt. Can
> > you send it, please ?
> > 
> > I suppose that in this draft, you populate the DNS with 
> E.212 or E.214
> > numbers. I do not have your draft to see how you deal with the
> > confidentiality of the IMSI, but my first idea is that mobile 
> > operators
> > should be very reluctant to populate the DNS with such 
> > confidential data.
> > Thank you for sending me your draft.
> > 
> > Regards,
> > 
> > Valerie.
> > 
> > end of message
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > 
> > Valérie Barnole
> > 
> > FTR&D/DAC/ACE
> > 
> > tel. : + 33 1 45 29 58 39
> > fax : + 33 1 46 29 31 42
> > 
> > mail to : valerie.barnole@francetelecom.fr
> > 
> > 
> > 
> > -----Message d'origine-----
> > De : john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Envoyé : mardi 7 novembre 2000 08:34
> > À : james.yu@neustar.com; enum@ietf.org
> > Cc : john.loughney@nokia.com
> > Objet : [Enum] RE: draft-loughney-enum-roaming-00.txt
> > 
> > 
> > Hi James & everyone,
> > 
> > > One reason that GTT is used in SS7 message transport is 
> > > because the message routing in many cases involve two 
> > > cellular networks in different countries. A SS7 point code 
> > > in U.K. cannot be used directly by a SS7 node in France to
> > > send a SS7 message to.   IP will change that because IP is 
> > > global.  This is just one example of use of ENUM.  Another 
> > > example is to identify the message center that serves a 
> > > particular cellular subscriber when there is a short
> > > message destined towards that subscriber.  In this example, 
> > > the E.164 number is assigned to an cellular subscriber; 
> > > however, the service that uses ENUM is again a "network-related 
> > > service."
> > 
> > Thanks for summarizing the intention of this draft.  You did 
> > a much better job that what I did at Pittsburgh :)
> > 
> > I also want to mention that this issues will get much more
> > complicated in the proposed 3G networks.  There will be 
> > operators implementing all of their networks over IP.  In 
> > your scenario, there will need to be some negotiation/
> > mapping between the SS7 addresses and IP address that will
> > be assigned for the VLR/HLR.
> > 
> > One further complication is that there may be AAA servers 
> > providing the same functionality for 3G cellular subscribers.
> > 
> > I would like to think that ENUM could be a techology that is
> > used to promote interoperability/interworking for this 
> > purpose.
> > 
> > > John and I would like to hear from you to see whether they is 
> > > any problem to move this I-D forward.  
> > 
> > thanks,
> > John
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > http://www1.ietf.org/mailman/listinfo/enum
> > 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Dec  2 01:45:03 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10733
	for <enum-archive@odin.ietf.org>; Sat, 2 Dec 2000 01:45:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01686;
	Sat, 2 Dec 2000 01:44:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01659
	for <enum@ns.ietf.org>; Sat, 2 Dec 2000 01:44:31 -0500 (EST)
Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10522
	for <enum@ietf.org>; Sat, 2 Dec 2000 01:44:32 -0500 (EST)
Received: from dcrocker.dcrocker.net ([63.112.84.226])
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id WAA01446;
	Fri, 1 Dec 2000 22:44:24 -0800
Message-Id: <5.0.1.4.2.20001202014441.02a75540@joy.songbird.com>
X-Sender: dhc@joy.songbird.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Sat, 02 Dec 2000 01:46:00 -0500
To: Richard Shockey <rshockey@ix.netcom.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
  Makers, and Numbering Authorities - January 17, 2001
Cc: "Douglas Ranalli" <dranalli@netnumber.com>, <enum@ietf.org>
In-Reply-To: <5.0.0.25.2.20001201113242.027842e0@127.0.0.1>
References: <5.0.1.4.2.20001201063442.033cf1c0@joy.songbird.com>
 <005201c05b9a$832e8890$5a498826@netnumber.com>
 <DF737E620579D411A8E400D0B77E671D310FF5@regdom-ex01.prod.netsol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

At 11:34 AM 12/1/00 -0500, Richard Shockey wrote:
>Yes ..but Its just my preference that BCP represent protocol technicial 
>thinking ..but I'm not tied to that thinking.

oh.  perhaps.

as I recall the P in BCP was meant to imply operations issues, however.

that does not exclude 'technical thinking', of course, no matter how much 
the ops folks claim that protocol designers think such low thoughts about 
the ops folks.

d/


=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Dec  4 06:54:13 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19364
	for <enum-archive@odin.ietf.org>; Mon, 4 Dec 2000 06:54:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15095;
	Mon, 4 Dec 2000 06:53:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15066
	for <enum@ns.ietf.org>; Mon, 4 Dec 2000 06:53:09 -0500 (EST)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19033
	for <enum@ietf.org>; Mon, 4 Dec 2000 06:53:08 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir04nok.nokia.com (esvir04nok.nokia.com [131.228.20.76])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB4BrnX23759
	for <enum@ietf.org>; Mon, 4 Dec 2000 13:53:53 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir04nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e4144c775046d89b8a@esvir04nok.nokia.com>;
 Mon, 4 Dec 2000 13:53:04 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <XZ2NVQ0N>; Mon, 4 Dec 2000 13:53:04 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF4B4@eseis04nok>
To: james.yu@neustar.com, valerie.barnole@rd.francetelecom.fr
Cc: enum@ietf.org
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Mon, 4 Dec 2000 13:53:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi James & Valerie,

[James said]
> Probably not interoperability and interworking.  I assume 
> that all cellular nodes can use IP to communicate with each 
> other (may be the 3G all IP networks?).

[Valerie said]
> > I do not see precisely how ENUM can facilitate interworking 
> > or interoperability between networks. Maybe there are other 
> > drafts I should read ?

ENUM can simplify the 'reachability' issue for cellular networks
(or for network providers).  Currently, finding the HLR/VLR for
a particular subscriber when roaming is a complex task, mapping
from global title to SS7 signaling point code.  As networks move
to IP, this should be less complicated & hopefully allow some
different protocols to interoperate more easily.

An example could be:

I'm roaming in China.  At the point of attachment to the network,
the Chinese operator needs to check if I can get service.  The
access point can use ENUM to find the address of my authorization
node (HLR, let's say) and retrieves it's location (IP address).
Then, it could use MAP over IP (a la SIGTRAN) or AAA (DIAMETER) 
to verify that I can roam in China.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Dec  4 06:56:55 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20242
	for <enum-archive@odin.ietf.org>; Mon, 4 Dec 2000 06:56:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15239;
	Mon, 4 Dec 2000 06:56:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15206
	for <enum@ns.ietf.org>; Mon, 4 Dec 2000 06:56:39 -0500 (EST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20134
	for <enum@ietf.org>; Mon, 4 Dec 2000 06:56:37 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir02nok.nokia.com (esvir02nok.nokia.com [131.228.20.74])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eB4BubP18460
	for <enum@ietf.org>; Mon, 4 Dec 2000 13:56:37 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e4144a715046dbda72@esvir02nok.nokia.com>;
 Mon, 4 Dec 2000 13:56:37 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <YBKBLYG8>; Mon, 4 Dec 2000 13:56:37 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF4B5@eseis04nok>
To: valerie.barnole@rd.francetelecom.fr, james.yu@neustar.com
Cc: enum@ietf.org
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Mon, 4 Dec 2000 13:56:35 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Valerie,

> I have no clear vision of the architecture of future workable 
> 3G mobile networks. Of course 3G nodes will have IP addresses. 
> But I don't know if "old" GSM nodes will have it. And roaming 
> between both will really be needed.

At least with my work in Sigtran, it seems that GSM operators
are also keen to use SS7 over IP for signaling. 

It is also possible to stuff SS7 addresses into DNS (maybe
not recommended) as a way to resolve to an SS7 node if there
is not IP connectivity.

I see some uses of ENUM as an extra tool in operator's
toolboxes to simplify network management.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Dec  4 07:06:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23083
	for <enum-archive@odin.ietf.org>; Mon, 4 Dec 2000 07:05:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15613;
	Mon, 4 Dec 2000 07:05:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15582
	for <enum@ns.ietf.org>; Mon, 4 Dec 2000 07:05:33 -0500 (EST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22940
	for <enum@ietf.org>; Mon, 4 Dec 2000 07:05:31 -0500 (EST)
From: john.loughney@nokia.com
Received: from esvir02nok.nokia.com (esvir02nok.nokia.com [131.228.20.74])
	by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eB4C5UP26258
	for <enum@ietf.org>; Mon, 4 Dec 2000 14:05:30 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T83e4144a715046e3fa09@esvir02nok.nokia.com>;
 Mon, 4 Dec 2000 14:05:29 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <XZ2NVR7T>; Mon, 4 Dec 2000 14:05:29 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DF4B6@eseis04nok>
To: valerie.barnole@rd.francetelecom.fr
Cc: enum@ietf.org, james.yu@neustar.com
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Mon, 4 Dec 2000 14:05:27 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Valerie,

> the draft is not clear to me on some points.

I shall try to clear some things up. I believe that James
has already answered some of them.

> 1) You do a search on the mobile subscriber within e164.arpa 
> number and you get a DNS record with a service flag saying 
> "roam+E2I". I suppose that you can also receive other DNS 
> records, like "E2U" or "SIP+E2U".  Am I correct ?

I believe the correct flag should be "roam+E2U", but
of course when a subscriber DNS record is queried, the
entire set of ENUM services are returned.

> 2) If so, how can the "roam+E2I" is chosen ? It should be on 
> a priority basis that is enterd according to the subscriber. 
> Am I right ?
> 3)If so, does it mean that the subscriber has to put the 
> roaming always in first priority ? 

James answered this one, but one thing that I know I need
to clear-up is the syntax of the roam tag.  

One idea that could be neat would be that a subscriber has
multiple subscriptions on a single number.  Especially in 
this day & age of the mega-operators, some operators
provide service using different technologies.  So,
it could be possible that you have an IS-41 service
and GSM.  Depending on the network you are roaming, 
you connect to the authorization element needed.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Mon Dec  4 18:26:19 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16103
	for <enum-archive@odin.ietf.org>; Mon, 4 Dec 2000 18:26:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29644;
	Mon, 4 Dec 2000 18:25:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29613
	for <enum@ns.ietf.org>; Mon, 4 Dec 2000 18:25:49 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15855
	for <enum@ietf.org>; Mon, 4 Dec 2000 18:25:47 -0500 (EST)
Received: by dnspri.npac.com; id RAA20617; Mon, 4 Dec 2000 17:25:49 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma020558; Mon, 4 Dec 00 17:25:09 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGSX3J>; Mon, 4 Dec 2000 17:23:27 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CEA239D@dc02.npac.com>
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: "'Douglas Ranalli'" <dranalli@netnumber.com>,
        Richard Shockey
	 <rich.shockey@neustar.com>, enum@ietf.org
Subject: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Date: Mon, 4 Dec 2000 17:29:22 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by dnspri.npac.com id RAA20617
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA29614
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id SAA29644
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA16103

Doug (et al),

Sorry for the delay in writing this down ...

The discussion on the list about the roles/responsibilities draft brings up
some issues that have been around for a while but which took me (at least)
some time to identify.  Here are a couple of them, because I think these
would need to be resolved along the way in any attempt to reach a common
framework.

Problem 1:  "Names" and "numbers" are confused in many documents.  An E.164
number does not live in DNS, but the ENUM name for it might or might not.
Yes, there's a one-to-one mapping, but being specific can make descriptions
much less confusing (in a bunch of i-ds). 

Problem 2:  Has Tier 1 been defined yet with anything like the agreed views
on Tier 2?  Tier 2 is where the NAPTRs go - that's OK.  But, how wide (or
deep) is Tier 1?  Is it just above Tier 2, is Tier 1 just below e164.arpa,
or both, or something else?  It would probably help if there's a way to say
it like there is for Tier 2.

Problem 3:  Grouping functions together makes it hard to separate them
later.  Look at the roles of Telco A in the RFC 2916 Scenario.  There are at
least two PSTN functions (tel svc prov and tel num prov) as well as one or
more DNS-related ones.  Some supportive responses on the list have suggested
an approach starting with clear ideas of functions and interfaces, and then
looking at different ways these could be combined.

Problem 4:  PSTN and Internet communities both care - a lot - about how
things on their turf are described.  ENUM makes this harder.  Even harder is
the fact that a ton of different glossaries and models already exist - where
to start?.  It's hard to figure out how to get to a description of ENUM
roles and responsibilities subject to the double burden of satisfying both
sides.  

Having said all that, I strongly agree that the effort to get to a common
framework is worthwhile.  Possible goals of such a core document could
include (a) each side being comfortable enough with how its own functions
are described, and (b) clear and reproducible walkthroughs of interface
functions, all of which rest on the same terms and definitions.

One problem, though, is that the January 17 workshop is only one day, right?
So the objectives (terms of reference) would have to be clear and observed
by the participants.  There's not enough time to work on definitions, or
roles, or models, but there should be enough time to reach a substantial set
of common understandings.  Good luck to the planners, contributors, and
participants.

-Andy Gallant

+1-202-533-2812
andrew.gallant@neustar.com

Disclaimer:  opinions are my own.


-----Original Message-----
From: Douglas Ranalli [mailto:dranalli@netnumber.com]
Sent: Thursday, November 30, 2000 5:10 PM
To: rich.shockey@neustar.com; enum@ietf.org
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
Makers, and Numbering Authorities - January 17, 2001


Richard and ENUM list-group,

I'm writing to follow-up on the note from Robert Shaw regarding the upcoming
ITU workshop on ENUM implementation.  My thought is that the "Roles &
Responsibilities" draft that we've been discussing on the list group is a
core document for ENUM and the ITU discussion.  The process of gaining
agreement on the set of "actors" in the ENUM System and the "roles and
responsibilities" of those actors is a foundation for all follow-on ENUM
work.  Based on this, I'd like to propose that we consider making the "Roles
& Responsibilities" draft a standards track document so that we can all work
to gain consensus on a common framework for advancing ENUM.  Please let me
know your thoughts.

Regards,

Doug

----- Original Message -----
From: Shaw, Robert <Robert.Shaw@itu.int>
To: <enum@ietf.org>
Sent: Thursday, November 30, 2000 4:09 PM
Subject: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and
Numbering Authorities - January 17, 2001


List members:

This is an initial heads-up that ITU is organizing an ENUM
Workshop: "Issues for Regulators, Policy Makers, and Numbering
Authorities" on January 17, 2001. The meeting will be in Geneva,
Switzerland at the ITU. The target audience is the latter group
and the objective is to provide better understanding of the
technical/regulatory/competition policy implications of the
ENUM protocol for those who will be involved in related
"country-code" level policy decisions at both the sub-cc
E.164 DNS and NAPTR provisioning/deprovisioning levels.

This date was chosen since an experts meeting related to an
ITU Policy Forum on IP telephony (in which ENUM is also a topic)
will be held on January 18/19 as well as a normal ITU-T Study
Group 2 for the following two weeks in Geneva.

IETF's ENUM Chair, Richard Shockey, Patrik Fältström, author of
RFC 2916, and Mirjam Kuehne from RIPE NCC have also already agreed
to participate on the 17th.

We will work with Richard on a synthesis of the discussions on
the list and from various drafts and discussions in San Diego to
provide some generic reference models for possible national or
integrated numbering plan level consideration as an input to
this meeting.

The meeting will be open, within space limitations of about 100
seats, and as soon as there is more detail and a registration form
available, I'll announce it on the list for those who may wish to
participate and also post it to www.itu.int/infocom/enum/.

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Dec  6 16:38:32 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00582
	for <enum-archive@odin.ietf.org>; Wed, 6 Dec 2000 16:38:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21844;
	Wed, 6 Dec 2000 16:36:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21816
	for <enum@ns.ietf.org>; Wed, 6 Dec 2000 16:36:43 -0500 (EST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00131
	for <enum@ietf.org>; Wed, 6 Dec 2000 16:36:42 -0500 (EST)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21)
	id <YL698X63>; Wed, 6 Dec 2000 22:35:44 +0100
Message-ID: <98388C05D464D111B61800805F1504160233A137@p-ibis.issy.cnet.fr>
From: BARNOLE Valerie FTRD/DAC/ISS <valerie.barnole@rd.francetelecom.fr>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        james.yu@neustar.com
Cc: enum@ietf.org
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Wed, 6 Dec 2000 22:35:45 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA21817
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id QAA21844
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00582

John and James,
forgive me if I understand wrongly but it seems to me that there are various
issues in roaming for ENUM:
1) the exemple of John, with mobile user roaming in China. When the roamer
wants to place a call. The input of the DNS query is the IMSI,the output is
the HLR IP address. But couldn't it also be the E.164 HLRID in case the HLR
has no IP address ?
2) The mobile user is still roaming in China ; a caller to him dials his
MSISDN (mobile phone number. This MSISDN is the input in the ENUM process.
The output of the DNS queries includes the IP address of the VLR. Of course
this output is of no use for the caller but is useful for the operator in
charge of finding the roamer to establish the call. Maybe the service field
is a trigger to prevent this query result to appear to the caller ?


 

-----Message d'origine-----
De: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Date: lundi 4 décembre 2000 12:53
À: james.yu@neustar.com; valerie.barnole@rd.francetelecom.fr
Cc: enum@ietf.org
Objet: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt


Hi James & Valerie,

[James said]
> Probably not interoperability and interworking.  I assume 
> that all cellular nodes can use IP to communicate with each 
> other (may be the 3G all IP networks?).

[Valerie said]
> > I do not see precisely how ENUM can facilitate interworking 
> > or interoperability between networks. Maybe there are other 
> > drafts I should read ?

ENUM can simplify the 'reachability' issue for cellular networks
(or for network providers).  Currently, finding the HLR/VLR for
a particular subscriber when roaming is a complex task, mapping
from global title to SS7 signaling point code.  As networks move
to IP, this should be less complicated & hopefully allow some
different protocols to interoperate more easily.

An example could be:

I'm roaming in China.  At the point of attachment to the network,
the Chinese operator needs to check if I can get service.  The
access point can use ENUM to find the address of my authorization
node (HLR, let's say) and retrieves it's location (IP address).
Then, it could use MAP over IP (a la SIGTRAN) or AAA (DIAMETER) 
to verify that I can roam in China.

best regards,
John

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Dec  7 12:17:04 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25103
	for <enum-archive@odin.ietf.org>; Thu, 7 Dec 2000 12:17:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11091;
	Thu, 7 Dec 2000 12:15:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11064
	for <enum@ns.ietf.org>; Thu, 7 Dec 2000 12:15:40 -0500 (EST)
Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24711
	for <enum@ietf.org>; Thu, 7 Dec 2000 12:15:25 -0500 (EST)
Received: from dranalli ([38.136.73.90]) by hvmta01-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20001207171453.DKSO1216.hvmta01-stg@dranalli>;
          Thu, 7 Dec 2000 12:14:53 -0500
Message-ID: <010901c06070$b9d34bd0$5a498826@netnumber.com>
Reply-To: "Douglas Ranalli" <dranalli@netnumber.com>
From: "Douglas Ranalli" <dranalli@netnumber.com>
To: "Andy Gallant" <Andrew.Gallant@neustar.com>
Cc: <enum@ietf.org>
References: <ED88182BFF78D211A4D800A0C9E9435CEA239D@dc02.npac.com>
Subject: Re: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Date: Thu, 7 Dec 2000 12:11:23 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id MAA11091
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25103

Andy,

Thank you for the feedback on the Roles & Responsibilities draft.  Here are
some follow-up thoughts:

Problem #1: Clarification of an "E.164 Number" versus the "ENUM name" for
it:  Good point, an E.164 Number (1.212.555.1212) is clearly different from
an ENUM name (1.2.1.2.5.5.5.2.1.2.1.e164.arpa).  Two separate terms are
required.  How about the following?

E.164 Number  (example:  1.212.555.1212)

E.164 Domain Name (example: 1.2.1.2.5.5.5.2.1.2.1.e164.arpa)


Problem #2:  How wide or deep is Tier-1?  You have suggested that Tier-2 can
be defined as follows:  "Tier-2 is where the NAPTR's go".  If this is the
definition of Tier-2, then the definition of Tier-1 would appear to be:

Tier-1 maps an E.164 domain name to the address of the authoritative Tier-2
name server".


Problem #3:  "Grouping functions together makes it hard to separate them
later".  I agree.  As we move forward please continue to provide input
whenever you see a definition that combines multiple roles which you believe
should be separated out.  I'll continue to work the issue of "telephone
service provider" versus "telephone number provider".


Problem #4:  A common definition of roles & responsibilities requires
agreement from both the PSTN and Internet communities.  I agree.  I've been
working under the assumption that the ENUM working group is the appropriate
place to start with this discussion.  If you have a recommendation for
another forum for discussing the roles & responsibilities draft please let
me know.  Otherwise, we'll continue to move the draft forward on the list
group and will seek to bring in contributors from both worlds.

Thanks again for the input.

Regards,

Doug


----- Original Message -----
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: 'Douglas Ranalli' <dranalli@netnumber.com>; Richard Shockey
<rich.shockey@neustar.com>; <enum@ietf.org>
Sent: Monday, December 04, 2000 6:29 PM
Subject: later response to RE: [Enum] ITU ENUM Workshop: Issues...


Doug (et al),

Sorry for the delay in writing this down ...

The discussion on the list about the roles/responsibilities draft brings up
some issues that have been around for a while but which took me (at least)
some time to identify.  Here are a couple of them, because I think these
would need to be resolved along the way in any attempt to reach a common
framework.

Problem 1:  "Names" and "numbers" are confused in many documents.  An E.164
number does not live in DNS, but the ENUM name for it might or might not.
Yes, there's a one-to-one mapping, but being specific can make descriptions
much less confusing (in a bunch of i-ds).

Problem 2:  Has Tier 1 been defined yet with anything like the agreed views
on Tier 2?  Tier 2 is where the NAPTRs go - that's OK.  But, how wide (or
deep) is Tier 1?  Is it just above Tier 2, is Tier 1 just below e164.arpa,
or both, or something else?  It would probably help if there's a way to say
it like there is for Tier 2.

Problem 3:  Grouping functions together makes it hard to separate them
later.  Look at the roles of Telco A in the RFC 2916 Scenario.  There are at
least two PSTN functions (tel svc prov and tel num prov) as well as one or
more DNS-related ones.  Some supportive responses on the list have suggested
an approach starting with clear ideas of functions and interfaces, and then
looking at different ways these could be combined.

Problem 4:  PSTN and Internet communities both care - a lot - about how
things on their turf are described.  ENUM makes this harder.  Even harder is
the fact that a ton of different glossaries and models already exist - where
to start?.  It's hard to figure out how to get to a description of ENUM
roles and responsibilities subject to the double burden of satisfying both
sides.

Having said all that, I strongly agree that the effort to get to a common
framework is worthwhile.  Possible goals of such a core document could
include (a) each side being comfortable enough with how its own functions
are described, and (b) clear and reproducible walkthroughs of interface
functions, all of which rest on the same terms and definitions.

One problem, though, is that the January 17 workshop is only one day, right?
So the objectives (terms of reference) would have to be clear and observed
by the participants.  There's not enough time to work on definitions, or
roles, or models, but there should be enough time to reach a substantial set
of common understandings.  Good luck to the planners, contributors, and
participants.

-Andy Gallant

+1-202-533-2812
andrew.gallant@neustar.com

Disclaimer:  opinions are my own.


-----Original Message-----
From: Douglas Ranalli [mailto:dranalli@netnumber.com]
Sent: Thursday, November 30, 2000 5:10 PM
To: rich.shockey@neustar.com; enum@ietf.org
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
Makers, and Numbering Authorities - January 17, 2001


Richard and ENUM list-group,

I'm writing to follow-up on the note from Robert Shaw regarding the upcoming
ITU workshop on ENUM implementation.  My thought is that the "Roles &
Responsibilities" draft that we've been discussing on the list group is a
core document for ENUM and the ITU discussion.  The process of gaining
agreement on the set of "actors" in the ENUM System and the "roles and
responsibilities" of those actors is a foundation for all follow-on ENUM
work.  Based on this, I'd like to propose that we consider making the "Roles
& Responsibilities" draft a standards track document so that we can all work
to gain consensus on a common framework for advancing ENUM.  Please let me
know your thoughts.

Regards,

Doug

----- Original Message -----
From: Shaw, Robert <Robert.Shaw@itu.int>
To: <enum@ietf.org>
Sent: Thursday, November 30, 2000 4:09 PM
Subject: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and
Numbering Authorities - January 17, 2001


List members:

This is an initial heads-up that ITU is organizing an ENUM
Workshop: "Issues for Regulators, Policy Makers, and Numbering
Authorities" on January 17, 2001. The meeting will be in Geneva,
Switzerland at the ITU. The target audience is the latter group
and the objective is to provide better understanding of the
technical/regulatory/competition policy implications of the
ENUM protocol for those who will be involved in related
"country-code" level policy decisions at both the sub-cc
E.164 DNS and NAPTR provisioning/deprovisioning levels.

This date was chosen since an experts meeting related to an
ITU Policy Forum on IP telephony (in which ENUM is also a topic)
will be held on January 18/19 as well as a normal ITU-T Study
Group 2 for the following two weeks in Geneva.

IETF's ENUM Chair, Richard Shockey, Patrik Fältström, author of
RFC 2916, and Mirjam Kuehne from RIPE NCC have also already agreed
to participate on the 17th.

We will work with Richard on a synthesis of the discussions on
the list and from various drafts and discussions in San Diego to
provide some generic reference models for possible national or
integrated numbering plan level consideration as an input to
this meeting.

The meeting will be open, within space limitations of about 100
seats, and as soon as there is more detail and a registration form
available, I'll announce it on the list for those who may wish to
participate and also post it to www.itu.int/infocom/enum/.

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 09:53:59 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24172
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 09:53:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05499;
	Fri, 8 Dec 2000 09:52:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05468
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 09:52:11 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23968
	for <enum@ietf.org>; Fri, 8 Dec 2000 09:52:11 -0500 (EST)
Received: by dnspri.npac.com; id IAA15184; Fri, 8 Dec 2000 08:52:11 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma015071; Fri, 8 Dec 00 08:51:38 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGTFV9>; Fri, 8 Dec 2000 08:49:55 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CEA23B8@dc02.npac.com>
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: "'Douglas Ranalli'" <dranalli@netnumber.com>
Cc: enum@ietf.org
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Date: Fri, 8 Dec 2000 08:55:43 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by dnspri.npac.com id IAA15184
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA05469
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id JAA05499
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24172

Doug,

Thanks for your reply.  I've interspersed some comments.
It would be nice if there's a little time early in the 
week for some brainstorming on these points.  Hope so.
Thanks for looking at these, and see you (all?) in SD.

Regards,

-Andy

-----Original Message-----
From: Douglas Ranalli [mailto:dranalli@netnumber.com]
Sent: Thursday, December 07, 2000 12:11 PM
To: Andy Gallant
Cc: enum@ietf.org
Subject: Re: later response to RE: [Enum] ITU ENUM Workshop: Issues...


Andy,

Thank you for the feedback on the Roles & Responsibilities draft.  Here are
some follow-up thoughts:

Problem #1: Clarification of an "E.164 Number" versus the "ENUM name" for
it:  Good point, an E.164 Number (1.212.555.1212) is clearly different from
an ENUM name (1.2.1.2.5.5.5.2.1.2.1.e164.arpa).  Two separate terms are
required.  How about the following?

E.164 Number  (example:  1.212.555.1212)

E.164 Domain Name (example: 1.2.1.2.5.5.5.2.1.2.1.e164.arpa)

<AG> I liked it too.  But, over the past few weeks I tried
running several possible terms by a few people.  It turns out
they dumped on most of them except for "ENUM name" - clean, 
simple, and especially short - seems OK enough for now.//

Problem #2:  How wide or deep is Tier-1?  You have suggested that Tier-2 can
be defined as follows:  "Tier-2 is where the NAPTR's go".  If this is the
definition of Tier-2, then the definition of Tier-1 would appear to be:

Tier-1 maps an E.164 domain name to the address of the authoritative Tier-2
name server".

<AG> Those Tier-2 words were a shorthand way to think about a definition,
as are the words about Tier-1.  IMHO, a useful goal is that Tier-1 words 
and Tier-2 words could each be turned into specific statements about 
DNS records.  Hope there's some input from DNS gurus ...//

Problem #3:  "Grouping functions together makes it hard to separate them
later".  I agree.  As we move forward please continue to provide input
whenever you see a definition that combines multiple roles which you believe
should be separated out.  I'll continue to work the issue of "telephone
service provider" versus "telephone number provider".

<AG> OK//

Problem #4:  A common definition of roles & responsibilities requires
agreement from both the PSTN and Internet communities.  I agree.  I've been
working under the assumption that the ENUM working group is the appropriate
place to start with this discussion.  If you have a recommendation for
another forum for discussing the roles & responsibilities draft please let
me know.  Otherwise, we'll continue to move the draft forward on the list
group and will seek to bring in contributors from both worlds.

<AG> Also OK.  There's still time for contributions into the next ITU-T
SG-2 meeting (23Jan-2Feb in Geneva) for international PSTN-type stuff.
Maybe the list can suggest where (else?) to focus and where not to.//

Thanks again for the input.

<AG> Thanks for the dialog, and good luck with your next draft.//

Regards,

Doug


----- Original Message -----
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: 'Douglas Ranalli' <dranalli@netnumber.com>; Richard Shockey
<rich.shockey@neustar.com>; <enum@ietf.org>
Sent: Monday, December 04, 2000 6:29 PM
Subject: later response to RE: [Enum] ITU ENUM Workshop: Issues...


Doug (et al),

Sorry for the delay in writing this down ...

The discussion on the list about the roles/responsibilities draft brings up
some issues that have been around for a while but which took me (at least)
some time to identify.  Here are a couple of them, because I think these
would need to be resolved along the way in any attempt to reach a common
framework.

Problem 1:  "Names" and "numbers" are confused in many documents.  An E.164
number does not live in DNS, but the ENUM name for it might or might not.
Yes, there's a one-to-one mapping, but being specific can make descriptions
much less confusing (in a bunch of i-ds).

Problem 2:  Has Tier 1 been defined yet with anything like the agreed views
on Tier 2?  Tier 2 is where the NAPTRs go - that's OK.  But, how wide (or
deep) is Tier 1?  Is it just above Tier 2, is Tier 1 just below e164.arpa,
or both, or something else?  It would probably help if there's a way to say
it like there is for Tier 2.

Problem 3:  Grouping functions together makes it hard to separate them
later.  Look at the roles of Telco A in the RFC 2916 Scenario.  There are at
least two PSTN functions (tel svc prov and tel num prov) as well as one or
more DNS-related ones.  Some supportive responses on the list have suggested
an approach starting with clear ideas of functions and interfaces, and then
looking at different ways these could be combined.

Problem 4:  PSTN and Internet communities both care - a lot - about how
things on their turf are described.  ENUM makes this harder.  Even harder is
the fact that a ton of different glossaries and models already exist - where
to start?.  It's hard to figure out how to get to a description of ENUM
roles and responsibilities subject to the double burden of satisfying both
sides.

Having said all that, I strongly agree that the effort to get to a common
framework is worthwhile.  Possible goals of such a core document could
include (a) each side being comfortable enough with how its own functions
are described, and (b) clear and reproducible walkthroughs of interface
functions, all of which rest on the same terms and definitions.

One problem, though, is that the January 17 workshop is only one day, right?
So the objectives (terms of reference) would have to be clear and observed
by the participants.  There's not enough time to work on definitions, or
roles, or models, but there should be enough time to reach a substantial set
of common understandings.  Good luck to the planners, contributors, and
participants.

-Andy Gallant

+1-202-533-2812
andrew.gallant@neustar.com

Disclaimer:  opinions are my own.


-----Original Message-----
From: Douglas Ranalli [mailto:dranalli@netnumber.com]
Sent: Thursday, November 30, 2000 5:10 PM
To: rich.shockey@neustar.com; enum@ietf.org
Subject: Re: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy
Makers, and Numbering Authorities - January 17, 2001


Richard and ENUM list-group,

I'm writing to follow-up on the note from Robert Shaw regarding the upcoming
ITU workshop on ENUM implementation.  My thought is that the "Roles &
Responsibilities" draft that we've been discussing on the list group is a
core document for ENUM and the ITU discussion.  The process of gaining
agreement on the set of "actors" in the ENUM System and the "roles and
responsibilities" of those actors is a foundation for all follow-on ENUM
work.  Based on this, I'd like to propose that we consider making the "Roles
& Responsibilities" draft a standards track document so that we can all work
to gain consensus on a common framework for advancing ENUM.  Please let me
know your thoughts.

Regards,

Doug

----- Original Message -----
From: Shaw, Robert <Robert.Shaw@itu.int>
To: <enum@ietf.org>
Sent: Thursday, November 30, 2000 4:09 PM
Subject: [Enum] ITU ENUM Workshop: Issues for Regulators, Policy Makers, and
Numbering Authorities - January 17, 2001


List members:

This is an initial heads-up that ITU is organizing an ENUM
Workshop: "Issues for Regulators, Policy Makers, and Numbering
Authorities" on January 17, 2001. The meeting will be in Geneva,
Switzerland at the ITU. The target audience is the latter group
and the objective is to provide better understanding of the
technical/regulatory/competition policy implications of the
ENUM protocol for those who will be involved in related
"country-code" level policy decisions at both the sub-cc
E.164 DNS and NAPTR provisioning/deprovisioning levels.

This date was chosen since an experts meeting related to an
ITU Policy Forum on IP telephony (in which ENUM is also a topic)
will be held on January 18/19 as well as a normal ITU-T Study
Group 2 for the following two weeks in Geneva.

IETF's ENUM Chair, Richard Shockey, Patrik Fältström, author of
RFC 2916, and Mirjam Kuehne from RIPE NCC have also already agreed
to participate on the 17th.

We will work with Richard on a synthesis of the discussions on
the list and from various drafts and discussions in San Diego to
provide some generic reference models for possible national or
integrated numbering plan level consideration as an input to
this meeting.

The meeting will be open, within space limitations of about 100
seats, and as soon as there is more detail and a registration form
available, I'll announce it on the list for those who may wish to
participate and also post it to www.itu.int/infocom/enum/.

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 10:39:55 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29631
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 10:39:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06414;
	Fri, 8 Dec 2000 10:36:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06383
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 10:36:26 -0500 (EST)
Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29187
	for <enum@ietf.org>; Fri, 8 Dec 2000 10:36:15 -0500 (EST)
Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id tjnjaaaa for enum@ietf.org; Fri, 8 Dec 2000 10:36:09 -0500
Message-Id: <5.0.2.1.2.20001208102801.0484c7d8@mail.netmagic.com>
X-Sender: amr@mail.netmagic.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 08 Dec 2000 10:36:09 -0500
To: Andy Gallant <Andrew.Gallant@neustar.com>,
        "'Douglas Ranalli'" <dranalli@netnumber.com>
From: "A.M.Rutkowski" <amr@netmagic.com>
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Cc: enum@ietf.org
In-Reply-To: <ED88182BFF78D211A4D800A0C9E9435CEA23B8@dc02.npac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Andy,

>AG> Also OK.  There's still time for contributions into the next ITU-T
>SG-2 meeting (23Jan-2Feb in Geneva) for international PSTN-type stuff.
>Maybe the list can suggest where (else?) to focus and where not to.//

Since the SG-2 WP has agreed that that provisioning is a national
matter with the caveat that synchronizing end user E164 numbers
should be maintained, isn't this sufficient?  Are not any further
matters concerning DNS provisioning out of scope for them?

best,
tony


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 10:54:07 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01390
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 10:54:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06618;
	Fri, 8 Dec 2000 10:52:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06589
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 10:52:55 -0500 (EST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01250
	for <enum@ietf.org>; Fri, 8 Dec 2000 10:52:52 -0500 (EST)
Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1])
	by internal.mail.demon.net with ESMTP id PAA22077;
	Fri, 8 Dec 2000 15:52:44 GMT
Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.16 #1)
	id 144Pnk-000C1X-00; Fri, 08 Dec 2000 15:51:12 +0000
Date: Fri, 8 Dec 2000 15:51:12 +0000
From: "Clive D.W. Feather" <clive@demon.net>
To: Andy Gallant <Andrew.Gallant@neustar.com>
Cc: "'Douglas Ranalli'" <dranalli@netnumber.com>, enum@ietf.org
Subject: Re: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Message-ID: <20001208155112.M1450@demon.net>
References: <ED88182BFF78D211A4D800A0C9E9435CEA23B8@dc02.npac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <ED88182BFF78D211A4D800A0C9E9435CEA23B8@dc02.npac.com>; from Andrew.Gallant@neustar.com on Fri, Dec 08, 2000 at 08:55:43AM -0600
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Andy Gallant said:
> E.164 Number  (example:  1.212.555.1212)
> 
> E.164 Domain Name (example: 1.2.1.2.5.5.5.2.1.2.1.e164.arpa)

I really hope these aren't meant to relate to each other !

Could I suggest that examples use a different number ? I would volunteer
the London Transport number +44 20 7222 1234, but if you really want an
NANP 555 number, use a different area code (803 or something like that that
isn't going to be confused with the trailing portion).

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive@davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 10:59:45 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02269
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 10:59:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06728;
	Fri, 8 Dec 2000 10:57:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06695
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 10:57:25 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01771
	for <enum@ietf.org>; Fri, 8 Dec 2000 10:57:24 -0500 (EST)
Received: by dnspri.npac.com; id JAA04605; Fri, 8 Dec 2000 09:57:24 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma004474; Fri, 8 Dec 00 09:57:09 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGTGBG>; Fri, 8 Dec 2000 09:55:25 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CEA23BA@dc02.npac.com>
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: "'A.M.Rutkowski'" <amr@netmagic.com>,
        "'Douglas Ranalli'"
	 <dranalli@netnumber.com>
Cc: enum@ietf.org
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Date: Fri, 8 Dec 2000 10:01:14 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hello, Tony.

Good questions.  Here's a personal response:  (1) The R&R discussion
could be useful if a common framework for discussion can [ever?]
be developed.  (2) As in previous emails on the list, there is
a proposed new task to assemble some guidance (**note - please
check wording in authoritative documents since this msg is clearly
not!), for which common framework work could be useful.  (3) IMHO,
a meeting looks at scope when a contribution is introduced or
discussed.  So, personally, anything that helps identify and
sort out "what needs doing" is useful.  Hope this helps.

-Andy


-----Original Message-----
From: A.M.Rutkowski [mailto:amr@netmagic.com]
Sent: Friday, December 08, 2000 10:36 AM
To: Andy Gallant; 'Douglas Ranalli'
Cc: enum@ietf.org
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...


Hi Andy,

>AG> Also OK.  There's still time for contributions into the next ITU-T
>SG-2 meeting (23Jan-2Feb in Geneva) for international PSTN-type stuff.
>Maybe the list can suggest where (else?) to focus and where not to.//

Since the SG-2 WP has agreed that that provisioning is a national
matter with the caveat that synchronizing end user E164 numbers
should be maintained, isn't this sufficient?  Are not any further
matters concerning DNS provisioning out of scope for them?

best,
tony

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 11:07:58 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03694
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 11:07:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07029;
	Fri, 8 Dec 2000 11:06:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06994
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 11:06:27 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03496
	for <enum@ietf.org>; Fri, 8 Dec 2000 11:06:26 -0500 (EST)
Received: by dnspri.npac.com; id KAA07499; Fri, 8 Dec 2000 10:06:27 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma007437; Fri, 8 Dec 00 10:06:10 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGTGDD>; Fri, 8 Dec 2000 10:04:27 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CEA23BC@dc02.npac.com>
From: Andy Gallant <Andrew.Gallant@neustar.com>
To: "'Clive D.W. Feather'" <clive@demon.net>,
        Andy Gallant
	 <Andrew.Gallant@neustar.com>
Cc: "'Douglas Ranalli'" <dranalli@netnumber.com>, enum@ietf.org
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Date: Fri, 8 Dec 2000 10:10:13 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

How about the canonical example in RFC 2916?

  "A user named Sven Svensson has from Telco A got the phone number
   +46-8-9761234."

and

  "The client converts the E.164 number into the domain name
   4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for
   this domainname."
  
Maybe Patrik can tell us if Sven would mind <grin?>.

-Andy Gallant

-----Original Message-----
From: Clive D.W. Feather [mailto:clive@demon.net]
Sent: Friday, December 08, 2000 10:51 AM
To: Andy Gallant
Cc: 'Douglas Ranalli'; enum@ietf.org
Subject: Re: later response to RE: [Enum] ITU ENUM Workshop: Issues...


Andy Gallant said:
> E.164 Number  (example:  1.212.555.1212)
> 
> E.164 Domain Name (example: 1.2.1.2.5.5.5.2.1.2.1.e164.arpa)

I really hope these aren't meant to relate to each other !

Could I suggest that examples use a different number ? I would volunteer
the London Transport number +44 20 7222 1234, but if you really want an
NANP 555 number, use a different area code (803 or something like that that
isn't going to be confused with the trailing portion).

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive@davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec  8 11:08:36 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03777
	for <enum-archive@odin.ietf.org>; Fri, 8 Dec 2000 11:08:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07103;
	Fri, 8 Dec 2000 11:08:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07070
	for <enum@ns.ietf.org>; Fri, 8 Dec 2000 11:08:00 -0500 (EST)
Received: from exchange.chaos.com (exchange.chaos.com [206.5.17.8])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03686
	for <enum@ietf.org>; Fri, 8 Dec 2000 11:07:56 -0500 (EST)
Received: from [206.5.17.17] by exchange.netmagic.com (NTMail 5.06.0016/NT2627.00.5ef58ba0) with ESMTP id lknjaaaa for enum@ietf.org; Fri, 8 Dec 2000 11:07:51 -0500
Message-Id: <5.0.2.1.2.20001208110003.00ae9250@mail.netmagic.com>
X-Sender: amr@mail.netmagic.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 08 Dec 2000 11:07:51 -0500
To: Andy Gallant <Andrew.Gallant@neustar.com>,
        "'Douglas Ranalli'" <dranalli@netnumber.com>
From: "A.M.Rutkowski" <amr@netmagic.com>
Subject: RE: later response to RE: [Enum] ITU ENUM Workshop: Issues...
Cc: enum@ietf.org
In-Reply-To: <ED88182BFF78D211A4D800A0C9E9435CEA23BA@dc02.npac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hi Andy,

>Good questions.  Here's a personal response:  (1) The R&R discussion
>could be useful if a common framework for discussion can [ever?]
>be developed.  (2) As in previous emails on the list, there is
>a proposed new task to assemble some guidance (**note - please

Fair enough.  My remark was narrowly directed at
the near-term usefulness of piping any of this
into SG-2 given the lack of closure on any of
these matters, and their seeming willingness
to go along with a minimal role that just
recognizes the two key points - national matter
and synchronous numbers.

best,
tony 


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Dec  9 11:56:07 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20916
	for <enum-archive@odin.ietf.org>; Sat, 9 Dec 2000 11:56:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28812;
	Sat, 9 Dec 2000 11:54:21 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28751
	for <enum@ns.ietf.org>; Sat, 9 Dec 2000 11:54:19 -0500 (EST)
Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20688;
	Sat, 9 Dec 2000 11:54:13 -0500 (EST)
Message-Id: <200012091654.LAA20688@ietf.org>
From: Mail Sender<postmaster@rusgoods.ru>
To: ensink.gijs@kpmg.nl
CC: entmib@ietf.org, enum@ietf.org, enum-request@ietf.org,
        eperrine@nettally.com, eporro.interform@planet.it
Reply-To: mailsender@mailsender.ru
Date: 09.12.2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Enum] Russian Goods and Service from Moscow
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


www.rusgoods.com    www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical 
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . 
  It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes 
watches for the Russian Air Forces , Russian Naval Forces. 
  All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the 
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any 
middlemans.
 The submarine "Kursk" had on board mechanical marine hronometr 6MX. 
 ===============================================================
The "table" of orders.    Here you can to order, to find, to know almost everything, than the Russia is rich, 
everything 
that does not contradict Russian Federation laws. 
Here you can receive or order:

The information about any enterprise, firm, organization, or person in Russia 
The production or any goods of Russian manufactories, and other things if it is possible. 
===============================================================
www.rusgoods.com    www.rusgoods.ru

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Dec  9 20:53:10 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04521
	for <enum-archive@odin.ietf.org>; Sat, 9 Dec 2000 20:53:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03497;
	Sat, 9 Dec 2000 20:49:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03466
	for <enum@ns.ietf.org>; Sat, 9 Dec 2000 20:49:18 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03705
	for <enum@ietf.org>; Sat, 9 Dec 2000 20:49:16 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id UAA04591
	for enum@ietf.org; Sat, 9 Dec 2000 20:49:16 -0500 (EST)
Date: Sat, 9 Dec 2000 20:49:16 -0500 (EST)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200012100149.UAA04591@newdev.harvard.edu>
To: enum@ietf.org
Subject: [Enum] notice of a public meeting about ENUM
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

 >>> A Service of www.cybertelecom.org <<< 

http://www.ntia.doc.gov/ntiahome/ntiageneral/enum120800.htm
DEPARTMENT OF COMMERCE

National Telecommunications and Information Administration

Public Meeting on the Telephone Number Mapping (ENUM) Protocol

AGENCY: National Telecommunications and Information Administration

ACTION: Notice of Public Meeting

SUMMARY: The National Telecommunications and Information Administration
(NTIA), U.S. Department of Commerce, will hold a roundtable to discuss and
explore issues related to the Internet Engineering Task Force's (IETF)
Telephone Number Mapping (ENUM) protocol and the work being undertaken
between the IETF and the International Telecommunication Union (ITU) Study
Group 2 (SG2) to consider how number resolution using ENUM may be affected
by public switched telephone network infrastructure and telephone numbering
administration

DATE: The meeting will be held from 12:30 p.m. to 5:00 p.m., Monday,
December 18, 2000.

ADDRESS: The meeting will be held at the U.S. Department of Commerce, Room
B841A, 1401 Constitution Avenue, N.W., Washington, D.C. The meeting will be
open to the public.

FOR FURTHER INFORMATION: For further information, please contact Karen Rose,
Office of International Affairs, NTIA, telephone: (202) 482-1866.
Individuals wishing to attend the meeting should send an e-mail with the
participants name, organizational affiliation, and telephone number to
krose@ntia.doc.gov with a subject line entitled ENUM ROUNDTABLE or call Ms.
Rose with this information at the above-listed number.

SUPPLEMENTARY INFORMATION: Currently, communications users require a number
of different identifiers to be reachable through various communications
networks and services. For example, a user might have an e-mail address, a
telephone number, and a fax number, among others. The ENUM protocol, the
result of work of the Internet Engineering Task Force's (IETF's) Telephone
Number Mapping working group
(http://www.ietf.org/html.charters/enum-charter.html), is designed to allow
communications users to be reachable using standard telephone numbers (E.164
numbers) as a universal communications identifier. The ENUM protocol uses
the Internet domain name system (DNS) to resolve E.164 numbers into the
specific routing information needed to connect users through a chosen
communication path. E.164 is an International Telecommunications Union (ITU)
Recommendation that provides the number structure used for international
public telecommunication numbering plan. The ENUM protocol itself is defined
in IETF document "E.164 number and DNS" (RFC 2916) (see website above).

As part of the its work, the IETF engaged the ITU to consider how number
resolution using ENUM might be affected by public switched telephone network
infrastructure and telephone numbering plans, such as the ITU E.164
standard. Work in the ITU has been undertaken in ITU Telecommunication
Standardization Sector (ITU-T) Study Group 2 (SG 2) Working Party 1 (WP1),
which recently held a meeting in Berlin, Germany on October 16-26, 2000.
Among other issues, SG2/WP1 meeting discussed issues raised by ENUM, and
particularly, the method for administering and maintaining ENUM E.164-based
resources in the DNS. The SG2/WP1 meeting resulted in the issuance of a
liaison statement to the IETF that set forth a view on how E.164 resources
should be administered, as well identifying other issues for further
consideration (See http://www.itu.int/infocom/enum/wp1-39_rev1.htm).

The December 18 meeting intends to explore and stimulate discussion on
issues raised by ENUM, including those raised by recent ITU work. To
facilitate an exchange of views, the meeting will be structured as a
roundtable discussion. The tentative agenda for the meeting (subject to
change) is as follows:

1.Welcome

2.Technical overview of ENUM and examples of possible services enabled by
the ENUM protocol.

3.Exploration and discussion of issues raised by ENUM and ENUM numbering
administration.

4.Discussion of ITU SG2/WP1 meeting results and possible US approaches to
SG2/WP1 to the issue going forward.

5.Discussion on additional steps for progressing consideration of the issue.

6.Summary

PUBLIC PARTICIPATION: The meeting will be open to the public an is
physically accessible to people with disabilities. Individuals wishing to
attend should send an e-mail with the participants name, organizational
affiliation, and telephone number to krose@ntia.doc.gov with a subject line
entitled ENUM ROUNDTABLE or call Ms. Rose at (202) 482-1866 with this
information. To facilitate entry into the Department of Commerce building,
please have a photo identification and/or a U.S. Government building pass,
if applicable. Any member of the public wishing to attend and requiring
special services, such as sign language interpretation or other ancillary
aids, should contact Ms. Rose at least three (3) days prior to the
roundtable at the above-listed e-mail address or telephone number.

Kathy D. Smith  Chief Counsel

>>> A Service of www.cybertelecom.org <<<

~ Robert Cannon
~ www.cybertelecom.org            Donate Food!
~ cannon@cybertelecom.org       www.thehungersite.com  

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sun Dec 10 23:33:41 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20402
	for <enum-archive@odin.ietf.org>; Sun, 10 Dec 2000 23:33:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22412;
	Sun, 10 Dec 2000 23:28:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA22380
	for <enum@ns.ietf.org>; Sun, 10 Dec 2000 23:28:25 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19233
	for <enum@ietf.org>; Sun, 10 Dec 2000 23:28:23 -0500 (EST)
Received: by dnspri.npac.com; id WAA11936; Sun, 10 Dec 2000 22:28:24 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma011916; Sun, 10 Dec 00 22:28:01 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <W8JGTLAM>; Sun, 10 Dec 2000 22:26:16 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C8B3@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'BARNOLE Valerie FTRD/DAC/ISS'" <valerie.barnole@rd.francetelecom.fr>
Cc: enum@ietf.org
Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
Date: Sun, 10 Dec 2000 22:31:59 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA22381
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id XAA22412
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA20402

Valerie,

Sorry that I was not able to access my e-mails last week.

You had a question about GSM working with 3G.  It is very likely that an
interworking function (IWF) can be used to interwork between GSM (SS7) and
3G network (IP).   So the SS7 messages from the GSM networks can be
provisioned through the SS7 global title translation (GTT) capabilities and
be routed to those IWFs and vice versa.  This probably may answer your first
question below.  For the first message that is sent from the VLR to the HLR
(or AAA server), IMSI (E.212) or the mobile global title (E.214) can be
used.  That would require the use of something such as e212.arpa or
e214.arpa instead of e164.arpa as was explained in an earlier message.  The
3G networks can certainly use IP addresses or domain names for subsequent
message exchange (HLRID and VLRID used today are the E.164 numbers).  But to
interwork with the 2G system (GSM, IS-41), E.164 IDs probably will still be
used.  In that case, enum (e164.arpa) can be used for subsequent message
exchange between the VLR and HLR.  We can certainly view e212.arpa and
e214.arpa as part of enum; however, enum currently only defines e164.arpa.

In terms of your example of a call to the MSISDN, there are at least two
aspects.  One aspect is the calling device (e.g., a SIP phone) or a
softswitch that invokes enum to determine how to route to the MSISDN.  The
other aspect is when the call reaches a MSC-G (a gateway switch into the
cellular network), that MSC-G uses enum to find out the HLR that maintains
the service profile for that MSISDN (this assume that the service profiles
are partitioned among several HLRs and SS7 GTT is used today to locate the
proper HLR and the GTT process is to be replaced by the enum process).  In
the first aspect, the invoking application will be looking for NAPTR RRs
such as sip URL and tel URL (e.g., records related to end user's application
services).  In the second aspect, the invoking application will be looking
for NAPTR RRs related to "network-related" services such as "roam" (e.g.,
records provided by the cellular network operators in this example).

James



> -----Original Message-----
> From: BARNOLE Valerie FTRD/DAC/ISS
> [mailto:valerie.barnole@rd.francetelecom.fr]
> Sent: Wednesday, December 06, 2000 4:36 PM
> To: 'john.loughney@nokia.com'; james.yu@neustar.com
> Cc: enum@ietf.org
> Subject: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> John and James,
> forgive me if I understand wrongly but it seems to me that 
> there are various
> issues in roaming for ENUM:
> 1) the exemple of John, with mobile user roaming in China. 
> When the roamer
> wants to place a call. The input of the DNS query is the 
> IMSI,the output is
> the HLR IP address. But couldn't it also be the E.164 HLRID 
> in case the HLR
> has no IP address ?
> 2) The mobile user is still roaming in China ; a caller to 
> him dials his
> MSISDN (mobile phone number. This MSISDN is the input in the 
> ENUM process.
> The output of the DNS queries includes the IP address of the 
> VLR. Of course
> this output is of no use for the caller but is useful for the 
> operator in
> charge of finding the roamer to establish the call. Maybe the 
> service field
> is a trigger to prevent this query result to appear to the caller ?
> 
> 
>  
> 
> -----Message d'origine-----
> De: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Date: lundi 4 décembre 2000 12:53
> À: james.yu@neustar.com; valerie.barnole@rd.francetelecom.fr
> Cc: enum@ietf.org
> Objet: RE: [Enum] RE: draft-loughney-enum-roaming-00.txt
> 
> 
> Hi James & Valerie,
> 
> [James said]
> > Probably not interoperability and interworking.  I assume 
> > that all cellular nodes can use IP to communicate with each 
> > other (may be the 3G all IP networks?).
> 
> [Valerie said]
> > > I do not see precisely how ENUM can facilitate interworking 
> > > or interoperability between networks. Maybe there are other 
> > > drafts I should read ?
> 
> ENUM can simplify the 'reachability' issue for cellular networks
> (or for network providers).  Currently, finding the HLR/VLR for
> a particular subscriber when roaming is a complex task, mapping
> from global title to SS7 signaling point code.  As networks move
> to IP, this should be less complicated & hopefully allow some
> different protocols to interoperate more easily.
> 
> An example could be:
> 
> I'm roaming in China.  At the point of attachment to the network,
> the Chinese operator needs to check if I can get service.  The
> access point can use ENUM to find the address of my authorization
> node (HLR, let's say) and retrieves it's location (IP address).
> Then, it could use MAP over IP (a la SIGTRAN) or AAA (DIAMETER) 
> to verify that I can roam in China.
> 
> best regards,
> John
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Fri Dec 15 12:14:27 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01444
	for <enum-archive@odin.ietf.org>; Fri, 15 Dec 2000 12:14:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06090;
	Fri, 15 Dec 2000 12:10:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06059
	for <enum@ns.ietf.org>; Fri, 15 Dec 2000 12:10:33 -0500 (EST)
Received: from mail2.itu.int (mail2.itu.ch [156.106.192.18])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00438
	for <enum@ietf.org>; Fri, 15 Dec 2000 12:10:30 -0500 (EST)
Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21)
	id <YQGC8RLK>; Fri, 15 Dec 2000 18:05:09 +0100
Message-ID: <B796A386E6C1D411B6FD00508B959DFE0AE31E@mailsrv4.itu.ch>
From: "Shaw, Robert" <Robert.Shaw@itu.int>
To: "'enum@ietf.org'" <enum@ietf.org>
Date: Fri, 15 Dec 2000 18:10:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Enum] ITU ENUM Workshop: January 17, 2001
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

On 17 January 2001, ITU will host a one-day ENUM Workshop 
on administrative issues related to deployment of the ENUM 
protocol. The meeting will be held at ITU Headquarters in
Geneva, Switzerland. The following related materials are 
now available on the ITU web site:

ITU ENUM Web pages
http://www.itu.int/infocom/enum/

Description and Objective of the Workshop 
http://www.itu.int/infocom/enum/workshopjan01/enum-ws-jan17.htm

Draft Agenda 
http://www.itu.int/infocom/enum/workshopjan01/enum-agenda.htm

Registration Form
http://www.itu.int/infocom/enum/workshopjan01/enum-ws-registration.htm

Registration Form also in MS Word at
http://www.itu.int/infocom/enum/workshopjan01/enum-ws-registration.doc

Although the workshop is principally intended for national regulators, 
policy makers and numbering authorities, attendance is open to any 
interested participant. 

Bob
--
Robert Shaw <robert.shaw@itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Sat Dec 16 01:20:28 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25074
	for <enum-archive@odin.ietf.org>; Sat, 16 Dec 2000 01:20:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22111;
	Sat, 16 Dec 2000 01:17:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22082
	for <enum@ns.ietf.org>; Sat, 16 Dec 2000 01:16:57 -0500 (EST)
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23377
	for <enum@ietf.org>; Sat, 16 Dec 2000 01:16:57 -0500 (EST)
Received: from computer.ix.netcom.com (user-2ivek6u.dialup.mindspring.com [165.247.80.222])
	by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA05409;
	Sat, 16 Dec 2000 01:16:49 -0500 (EST)
Message-Id: <5.0.2.1.2.20001215124248.02b8bec0@127.0.0.1>
X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 15 Dec 2000 12:46:04 -0500
To: Scott Bradner <sob@harvard.edu>, Allison Mankin <mankin@isi.edu>
From: Richard Shockey <rshockey@ix.netcom.com>
Cc: enum@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Enum] Preliminary ENUM WG Meeting summary
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org


The ENUM WG met on Thursday afternoon and reviewed the status of several 
documents that have relate to the implementation of the ENUM protocol.

Consensus was agreed that these documents should move forward as Informational.

A discussion was held on the status of the WG and it was determined that A. 
the core protocol work of the WG is done and B. there was not consensus on 
whether 1. the WG should go to sleep for a while or 2. declare victory and 
close up.

Detailed Meeting Minutes will be posted in due course.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Richard Shockey
Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W.
Suite 550
Washington DC. 20005
Voice 202.533.2811
Fax to EMail 815.333.1237 (Preferred for Fax)
Cell : 314.503.0640
INTERNET Mail & IFAX : rich.shockey@neustar.com
or   rshockey@ix.netcom.com
http://www.neustar.com

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Wed Dec 20 10:00:55 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27312
	for <enum-archive@odin.ietf.org>; Wed, 20 Dec 2000 10:00:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23830;
	Wed, 20 Dec 2000 09:59:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23807
	for <enum@ns.ietf.org>; Wed, 20 Dec 2000 09:59:43 -0500 (EST)
Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27263
	for <enum@ietf.org>; Wed, 20 Dec 2000 09:59:42 -0500 (EST)
From: Francois-Xavier.Derome@alcatel.fr
Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32])
        by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id PAA05689;
        Wed, 20 Dec 2000 15:59:13 +0100 (MET)
Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C12569BB.00524FB4 ; Wed, 20 Dec 2000 15:59:03 +0100
X-Lotus-FromDomain: ALCATEL
To: SLINd@att.com, enum@ietf.org
Message-ID: <C12569BB.00524DED.00@frmta003.netfr.alcatel.fr>
Date: Wed, 20 Dec 2000 15:58:56 +0100
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Enum] question on call flows
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org



Hi steven and all,

in the ip to pstn example of the call flow, you used :
- enum to resolve number to tel uri
and
- trip front end protocol to resolve tel uri to ip address of the gateway.
Do you thing it will be possible to use enum to resolve directly number to sip:number@gateway to avoid the extra time. I though the tier 2 or the tier 3 should be able to do such resolution.

And will it be possible to detail the various tiers in the call flows, I think it will avoid some confusion amoung readers of the drafts.
thanks
fx



_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Dec 21 02:07:01 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12487
	for <enum-archive@odin.ietf.org>; Thu, 21 Dec 2000 02:07:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11765;
	Thu, 21 Dec 2000 02:05:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11736
	for <enum@ns.ietf.org>; Thu, 21 Dec 2000 02:05:28 -0500 (EST)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12453
	for <enum@ietf.org>; Thu, 21 Dec 2000 02:05:26 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA03915;
	Thu, 21 Dec 2000 02:08:03 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2076KMZ>; Thu, 21 Dec 2000 02:02:58 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAEAE@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Francois-Xavier.Derome@alcatel.fr'"
	 <Francois-Xavier.Derome@alcatel.fr>,
        SLINd@att.com, enum@ietf.org
Subject: RE: [Enum] question on call flows
Date: Thu, 21 Dec 2000 02:02:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org



 

> -----Original Message-----
> From: Francois-Xavier.Derome@alcatel.fr
> [mailto:Francois-Xavier.Derome@alcatel.fr]
> Sent: Wednesday, December 20, 2000 9:59 AM
> To: SLINd@att.com; enum@ietf.org
> Subject: [Enum] question on call flows
> 
> 
> 
> 
> Hi steven and all,
> 
> in the ip to pstn example of the call flow, you used :
> - enum to resolve number to tel uri
> and
> - trip front end protocol to resolve tel uri to ip address of 
> the gateway.
> Do you thing it will be possible to use enum to resolve 
> directly number to sip:number@gateway to avoid the extra 
> time. I though the tier 2 or the tier 3 should be able to do 
> such resolution.

This is a frequently asked question.

You can find discussions in the archives; there is also discussion in the
TRIP framework document:

http://www.ietf.org/rfc/rfc2871.txt

To summarize, ENUM is a *name to address* mapping solution, whereas TRIP is
an *address to route* mapping solution. These are vastly different, just as
directory protocols are different from routing protocols. Why? Because the
answer of "which gateway to go to" in the routing case depends on who is
asking, and that is not something you can do with a database protocol like
enum. Each VoIP provider will have differing relationships with various
other gateway providers, and so the decision about which gateway to use to
terminate a call is a matter of local policy. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Dec 21 04:05:09 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13618
	for <enum-archive@odin.ietf.org>; Thu, 21 Dec 2000 04:05:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12865;
	Thu, 21 Dec 2000 04:04:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12837
	for <enum@ns.ietf.org>; Thu, 21 Dec 2000 04:04:33 -0500 (EST)
Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13615
	for <enum@ietf.org>; Thu, 21 Dec 2000 04:04:33 -0500 (EST)
From: Francois-Xavier.Derome@alcatel.fr
Received: from frmta004.netfr.alcatel.fr (frmta004.netfr.alcatel.fr [155.132.182.160])
        by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id KAA15910
        for <enum@ietf.org>; Thu, 21 Dec 2000 10:03:53 +0100 (MET)
Received: by frmta004.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C12569BC.0031C892 ; Thu, 21 Dec 2000 10:03:46 +0100
X-Lotus-FromDomain: ALCATEL
To: enum@ietf.org
Message-ID: <C12569BC.0031C741.00@frmta004.netfr.alcatel.fr>
Date: Thu, 21 Dec 2000 10:03:40 +0100
Subject: RE: [Enum] question on call flows
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org




yes, i agree with your statement but i wanted to know if it was also correct to return the sip uri instead of the tel uri.
I have a subscription to a french itsp and  i want him to handle my calls because he knows how to handle them.
So the tier 1 point to my itsp and my itsp's gateway or sip server knows what to do with my calls with or without using trip.
fx



Jonathan Rosenberg <jdrosen@dynamicsoft.com> on 21/12/2000 08:02:54
                                                              
                                                              
                                                              
 To:      Francois-Xavier DEROME/FR/ALCATEL@ALCATEL,          
          SLINd@att.com, enum@ietf.org                        
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: RE: [Enum] question on call flows                   
                                                              









> -----Original Message-----
> From: Francois-Xavier.Derome@alcatel.fr
> [mailto:Francois-Xavier.Derome@alcatel.fr]
> Sent: Wednesday, December 20, 2000 9:59 AM
> To: SLINd@att.com; enum@ietf.org
> Subject: [Enum] question on call flows
>
>
>
>
> Hi steven and all,
>
> in the ip to pstn example of the call flow, you used :
> - enum to resolve number to tel uri
> and
> - trip front end protocol to resolve tel uri to ip address of
> the gateway.
> Do you thing it will be possible to use enum to resolve
> directly number to sip:number@gateway to avoid the extra
> time. I though the tier 2 or the tier 3 should be able to do
> such resolution.

This is a frequently asked question.

You can find discussions in the archives; there is also discussion in the
TRIP framework document:

http://www.ietf.org/rfc/rfc2871.txt

To summarize, ENUM is a *name to address* mapping solution, whereas TRIP is
an *address to route* mapping solution. These are vastly different, just as
directory protocols are different from routing protocols. Why? Because the
answer of "which gateway to go to" in the routing case depends on who is
asking, and that is not something you can do with a database protocol like
enum. Each VoIP provider will have differing relationships with various
other gateway providers, and so the decision about which gateway to use to
terminate a call is a matter of local policy.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum






_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Dec 21 10:08:37 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21461
	for <enum-archive@odin.ietf.org>; Thu, 21 Dec 2000 10:08:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16641;
	Thu, 21 Dec 2000 10:07:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16611
	for <enum@ns.ietf.org>; Thu, 21 Dec 2000 10:07:26 -0500 (EST)
Received: from dnspri.npac.com (firewall-user@dnspri.npac.com [208.143.33.66])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21437
	for <enum@ietf.org>; Thu, 21 Dec 2000 10:07:26 -0500 (EST)
Received: by dnspri.npac.com; id JAA07204; Thu, 21 Dec 2000 09:07:27 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma007182; Thu, 21 Dec 00 09:06:56 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <ZAYY8GNW>; Thu, 21 Dec 2000 09:05:07 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C919@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'Francois-Xavier.Derome@alcatel.fr'"
	 <Francois-Xavier.Derome@alcatel.fr>
Cc: enum@ietf.org
Subject: RE: [Enum] question on call flows
Date: Thu, 21 Dec 2000 09:10:52 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Yes, you can put a sip URL instead of a tel URL in the NAPTR RR.  sip URL
can also carry the telephone number at the user portion.  Your example
indicates that the French ITSP is your Tier 2 Entity (T2E).  Your T2E can
return anything you want so long as they are valid URLs (it is a service
that can be provided by a T2E).  It can return the sip URL in the NAPTR RR
with a domain name or IP address in the host portion based on some criteria.
In this case, your T2E may need to use the TRIP information to do that. 

Your T2E does not handle the call at this point yet.  It simply responds to
the DNS/ENUM query for the NAPTR RRs associated with your E.164 number.
The requestor may not need to use TRIP if no tel URL is returned in the
NAPTR RRs or the returned tel URLs are not used for call termination.

James



> -----Original Message-----
> From: Francois-Xavier.Derome@alcatel.fr
> [mailto:Francois-Xavier.Derome@alcatel.fr]
> Sent: Thursday, December 21, 2000 4:04 AM
> To: enum@ietf.org
> Subject: RE: [Enum] question on call flows
> 
> 
> 
> 
> 
> yes, i agree with your statement but i wanted to know if it 
> was also correct to return the sip uri instead of the tel uri.
> I have a subscription to a french itsp and  i want him to 
> handle my calls because he knows how to handle them.
> So the tier 1 point to my itsp and my itsp's gateway or sip 
> server knows what to do with my calls with or without using trip.
> fx
> 
> 
> 
> Jonathan Rosenberg <jdrosen@dynamicsoft.com> on 21/12/2000 08:02:54
>                                                               
>                                                               
>                                                               
>  To:      Francois-Xavier DEROME/FR/ALCATEL@ALCATEL,          
>           SLINd@att.com, enum@ietf.org                        
>                                                               
>  cc:                                                          
>                                                               
>                                                               
>                                                               
>  Subject: RE: [Enum] question on call flows                   
>                                                               
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Francois-Xavier.Derome@alcatel.fr
> > [mailto:Francois-Xavier.Derome@alcatel.fr]
> > Sent: Wednesday, December 20, 2000 9:59 AM
> > To: SLINd@att.com; enum@ietf.org
> > Subject: [Enum] question on call flows
> >
> >
> >
> >
> > Hi steven and all,
> >
> > in the ip to pstn example of the call flow, you used :
> > - enum to resolve number to tel uri
> > and
> > - trip front end protocol to resolve tel uri to ip address of
> > the gateway.
> > Do you thing it will be possible to use enum to resolve
> > directly number to sip:number@gateway to avoid the extra
> > time. I though the tier 2 or the tier 3 should be able to do
> > such resolution.
> 
> This is a frequently asked question.
> 
> You can find discussions in the archives; there is also 
> discussion in the
> TRIP framework document:
> 
> http://www.ietf.org/rfc/rfc2871.txt
> 
> To summarize, ENUM is a *name to address* mapping solution, 
> whereas TRIP is
> an *address to route* mapping solution. These are vastly 
> different, just as
> directory protocols are different from routing protocols. 
> Why? Because the
> answer of "which gateway to go to" in the routing case 
> depends on who is
> asking, and that is not something you can do with a database 
> protocol like
> enum. Each VoIP provider will have differing relationships 
> with various
> other gateway providers, and so the decision about which 
> gateway to use to
> terminate a call is a matter of local policy.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 
> 
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum


From enum-admin@ietf.org  Thu Dec 21 15:28:50 2000
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29648
	for <enum-archive@odin.ietf.org>; Thu, 21 Dec 2000 15:28:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20585;
	Thu, 21 Dec 2000 15:26:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20556
	for <enum@ns.ietf.org>; Thu, 21 Dec 2000 15:26:11 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29585
	for <enum@ietf.org>; Thu, 21 Dec 2000 15:26:12 -0500 (EST)
Received: from flf960r1.ems.att.com ([135.71.244.37])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBLKPXG25132
	for <enum@ietf.org>; Thu, 21 Dec 2000 15:25:33 -0500 (EST)
Received: from njb140bh1.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA02719; Thu, 21 Dec 2000 15:23:11 -0500 (EST)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35)
	id <Z10MRNGD>; Thu, 21 Dec 2000 15:25:30 -0500
Message-ID: <B13F591F20ACD311BE4300902761550F034BA53F@njb140po06.ems.att.com>
From: "Lind, Steven D, ALCOO" <sdlind@att.com>
To: "'Francois-Xavier.Derome@alcatel.fr'"
	 <Francois-Xavier.Derome@alcatel.fr>,
        enum@ietf.org
Subject: RE: [Enum] question on call flows
Date: Thu, 21 Dec 2000 15:25:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

ENUM will return a set of URIs, one of which could be for SIP. It will be up
to whatever ENUM-enabled client you are using to select the most appropriate
URI to use. I've seen some examples where the SIP URI is <telephone
number>@<host> with a qualifier to indicate that the destination is a PSTN
device.

Steve

---------------------------------------------------------------
Steven D. Lind                   Tel: (973) 236-6787
AT&T                             Fax: (973) 236-6452  
180 Park Ave., Bldg. 2            e-mail: sdlind@att.com
Florham Park, NJ 07932        web: sdlind.ims.att.com         
---------------------------------------------------------------


> -----Original Message-----
> From:	Francois-Xavier.Derome@alcatel.fr
> [SMTP:Francois-Xavier.Derome@alcatel.fr]
> Sent:	Thursday, December 21, 2000 4:04 AM
> To:	enum@ietf.org
> Subject:	RE: [Enum] question on call flows
> 
> 
> 
> 
> yes, i agree with your statement but i wanted to know if it was also
> correct to return the sip uri instead of the tel uri.
> I have a subscription to a french itsp and  i want him to handle my calls
> because he knows how to handle them.
> So the tier 1 point to my itsp and my itsp's gateway or sip server knows
> what to do with my calls with or without using trip.
> fx
> 
> 
> 
> Jonathan Rosenberg <jdrosen@dynamicsoft.com> on 21/12/2000 08:02:54
>                                                               
>                                                               
>                                                               
>  To:      Francois-Xavier DEROME/FR/ALCATEL@ALCATEL,          
>           SLINd@att.com, enum@ietf.org                        
>                                                               
>  cc:                                                          
>                                                               
>                                                               
>                                                               
>  Subject: RE: [Enum] question on call flows                   
>                                                               
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Francois-Xavier.Derome@alcatel.fr
> > [mailto:Francois-Xavier.Derome@alcatel.fr]
> > Sent: Wednesday, December 20, 2000 9:59 AM
> > To: SLINd@att.com; enum@ietf.org
> > Subject: [Enum] question on call flows
> >
> >
> >
> >
> > Hi steven and all,
> >
> > in the ip to pstn example of the call flow, you used :
> > - enum to resolve number to tel uri
> > and
> > - trip front end protocol to resolve tel uri to ip address of
> > the gateway.
> > Do you thing it will be possible to use enum to resolve
> > directly number to sip:number@gateway to avoid the extra
> > time. I though the tier 2 or the tier 3 should be able to do
> > such resolution.
> 
> This is a frequently asked question.
> 
> You can find discussions in the archives; there is also discussion in the
> TRIP framework document:
> 
> http://www.ietf.org/rfc/rfc2871.txt
> 
> To summarize, ENUM is a *name to address* mapping solution, whereas TRIP
> is
> an *address to route* mapping solution. These are vastly different, just
> as
> directory protocols are different from routing protocols. Why? Because the
> answer of "which gateway to go to" in the routing case depends on who is
> asking, and that is not something you can do with a database protocol like
> enum. Each VoIP provider will have differing relationships with various
> other gateway providers, and so the decision about which gateway to use to
> terminate a call is a matter of local policy.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum
> 
> 
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> http://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
http://www1.ietf.org/mailman/listinfo/enum