Subject: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt

From: Richard Shockey <[email-masked]>
Date: Fri, 08 Jul 2005 16:55:43 -0400

To: i-d-announce at ietf.org
From: Internet-Drafts at ietf.org
Date: Fri, 08 Jul 2005 15:50:01 -0400
Reply-To: internet-drafts at ietf.org
Sender: i-d-announce-bounces at ietf.org
Subject: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt

X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA11687
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

        Title           : IANA Registration for an Enumservice
                          Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8
   This document registers the Enumservice "npd" and subtype "tel" using
   the URI scheme 'tel:' as per the IANA registration process defined in
   the ENUM specification, RFC 3761.  This data is used to facilitate
   the routing of telephone calls in those countries where Number
   Portability exists.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at ietf.org with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-livingood-shockey-enum-npd-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
        mailserv at ietf.org.
In the body type:
        "FILE /internet-drafts/draft-livingood-shockey-enum-npd-00.txt".
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2005-7-8104034.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-livingood-shockey-enum-npd-00.txt
<ftp://ftp.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Sun, 10 Jul 2005 08:48:51 -0400

Dear all, especially Allison Mankin,
 
I consider this I-D very interesting, because I also proposed in the past to use the 
parameters defined in draft-ietf-iptel-tel-np-06.txt e.g. ";rn=" within ENUM,
but did not bring this forward because of reason stated below.
 
Before I comment on this draft and raise some questions, I would like to
get some principle statements from our esteemed AD Allison if this draft
is within the scope of IETF and ENUM WG.
 
The rationale for this question is the following:
 
The intended use of the Enumservice "npd:tel" is primarily for 
carriers, because only carriers my interpret and use the "rn= parameter.
 
Routing numbers MUST NEVER be used by end-users.
 
During the discussion Lawrence Conroy and I had with Ted Hardie
and Allison Mankin in Geneva in May regarding the I-D draft-ietf-enum-msg-04.txt,
especially about Enumservice "mms:mailto", I mentioned the fact that
this Enumservice MAY also be used by carriers.
 
Allison did not like this statement at all and said ENUM and 
Enumservices to-be-defined are ONLY for end-user usage. I only
got over this hurdle by confirming that "mms:mailto" is ALSO
useful for end-users.
 
Therefore I want to have a clear statement from the responsible AD
if an Enumservice for carrier use ONLY is within the scope of ENUM WG,
before I waste my time in discussing this I-D on the list.

Richard Stastny

________________________________

Von: enum-bounces at ietf.org im Auftrag von Richard Shockey
Gesendet: Fr 08.07.2005 22:52
An: enum at ietf.org
Betreff: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt

>X-Spam-Score: 0.4 (/)
>X-Scan-Signature: 73734d43604d52d23b3eba644a169745
>X-BeenThere: i-d-announce at ietf.org
>X-Mailman-Version: 2.1.5
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:i-d-announce-request at ietf.org?subject=unsubscribe>
>List-Post: <mailto:i-d-announce at ietf.org>
>List-Help: <mailto:i-d-announce-request at ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:i-d-announce-request at ietf.org?subject=subscribe>
>X-SongbirdInformation: support at songbird.com for more information
>X-Songbird: Found to be clean
>X-Songbird-From: i-d-announce-bounces at ietf.org
>X-Keywords:

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Jul 2005 11:08:02 -0400

Mike wrote:

>All E.164 numbers in ENUM are effectively ported, so I don't understand
>why the npd needs to be an ENUM service rather than just an attribute of
>the tel ENUM service.  This is not to say that the result returned does
>not have the npdi, rn, cic or other tel parameters provided.
 
Since e talk here about USER ENUM and Carrier ENUM, could you PLEASE
state what ENUM you are talking about.
In User ENUM it is meaningless if a number is ported or not, because
the holder of the domain is the end-user having the right to use the number
and this user does not change if the number is ported
 
In Carrier ENUM the holder of the domain has to change if the number is ported.
 
What is the tel ENUM services? There is none currently defined.

>Second, IP-based softswitches can do routing based on such information
>in the IP domain, so such information is not only of use to PSTN-based
>switches (during the migration from PSTN to IP-based).
 
No, routing numbers are only meaningfull on the PSTN and also
here only in a national context.
On IP you need an additional information, e.g. instead of a tel URI
with a rn also a sip URI with a domain name.

>Third, since number portability is essentially performed by service
>providers, is the scope of this limited only to Carrier ENUM?
 
YES. I said it many times already that a user cannot access routing numbers,
so putting rn in User ENUM is not useful.

>Number portability is a PSTN routing database mechanism.  If ENUM is
>done right, then when the TDM PSTN as we know it disappears, so should
>number portability.  Porting a number in the IP domain ought to be
>simply an ENUM re-registration.  A single ENUM dip should be needed, not
>an ENUM and an NP dip.  Some of the crufty PSTN mechanisms will fade
>away, no?
 
Maybe, maybe not

>Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On
> Behalf Of Stastny Richard
> Sent: Monday, July 25, 2005 6:23 AM
> To: Richard Shockey
> Cc: enum at ietf.org
> Subject: Re: [Enum] Fwd: I-D
> ACTION:draft-livingood-shockey-enum-npd-00.txt
>
> Rich,
> 
> One comment first
> I basically like the idea of a generic tel Enumservice,
> whatever it is called. but I do not have thought through all
> implications Maybe we can discuss this in Paris (we have a
> whole week ;-)
> 
> To your remarks:
> 
> >That is not true. The ENUM serive npd indicated number
> portability data
> >that may be associated with any telephone number.
>
> >The examples in the textare quite clear that the information
> relates to
> >both Ported and NonPorted numbers.
>
> Thats what I said:
>
> Still, the sentence:
>
> "The purpose of this Enumservice is
> to describe information about telephone numbers which cannot
> be used on the public Internet or a private/peered Internet
> Protocol (IP) network.  "
>
> is unclear (or wrong, because you can use proted numbers on
> the Public Internet (I do)
>
> >The modification is to define a new enumservice field.
> >E2U+npd:sip
> >with the URI defined something like this.
>
> >NAPTR 10 10 "u" "E2U+npd:sip"
> >"!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!"
>
> >the rationale for this is that many gateways dont know what
> tel URI's are.
> 
> Now I am completely lost. I tought the "npd" was a generic
> Enumservice giving the "rn" to be used (in the national
> network), but the gateway to user is your choice. One may
> even query this information from the PSTN via a IN-mediation
> device. Now you introduce a specific "transit" gateway.
> 
> BTW: your example URI should be:
> sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net
> 
>
> >For what purpose?
> 
> For this:
>
> >
> >One example is the usage of ENUM-only numbers existing only in User
> >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be
> >useful to point from Carrier ENUM to User ENUM. Such a
> number may have
> >a routing number , but this routing numbers are only of national
> >significance and cannot be used in a global system.
> >
> >There is also missing a note that with this Enumservice the tel URI
> >MUST always contain the same number then the AUS.
>
>
>
> Von: Richard Shockey [mailto:Rich.Shockey at neustar.biz]
> Gesendet: Fr 22.07.2005 20:46
> An: Stastny Richard
> Cc: Richard Shockey; enum at ietf.org
> Betreff: Re: [Enum] Fwd: I-D
> ACTION:draft-livingood-shockey-enum-npd-00.txt
>
>
>
> Stastny Richard wrote:
>
> >Dear all,
> >
> >although I did not receive (yet) any response to my e-mail below, I
> >want to comment on the mentioned draft:
> >
> >I have a question to the following paragraph:
> >
> >"The following Enumservice is registered with this document: "npd" to
> >   indicate number portability data.  The purpose of this
> Enumservice is
> >   to describe information about telephone numbers which
> cannot be used
> >   on the public Internet or a private/peered Internet Protocol (IP)
> >   network.  Thus, these are numbers which are only reachable via the
> >   traditional Public Switched Telephone Network (PSTN)."
> >
> >The second sentence seems to imply that ONLY ported numbers will be
> >used with the Enumservice "npd". The example 4.2 indicates that also
> >non-ported numbers may be used.
> >
> >
> That is not true. The ENUM serive npd indicated number
> portability data that may be associated with any telephone number.
>
> The examples in the textare quite clear that the information
> relates to both Ported and NonPorted numbers.
>
> 4.1 Example of a Ported Telephone Number
>
> $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa.
>
> NAPTR 10 100 "u" "E2U+npd:tel"
>
> "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!"
>
>
> In this example, a Routing Number (rn) and a Number Portability Dip
>
> Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt
>
> [10] (Internet-Draft New Parameters for the "tel" URI to Support
>
> Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The 'npdi'
>
> field is included in order to prevent subsequent lookups in legacy-
>
> style PSTN databases.
>
> 4.2 Example of a Non-Ported Telephone Number
>
> $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa.
>
> NAPTR 10 100 "u" "E2U+npd:tel"
>
> "!^.*$!tel:+1-215-981-7813;npdi!"
>
> I have had a private request to consider an alternative
> formation of th e URI.
>
> as in
>
> The modification is to define a new enumservice field.
>
> E2U+npd:sip
>
> with the URI defined something like this.
>
> NAPTR 10 10 "u" "E2U+npd:sip"
> "!^.*$!sip:+15714345651 at mg4.mso.net;rn=+15712768933;npdi!"
>
> the rationale for this is that many gateways dont know what
> tel URI's are.
>
> >
> >The third sentence is simply not true: I myself have ported numbers
> >that can be reached on the public Internet via SIP URIs.
> >
> >
> A fair criticism a better wording might have been.
>
> "Thus, this information is only useful in a national specific
> context within the traditional Public Switched Telephone
> Network (PSTN)."
>
>
> >
> >IMHO there is a more in-depth analysis required how this
> Enumservice is
> >used, what it implies and with which other Enumservices it
> can be used
> >togother
> >
> >There is also a need to consolidate the different Enumservices using
> >the tel URI and their use in User and Carrier ENUM.
> >Also the usage of crosspointers (entries in User ENUM pointing to
> >Carrier ENUM and vice versa) with tel URIs is necessary.
> >
> >
> For what purpose?
>
> >
> >One example is the usage of ENUM-only numbers existing only in User
> >ENUM (e.g. +43780 and +87810). Here a pointer in Carrier ENUM may be
> >useful to point from Carrier ENUM to User ENUM. Such a
> number may have
> >a routing number , but this routing numbers are only of national
> >significance and cannot be used in a global system.
> >
> >There is also missing a note that with this Enumservice the tel URI
> >MUST always contain the same number then the AUS.
> >
> >regards
> >
> >-richard
> >
> >Von: enum-bounces at ietf.org im Auftrag von Stastny Richard
> >Gesendet: So 10.07.2005 14:51
> >An: Richard Shockey; enum at ietf.org
> >Betreff: Re: [Enum] Fwd: I-D
> >ACTION:draft-livingood-shockey-enum-npd-00.txt
> >
> >
> >
> >I consider this I-D very interesting, because I also proposed in the
> >past to use the parameters defined in draft-ietf-iptel-tel-np-06.txt
> >e.g. ";rn=" within ENUM, but did not bring this forward
> because of reason stated below.
> >
> >Before I comment on this draft and raise some questions, I
> would like
> >to get some principle statements from our esteemed AD
> Allison if this
> >draft is within the scope of IETF and ENUM WG.
> >
> >During the discussion Lawrence Conroy and I had with Ted Hardie and
> >Allison Mankin in Geneva in May regarding the I-D
> >draft-ietf-enum-msg-04.txt, especially about Enumservice
> "mms:mailto",
> >I mentioned the fact that this Enumservice MAY also be used
> by carriers.
> >
> >Enumservices to-be-defined are ONLY for end-user usage. I
> only got over
> >this hurdle by confirming that "mms:mailto" is ALSO useful for
> >end-users.
> >
> >Therefore I want to have a clear statement from the
> responsible AD if
> >an Enumservice for carrier use ONLY is within the scope of ENUM WG,
> --
> Richard Shockey, Director - Member of Technical Staff NeuStar Inc.

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Jul 2005 11:39:21 -0400

Rich wrote:
 
>Did you see my reply ..I conceded this point.

>"Thus, this information is only useful in a national specific context
>within the traditional Public Switched Telephone Network (PSTN)."

Scusi, I saw it the first time, but I missed it when I wrote the reply

>The operators choice. This draft is meant for use only within the
>context of a Carrier ENUM service and more specifically in North America
>this data would never be globally visable.In other national
>jurisdictions it might be but not in NA.
 
They are globally visible, but not usable

>no the original was correct. This is not a SIP URI.
 
IMHO the correct version is
sip:+15714345651;rn=+15712768933;npdi at mg4.mso.net; user=phone

To be continued in another post
 
-richard

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 25 Jul 2005 12:45:34 -0400

Richard,

I did not write the draft, nor the email that started this, so as my
later comment noted, it was not clear what ENUM the original email
referred to.

Inline. 

> From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
> Sent: Monday, July 25, 2005 11:11 AM
> To: Michael Hammer (mhammer); Richard Shockey
> Cc: enum at ietf.org
> >why the npd needs to be an ENUM service rather than just an 
> attribute 
> >of the tel ENUM service.  This is not to say that the result 
> returned 
> >does not have the npdi, rn, cic or other tel parameters provided.
>  
> Since e talk here about USER ENUM and Carrier ENUM, could you 
> PLEASE state what ENUM you are talking about.
> In User ENUM it is meaningless if a number is ported or not, 
> because the holder of the domain is the end-user having the 
> right to use the number and this user does not change if the 
> number is ported

This begs the question.  If I have the right to use an E.164 number and
therefore can register it in User ENUM, can I not register it even when
I have a PSTN phone along with other IP-based services?  This would
suggest that I could put in a tel URI in the NAPTR, no?

> In Carrier ENUM the holder of the domain has to change if the 

Call it porting if you like, but do you use the ENUM registration
process or the Number Portability process to make the change in the
Carrier ENUM registry?

> What is the tel ENUM services? There is none currently defined.

I have heard discussion of putting tel URIs in NAPTR records (maybe that
was on IPTEL list).  Perhaps, I am using wrong terminology.  What do you
call such NAPTRs?  Perhaps, also defining such is still work in
progress.  I found all the SIP+E2U versus E2U+SIP IANA registration
mixup confusing.

> here only in a national context.

Given the +CCxxxxx digits the national context can be known.  While it
is meanful to determine which switch or gateway the rn= digits are homed
to, that does not mean that one needs to route to the nearest PSTN GW to
get the call to that switch.  If an SP has many PSTN GWs, it may be
cost-effective to route to that rn= value through one PSTN GW versus
another.  Are there any assumptions being made here?

> On IP you need an additional information, e.g. instead of a 
> tel URI with a rn also a sip URI with a domain name.

Some have suggested that having tel instead of sip URI leaves the
IP-domain more flexibility in how to route.

> YES. I said it many times already that a user cannot access 
> routing numbers, so putting rn in User ENUM is not useful.

The original email did not specify Carrier ENUM.

Mike
 
> >simply an ENUM re-registration.  A single ENUM dip should be needed, 
> >not an ENUM and an NP dip.  Some of the crufty PSTN mechanisms will 
> >fade away, no?
>  
> Maybe, maybe not
> 
> >Mike
> 
> 
> > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] 
> On Behalf 
> > Of Stastny Richard
> whatever it is 
> > called. but I do not have thought through all implications Maybe we 
> > can discuss this in Paris (we have a whole week ;-)
> > 
> > To your remarks:
> > 
> > network.  "
> Enumservice 
> > giving the "rn" to be used (in the national network), but 
> the gateway 
> > to user is your choice. One may even query this information 
> from the 
> > PSTN via a IN-mediation device. Now you introduce a 
> specific "transit" 
> > gateway.
> > 
> > That is not true. The ENUM serive npd indicated number portability 
> > data that may be associated with any telephone number.
> >
> > The examples in the textare quite clear that the 
> information relates 
> > to both Ported and NonPorted numbers.
> >
> formation of 
> > th e URI.
> tel URI's 
> > are.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 25 Jul 2005 12:58:27 -0400

Richard,

I suspect that some 20 years in the future we will have something called
the PSTN, but it will not look anything like the TDM network.  My only
goal here is to not assume that the number portability databases and
processes will automatically become the ENUM databases and processes.
As a result, I start with the assumption that number portability is
purely a TDM mechanism that affect routing in the TDM domain.  But, then
acknowledge that certain information may bleed over and be acted on in
the IP domain.

But, there have been others that have suggested that somehow the ENUM
registration change needs to be dependent on the number portability
change, and I don't think that is necessary.  If ENUM can do it in one
day, while NP takes several weeks, no sense in anchoring ENUM down.

Mike

> From: Richard Shockey [mailto:richard at shockey.us] 
> Sent: Monday, July 25, 2005 11:52 AM
> To: Michael Hammer (mhammer)
> Cc: Stastny Richard; Richard Shockey; enum at ietf.org
> Michael Hammer (mhammer) wrote:
> 
> >Richard and Richard,
> >
> >All E.164 numbers in ENUM are effectively ported,
> >
> you cannot completely draw that conclusion over time. Policy 
> over number allocation isues  are under serious discussion 
> which might change that statement ..though for the indefinate 
> future it is reasonable to assume that most VoIP numbers will 
> be ported or pooled.
> 
> > so I don't understand
> Enhancing  the search pattern the resolver uses to find the 
> appropriate NAPTR record. Yes it could use a pure E2U+tel but 
> I think this is better and there are logical arguments for 
> seperating values out such as if you wanted to add CNAM.
> 
> Unlike some in this WG I have never had an objection to 
> granular "hints" 
> as to the service or information contained in a NAPTR record.
> 
> More information is better than less.
> 
> Yes .. you can make some interesting trunking decisions based 
> on the NPA-NXX of a particular LRN if you can aquire that 
> information at point of session origination vs N-1.
> 
> Yes ..that should be self evident by now but as Richard 
> points out this is a national specific issue. And as I 
> spefically said before North American LNP data cannot be 
> openly distributed. The context of the query in the US and 
> Canada would certainly be some form of closed network or 
> internal network databases that have DNS query response capability.
> 
> BTW this would certainly work in a SIP redirect context as well.
> 
> >done right,
> and IF you get significant consumer and enterprise OP-IN ... 
> lots of big IF's here
> 
> > then when the TDM PSTN as we know it disappears, so should number 
> >portability.
> >
> Yes  in the long run we are all dead.
> 
> > Porting a number in the IP domain ought to be simply an ENUM 
> >re-registration.
> >
> Correct ... IF the PSTN disapears.  but I'm not holding my 
> breath for that to happen anytime soon or ending world 
> hunger, rediscovering cold fusion, fixing the US trade decifit...etc
> 
> > A single ENUM dip should be needed, not an ENUM and an NP 
> dip.  Some 
> >of the crufty PSTN mechanisms will fade away, no?
> >  
> >
> Yes and we'll all join hands and sing Kumbayaa, but until 
> that time of perfect Nirvana, spiritual harmony and bliss 
> arrives we'll just have to plug along trying to solve the 
> simple practial problems of interworking IP and PSTN networks.
> 
> >Mike
> >
> >  
> >
> 
> -- 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Jul 2005 15:46:15 -0400

>suggest that I could put in a tel URI in the NAPTR, no?

This is a very valid point, and needs some explanation,
because there is some history involved

Originally this was not considered necessary, because
any entry in User ENUM requires that the E.164 number exists
(is assigned to an end-user) and is IN SERVICE. The last point
is a validation requirement. So a number within a block
assigned to a carrier and not in service cannot be in User ENUM.
 
So putting a tel URI with the same number would give no additional
information. Nevertheless, a voice:tel Enumservice is proposed (and 
in discussion for now already 3 years),  to be used to point to another 
E.164 number on the PSTN e.g. if you try a sip URI and it does not work,
you may try my mobile number.This voice:tel is implemented in Austria
(it is defined by ETSI) and ALSO used be some end-users (e.g. companies
to exactly do what you suggest, namely to indicate that the same number is
existing on the PSTN also.

The reason for this is because in the meantime so-called ENUM-only
numbers which do not exist on the PSTN are also in use. When I say
do not exist this does not mean they are not routed. This numbers are
routed to gateways from the PSTN to IP, so if you route such calls from the
Internet to the PSTN you would finally end up on the Internet again.
 
Having this in mind, an indication that the number also exists REALLY
on the PSTN would make sense now. If this is finally voice:tel or
ndp:tel is a somewhat philosophical question discussed within ENUM
WG since years.
 
One should only keep in mind that also some other proposals exist
using the tel: URI. One is video:tel. Here the issue is not so clear, because
here at least two standards exist, one for ISDN video and one for 3G video.
 
In addition there exists the proposal for enum:tel. 
This enum service would allow to point to another number
in ENUM. One use case would be that you have eg 3 E.164
numbers in ENUM and point two of them to the third and
maintain your real ENUM entries only in onel place.

The other use case would be to cross-point to an ENUM-only number
from a carrier ENUM tree. ENUM-only numbers cannot be hosted
in Carrier ENUM by definition, because the number exists only in User
ENUM and the information there is authoritative. So some infromation
is necessary in Carrier ENUM to indicate this fact. The easiest would
be to put in one wildcard record for the whole number range.
 
There is also a proposal to use enum:tel with special parameters
giving the apex of the carreir tree in the tel: URI instead of the 
non-terminal NAPTRs in Tier 1
 
-richard
PS: additional answers in separate postings

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 25 Jul 2005 15:50:57 -0400

Replies inline below.

> I suspect that some 20 years in the future we will have 
> something called the PSTN, but it will not look anything like 
> the TDM network.  My only goal here is to not assume that the 
> number portability databases and processes will automatically 
> become the ENUM databases and processes.
> As a result, I start with the assumption that number 
> portability is purely a TDM mechanism that affect routing in 
> the TDM domain.  But, then acknowledge that certain 
> information may bleed over and be acted on in the IP domain.

This is probably a fair assumption to make.  However, simply because the
endpoints may not be IP-based, does not mean that the data/addressing
cannot be queried for over IP or that such data can be distributed via
IP networks.

The motivation on my part grew out of a desire to consolidate both
on-net and off-net TN lookups into a single DNS query that hits my ENUM
server.  Some vendors are (creatively) starting to propose methods of
doing so (to carriers at least) that are vendor-specific (aka
proprietary).  As a service provider, I have an interest in trying to
standardize this so that I have more potential software providers to
choose from, more competition, innovation, etc.  I then have a open
standards-based method for querying for any addressing info associated
with both on-net and off-net TNs (not-IP-based, or not IP-based that I
can route to), as well as distributing such data around my IP network,
etc. since it all uses DNS and ENUM.

> But, there have been others that have suggested that somehow 
> the ENUM registration change needs to be dependent on the 
> number portability change, and I don't think that is 
> necessary.  If ENUM can do it in one day, while NP takes 
> several weeks, no sense in anchoring ENUM down.

This should not in any way slow down or conflict with various national
NP processes.  

Jason Livingood

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 25 Jul 2005 16:06:48 -0400

>process or the Number Portability process to make the change in the

It is not decided yet how this works in practice

This is the discussion about the so-called carrier-of-record, and
will be defined nationally

It is my private opinion that basically no validation is necessary
if a carrier says he is hosting the number. Why should he cheat?

In User ENUM it is commonly agreed that the best validation method
is that the carrier hosting the number is approving that the end-user
has the right to use this number.

Now if the carrier wants to do the same in carrier ENUM why not trust him now?
What would be the incentive to enter number in Carrier ENUM he is not hosting?
the calls would be routed to him and what then?

Carrier ENUMs already implemented use this trust principle

Of course if a process for NP is in place and Carrier ENUM is implemented
in or near e164.arpa, the existing mechanism could be used to include Carrier
ENUM also.

>progress.  I found all the SIP+E2U versus E2U+SIP IANA registration

As I stated in my previous posting, there are many Enumservices
using tel: URI already. in addition there is fax:tel, mms:tel, sms:tel, etc

Yes, it is confusing and you are not alone ;-)

>another.  Are there any assumptions being made here?

You may route such a call to any PSTN-GW, but then the
rn info is meaningless, so you could as well remove it.

Only if you route it to a PSTN GW in the country,
an then you just save the GW another NP dip.

As Rich pointed out this is basically for the US
and here everything is national anyway ;-)

The real benefit of this Enumservice is IMHO that
you may no use Carrier ENUM as the real NP Database
by querying the DB also from the PSTN via an IN  SCP-mediation

-richard

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 25 Jul 2005 17:12:22 -0400

Oh, I was trying to clarify whether 
"you may *no* use Carrier ENUM"

was "not" or "now" in my over-eager response.

I am hoping that ENUM works faster than the current NP.  It seems to be
taking weeks for my home number under the old system.  We shouldn't just
put lipstick on an old system.

Mike

> Sent: Monday, July 25, 2005 4:48 PM
> Cc: Stastny Richard; enum at ietf.org
> >>As Rich pointed out this is basically for the US and here 
> everything 
> >>is national anyway ;-)
> >>
> >>The real benefit of this Enumservice is IMHO that you may no use 
> >>Carrier ENUM as the real NP Database by querying the DB 
> also from the 
> >>PSTN via an IN  SCP-mediation
> >>    
> >>
> >
> >Yes, the ENUM can *now* replace the current NP database system.
> >  
> >
> 
> Ah ...well.. <cough> no.  You cant replace the NPAC ..but you 
> can provide service providers some new options on how to use it.
> 
> -- 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 26 Jul 2005 09:00:26 -0400

Understood and acknowledged.  I will figure out an appropriate way to
note this in a subsequent draft of this I-D.

Jason 

> From: Ray Anderson [mailto:ray at bango.net] 
> Sent: Tuesday, July 26, 2005 4:22 AM
> To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey
> Cc: enum at ietf.org; Stastny Richard
> Subject: RE: [Enum] Fwd: I-D 
> At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote:
> >Agree completely.  I think I hinted at the idea that the 
> E.164 number 
> >could terminate in either the IP domain or TDM domain and still be 
> >included in ENUM.
> 
> Just for clarity, there will be ENUM's (E.164 numbers) that 
> DO NOT terminate in either IP or TDM domains.  They are used 
> purely for "non-voice" purposes, and allocated by an E.164 
> "delegator" for such purposes. 
> 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 26 Jul 2005 12:23:14 -0400

Ray wrote:
>Just for clarity, there will be ENUM's (E.164 numbers) that DO NOT
>terminate in either IP or TDM domains.  They are used purely for
>"non-voice" purposes, and allocated by an E.164 "delegator" for
>such purposes.

Just for my personal enlightment, could you please give me
some examples of these numbers and also
expalin what a "delegator" is?

-richard

Von: Ray Anderson [mailto:ray at bango.net]
Gesendet: Di 26.07.2005 10:21
An: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey
Cc: enum at ietf.org; Stastny Richard
Betreff: RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt

At 01:22 26/07/2005, Michael Hammer \(mhammer\) wrote:
>Agree completely.  I think I hinted at the idea that the E.164 number

Just for clarity, there will be ENUM's (E.164 numbers) that DO NOT
terminate in either IP or TDM domains.  They are used purely for
"non-voice" purposes, and allocated by an E.164 "delegator" for
such purposes.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 26 Jul 2005 14:37:52 -0400

That gives me an idea of what you meant.  But, note that these do
involve interaction channels that do involve the PSTN and GSM networks,
and may be adapted to ride over IP networks.

Mike

> Sent: Tuesday, July 26, 2005 12:59 PM
> To: Michael Hammer (mhammer); Ray Anderson; Livingood, Jason; 
> Richard Shockey
> An example might be Mobile TV.  A Broadcaster might make a 
> number point to a URL that in turn contains information that 
> causes the terminal to connect to a video-stream
> which  might be coming over DVB or DAB.   Would that be a 
> suitable example?
> 
> At 15:13 26/07/2005, Michael Hammer \(mhammer\) wrote:
> >Ray,
> >
> >Although voice is a first killer app, it is not the last, so I 
> >understand the "non-voice" part of your comment.  Could you 
> elaborate 
> >on the "non-IP" part?
> >
> >Mike
> >
> > >
> > > "non-voice" purposes, and allocated by an E.164 
> "delegator" for such 
> > > purposes.
> > >
> 
> 
> Ray Anderson   T:+44 7768 454545    F:+44 20 7692 5558
> ray at bango.com
> 
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 26 Jul 2005 14:58:20 -0400

Kevin,

"needs to be synchronized"  Could you elaborate on what this requirement
means?

For example.  Let's say I contract with a VoIP provider to port my
number to them as my service provider.  Let's say also for argument's
sake that I have a WiFi-based phone as well as the old analog phone
connected to the PTT.  Can the VoIP provider register my number into
Carrier ENUM immediately and have calls from other VoIP callers directed
to my WiFi phone immediately, along with all its features, without
waiting on the PSTN bureaucracy to provision the number as ported in the
TDM network?  (Note I recognize that TDM callers will be delayed and
calls may still route to my old phone.)

I suspect I won't like the answer, but it might make glaringly obvious
how much room for improvement there may be to this porting process.
Wonder if we can get it down to less than one day (Web time).

Mike

> From: McCandless, Kevin [mailto:KMcCandless at verisign.com] 
> Sent: Tuesday, July 26, 2005 11:53 AM
> The NPD is authoritative and therefore the source for routing 
> on ported numbers.  This information can be replicated in the 
> IP space but needs to be synchronized to the one in the TDM 
> side ie the NPAC.
> 
> Behalf Of Michael Hammer (mhammer)
> Sent: Monday, July 25, 2005 7:22 PM
> To: Livingood, Jason; Richard Shockey
> E.164 number could terminate in either the IP domain or TDM 
> domain and still be included in ENUM.
> 
> My concern about tying too tightly to NP was when I heard 
> suggestion in other fora that ENUM add things like CLLI codes 
> and other TDM elements, as well as anchoring ENUM to NP 
> administrative processes.  I may have misunderstood what was 
> proposed, but it seemed headed in the wrong direction.
> 
> Mike
> 
> 
> > Of Livingood, Jason
> > Sent: Monday, July 25, 2005 3:50 PM
> > > I suspect that some 20 years in the future we will have something 
> > > called the PSTN, but it will not look anything like the TDM
> > network.  
> > > My only goal here is to not assume that the number portability 
> > > databases and processes will automatically become the ENUM
> > databases
> > > and processes.
> portability is 
> > > purely a TDM mechanism that affect routing in the TDM 
> domain.  But, 
> > > then acknowledge that certain information may bleed over
> > and be acted
> > > on in the IP domain.
> > 
> > This is probably a fair assumption to make.  However, 
> simply because 
> > the endpoints may not be IP-based, does not mean that the 
> > data/addressing cannot be queried for over IP or that such 
> data can be 
> > distributed via IP networks.
> > 
> > on-net and off-net TN lookups into a single DNS query that hits my 
> > ENUM server.  Some vendors are (creatively) starting to propose 
> > methods of doing so (to carriers at
> > least) that are vendor-specific (aka proprietary).  As a service 
> > provider, I have an interest in trying to standardize this 
> so that I 
> > have more potential software providers to choose from, more 
> > competition, innovation, etc.  I then have a open standards-based 
> > method for querying for any addressing info associated with both 
> > on-net and off-net TNs (not-IP-based, or not IP-based that 
> I can route 
> > to), as well as distributing such data around my IP network, etc. 
> > since it all uses DNS and ENUM.
> >

---

From: "McCandless, Kevin" <[email-masked]>
Date: Tue, 26 Jul 2005 16:15:34 -0400

Mike comments in line

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer at cisco.com] 
Sent: Tuesday, July 26, 2005 1:58 PM
To: McCandless, Kevin; Livingood, Jason; Richard Shockey
Cc: enum at ietf.org; Stastny Richard
Subject: RE: [Enum] Fwd: I-D

Kevin,

"needs to be synchronized"  Could you elaborate on what this requirement
means?
 <KM> Yes, if NP records are placed into other databases, ENUM, then
those records need to be synchronized, updated, when changes are made in
the NPAC associated with the TN.  If not, then you will have NP data in
ENUM that are no longer valid.  The authoritative source is still the
NPAC for all ported numbers, (US specific in this discussion).

TDM network?  

<KM>Yes, but if the call originates from the PSTN then you still have
the time frames for processing a ported number. But for on Net to on Net
calls you should not have any delay, theoretically ;-)  In reality, 99%
of VoIP originated calls are dumped onto the PSTN (US again).  Ooops  

Mike

---

From: "McCandless, Kevin" <[email-masked]>
Date: Wed, 27 Jul 2005 08:55:29 -0400

That might work in your neck of the woods but not over here.  

-----Original Message-----
From: Michael Haberler [mailto:mah at inode.at] 
Sent: Wednesday, July 27, 2005 12:19 AM
To: McCandless, Kevin
Cc: enum at ietf.org
Subject: RE: [Enum] Fwd: I-D

At 17:53 26.07.2005, McCandless, Kevin wrote:

>The NPD is authoritative and therefore the source for routing on ported
>numbers.  This information can be replicated in the IP space but needs
>to be synchronized to the one in the TDM side ie the NPAC.

If an NPD exists. If - like over here in the fixed network - the NP
process 
uses onward routing and just local information exchange & keeping by
donor 
and recipient carrier, a Carrier ENUM register will eventually become
the 
defacto NPD.

-Michael